Configurable polarity of I/O

[Fred]

Hi, ca7 brought up an interesting point in another thread that I hadn't considered at all until now.

I/O polarity.

I suspect that we should be paying close attention to these threads while discussing this :

http://www.diyefi.org/forum/viewtopic.php?f=9&t=135
http://www.diyefi.org/forum/viewtopic.php?f=8&t=134

For input I can see some reasons for handling it, BUT, it IS a minor pain in the arse to handle AND it slows the code down. So, if we can make it something to be done in hardware, that *might* make sense, or for input it might not.

For ignition output I had been thinking about how to implement it super efficiently and failed to think of a nice way. It would be VERY nice for the code if we didn't do that at all. Further as illustrated in the other thread having the hardware setup not matching the software brings dire consequences. If the software is fixed, the hardware will be forced to be correct from the start or it simply will not work. Additionally (and I fully had not realised the implications of what I was saying) if we are to have a situation where during bootloader it isn't possible to burn stuff out, then either the wiring setup I've suggested would need to be adhered to and/or we need to fix the way the outputs work up front and not allow selection.

I can't see much of a problem with the ignition outs being fixed polarity as if you are driving coils directly then it will just be correct, and if you are driving them through external ignitors then you can easily insert a transistor to invert the signal.

On the input side for RPM I'm wondering if I could remove some code and speed and clean things up if we allowed configurable polarity in hardware by default. Just have a jumper for each input that selects inverted or not.

I know I always tend to this standardised inflexible way of doing things, but the general reason is a good one (standardisation of installs) and in this case I believe we have a very valid reason to not allow configurability.

Thoughts anyone? ca7, do you have anything to add/disagree with/agree with on this? Thanks for your post btw, most appreciated!

Fred.

[jharvey]

About the RPM input, if your using hall, I can see variation between NO and NC, so I can see that as an issue. The VR chip allows for inverting the polarity if required, but I'm not certain I allowed it. I'll check to see that I allow it, but will default to one way.

I think injector and ingnition drivers should be fine, although other chips might be say N vs P junction, and enhanced vs depletion, so perhaps other chips might want inversion.

Other resistive inputs like the bat sense, and temp, should be fine.

[Fred]

Hall sensors (as in the ones you actually use for sensors, not the hall effect element) are binary on/off in operation. Not only that, but the inputs on the CPU that handle RPM do not see voltage levels, only on, off and edges. It's just a matter of inverting the signal AFTER conditioning it.

What would you get as output if you fed a square wave into the VR chip? One would presume that you would get the same square wave out with it configured correctly. If that is the case, perhaps all signals should go through that chip just so that they can be inverted by it if required and also to keep things simple input wise. That way we only have two inputs and just the configuration of those inputs change. I don't know if this is feasible or not though. I hope so :-)

As for the other stuff, correct, battery and temps etc are not edge based anyway, so it doesn't affect them.

Fred.

[jbelanger]

The LM1815 triggers on a negative going zero crossing so you can't change the polarity and you can't use it with a non zero crossing square wave.

Jean

[Fred]

The LM1815 triggers on a negative going zero crossing so you can't change the polarity and you can't use it with a non zero crossing square wave.

Yes, I should have known that shouldn't I! Well, worst case we can put a fast op amp on each input wired to invert or bypassed.

Jean, do you agree in principle with the lack of invertible outputs? If you disagree, can you think of a clean way to minimally bit bang channels in an arbitrary direction based on config? I couldn't but I could just be having a mental block :-)

Fred.

[jbelanger]

I'm a bit ambivalent about this. On one hand, it's nice to be able to just tick one box in a tuning software to set the correct polarity but on the other hand that leads to potential problems (which can be serious as shown on the microsquirt forum link).

I can't think of a clean way of doing an arbitrary direction based on config. And having that applied when in bootloader mode is even more problematic. So, as much as I don't like the idea of having to have optional inverting hardware, I think that's probably the best compromise. You'll have to be careful when doing the first installation and if you swap ECUs between cars but that's very likely going to be much less frequent that firmware updates.

So that then means the board has to be configured to have optional inverting components for certain outputs. I don't think injectors will need it but ignition would likely need it as well as other generic outputs.

Jean

[Fred]

BTW, I have a functional setup for the inputs, but I don't like it much. I'd prefer to remove it if I had the choice. The outputs on the other hand would be a bit of a pain to do esp for ignition. For injection there may be an easier way, but off the top of my head I can't think of it.

I'm glad you agree, even if it's reluctantly.

Fred.

[jharvey]

Should we allow inversion by simply adding pads / holes for a 2n222? If you need inversion solder in the 2n222, if not, jump it out.

Or would folks perfer that the inversion be there no matter what, so that delay's are consistent.

[Fred]

Are you talking for the outputs such as ignition? Or for the RPM inputs? I think that is suitable for the ignition outputs AND as a bonus those outputs will need a buffer if used with external ignitors anyway. No CPU pin should be exposed outside of the case, everything should be buffered some way or other. I think that could be a good simple way to do it for the ignition pins but for some reason it strikes me as ugly on the input side.

Fred.

[Costa]

I don't think inputs need it. But if we go that way then we should set all ignition inputs to falling trigger. For VR the LM1815 output will not need inverting and for a hall input we could use a simple 2N2222 (or two for inversion).

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