PIT ignition scheduling code open design draft discussion

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

PIT ignition scheduling code open design draft discussion

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: PIT ignition scheduling code open design draft discussion

Post by Fred »

I should add that the initial schedule should contain an offset to account for latency, however because there is zero inter event latency for queued events, no further compensation should be required.

This compensation may need to be rpm dependent, or it may not.

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: PIT ignition scheduling code open design draft discussion

Post by Fred »

I guess my algorithm is perfect as there have been no responses. Either that or I'm on this board alone for now (till the hard work is done :-P). I suspect the latter.

Anyhow, I might give this a shot this arvo and see what I can get happening.

This algorithm does not allow for longer than 52ms - dwell retard from schedule tooth location. If we need that, more work is required. Not hard, but something to do. I doubt we will need it, but...

Admin.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply