Configurable polarity of I/O

[Brian]

This may be way off the mark but here goes:

I have a SPDT switch supplying power to the ecm, in one position power is supplied directly from the battery via a small fuse, in the other position the power is supplied when the ignition key is turned on. I use the "direct from battery" position whenever I connect to the ecm and do not need the engine running. It's not an "automatic" system but is very simple and effective.

[Fred]

I have a SPDT switch supplying power to the ecm, in one position power is supplied directly from the battery via a small fuse, in the other position the power is supplied when the ignition key is turned on. I use the "direct from battery" position whenever I connect to the ecm and do not need the engine running. It's not an "automatic" system but is very simple and effective.

No, that's a good idea, I intend to run a similar system myself along with isolation switches for various components so I can configure things to work different ways on the fly. We still need to protect the "consumers" (our fellow board members, our selves, and future users) from flooded engines and burnt out coils as best we can. I believe this thread is pointing in the right direction for that.

I have more replies to the posts before these, but haven't had a chance to formulate them just yet. Watch this space :-)

Fred.

[Fred]

For injection: Whatever the state of those pins during code load and the driver of choice determines if the circuit needs to invert. Since we are settling on an N channel protected FET for these (according to the schematic thread), if these pins are lo during code load, we need to do nothing. If they are hi, we need to invert this to keep the injectors off during code load regardless if they are powered by the fuel pump relay or not. The default for this drive circuit should be *off* unless the code wants fuel to be delivered and *off* should be defined as whatever the pin state is during code load.

Correct. The paranoid person in me wants to include an inversion driver in there anyway in case of bootloader code change in the future. That REALLY is paranoid though. The pragmatist in me knows it will be best to NOT have inversion capability on the fuel injectors and fuel pump relay. The staged channels are inverted during bootload, so those will need to have a NOT gate between them and the FETs, however that is on an expansion board, so not something to worry about at all now. So, let's not worry about bootloader changes then and not include any inversion for the 6 injector channels and the fuel pump relay drive (which I would like to see as a to220 part regardless).

For ignition: Similar. Since we are contemplating an N channel IGBT for this, we also do not want the coils charging (regardless of FPR action of connection). If these pins are hi during code load, then fine, If they are low, there needs to be an inverting circuit so that the IGBT is not conducting. If low, omit the inverting circuit. <DIV> If someone wants an inverted output (that is not driving coils directly) they can jump the output of this device (fet or bjt) to the ignition output they are interested in so that it gets to the correct pin on the connector.

The first part is fine up to where I inserted the red divider. Post that I disagree. I think external ignitors will be a common choice (10US per IGBT or 1US per ignitor from a junk yard that is more reliable and keeps the ECU free of noise and heat, obvious choice IMO). Thus we should handle this up front. The ignition outputs should have an XOR chip and/or current buffer designed in so people don't feel inclined to drive from the CPU directly in a hacky MS way. The CPU pins should NEVER be exposed to the outside world. For the injector FETs this happens by default, for ignition we should ensure it is the case and provide for the varying polarity demands of the outside world. If you are using the IGBTs, you can just jumper the chip, if not, you can install the chip and not the IGBT. It is way too much to expect users to pay for expensive IGBT devices just for inversion when they won't use them to their potential/value. So, for ignition I think we need inversion and buffer capabilities on board regardless. Additionally that paranoid part of me wants them anyway in case of code change, but that's just silly.

The reason the ign and inj are 'regardless of FPR' is because I do not want the injectors squirting or coils charging when I cycle the fuel pump on boot up.

I agree with doing it, but not for that reason. I think they should be relay isolated anyway. However a double layer of protection for those that wire it up with relays is good, and there will always be some rough bastards like you that don't wire it up like that

Am I still way off?

No, right on the money as usual :-)

Fred.

[Fred]

Something else that I just realised :

In the event that we decide to not support P&H then we should include an IC to buffer the CPU so that the external setups are driven with a good low impedance source. It seems like we might be going that way, so that will leave only the fuel pump drive unbuffered pre the main driver.

Fred.

[Brian]

Fred,

You can only go so far with protection. You can go to extreme lengths, but someone will still fry something anyway. KIS. This is an advanced EFI system? Then it doesn't need to be padded out with Vista-like cushions for newbies, IMHO. Same for the reverse-polarity input diode.

Brian.

[ababkin]

can someone please elaborate on the following
- inversion driver
- reverse-polarity input diode

and what good would it do for the problem at hand?

Also, Fred, did you miss my earlier post? Still waiting for reply.

EDIT: i've decided to move my proposed solution to this problem here:
http://www.diyefi.org/forum/viewtopic.php?f=42&t=384

Whoever is familiar with opamps, mosfets please comment/criticize. I need your input.

thanks
Alex

[gearhead]

The reason the ign and inj are 'regardless of FPR' is because I do not want the injectors squirting or coils charging when I cycle the fuel pump on boot up.

I agree with doing it, but not for that reason. I think they should be relay isolated anyway. However a double layer of protection for those that wire it up with relays is good, and there will always be some rough bastards like you that don't wire it up like that

But I do have it wired with a relay on both. It is only the fuel pump and ignition that are driven by the relay drive transistor. The injectors are powered by the 'key on' relay.

It is 'best', in my experience, if we have the fuel pump relay able to cycle on without cycling on the coils. So, if the fuel pump relay cycles on at boot as it should, it should not cycle power to the coils and injectors unless we know that those outputs are never on at boot. A fuel pump cycle is about 2 seconds and I would rather not have the ability to pressurize the fuel system and then discharge all 4 coils after it is done with its cycle. This is different from the state at code load, but related. I just wanted to be clear with my concern.

Gearhead

[Fred]

You can only go so far with protection. You can go to extreme lengths, but someone will still fry something anyway. KIS. This is an advanced EFI system? Then it doesn't need to be padded out with Vista-like cushions for newbies, IMHO. Same for the reverse-polarity input diode.

You have a good general point. The trouble is that even advanced users mess things up occasionally. Let me quote a passage from my favourite audio book :

Randy Slone - "an amplifier should be protected from any reasonable overload condition or external connection error. Mistakes can be made by anyone -- from the seasoned professional to the novice."

You are right though, we need to draw a line somewhere.

But I do have it wired with a relay on both. It is only the fuel pump and ignition that are driven by the relay drive transistor. The injectors are powered by the 'key on' relay.

So the injectors are susceptible to boot load state as you have it.

It is 'best', in my experience, if we have the fuel pump relay able to cycle on without cycling on the coils. So, if the fuel pump relay cycles on at boot as it should, it should not cycle power to the coils and injectors unless we know that those outputs are never on at boot. A fuel pump cycle is about 2 seconds and I would rather not have the ability to pressurize the fuel system and then discharge all 4 coils after it is done with its cycle.

The thing is, when you are priming the fuel pressure, the real code is loaded and in control, so the outputs will be as desired and intended, not random.

Either way, I think we agree on this :-)

Fred.

[gearhead]

Last version of the schematic showed none of this. How can/should we get this integrated?

Gearhead

[Fred]

We should finalise a localised design in this thread for the ignition channels (the others are OK as is) and when we have it, post in the schem thread as something to add to Jared's TODO list.

So, from all of this, all we need are :

XOR and/or buffer chips for the ignition channels

And maybe :

XOR on the RPM inputs.

We've been through some of the chip possibilities, can someone in the know post up the best option(s) for the ignition output buffer with invert?

The XOR for RPM can be an 8 pin 74 series 86 compatible unit such as the 74ACT86 which can drive 50mA on it's outputs. I guess that means it's ideal for ignition out duties too as that is more than some of the other parts listed earlier. Sweet, XOR = buffer = good to go.

So, do we want them on the inputs too? It will save people from forgetting to sort that out on a fresh code load, I hear you are a fan of that :-)

Fred.