Configurable polarity of I/O

[Fred]

No CPU pin should be exposed outside of the case, everything should be buffered some way or other.

I agree. I was supprised when I saw the mS external ignitor mods shown here http://www.microsquirt.info/us_logic_level_spark.htm

LOL, yeah, no surprises there really. My ignitors are driven the same way too (shame on me) but I did it in a hurry and didn't have time to research a better way at the time.

Thinking about inputs again, the code for each type of setup will be different and separate so this doesn't need it at all. Generic wheel code can be written with it configurable and special stuff can be hard wired to suit the OEM setup. Let's keep the inputs simple.

Fred.

[MotoFab]

You can always use the tried and true 74HC01 (NAND) or 74HC08 (AND) gates to buffer the inputs and outputs. There are 4 gates per package so that's 4 Is or Os per gate package. Use one jumper for each nand or and gate to set polarity.

About the most trued and true thing in existence.

If you want more drive than a CMOS pin, driving relay coils for instance, use NPN or PNP, 6, 7, or 8 "transistor arrays". I think they are still commonly available as mixed NPN/PNP arrays.

If memory serves the sort of generic prefix for these parts is 'ULN'

- Jim

[Costa]

How about the 74HC367 for Ignition outputs.
Readily available http://www.jaycar.com.au/productView.asp?ID=ZC4872 (in Oz anyway)
A few on msextra.com have recommended the similar 74HC125 for external ignitors.

[Fred]

How about the 74HC367 for Ignition outputs.
Readily available http://www.jaycar.com.au/productView.asp?ID=ZC4872 (in Oz anyway)
A few on msextra.com have recommended the similar 74HC125 for external ignitors.

I like the part from Jaycar, it would perhaps be good to standardise all output pins on this chip or something similar? It would certainly save a LOT of discreets. It can also be used with a much lower current limit resistor on the output and therfore drive more substantial loads than the CPU pin could more reliably. It doesn't matter too much that they are unprotected as they are cheap enough and if current limited would only die from over voltage which could be diode protected just like the CPU pins.

For the inputs, I think the best approach might be an XOR chip like 74HC86. That way it is always populated and just configured to suit the particular setup.

I wonder if there is a high current buffer and XOR in the same package available? If so, that would be the best option (assuming availability) for the ignition outputs and others.

Fred.

[Costa]

For the inputs, I think the best approach might be an XOR chip like 74HC86. That way it is always populated and just configured to suit the particular setup.

I like the simple XOR approach. I'm leaning towards fixed input polarity as well now.

[Fred]

I like the simple XOR approach. I'm leaning towards fixed input polarity as well now.

It will speed up the code a little and simplify both the code and the configuration interface. Both very good things IMO.

Fred.

[MotoFab]

I like the simple XOR approach. I'm leaning towards fixed input polarity as well now.

It will speed up the code a little and simplify both the code and the configuration interface. Both very good things IMO.

Fixed input polarity to the uC makes sense, and fixed output polarity from the uC as well.

Many have voiced legitimate concern about users damaging their EMS board or their car due to incorrect configuration in the set up software.

Moving the configuration out of the software, and into the hands of the end user by way of configurable I/O buffers is a smart way to go I think. If something is damaged, it leaves no question as to the source. This is good for all concerned. It isn't a joke, though it may be funny, that the biggest benefit is that the end user knows where to look to find the problem.

Doing that serves two purposes. The input and output buffer gates or drivers, whichever type is settled on, buffers both the uC and the freeEMS effort.

- Jim

Edit

[gearhead]

I am sure everyone here has already thought of this, but with my current trials with an MS2 daughter card modification, it has become clear that this should be discussed.

Pin state during code load. Are they all hi or lo? Selected? Default condition?

Whatever we have for the injection pins, these should be gnd during code load, right? Ignition pins. If these are gnd during load as well, we can burn up coils. I think this is what MS2/E has as a default and why they say to disconnect coils.

A thought: If they must gnd during code load, we can have igniton drive type suggest a circuit construction for the drive circuits. For example, Lets assume that the code always goes hi to 'trigger', we can set the outputs to invert this if necessary for some ignition types.

Thoughts?

Gearhead

[Fred]

EDIT : This post and gearheads above were separate from this thread before. Now merged in.

Tut tut, not keeping up with the play ;-)

There were some discussions about this in another thread, but I've temporarily misplaced it. Found it http://www.diyefi.org/forum/viewtopic.php?f=41&t=365

Once you respond to this I'll merge the two threads and/or delete this post etc.

It belongs in general because it affects both hardware and software.

Fred.

[ababkin]

Not sure whether it was offered/discussed before (i looked), but why not think of implementing a smart polarity detector as a part of bootloader/firmware (do it on each startup, for instance)?

algo is something like this:
- assert default level as off
- quickly measure the current going through the ign/inj output
- make a conclusion as to whether it really was the 'off level'
- adjust to the 'real off level' if current detected (flip levels)
- write this info down into EEPROM


Alex