Reserving pins for future use

From DIY contraptions to sophisticated FreeEMS-specific designs! Plus general hardware development!
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Reserving pins for future use

Post by KW1252 »

There are many pins left unused on the MCU in the FreeEMS project. Now, while it's easy to look at the schematics or the code and pick one, it would be a good idea to have an open discussion on reserving pins for future use, to keep the hardware from branching out into incompatible versions. Note that this isn't about features to be added immediately; at the first convenience would perhaps be more accurate.

First is a CAN wake-up pin. I've been sketching a CAN adapter board which may be useful in the future. Right now it's put into quiescent mode whenever the engine is not running, but there might be a need for the ECU to activate CAN on it's own later.

The other is for SPI. I don't believe an interrupt controller is needed, as ECU will most likely be the master unit in any given possibility. SPI needs a number of lines; MOSI, MISO, CLK and one Chip Enable signal for each SPI module. I believe however it's possible to make a sort-of addressing SPI by first sending an address message to a bus controller and then the actual message. This would allow to use only one pin for SPI addressing, while traditional methods require a bunch, even though decoders are used to create individual lines out of parallel binary numbers.

However, I'm only designing the modules, not a fork on the whole ECU system. I don't think it's my call for which pin goes where; are there any thoughts?
User avatar
Spudmn
LQFP112 - Up with the play
Posts: 232
Joined: Thu Feb 10, 2011 12:27 am
Location: Auckland, NZ

Re: Reserving pins for future use

Post by Spudmn »

KW1252 wrote:There are many pins left unused on the MCU in the FreeEMS project.
There are a number of pins that have no connection on Spin1.

I would like to request that all pins come out to a header for the connector board, or at the very least come out to a pad so that I can solder a wire on to it. I intended to use a lot of these pins in some of the features I have plained.
I know that some of these pads are hard to get to because they have tracks close to them but I am sure that it can be done with a bit of work.

KW1252 wrote: The other is for SPI. I don't believe an interrupt controller is needed, as ECU will most likely be the master unit in any given possibility. SPI needs a number of lines; MOSI, MISO, CLK and one Chip Enable signal for each SPI module.
+1. I will need, at the very least, a Chip Enable pin for my SD card data logging. Other pins I could use are for write protect and power enable
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Reserving pins for future use

Post by nitrousnrg »

I don't think all pins can be brought up in puma. Its very difficult to do so using 2 layers (and the bottom one is mostly intended for ground/thermal dissipation).

However, I want to route outside as much as I can, so I'd appreciate your inputs about which pins are the most useful.

For example, my first aim is to route the 4 unused ADC channels to the 40 pin header.
+1. I will need, at the very least, a Chip Enable pin for my SD card data logging. Other pins I could use are for write protect and power enable
Spudmn, using one of the 12 digital I/O from the 40 pin header is not an option?

The correct way to suggest and standarize pin usage is helping to update and complete this document :-)

https://github.com/fredcooke/freeems-va ... XDP512.ods

btw, I just added a 5v pin to the comms header
Marcos
User avatar
Spudmn
LQFP112 - Up with the play
Posts: 232
Joined: Thu Feb 10, 2011 12:27 am
Location: Auckland, NZ

Re: Reserving pins for future use

Post by Spudmn »

Spudmn, using one of the 12 digital I/O from the 40 pin header is not an option?
Yes I will use I/O from the 40 pin. I was just thinking that if you where going to change the SPI header it would make sense to add some I/O for chip enable etc.
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Reserving pins for future use

Post by jharvey »

I've been thinking of putting a SMT connector under the SX12, such that those pins can be used via connector card. However we don't know if the connector card goes on top, or bottom right now, so it's something that is being thought about.

I seem to recall that Fred has a pinout .odt file in the vanilla code source files. I'm not sure if it's been updated, but it listed pins and their potential uses. That is likely a good place to document the features your inquiring about. I would agree we should reserve a place for things like ion sensing, CAN, ect.

Have you seen the misc pins that were put near the MCU and allow access to a couple of the pins? I think it was 3 pins, and I think Fred has used one. Basically at the last minute in the layout, I helped Marco's put in a couple misc via's that allow you to solder a wire directly to what ever MCU pins we could get easily available.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reserving pins for future use

Post by Fred »

Firstly, I disagree with reserving pins in general. ONLY core functions should get exclusive use of any pins, and even then, if they aren't being used for core functions, they should be free for general use via configuration. Such a system will require some infrastructure which is not yet present, but is definitely the way to go, and also required to support external pins available for control or inputs over can or spi or i2c etc.

Secondly, the most useful pins are:

PWM
ADC
I2C/SPI/CAN/SCI modules
Interruptable pins

I'd REALLY like to see the PT6 and PT7 pins setup with XOR channels and FET/ign driver locations along that edge with the others, there is room for it there, and they are core pins, a shame to not expect them to be used, IMO. That would free up two more pins on the dil40.

The document that Jared mentioned that Marcos had already linked is fairly complete. It is there to list pin specifications and powers, and to show what is NOT available for various uses due to being a core function pin or having some property that doesn't allow it to be used in certain ways, etc. Whether the doc is up to date or not, who knows. More testing and coding is required before it is. At some point, someone should actually try to help me verify the behaviour on porta and the cause of it so we can finalise our hardware compatibility guidelines and make sure spin2 of puma is compliant or close to it and possible for spin 3.

Spudmn, perhaps it's best to refer to spin1 of puma with puma in your sentence unless in the puma section. It could become ambiguous later, that's all.

Finally, Jared, those vias are not easy to solder to due to the lack of pad on top and bottom. Can we get, at least the ones intended for optional use, surrounded by a bit of gold pad on top or bottom or both? That would make a world of difference. They are just the right diameter for a 1/4w resistor lead, but its hard to get a good connection on them.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Reserving pins for future use

Post by jharvey »

Fred wrote:Jared, those vias are not easy to solder to due to the lack of pad on top and bottom.
I'll see what can be done, I think they are easier to use than going direct to the MCU pin, so they will probably stay. I'll make them larger if we have the space, but it's really tight, and they barely fit as is, so I might not have much wiggle room.
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Reserving pins for future use

Post by nitrousnrg »

Fred wrote:I'd REALLY like to see the PT6 and PT7 pins setup with XOR channels and FET/ign driver locations along that edge with the others, there is room for it there, and they are core pins, a shame to not expect them to be used, IMO. That would free up two more pins on the dil40.
Now this makes sense. It didn't make sense when the board was intended for argy cars, but seeing that the board might be used worldwide, that should be done.

re the pin usage: I thought I was going to see suggestions in that file. Like "The default control pins for X module/board are a,b,c" or something like that. If someone implements vvti, maybe that circuit could be in more than one daughter board, so it would be nice to have a standar-ish way to conect external modules. Just a thought, if that odt isn't intended for that, its okay.

And, Jared is right, we're not sure if puma is going to be on top/middle/bottom of the stack. The SMT connector can solve the situation, that will be discussed soon :-)
I was just thinking that if you where going to change the SPI header it would make sense to add some I/O for chip enable et
Spudmn, it is doable, give me some time.
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reserving pins for future use

Post by Fred »

Now this makes sense. It didn't make sense when the board was intended for argy cars, but seeing that the board might be used worldwide, that should be done.
It still made sense even then as you don't want to limit yourself arbitrarily, and there MUST be some 6 cyl cars in argy land, even if not many. Not to mention that two more GPIO FETs would be useful to argies too ;-)
re the pin usage: I thought I was going to see suggestions in that file. Like "The default control pins for X module/board are a,b,c" or something like that. If someone implements vvti, maybe that circuit could be in more than one daughter board, so it would be nice to have a standar-ish way to conect external modules. Just a thought, if that odt isn't intended for that, its okay.
I agree that a guide on "design your accessory boards like this for best pin usage" is a good idea, mainly such that people don't waste valuable pins that they might want to use later for other things, but the main point is, we need some sort of pin abstraction / HAL to support things properly and cleanly and avoid a ms like mess.
And, Jared is right, we're not sure if puma is going to be on top/middle/bottom of the stack. The SMT connector can solve the situation, that will be discussed soon :-)
Urrr, que? explain?

Shall I move this to Puma as it's gone pretty off-topic for general hw?

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
KW1252
LQFP112 - Up with the play
Posts: 166
Joined: Tue Jan 15, 2008 5:31 pm

Re: Reserving pins for future use

Post by KW1252 »

I'll clarify myself a bit here. I don't want to reserve pins just for the heck of it, I agree on 100% that flexible configurability is the goal to go for. However, I do find buses for expansion (I2C, SPI incl. MMC/SD, CAN) core features, one that should be embedded on the board at some point. At that point having no generally agreed pin assignment for those functions is a great liability, not a benefit.
Post Reply