Whats a super fast Analog I/O Processor?

[Gumby83]

Hello friends, i am looking for some advice. I am 100% a newbie, but i just recently got interested in a specific project i have. so i have only been learning about electronics for 4-5 days. I had an electrical engineer helping with the basics, but it really wasnt his field. So i come to you fine folk with a few questions.   
 
First i have to discribe what i am trying to do, this is an automotive application so 12vdc, i am trying to take 8 injector signals for a set of high impedance fuel injectors (saturated circut style) and duplicate them to two sets of 8.   
 
The Engine control computer has +12v running to one side of all the injectors at all times, then fires them individually using a ground signal, that ground signal will be shorter or longer for more or less fuel depending on engine loads and fuel demands.   
 
The injector drivers in the engine control computer cannot handle 16 injectors, so i am going to try to build a logic board that has 16 injector drivers (transistors AFAIK) that will duplicate the original injector signal to two sets of 8 with its own power/ground supply. 
 
Lets call them "injector set A" and "injector set B". Idea is to have a 0-5v sensor determine when injector set A is in operation (0-2.5v) and when Injector set B is in operation (2.5-5v), however i need to have a crossover period of around 100ms (where both injectors are working together before shutting down the other injector set)   
 
Ideally with the lowest possible latancy. I would also like the ability to adjust when the crossover happens. The application requires high durability and if possible no risk of crashing or freezing. 
 
i enrolled in a PLC course to see if thats the right way to going about it, but it seems its more for industrial automation and the form factor of these PLC's seem to be more in line with server rack stuff. i intend on having a PCB board made with the required components once i know what components i should be looking at. I went to winsource electronics website and the sheer amount of components is extremely daunting, i am hoping maybe one of you could help me by pointing me at in the right direction of where to start learning. I appreciate your time!

[brucehoult]

Ideally with the lowest possible latancy.

Latency in single digit ns is easily possible.

A 4 stroke engine running at 10,000 RPM fires each spark plug once every 12ms or 12,000,000ns.

This is not "super fast". A 100 kHz 1970s microprocessor can do this.

[Gumby83]

Latency in single digit ns is easily possible.

A 4 stroke engine running at 10,000 RPM fires each spark plug once every 12ms or 12,000,000ns.

This is not "super fast". A 100 kHz 1970s microprocessor can do this.

This is great news, i didnt know if it was possible. i figured time recieving the signal, to time outputting the signal would add miliseconds onto the original signal. It sounds like i could ask for more even, would it be possible to delay the start of a signal on 8 of the injectors by a milisecond or two with any accuracy? Could the signal input be a ground? and could the microprocessor duplicate that signal on a output accurately like a repeater?

[cortex_m0]

i enrolled in a PLC course to see if thats the right way to going about it, but it seems its more for industrial automation and the form factor of these PLC's seem to be more in line with server rack stuff. i intend on having a PCB board made with the required components once i know what components i should be looking at. I went to winsource electronics website and the sheer amount of components is extremely daunting, i am hoping maybe one of you could help me by pointing me at in the right direction of where to start learning. I appreciate your time!

FYI, WinSource is a "grey market" source, known as a component broker. They buy surplus components, and re-sell them. Component brokers are a common way to be bothered by fake components, and are rarely enough lower priced to warrant the risk.
Engineers usually like Digikey & Mouser as a starting point.


There are plenty of automotive microcontrollers out there. When you say "high speed analog", and "automotive" I think about the Microchip ATSAMV7 family. That's a pretty beefy product (300 MHz ARM core, 64 to 144 pins, up to 2MB flash, up to 384KB RAM).

There is probably something lower end you could use. But if you want to minimize latency before all else, you should start with something big. If you find the ATSAMV7 can do the calculations in 20ns but 200ns would be fine, you could step down from the 300MHz part to something rated for 48 or even 32 MHz.

The application requires high durability and if possible no risk of crashing or freezing. 

The microcontroller choice has relatively little to do with this. There are automotive qualified microcontrollers out there, and you should probably use one. But the reason for "crashing and freezing" is almost entirely due to software problems.

[Gumby83]

Thank you Cortex, good food for thought here.. i am running into a theme here.. my interpretation of fast is vastly different then what some of these top notch microprocessors are capable of. I honestly would be really happy with milisecond or so of response time. I would like to try to keep this project on the cheaper end so maybe i can get away with a 32mhz microchip. Any brand recommendations? id like to find something that can accept 10-16 inputs,16-24 outputs and runs off 12vdc.

[ledtester]

... I am 100% a newbie, ...

1. Since it seems you are new to the world of microcontrollers I would start with an Arduino (either UNO or Nano). It's the simplest to get started with and there are tons of resources for teaching yourself how to use it and solve problems with it and it works just like other microcontrollers although others may be more capable.

2. Start with a smaller version of your problem - i.e. like monitoring just 2 or 4 injector sensors. When you've figured out what the microcontroller needs to do for your smaller problem you can worry about scaling it up.

3. Think of ways you can test your code without having to hook it up to the real hardware. You might have to use another microcontroller to simulate the input signals but if you're able to do this it will save you a lot of development time.

[ledtester]

First i have to discribe what i am trying to do, this is an automotive application so 12vdc, i am trying to take 8 injector signals for a set of high impedance fuel injectors (saturated circut style) and duplicate them to two sets of 8.   
...
Lets call them "injector set A" and "injector set B". Idea is to have a 0-5v sensor determine when injector set A is in operation (0-2.5v) and when Injector set B is in operation (2.5-5v), however i need to have a crossover period of around 100ms (where both injectors are working together before shutting down the other injector set)

After reading this I wonder if the injector signals even have to pass through the microcontroller. It seems that the MCU (microcontroller unit) will either cause the input signals to be diverted to either injector set A or to set B or both (for the 100ms crossover period) -- kind of like how a railroad switch determines which set of tracks a train will continue traveling on. If so, that aspect of the problem can be handled by other chips such as MUXes and/or buffers. That is, the MCU will never have to read or output the injector signals itself - it just has to read the 5V sensor signal and configure the MUXes/buffers to route the injector signals to the correct destination.

[Gumby83]

After reading this I wonder if the injector signals even have to pass through the microcontroller. It seems that the MCU (microcontroller unit) will either cause the input signals to be diverted to either injector set A or to set B or both (for the 100ms crossover period) -- kind of like how a railroad switch determines which set of tracks a train will continue traveling on. If so, that aspect of the problem can be handled by other chips such as MUXes and/or buffers. That is, the MCU will never have to read or output the injector signals itself - it just has to read the 5V sensor signal and configure the MUXes/buffers to route the injector signals to the correct destination.

I really like this idea! Just the crossover time i think would damage the ECU's injector drivers. they can only support 8 injectors at a time

[tooki]

After reading this I wonder if the injector signals even have to pass through the microcontroller. It seems that the MCU (microcontroller unit) will either cause the input signals to be diverted to either injector set A or to set B or both (for the 100ms crossover period) -- kind of like how a railroad switch determines which set of tracks a train will continue traveling on. If so, that aspect of the problem can be handled by other chips such as MUXes and/or buffers. That is, the MCU will never have to read or output the injector signals itself - it just has to read the 5V sensor signal and configure the MUXes/buffers to route the injector signals to the correct destination.

I really like this idea! Just the crossover time i think would damage the ECU's injector drivers. they can only support 8 injectors at a time

What is the limiting factor?

[Gumby83]

What is the limiting factor?

I think i misinterperated what Ledtester said, i was thinking he ment switching the original signal from the ECU injector drivers... its 3am so im tired lol. but the limiting factor in the ECU i guess is the size of the transistors they use to drive the injectors. I am not 100% sure, i am trying to find a broken ECU i can buy to disassemble and find out what they use specifically. but i am not willing to risk breaking a function one, too expensive.

[xvr]

Just the crossover time i think would damage the ECU's injector drivers. they can only support 8 injectors at a time

You can add transistors as buffers. In any case you will need them because MUX is a digital ICs and they can't directly commutate ground based signals from input to output.
You can use Analog MUXes, but they have to commutate signals to loads outside of PCB and with unknown characteristics. It could be tricky, so digilat MUX + output transistors will be better and more robust.

[Berni]

Using a MCU is pointless here unless you want to actually on the fly modify the injector timings using a mapping or something.

Just treat being pulled to GND as an input signal and use that signal to turn on some transistors that pull a output signal to GND on the output. This way you make a "signal repeater" in just discrete transistor logic. Then you just need to add an AND gate in between to enable or disable the bank of outputs. Once you have that you just need to generate the two enable signals for each bank. This is easily done by implementing a delayed turn off circuit (can be a diode capacitor resistor combo) for both enable signals. To finish it off we just need to create the two enable signals from the input of "A or B", we can do this by just inverting the A signal to get B. Then to create the A signal with the 2.5V logic you want to have we use a analog comparator to compare the input against a 2.5V reference voltage.

All this sounds like an odd way to do it tho. If you really wanted to smoothly transition to the other injectors you would actually want to slowly reduce the duty cycle time on one bank and slowly increase the duty cycle on the other bank. Doing this would get complicated using just analog circuitry, so this is where you might use a MCU.

[Gumby83]

You can add transistors as buffers. In any case you will need them because MUX is a digital ICs and they can't directly commutate ground based signals from input to output.
You can use Analog MUXes, but they have to commutate signals to loads outside of PCB and with unknown characteristics. It could be tricky, so digilat MUX + output transistors will be better and more robust.

Thank you for this! lots to learn in this post.

[Gumby83]

Using a MCU is pointless here unless you want to actually on the fly modify the injector timings using a mapping or something.

Just treat being pulled to GND as an input signal and use that signal to turn on some transistors that pull a output signal to GND on the output. This way you make a "signal repeater" in just discrete transistor logic. Then you just need to add an AND gate in between to enable or disable the bank of outputs. Once you have that you just need to generate the two enable signals for each bank. This is easily done by implementing a delayed turn off circuit (can be a diode capacitor resistor combo) for both enable signals. To finish it off we just need to create the two enable signals from the input of "A or B", we can do this by just inverting the A signal to get B. Then to create the A signal with the 2.5V logic you want to have we use a analog comparator to compare the input against a 2.5V reference voltage.

All this sounds like an odd way to do it tho. If you really wanted to smoothly transition to the other injectors you would actually want to slowly reduce the duty cycle time on one bank and slowly increase the duty cycle on the other bank. Doing this would get complicated using just analog circuitry, so this is where you might use a MCU.

What you said, about on the fly modifying injector timings would be ideal, The logic board would beable to determine RPM due to injector cycle rate and the 0-5v sensor i referred to is a MAP sensor, aka Boost pressure.   

I'd like to beable to adjust when the injectors swap over (what boost level) and the length of time there is a crossover. And as you said, it would be more ideal to back down the duty cycle of one set while ramping up the injector duty cycle of the other. But i dont think that would be possible due to the wide range of available injectors, flow rates/pressures and fuels. Also the ECU is the one that determines injector duty cycle based on the o2 Sensor readings and the injector information entered into the ECU (i'll include a picture showing the differences between the two i will be testing with). 
 
Once the crossover of the two injectors happens, it will run pig rich in a few cylinders before the crossover is complete. but the massive difference in flow characteristics of the two injectors will require specific injector tuning in the fuel table (VE) table. I can closely match fuel injector sizing vs fuel used.   

For instance, my idea was to run Pump 91 Gas on 83lbjr injector set A till say 10psi of boost, then the 224lbhr injector set B comes on. but its flowing Methanol. which requires about 2.3 times more fuel to hit stoichiometric values. So my original injector scaling would only be about 14% off. However, if i did something like run Race Gas through those massive injectors, my scaling would be off by 268%.   
 
This isnt a huge issue as even this scale can be tuned for, and since it only activates while the engine is at high load scenarios, it wouldn't effect any drivability or idle, i will include a picture of the specific area in the VE table you would see the methanol injectors operating in, this makes the fine level controls of the injector somewhat less important. 
I'd really like to beable to enter two sets of injector data, and have a fuel type offset so the injectors can crossover seemlessly. but the math and complexity of that is beyond my knowledge currently. although it would be super useful in the future which makes me think the MCU is probably the right choice since once the hardware is proven, i can work on the software long term.
 
I really appreciate the help, for every post i end up having to do 30-45 minutes of research just to comprehend whats being said which by itself is a huge help, i am learning about specific relevant components.

[EDIT] I just realized that i might actually be wrong about changing injector duty cycles via the MCU, if i can get the injector scaling between the two very close, its possible i could change the duty cycle of each injector. This opens up a whole world a possibilites, such as being able to reduce injector set A's duty cycle to 70% while running Injector Set B's duty cycle at 30%. this would be the truest sense of octane on demand. a 50/50 mix of pump gas 91 and methanol would have an effective octane rating of 105, exceeding the requirements for most enthusiasts. Thank you for the idea, it would not even have occured to me that it was possible.

[SteveThackery]

I'm concerned that for a "100% newbie" you are being far too ambitious. From the start of this thread to now your vision of what you want to achieve has grown by an order of magnitude.

There's a significant learning curve to climb from newbie to your most recent post.  What you should do is break the project into little tiny steps, and tackle them one at a time, thus moving slowly but surely towards your end goal.

Don't get carried away and try to do the whole thing in one go - it'll end in tears.

[Gumby83]

I'm concerned that for a "100% newbie" you are being far too ambitious. From the start of this thread to now your vision of what you want to achieve has grown by an order of magnitude.

There's a significant learning curve to climb from newbie to your most recent post.  What you should do is break the project into little tiny steps, and tackle them one at a time, thus moving slowly but surely towards your end goal.

Don't get carried away and try to do the whole thing in one go - it'll end in tears.

I agree whole heartedly, the software aspect of this project is going to be hugely daunting. i am laying out plans and potential future plans as to not have hardware limitations in the future. After i have a proof of concept, even if its just acting as a basic repeater, or rail road switch initally and i can successfully take a injector signal, and duplicate it to either set of injectors or both then My end goal is to understand enough i can talk with a electrical engineer or someone who can design/suggest a board for my application and a software engineer who can do the software side of it. I have no illusions that i will become competent in this field, i just need to understand enough to beable to discribe my goals to those who are while insuring there is nothing overlooked on my side (the engine/mechanical side)  There are issues i havnt touched on yet, such as the ECU is expecting a certain amount of draw from its injector drivers otherwise it will throw an injector fault code, i feel like its possible to trick the ECU by putting in something that has a similar draw to all high impedance injectors. but i still need to figure that aspect out before i can touch on it.

[Doctorandus_P]

Microcontrollers are more then capable to do a job like this, but it is a very bad choice for a beginners project. First, the environment when dealing with cars in a garage is much more irksome then an office (at home?) with a desk and a PC. Second. I guess there is a real chance of expensive damage though small programming errors, or the uC getting upset by EMC caused by the ignition sparks. When an ignition coil fires at the wrong time, you get the worst "knocking" in your life.

I also see an overlap with BLDC controllers. Even those are not a beginners project (I recommend you start with a few blinking leds on a breadboard, then extend to some simple IC's to get a "feeling" for microcontroller programming. With a BLDC motor, you have to fire the phases in sequence, and with the right timing. There are also all kind of Open Source projects (both hardware, PCB's and software) to get you started. Have a look into "SimpleFOC".

You may also want to have a look into engine control systems such as for example Rusefi:
https://github.com/rusefi/rusefi/wiki

[Berni]

Yeah this sort of timing critical code is not a good beginner project.

Not only do you need to write fast code (leading to needing to know how CPUs work) but it is also code that works very intimately the peripherals inside the MCU (so you likely need to write your own register level driver). To make things worse, real time things like this are annoying to debug and troubleshoot. So to for development you would likely need to also build a mockup test stand that runs it as if it was on a real engine by mimicking ECU signals, then need test equipment (at least an oscilloscope) to observe the signals while it is running.

Doing it with just transistors is easier to both develop and test. You can easily simulate the thing inside of a SPICE simulator. So you can get most of your design working on a computer(where you have much more flexibility to easily experiment with the circuit)

[Gumby83]

Yeah this sort of timing critical code is not a good beginner project.

Not only do you need to write fast code (leading to needing to know how CPUs work) but it is also code that works very intimately the peripherals inside the MCU (so you likely need to write your own register level driver). To make things worse, real time things like this are annoying to debug and troubleshoot. So to for development you would likely need to also build a mockup test stand that runs it as if it was on a real engine by mimicking ECU signals, then need test equipment (at least an oscilloscope) to observe the signals while it is running.

Doing it with just transistors is easier to both develop and test. You can easily simulate the thing inside of a SPICE simulator. So you can get most of your design working on a computer(where you have much more flexibility to easily experiment with the circuit)

I have no quams with trying something myself, even if the code is hot garbage and i have a massive amount of latancy initally. as long as i can prove its possible i have no issues hiring a smart fella to write the code on this project. I will definitely look into the SPICE simulator, it sounds like a great way for me to rapidly fumble my way through trying to learn lol. As for inital real world testing i will be using a set of injector flow benches, since they emulate the ECU's signal through a range of RPM. each injectors flow is measured at the end of the run as a real world measurement of fuel delivered. This allows me to test the box with real world injectors and known timing. for instance if i get 300cc's per injector in a test run without, then plug my project in and i see 250cc's i have an idea of whats happening. This will work well for initial testing. Once all is well there. its on to real world testing with a engine on a engine dynometer but thats all in the distant future right now.

[Gumby83]

Microcontrollers are more then capable to do a job like this, but it is a very bad choice for a beginners project. First, the environment when dealing with cars in a garage is much more irksome then an office (at home?) with a desk and a PC. Second. I guess there is a real chance of expensive damage though small programming errors, or the uC getting upset by EMC caused by the ignition sparks. When an ignition coil fires at the wrong time, you get the worst "knocking" in your life.

I also see an overlap with BLDC controllers. Even those are not a beginners project (I recommend you start with a few blinking leds on a breadboard, then extend to some simple IC's to get a "feeling" for microcontroller programming. With a BLDC motor, you have to fire the phases in sequence, and with the right timing. There are also all kind of Open Source projects (both hardware, PCB's and software) to get you started. Have a look into "SimpleFOC".

You may also want to have a look into engine control systems such as for example Rusefi:
https://github.com/rusefi/rusefi/wiki

Your bang on, my initial testing wont be on a running engine but instead injector flow benches, i learned tuning through the school of hard "knocks" if you know what i mean lol. I did play around with a arduino like a decade ago, was fun. i used it to switch relays and water pumps on/off for... ahem... agriculturial purposes.... I wouldnt mind getting into it again as long as i am learning the same coding i would have to learn on a MCU used in the final project. But when you say you see overlap with BLDC controllers, what do you mean? with my idea i have 9 inputs (8 of them are injectors, one each) and one 0-5v input. each injector signal comes in seqence from the ECU with the correct timing. The MCU's job would be basically acting like a relay initally. With the inputs delivering the timing, sequence and duty cycle. It would just be relaying those signals and lengths initally. If you mean with altering injector duty cylces, could i not just take the original signal, and delay the start of it by a few miliseconds to reduce duty cycle or delay the end of it by a few to increase the duty cycle? Also, i have looked into the RuseEFI, its super cool, never played with it but the open source ECU's like Microsquirt which i have played with are really nice for the price. The big names like Holley, Fueltech and Haltech are really easy and packed with features but for guys on a budget who are willing to learn alittle, hard to beat the open source fellas. Especially when you go to a car meet and see someone with it, extra few points in the respect catagory for me.  I am looking through these Arduino boards and found the Arduino Mega may be the ticket for me.

[brucehoult]

I did play around with a arduino like a decade ago, was fun. i used it to switch relays and water pumps on/off for... ahem... agriculturial purposes....

I see. Watering weeds.

I am looking through these Arduino boards and found the Arduino Mega may be the ticket for me.

The ATMega2650 has a lot of I/O pins, yes. And probably more than fast enough for what you're wanting.

Around 10-15 years ago all 3D printers seemed to be using an Arduino Mega to control all the stepper motors and sensors and the nozzle temperature control etc. As well as interpreting the G-code, figuring out accelerations etc. Very much a real-time task.

There are much faster chips available now, but the Mega is still useful.

Also, I personally know the guy who did this and can connect you if that helps: http://freeems.org/

[Gumby83]

The ATMega2650 has a lot of I/O pins, yes. And probably more than fast enough for what you're wanting.

Around 10-15 years ago all 3D printers seemed to be using an Arduino Mega to control all the stepper motors and sensors and the nozzle temperature control etc. As well as interpreting the G-code, figuring out accelerations etc. Very much a real-time task.

There are much faster chips available now, but the Mega is still useful.

Also, I personally know the guy who did this and can connect you if that helps: http://freeems.org/

Thats awesome, i'd love to have his contact information. its still super early for me to talk to someone whos made a ECU. thats levels of magnitude beyond what i am aiming for or even able to comprehend at the moment. Once i have alittle programming under my belt with a proof of concept id definitely be interested in talking to him. As it sits right now i dont have enough information to beable to understand the keypoints i need to learn.

[xvr]

May be it's worth to split system in 2 parts - injectors multiplexing (with optional timing adjusting) implement in hard logic (in CPLD or FPGA), and control for it in MCU. This split allow to build robust system. MCU program can hung or behave in incorrect way (because of software errors), but it will not affect injectors - they will be controlled by simple hardware.
MCU program for automotive grade application is not a simple task, even for quite experienced developer. It requires a special development process, and coding itself is less than 10% of it

[tooki]

Would that maybe be an application for an MCU with a small amount of configurable logic, like the RP2040 or some PIC MCUs?

[radiolistener]

such projects should be done with special automotive grade MCU and firmware should be developed by very skilled software engineer developers and tested by skilled QA engineers team. If some newbie trying to do it on some arduino, in better case it will be finished with engine damage, in worst case it can lead to death of topic starter and passengers...