Interrupt Priority Settings
Posted: Tue May 18, 2010 2:49 am
I had a thought last night about how to get the best accuracy on our bit banged fuel and/or ignition pins. Clearly we want the RPM input ISRs to run first and foremost in every case. The primary RPM and position measurement one should have absolute top priority with the cam phase detection stuff falling in as a lower priority ISR, possibly after some others of high importance.
Then what?
Well, for any given set of related sequential pins (ign and fuel) you require 2 interrupt pins - this is because as dwell or duration changes over due to whatever, the on and off points will cross over each other and the math and logic to do it would be tricky if not impossible to do quickly enough to keep ISR runtime low. Now, the trouble is, the on and off pins can't ever run at the same time, so when the on and off timing of two pins comes in at the same time, one will lag the other.
The thought:
Run the ON on the S12 CPU and the OFF on the XGate CPU!
That way the ON and OFF of some related pins can run at EXACTLY the same time! Sure other things can screw this up a bit, but with appropriately short code run times and appropriate interrrupt priorities setup, it should work very well.
For IGN the dwell end timings are critical, so those should be on the fastest interrupts with the highest priorities. The dwell start timings are NOT critical and should be lower priority - provided that they are early enough and not, on average, too early, we're golden.
For fuel, the period matters, so both ends should be accurate if possible. We could potentially stick with the 6 cyl sequential or at least 6 cyl hardware timed limitation. Or we could suffer a minor accuracy hit and just bit bang those too. In the latter case we'll be left with 4 spare timers and up to 4 spare input capture timers. These would be super handy for doing stuff like wheel speed and other high input rate stuff. I'll ONLY accept this compromise if the fuel accuracy is sufficiently good bit banging. If it's not, then we stick with the wasted spark style semi sequential fueling for the 8, 10 and 12 cylinder engines and run with sequential on 1,2,3,4,5,6 cylinder engines.
This thread is primarily for information purposes, but I'm open to comments and input from anyone on anything.
Fred.
Then what?
Well, for any given set of related sequential pins (ign and fuel) you require 2 interrupt pins - this is because as dwell or duration changes over due to whatever, the on and off points will cross over each other and the math and logic to do it would be tricky if not impossible to do quickly enough to keep ISR runtime low. Now, the trouble is, the on and off pins can't ever run at the same time, so when the on and off timing of two pins comes in at the same time, one will lag the other.
The thought:
Run the ON on the S12 CPU and the OFF on the XGate CPU!
That way the ON and OFF of some related pins can run at EXACTLY the same time! Sure other things can screw this up a bit, but with appropriately short code run times and appropriate interrrupt priorities setup, it should work very well.
For IGN the dwell end timings are critical, so those should be on the fastest interrupts with the highest priorities. The dwell start timings are NOT critical and should be lower priority - provided that they are early enough and not, on average, too early, we're golden.
For fuel, the period matters, so both ends should be accurate if possible. We could potentially stick with the 6 cyl sequential or at least 6 cyl hardware timed limitation. Or we could suffer a minor accuracy hit and just bit bang those too. In the latter case we'll be left with 4 spare timers and up to 4 spare input capture timers. These would be super handy for doing stuff like wheel speed and other high input rate stuff. I'll ONLY accept this compromise if the fuel accuracy is sufficiently good bit banging. If it's not, then we stick with the wasted spark style semi sequential fueling for the 8, 10 and 12 cylinder engines and run with sequential on 1,2,3,4,5,6 cylinder engines.
This thread is primarily for information purposes, but I'm open to comments and input from anyone on anything.
Fred.