DIYEFI.org Forum

Sorry if these are super noob questions.

I need some advice on fuel injection firmware I'm currently developing. It is just simple batch injection at the moment. Ignition spark triggers an interrupt and I can choose how many ignition sparks there are for every engine cycle. Currently I am calculating RPM every crank revolution, is this correct? Should I calculate RPM every spark event? Does it really matter?

Also, I can choose how many injection squirts I want per engine cycle. Should I calculate injector pulse width every time before injection occurs or every time RPM gets calculated? Or once every engine cycle?

Hope that makes sense lol

Crazy,

Don't think of everything as sequential. (not fuel sequential, but code sequential)

Think of it as multiple processes going on at same time. Here are some simple/basic ones:

P1) Reading of Analog Sensors
P2) Reading/Filtering of Position type inputs, crank/cam triggers, other rpm related inputs
P3) Filter readings/Calculate parameters such as IAT,CLT,MAP,MAF,ect.
P4) Calculating Pulse Width

Obviously with unlimited processor speed you could do ALL readings/filtering/computations in super scary fast sub-picosec interrupt....Hmm, not going to happen with today's current hardware, so construct your code to do the things that need to be fast occur where they need to be and the slow things can happen elsewhere. For instance:

p1) Sample all the a/ds and store off in a variable. Don't filter, just grab data and store. Most likely an interrupt here, but some could be in main().
p2) Same for the rpm information. Grab the current time between pulses of each input and store. If enough time to filter & calculate RPM, do so. Otherwise just store. Depending on your hardware, you can setup an input capture to do most of this for you.
p3) Filter the readings, many you can filter in main (such as coolant temp that changes slow), others you may want in interrupt such as MAP,MAF. But regardless, even if you don't filter in the latest/greatest reading in time, your filtered value setting in a handy variable is ready to use by any other process at any other time.
p4) Calculate the pulse width based on all the filtered variables you calculated above. Some will have been sampled/refreshed as recent as the last interrupt, others will be slower. The key is that this process doesn't has to happen at the same time as the other processes. For calculating pulse width, you only need to do this once/per cycle. Any more than that is superfluous. Technically, if you had a really slow micro you could do it only every two cycles, or three, or four, ect. but now you're missing opportunities to be more accurate.

Hope this is helpful to you.

Lenny

If you want to do a good job, there's more to it than the above, and indeed, some of the above is wrong, but the general principals are sound enough.