Puma board for FreeEMS

[nitrousnrg]

Well, here I am writing about something I'm still not sure I'll be able to finish, mostly because of my lack of time.
The official piece of hardware wouldn't fit the cars I'm used to see here, and given the large amounts of time dedicated to every decision, and that the firmware is pretty mature, I started to design my own hardware version.

It won't as flexible, robust, and tested as Jared's version, but I have a couple of cars that need a high performance EMS (higher performance than my EMS at least).

My main interests are:
* No CPU board.
The microcontroller is integrated in the board, mostly because the Adapt board is really expensive to me.
* USB
* Full SMD assembly.
In my opinion, if one component must be SMD, then why not make the whole board SMD.
* up to 8 cylinders.
Here, the bigger cars are 6cyl Fords or Chevys. V8s are really rare, but most of the 4 cyl turbo cars have a dual rail setup.
* Low Z driver.
Most of the cars are 4 cyl. The better ones (and, in particular, my uncle's car) are turbo, and have large injectors. My ECU doesn't have a low-Z driver, but I prefer to develop the driver for FreeEMS.
* Connector board
I don't want a flexible board, except for the connector.

Today (April 4, 2011) the board looks like this:


3D view


You can watch the development here
https://github.com/nitrousnrg/puma

If I can make it with big, differentiated (digital/analog/power) ground planes, the noise floor will be low.
Plus, this could be my career's final project, so I can find help from my professors, which in turn are quite friendly with open source projects. Keep in mind that all projects must be finished before june (2011 in my case;-). It's good to have a due time.

The idea is to have the latest progress I make, in this first post, as I've seen in other parts of this forum.
I still have to decide certain things, like the ignition circuits, wb lambda, etc.

Let's hope this has a good end :-)

[jharvey]

Cool and good work.

What's the plan for connecting this to the engine? Are you going with the connector card theory, with a separate PCB that resides below or above this PCB which will take these IO to the edge of a PCB? Perhaps you plan for circular harness CPC connectors, or other.

However you decide to get these IO out, I would like to recommend drawing it up in a DXF file. Most connectors will offer a CAD DXF file that can be opened with QCAD. There is a free (as in beer and freedom) version of QCAD, but you have to find the right one for the free (as in beer) version.

[nitrousnrg]

Hi, thanks for the support!

The plan is to have a connector board. Mostly because I don't know what good connectors are available. Another idea is that I'd like to make a connector board that fits the original EMS connector. Fiat Palio, Fiat Uno, Volkswagen Gol, and the Chevrolet Corsa are quite popular cars. Having a plug and play EMS could be a winner solution.

[jharvey]

Looks like I should have responded a bit quicker, you've moving right along on this, which is great to see. One suggestion would be to put the injectors and ignition silicon on one edge of the board. Such that the connector card can be attached with either a ribbon cable, or a line of wires. That would allow the connector card and processing card to be opened like a book for diagnostics / assembly. A large part of the reason why I didn't draw it this way with 1.0, was because we wanted the flexibility of including the ignition and injection in the same case, such that it could drive it all from one box. They were put on separate sides to help draw out the heat from the drive silicon. However since then, it's become a reasonable strong preference to use a lower power internal drive to drive an external OEM ignition driver. That approach really is the better approach, it help keep noise/heat out of the EMS.

[jharvey]

Some other notes, on the fuel pump drive, ect. You're using the same thing I had drafted in 1.0, or near equivalent. The CPU drives 10k, then 10k, then 1k then the MOSFET gate, a total impedance of over 21k. The 10k's were chosen to match the bandwidth of the 100nF C27 filter. I seem to recall the MCU output drive wants a total impedance of 1.6k. The higher the impedance, the less hard you drive the MOSFET, the less accurate your on and off times become. So trying to get that close to the 1.6k is desirable. To do this, the filter will need to have the values changed. I didn't update the print because I don't have a more accurate prediction. Also I don't know the exact characteristics of the rest of the circuit, so I figured I'd do it empirically after it was built.

A quick note about my net naming convention, I typically did something that made some sense to me, for example INDuctive General Power Drive 3 is net name ind_gpd3. Output signals were typically lower case, and input signals were typically CAP's. I see I also wrote IN on the inputs, so that was a bit redundant.

I see you removed the 74hc78's. Those allowed additional isolation of the ignition circuits, such that a voltage spike would take out a replaceable chip, not the entire CPU. Also it allowed inversion of the signal which can help prevent issues on some rare configurations. That chip would also change the drive impedance so an attached filter would likely need adjustment to work correctly. In your case, those are probably mute points, as it appears you have a specific and slightly less generic approach.

Looks like your above picture doesn't currently match the files in git hub. Not a huge deal, I just noticed it and thought I'd mention it.

Keep up the good work.

[nitrousnrg]

Good ideas. Anyway, I'm stuck until we know which is the final pinout of the micro. If it stays like it is now, I'll have to rearrange the power part. Ignition will move up, injectors drivers will go down. Besides, I don't want the oscillator circuit near the ignition drivers.

Such that the connector card can be attached with either a ribbon cable, or a line of wires.

My idea of a connector board is a board not connected by a cable, but plugged onto the main board (like the stack made with the 1.0 and the adapt board). I don't like cables.

A large part of the reason why I didn't draw it this way with 1.0, was because we wanted the flexibility of including the ignition and injection in the same case, such that it could drive it all from one box. They were put on separate sides to help draw out the heat from the drive silicon.

And I agree with that. My aim is to drive the coils directly from the EMS. I want to have 2 options:
*Drive the coil(s) directly. (in my car)
*Drive a CDI. (in my uncle's car)
So I'll probably need a good dissipation for the ignition driver too.

Summing up, the analog part is almost ready, crank/cam circuit too. I need to lay out the ign & inj driver, locate the fuses and improve the oscillator circuit.

I seem to recall the MCU output drive wants a total impedance of 1.6k

Thats a huge tip, thanks a lot. Do you recall where the MOSFET filter has been discussed? No one taught me to put a filter in a digital line, please instruct me :-)

A quick note about my net naming convention, I typically did something that made some sense to me, for example INDuctive General Power Drive 3 is net name ind_gpd3. Output signals were typically lower case, and input signals were typically CAP's. I see I also wrote IN on the inputs, so that was a bit redundant.

Okay, I'll try to follow it (I'm bad at namings)

I see you removed the 74hc78's. Those allowed additional isolation of the ignition circuits, such that a voltage spike would take out a replaceable chip, not the entire CPU.

Oh, thats a good explanation for it. I think I'm going to take a chance with my board. If the crappy PIC I use at work can handle 220Vac in an I/O pin, then why not this automotive-grade IC :-).
Reading the datasheet, it says that I/O pins are clamped to VDDs and VCCs. To me, that means that I don't care if there is a voltage spike, as long as I can limit the current generated by that spike. I took that from a Microchip's application note, with a 5Mohm resistor between the pin and the AC line, the IC can be a zero crossing detector.

Looks like your above picture doesn't currently match the files in git hub. Not a huge deal, I just noticed it and thought I'd mention it.

hmmm, I pushed it up again, just in case I didn't :-)

[Fred]

There shouldn't be a filter on digital OUTPUT lines, only on inputs. The outputs could be rail protected, but otherwise, just the 1.6k current limiting resistor is required on outputs. In terms of drive levels and switch times, it is important to drive logic level autofets hard, but if you're not using logic level autofets then you must use an actual fet driver. For the record, 1.6k is derived from 20mA per 8pin port and full short to ground from 5v or vice versa. You could, and MegaSquirters regularly do, go lower than that, but I don't recommend it.

As for the 74hc parts, it is likely that those may be part of official freeems hardware compatibility compliance in future once the pin out is made more solid. Some of the pins have a switch on blip, potentially long enough to charge a coil etc. I don't want any box with my name attached to it (however indirectly) exhibiting MS like behaviours. Once we figure out which pins do what, why, and when, we can start to nail all of this down.

Another thing not discussed and not currently implemented is that FreeEMS hardware compliance is likely to require constant cpu power and some other power input pin connection to allow good hot starts and other "time since last run" variables.

I assume that you realise that you'll need a BDM port on each board? And that you'll also need a BDM to program the SM and/or firmware into the chips? I'm sure you did, but I thought I'd better point it out.

As for firmware maturity, it still needs some scheduler code and better/decent wheel decoders written. The serial interface needs to be finalised and polished up. Generic features need to be added. etc. Given your time frame, if you can keep the pinning flexible for a while, it seems reasonable that the firmware will mature enough in time for you.

Of course, much of the above does not apply if you fork and hack your own versions of the firmware, but it would be much sweeter if we could all keep using the same one, just configured differently.

Fred.

[jharvey]

I seem to recall the filter for both analog and digital circuits was posted by Fred from a fellow who drew it on a piece of paper. So it's a picture, and a bit hard to search for.

The search option won't let me search for 1.6k, I did find the below links via this google search.
http://www.google.com/#hl=en&source=hp& ... 5a0cce78cd

Fred talks some about the 1.6k and 1.2k here.
http://www.diyefi.org/forum/viewtopic.p ... 2&start=10

More detailed here, includes the 100nf cap used for digital and analog filters / EMI protection, ect.
[edit]
http://www.diyefi.org/forum/viewtopic.p ... 5&start=30

More talks about it here. [/edit]
http://www.diyefi.org/forum/viewtopic.p ... &start=160

There we go that was the picture I started with. I seem to recall it switched to how it's currently drawn for some reason, I see this digital used a 10R. I seem to recall this discussion continued else where in this forum, and we settled on the current drawn design, then Fred pointed out the 1.6k issue, so it needs to be addressed again. I seem to recall this filter was used to prevent EMI emissions, squelching issues at the source. The digitals are relatively low frequencies, this filter would chop off frequencies higher than like 1MHz or something reasonably high like that. That may conflict with Fred's above post. Also the resistors worked for current limiting, and the diodes helped prevent OV conditions. There was concern that the - tolerance is listed as -.2v, yet the diodes noted will conduct closer to .7v. I seem to recall a .2V diode was found and suggested somewhere.

PIC's are largely used in consumer products like the X10 module where they are directly connected to the power mains. They come with some very beafy diodes for that connection to the main power. I believe that most other MCU's do not have diodes that are that over built, and I would recommend avoiding relying on them. Replacing the MCU is a pain.

[nitrousnrg]

Thanks for the links, I want to know the why of everything here :-)
I'll keep the capacitors on the outputs as long as they don't add significant lags.

I assume that you realise that you'll need a BDM port on each board? And that you'll also need a BDM to program the SM and/or firmware into the chips? I'm sure you did, but I thought I'd better point it out.

Crap! I overlooked it. The last microcontroller I used came with a bootloader preloaded in ROM, and you can flash it using only the serial port. Sorry, my bad.

Another thing not discussed and not currently implemented is that FreeEMS hardware compliance is likely to require constant cpu power and some other power input pin connection to allow good hot starts and other "time since last run" variables.

Just a thought:
That switch on blip (damn, it took me a while to figure what it means :P), would happen only on the startup... if we keep the microcontroller constantly powered on the blip won't happen every time (btw, is the blip mentioned in the datasheet?)
I'm thinking about how often I have to reconfigure the radio clock, that would be the same frequency of pin blips, or am I wrong? If FreeEMS doesn't tolerate one accidental coil charge per month(s), then it will have the buffer for sure.

The digital I/O pinout can be left for a while (not forever, tough), but I took the liberty of reallocate the analog inputs. I consider that that pinout can be easily configured in software, while it was pain to route according to Jared's schematic. I hope you agree on that one.

Fred, I want the board to be "FreeEMS compliant", so I'll agree on most of your recommendations. Just let me argue on some points, I need to know everything happening in the board.
See me as a member of the team, I want to see FreeEMS completed. My problems are a not-so-vast experience, not much free time, and a crappy slow english, I hope you can bear with that.

[jharvey]

That switch on blip (damn, it took me a while to figure what it means ),

I don't think I fully understand this issue, or why the buffer helps prevent it. Can you explain this a bit? Right now I believe it means that when the chip is started the datasheet notes certain starting conditions specifically whether a pin is driven high/low/float. Then at some point after the MCU has been started, but before the firmware has finished initialization, the pins have some potential to wonder. I can guess that they could wonder because a tristate could allow some energy through, but that's just a guess, and I'm not sure why the buffer would help. Perhaps the buffer would add some hysteresis such that a floating pin wouldn't typically trigger until it's actually driven, or perhaps it would load down the pin such that some stray electrons wouldn't cause the circuit to activate. I don't fully understand. Please feel free to elaborate.