PIT ignition scheduling code open design draft discussion
Posted: Mon Apr 28, 2008 8:55 pm
This is very likely full of holes and poorly thought through, so feel free to help develop the ideas where I have made mistakes and left things out and I'll try to continue on with it. When this discussion looks like it has an algorithm that works, I'll knock up the code, or finish off what I am working on along these lines.
Today I demonstrated that the PIT timers could indeed work and work accurately for this purpose. However because we are using two for all channels, they are limited to the angle of advance possible between two "schedule-from teeth". Compounding this situation the fact that dwell would also have to fit inside this window, and dwell is intended to be arbitrarily programmable (even in random ways).
Thus it seems to me that we need to have a queuing system where by if nothing is happening ign wise, the event is scheduled as per normal (as I did today, or similarly), however, if the timer is still running and enabled we need to queue the event.
If the timer isnt running, we schedule as normal, and when the code runs, if queue length is zero, disable the timer etc.
If the timer is running and the queue is of zero length, the new time offset should be loaded to the register directly, and a flag set to increment the cylinder number to fire (used to index an array of pin out masks), the queue length should be set to 1. When the code runs, it decrements the queue length from one, and leaves the counter enabled with interrupt on for the next time.
If the timer is running and the queue length is one or greater, the time should be added to the time buffer array at the appropriate index and the queue length incremented. When the code runs, it decrements the queue length, and if required loads the timer register from the buffer at the appropriate index.
That seems to cover it fairly well in three cases. Bare in mind, each schedule type may be paired with a different run type if that makes sense depending on how rapidly the engine parameters are changing.
Criticism appreciated, especially constructive criticism!
Rip it apart boys!
Admin.
Today I demonstrated that the PIT timers could indeed work and work accurately for this purpose. However because we are using two for all channels, they are limited to the angle of advance possible between two "schedule-from teeth". Compounding this situation the fact that dwell would also have to fit inside this window, and dwell is intended to be arbitrarily programmable (even in random ways).
Thus it seems to me that we need to have a queuing system where by if nothing is happening ign wise, the event is scheduled as per normal (as I did today, or similarly), however, if the timer is still running and enabled we need to queue the event.
If the timer isnt running, we schedule as normal, and when the code runs, if queue length is zero, disable the timer etc.
If the timer is running and the queue is of zero length, the new time offset should be loaded to the register directly, and a flag set to increment the cylinder number to fire (used to index an array of pin out masks), the queue length should be set to 1. When the code runs, it decrements the queue length from one, and leaves the counter enabled with interrupt on for the next time.
If the timer is running and the queue length is one or greater, the time should be added to the time buffer array at the appropriate index and the queue length incremented. When the code runs, it decrements the queue length, and if required loads the timer register from the buffer at the appropriate index.
That seems to cover it fairly well in three cases. Bare in mind, each schedule type may be paired with a different run type if that makes sense depending on how rapidly the engine parameters are changing.
Criticism appreciated, especially constructive criticism!
Rip it apart boys!
Admin.