Configurable polarity of I/O

[jbelanger]

I doubt TA will do anything about the bootloader because, as far as I know, they use the unmodified Freescale version. At least, that's what they did for the 9S12C32 which is also the same as the MS2 bootloader (at least originally). And Freescale provides the source code (in assembler). This might be the same code for all HCS12 CPUs with some defines and conditional compilation depending on the chip version. This is covered in AN2548. I haven't looked to see if the XDP is covered but it should be relatively straightforward.

Also, as soon as boards get done with the CPU on it instead of the TA board, the BDM will become necessary as well as the bootloader and the code can be changed easily (at least for the initial state of the pins).

Jean

[ababkin]

I doubt TA will do anything about the bootloader because, as far as I know, they use the unmodified Freescale version.

This is basically what Karl implied


attached is a scan of my analog-noob attempt at implementing the idea i described earlier. Perhaps people who dealt with op-amps can say if it'll work.

legend:
fat lines = high current lines
arrow pointing to + is actually connected to the hot side if injector/coil

comments:
as you can see, i've tried to use one op-amp per batch (one for ign and one for inj) as the polarity at each batch is the same. Each op-amp only takes it's neg feedback from a single driver in a batch

EDIT: for added power-on stability of this circuit, it needs a capacitor between the + and - op-amp inputs. (i.e we need to guarantee the op-amp starting with logical 0 level on the output, otherwise, for some cases, it'll send itself to logical infinity)

[Fred]

I have the code, and the original, and I've diffed them, and they aren't the same.

Whatever the pins are doing, it's enough to saturate a transistor and drive a LED hard on. That's enough to turn on other stuff too.

I agree that it won't change. I know we can do whatever once we start making boards BUT we need to standardise on something so the current bootloader (which I have an S19 of and code for) is how we should lay down our plans for the future. What is the point in having the new boards different to the dozen TA boards out there? Zero. Just standardise on the existing stuff and perhaps hope it doesn't change. I doubt they'll change it, and on second thoughts on that basis, the injector drives can be fixed polarity just fine.

I don't see how your diagram helps with users that need the IO inverted for their application.

Fred.

[ababkin]

I don't see how your diagram helps with users that need the IO inverted for their application.

Fred.

ok let me try and make sense of it:

(.. while looking at the diagram)

case 1: logic level 0 causes the output driver to saturate (conversely, logic level 1 closes it shut)
- upon the startup, assuming opamp puts 0 on the output, setting the driver inputs to 0 through the 'pull resistors' -> this causes the driver to momentarily open -> the potential on the '-' of opamp becomes lower than on '+' and opamp starts to raise the potential on the output. This happens (instantly) until the opamp output potential causes the driver to close shut

case 2: logic level 0 shuts the output driver (conversely: 1 = opens)
- upon the startup, same assumption as above, 0 on the output. The driver is shut at logic level zero, so nothing happens.

...so, the only problem is to guarantee that '+' and '-' potential are equal at start and that it's logic level 0 on opamp's output in the beginning.

Then, after bootloader is done and gives control to firmware, all it needs to do is to simply read the logic level at the MCU IO pin (which is pulled appropriately by the feedback circuit), save it and use it as default.
Once MCU sets the pin into push-pull - it overwrites the effect of the feedback circuit (assuming the right pull resistor values)

am i making any sense?
Alex

[Fred]

None to little. Because you are neglecting the need of the user to have either polarity at their discretion. I see what you mean, but... plus, what a bucket load of complexity for something that we are attempting to simplify and standardise.

Fred.

[davebmw]

OK if we are saying there are IO pins we can be 100 % sure are going to be one state or another during bootloader download? if so we can use this output to ensure that the Ignition and Injection relay drive is disabled.

building this simple safety circuit into the design would be cheap and easy all we have to do is make sure that pin changes state when we really want to enable the inj and ign drive.

Thoughts?

[Fred]

Sure, the bootloader switch pin itself is by definition guaranteed to be in a particular state. How is it that you want to use this to drive an output a particular way? Again, that seems like adding complexity to the system to force something that we could get more naturally. Other than the bootloader, barring a code change by TA ALL the pins are in a guaranteed state during bootload. It's just a matter of ensuring that that state means OFF in our circuits and that when our code is running it uses the same state as OFF and the opposite as ON. That way it's perfectly simple. Then it's up to the user to either invert or not invert the IO pins that they need to use. For the ignition we should provide that capability, for injection we don't need to.

EDIT, actually, even the bootloader pin state is susceptible to a bootloader code change so we definitely may as well just KISS it.

Fred.

[davebmw]

Fair enough!

[Costa]

At least 20 pins are ON and I don't have them all connected to be able to tell at the moment. Some of those are important pins. Either way, as I said, we can't guarantee the future bootloader code of TA boards so we should plan for that now.

The 74HC367 and similar line drivers have enable pins. We can put a NPN transisitor, controlled by a dedicated 'enable output' pin, between the enable and ground. Then we only have to worry about one pin being off in bootload mode. This output can be programmed to operate the same as the fuel pump relay for protection on stalls etc. when coils are not wired via the fuel pump relay. It can also be the same pin as the fuel pump relay output.

[ababkin]

None to little. Because you are neglecting the need of the user to have either polarity at their discretion.

If this works, the user is relieved from having anything to do with polarity - no jumpers, no check boxes, no fried coils and flooded engines, no figuring needed polarity out - it just works. You've formulated the problem, i've proposed a solution.

IMO 2xcyl# of resistors, 2 opamps and 2 caps, reading and registering the state of the feedback is not that complex.

Alex