Who was complaining about lack of outputs on ms2+v3 ???

[Xtatic]

There is a little puzzle i was playing with recently, motivated by claims that we don't have enough outputs for sequential on our MS2+V.3 hardware.

Here are the puzzle pieces:

1. http://www.technologicalarts.ca/catalog ... cts_id=357

2. s12c chip on ms2 daughter board has SPI needed for piece #1
http://www.coe.montana.edu/ee/rlarimer/ ... 128_V1.pdf

3. tracing pins revealed that the 3 needed pins for SPI (SS, MOSI, CLK) are same as the LED outputs (or spark outputs A, B, C in case of extra) and MISO is not needed.

4. http://jbperf.com/p&h_board/index.html
to drive the injectors

5. use another part like in #1 for seq ignition, SPI slave (inj or ign) is selectable with one spare output

6. VB921s to drive ignition

Now who's brave enough to try this and write firmware for everyone?

Note that this little addition can be completely off the V3 board (just like the VB921 ignition additions everyone is doing here), so the B&G licence is not violated.

[devojet]

A shift register like that would be too slow to handle the timing needs required to controll injectors and ignition.

[AbeFM]

My only thought was a shift register like that would be GREAT for things like my fans, variable intake runners, clutch pedal in (can it do ins?), shift light, water injection, etc. Anything that happens on a time scale of a hundred milliseconds (probably ten).

This would free up the faster, native, I/O I'm using for those functions now. Think it could handle 100 hz (i.e. PWM boost and idle solenoids?)

[6040solder]

Nice work Alex! it would require some messing around in code for sure, but definitely a good idea for ms2 users that are a bit IO short. Most of us? lol

Now who's brave enough to try this and write firmware for everyone?

You? :-p

[devojet]

Sorry I must have miss read your post, I thought you ment use that chip for ignition and injector outputs. Your right it could be used for the other non critical outputs to free up ports. For inputs try searching for Parallel to serial converters.

[Keithg]

But this still does not have hardware PWM.

KeithG

On Jan 10, 2008 4:57 AM, devojet wrote:

Sorry I must have miss read your post, I thought you ment use that chip for ignition and injector outputs. Your right it could be used for the other non critical outputs to free up ports. For inputs try searching for Parallel to serial converters.

[Xtatic]

A shift register like that would be too slow to handle the timing needs required to controll injectors and ignition.

yes, i was suspecting this could be a problem (just being optimistic here )

if the reaction speed is indeed not fast enough (i am in process of researching about how fast the reaction will be with this chip), this delay, if it's constant (and i suspect it is, as i am sure that the amount of data to transfer through SPI for a single change in the parallel output and clock pulses are always the same for any combination of parallel output), which means we can just measure and factor in the delay into the code if it's not very large and indeed consistent. (i think ken and james do this delay correction already in their firmware, for ignition anyway)

[Xtatic]

But this still does not have hardware PWM.

KeithG

bit banging?

[Xtatic]

here are some more resources i found about shift registers and 74HC595 in particular for those who are curious.

http://homepages.which.net/~paul.hills/ ... ister.html
http://www.circuitcellar.com/library/de ... c99cd4.asp

according to this, the parallel outputs can be 'strobed' at the end of 'state loading'.
Translating to our case, this means that the output configuration is sent through SPI before the actual event (let's say changing state from firing only injectors #1 and #3, to add firing injector #2), then when we need to start firing #2, we send a strobe through another dedicated line and the output configuration (i.e #1, #2 and #3 firing in our case) will be latched instantly.

So the only problem i foresee is the time it takes to 'load' the parallel output config through the SPI. We need to have sufficient time to do this loading in between the strobes (i.e changing output states)
Now if i could only calculate the time needed for this state loading.

EDIT: according to one guide it seems that it'll take around 0.2mS to transfer a byte through an SPI providing the clock is around 15MHz (200k baud). Is this too long? (that's less than an opening time even for LowZ injectors)

EDIT2: from further research it seems that indeed the data transfering delay will be around 0.25mS with 12Mhz (1/2 clock divider set on the mc9s12c for the SPI).
I've calculated for my 6 cyl @ 8krpm, the period between events will be around 2.5mS. The phase of the injector opening is not as critical as the duration (just look at batch inj systems where phase isn't even accounted for), i.e an injector can be opened and closed X time earlier or later, as long as X is reasonably small and duration of being open is fixed.
Duration can be set accurately with the instant 'strobe' signal (insignificant delay i imagine). We just need to guarantee the ability to "strobe close" an injector at an exact time and not interfere with 'state loading' for some other event (for instance an injector opening just an instant before another injector having to be closed in time).
I imagine we can beat this possible "collision" by predicting that the "injector #x close strobe" is coming soon and simply shift the "just before" 'inj #y open' event to happen at the same time as the "close inj #x strobe". Then, later, close the inj #y accordingly to maintain the overall duration.

Upshot: the important thing here is that one can maintain the injection pulse duration precisely, with some imprecision in commanding the phase for each injector, which is not very critical with resolution of 0.25mS with SPI clock set to 12.5MHz.



The problem of undefined state of the outputs on power-up is also solved (see the links above)

[6040solder]

cool :-)

[AbeFM]

I guess I don't know how the PMW stuff works on the regular board. But if you have control anywhere *anywhere* near what it would take to run injectors (at least millisecond accuracy), then you could certainly run an idle valve.

60 hz idle valve means 16ms/cycle. To make a 2% change to that, you only need accuracy to 300 us.

Maybe that is too fast, but I bet not?

Anyway, I don't know about you guys, but the I/O I'm hoping for falls into two categories: Low speed digital I/O, and low speed ADC. Maybe a bit of D-to-A if I can get it.

But mostly the MS handles the high speed stuff I need (sure, I have dreams of staged injection, but it's not nearly as realistic), - what I find myself limited on is turning things on and off. The car, in OEM trim, has higher idle targets when the AC is on, or the power steering pump is under load. Easy to implement, and I would be happy polling that at 10 hz.

[Keithg]

But this still does not have hardware PWM.

KeithG

bit banging?

Which is why I am looking for a hardware PWM output. Don't know why for sure, but the bit bang PWM in MS2/E is limited to 1% increments at 100 hz.

KeithG

[Xtatic]

Which is why I am looking for a hardware PWM output. Don't know why for sure, but the bit bang PWM in MS2/E is limited to 1% increments at 100 hz.

KeithG

i am sure you can find a chip with SPI interface and PWM outputs.

[Xtatic]

so i've been thinking about it a bit more and somewhat concluded that J&K's every tooth decoder and scheduler code (let's call it ETDS) for ignition can be extended to schedule the sequential injection events to drive the gizmo i described earlier.

my train of thought:
first thing i did is analyzed the needs of the seq inj and looked at what ETDS already provides for spark.
The similarities are quite inspiring: both strive to align the "end of duration" event as precisely as possible in relation to the angular crank position. (seq inj likes it when PW is finished right before opening of the intake valve)
And calculate the "start of duration" in relation to the targeted duration itself together with the "end of the duration" point in time (i.e just maintain the specific time interval in between).
In ETDS's case it's predetermined ign adv angle and dwell, in seq injection it's angle at which intake valve is opening and the PW - both have to have a precise duration in terms of time and precise "end point" in terms of angular crank position.

Another thing to check is whether there will be enough timers for all that. (timers for the current 2 inj channels in MS can be reused as these channels won't be used anymore)

btw, i need people's input here. Especially Ken or James.

[jsmcortina]

Sorry, I'm not interested in this idea. By all means go ahead if you want to though.

I think you'd be better off getting the GPIO and communicating by CAN. The SPI pins are a clash with the existing spark outputs whereas CAN already has its own pins.

For twin CPU operation get the Sequencer as it will already have the required interconnects on board.

James