Any general discussion around the firmware, what is does, how it does it etc.
By punisher454
So I have a few extra uC's , black board, bluepills, mega 2560 and mega 2560 pro's, now a couple teensy 3.5's with tall dog breakout boards. I'm thinking about building a modular ecu with a seperate input and output boards (I etch boards at home). I like the teensy, and judging by the discussion on Josh's Saturday live chat, the teensy is the direction things are headed right now, but as has been stated on this board before by pazi88;

"Just be aware that you will quicly run out of pins with teensy"

I have need for 8x8 sequentiall, along with 8 more staged injectors. So thats already 24 pins (or 17 if the staged injectors are paired to the primaries and just get all their drivers enabled/disabled with 1 output pin).
So why not just drive these 24 (or 17) channels from an external shift register as 3 Bytes of data. It should only take 3 output pins to send it serially. With 100+Mhz processors surely sending 24 bits of data serially wouldn't be a performance issue would it? I was thinking this would also be an easy way to send a 5V signal to the injector drivers by just using one one 3.3 to 5v level shifter between the 5v shift register chip(s) and the Teensy. With the shift register operating at 5v I would think you might be able to use the vnld5090 dual igbt's, which apparently dont work well on 3.3v.

Anyhow, just something I was pondering today, I havent looked at the code yet to see if this would be simple or hard to redirect the injector and ignition bits to a serial output rather than individual pins.

I'm not a great coder at all, and last time I wrote any code to send data serially was 20 years ago on a pic using pbasic to draw a bargraph on a hd44780 2x20 character display. But I know that even on a really slow uC you can bit bang small chunks of data reasonably quick.
That's an interesting chip, obviously it's target application is a 4cyl, but yes I can see using two for a V8 will work fine.

Having another thought here. Maybe an Arduino nano as the serial to parallel decoder. Of course not as compact as the 33810, but I'm building a mostly through hole modular ecu anyhow.
Hopefully the SPI output will be easy to configure. It would be really cool to be able to map to a particular bit on the output data packets just like choosing which pin you map an output channel to.
By JHolland
It would be easier to implement with a conventional scheduler than with the current Speeduino code. You definitely don't need a Nano to decode, you just use a TTL shift register. The SPI on the MC33810 is primarily for diagnostics and for driving non-timing dependant loads, injectors and ignition would be driven through the parallel interface. However it is possible to use a shift register and maintain accurate timing. Use the UART in synchronous mode to clock the data out and then drive the load signal from the output compare pin.
All you need to do is have one byte of bitfields that correspond to each output, then when you schedule an output compare for the next event you update the bitfield with the next values and then send the data to the shift register. When the output compare hits the match value then the load signal is toggled and the 'pending' data is switched through to the outputs. If the load pin is driven directly by the timer then the accuracy is the resolution of the timer.
By punisher454
Thanks Eric for pointing me to that one, basically exactly what I was looking for.
And based on what I gather from the new DropBear design sending the Injector and ignition outputs over SPI should work just fine.
By dazq
punisher454 wrote:
Mon Jul 06, 2020 10:49 am
Thanks Eric for pointing me to that one, basically exactly what I was looking for.
And based on what I gather from the new DropBear design sending the Injector and ignition outputs over SPI should work just fine.
As was mentioned above the outputs are driven by parallel inputs, the spi can control the ouputs but is mainly for diagnostic and configuration.
The delay in data transfer would need tobe accounted for with any spi transfer if used.
I guess I misunderstood what I was seeing in the code when I was looking at it a couple days ago. Looked to me like when the 33810 was defined the injector outputs were redirected from the pins to elsewhere (I assumed the spi port).

This talk about a serial interface being slow has got me thinking that I should just try a test for curiosity's sake sometime.
I'll setup a micro (probably a teensy or something reasonably fast) and have it toggle a set of pins in sequence at a fast rate (simulate injector outputs at 8kRPM) and then replace a couple port pins with an SPI driven expander , such as the 23s17 at 10Mhz SPI and see just how much extra delay is incurred. Might be a bunch, or maybe insignificant.
I have some 23s17's on order, and maybe I'll get the chance to do a test in the next couple months sometime. I'll be sure to share any observed results.
By dazq
It's not that a serial transmission is slow but the time elapsed between when the sending device begins to send an update to when the recipient device makes the actual change.
Also remember that delay occurs twice, when you turn the output on and then when you turn it off.
Eg. With ignition timing you could compensate for the turn off trigger by starting earlier . The turn on delay would mean starting dwell earlier too.
User avatar
By Eric H
The delay is easy enough to figure out.
For SPI, it takes a 16 bit write to set one of the 8 bit output registers, plus 1 extra clock for the CS setup.
17 bits x 10MHz is 1.7us.
1.7us at 8K RPM is 0.0816 degrees. 360 * (1.7us/(1/(8000/60)))
Negligible delay if you have a 10MHz bit rate.
I2C running at 1.7MHz requires three writes for the same operation so 24 bits or 14.118us.
At 8K that's 0.677664 degrees. Noticeable but not the end of the world.
There will be overhead in setting up the data and the library overhead to push the data out over the selected bus but that should be irrelevant at the speeds that engines spin.
proyect ford zetec-e 2.0 16v

Wow! Awesome. Thank you

I have moved my design files to the more logical p[…]

If you have max coil primary voltage at 400V : -[…]

Problems loosing sync

normally it should be ok, but the output from anot[…]

Still can't find what you're looking for?