Scheduling of primary pulsewidth and timing calculations

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

Scheduling of primary pulsewidth and timing calculations

Post by Fred »

Ideally what we want is the following :

Ignition timing :
calculation just before dwell begins to optimise dwell length for potential spark angle range
calculation done again while dwelling to further optimise spark angle with the latest data (mainly relative to where the crank currently is incase the rate of rotation has changed, but potentially to get a new spark advance for new environmental variables.

Fuel pulsewidth and to a MUCH lesser extent timing :
calculation just before starting the pulse such that intended length is close to accurate and start time reflects the most likely range of end times.
calculation again while the pulse is flowing as close as possible to the end to enhance the length of time that it is open relative to current environmental conditions.

Ways of doing the calcs :

1. Repeatedly do the same sampling, lookup, calculations in the rtc or main loop such that they are always the latest, and just use those values when scheduling things on the fly. I believe MS does this in all variants.

Pros at low revs, you have the data asap.

Cons you waste a lot of cpu time doing the same thing, at high revs, you get the data asyncronously or too infrequently (because of all the other stuff in the main loop)

2. Do it in a fixed location such as trigger teeth on the wheel input when you are about to schedule and schedule everything based on those calcs

Pros, consistent calcs with regards angle of sample/calc etc

Cons, depending on current pulsewidth and rpm you might be doing the calc quite far away from when you need it. At higher RPM where time is limited, particularly on high tooth count wheels, using an advanced tableless tuning system could render this method useless by being too slow and reducing max RPM for the system.

3. A more complex algorithm that does the calcs at different times and rates based on pulsewidth, rpm, delta rpm, etc such that at low rpm it is done just before required and at high rpm it is done less often (but more frequently due to the speed)

I think 2 is inherently worse than 1, but 3 if done right can be the ticket to the best DIY EMS out there :-)

I have some ideas on this, but I won't post them now as I've spent enough time today JUST on this forum and haven't touched the code at all.

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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by jbelanger »

Admin wrote: I think 2 is inherently worse than 1, but 3 if done right can be the ticket to the best DIY EMS out there :-)
I agree about the first part of the statement but I have my doubts about the second part. If you do 1 then you just do the computations over and over but if there's nothing else to do you're not wasting CPU cycles anymore than doing NOPs. I'm just afraid that if you do 3, you'll end up with an algorithm that will be very similar to ignition/injection timing computations which will be quite time consuming and you'll be doing those computations instead of the necessary ones and finally get fewer refreshes of the ignition/injection values then you would by just doing 1. Also, you don't want to be late with the update because then it's for nothing.

I'm looking forward to being proved wrong about the complexity of the computation required for 3 and in that case you're right that 3 would be better than 1.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

Yeah, it could be a no go thats for sure, but it's worth a shot.

The scheme could be to do main loop calcs at extreme rpms (both low and high) and in the middle where there is time, but its not too slow to be out of date by the time you need it.

A single flag could be set by the wheel code such that either it does it, or it is delegated off to the main loop.

In the middle, the code could schedule the calcs either on the same tooth that its required on, or an earlier one that there isn't anything else to do in such that its just ready in time.

As I was typing I thought of a scheme to make 1 MUCH better in terms of frequency of fuel calcs :

Different sections such that some stuff runs on every main loop, other stuff runs every second, third, 8th, etc.

Alternatively, the ADC's etc could just be sampled from the wheel code (this HAS to happen, or something similar to it) and a flag set saying "recalc required" that the main loop reads, clears, and performs calcs for. that way the latency between loop iterations is minimised such that it happens as soon as possible after its required/possible.

A combination of doing some things once every X loops and and the latter seems like a really good compromise if 3 doesn't work out for us (which it may not), but fast updates on fuel and ign are crucial to really good transient behaviour in my opinion, and syncronous sampling of all variables that matter is also important to minimise engine frequency based noise input.

Thoughts?

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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by jbelanger »

The idea of doing the computations only when the inputs have changed and as soon after they've changed is good. Like you say, reading the ADCs should be tied to the engine position so the computations relying on these should also be done at that time (but not in the IC ISR). So the use of flags in the main loop and some kind of hierarchy for the different computations so that they're done only when needed would probably optimize things in terms cpu cycles and refresh rates for ignition and injection data.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

I should really try to recall all that "lingo" that they were trying to teach me at uni years ago "hierarchy" you say, is that like an exception hierarchy, or hire an iraqi?

Well said, glad you agree :-) and to think, I type pretty fast, and I came up with that idea while banging out that post at warp speed :-)

Cheers,

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
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by AbeFM »

I liked method 3 originally, but what Jean was saying makes sense. At least with method 1 stuff isn't too late.

Doing "temp calcs every 7 loops, and pressure calcs every 4" is going to lead to weird beat cancels in cpu load. :-) I'd just make a list like:
air temp
pressure
air temp
gear
air temp
pressure
coolant temp
AC-on?
air temp

etc. And when you have time to do a calc, you do the next one on the list. This, coupled with the flags-on-change seems a good idea. To me, most of the wheel-sensors, etc, should have a delta - value that's acceptable (withing a reasonable range of the last sample plus it's derivative) then a mild interupt do deal with it if it gets out of hand. Therefore, if things are running well, you get a "30 counts in last loop", and if they go weird you get a "4ms became 8 ms between the last two teeth".


More on topic, for spark at least, the small amount of error in dwell time from starting just a bit early is no biggie. No need to recal right before turning on. A calc to turn off at the last second makes sense, with enough buffer to deal with possible interupts in between.


Admin wrote:Yeah, it could be a no go thats for sure, but it's worth a shot.

The scheme could be to do main loop calcs at extreme rpms (both low and high) and in the middle where there is time, but its not too slow to be out of date by the time you need it.

A single flag could be set by the wheel code such that either it does it, or it is delegated off to the main loop.

In the middle, the code could schedule the calcs either on the same tooth that its required on, or an earlier one that there isn't anything else to do in such that its just ready in time.

As I was typing I thought of a scheme to make 1 MUCH better in terms of frequency of fuel calcs :

Different sections such that some stuff runs on every main loop, other stuff runs every second, third, 8th, etc.

Alternatively, the ADC's etc could just be sampled from the wheel code (this HAS to happen, or something similar to it) and a flag set saying "recalc required" that the main loop reads, clears, and performs calcs for. that way the latency between loop iterations is minimised such that it happens as soon as possible after its required/possible.

A combination of doing some things once every X loops and and the latter seems like a really good compromise if 3 doesn't work out for us (which it may not), but fast updates on fuel and ign are crucial to really good transient behaviour in my opinion, and syncronous sampling of all variables that matter is also important to minimise engine frequency based noise input.

Thoughts?

Admin.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

It would probably end up looking like this :

{
if(fuel/ign calc flag set){
do fuel calcs;
do ign calcs;
}

increment counter

if(counter == 10){
counter = 0;
do lots of boring crap;
and more of it;
especially shift lights;
pwm updates for stuff;
and other junk that is so slow we just don't mind;
etc;
}
}

such that fuel calcs dont run most times and other crap doesnt run most times, but fuel calcs run asap.

in fact, to be even better, you want to minimise your maximum latency, the best way to do that is to group all the other stuff around such that on one iteration block 1 runs, and on the next block 2 ... block n ... block 10, and before each one the fuel flag is checked and that code run.
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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by jbelanger »

Admin wrote: in fact, to be even better, you want to minimise your maximum latency, the best way to do that is to group all the other stuff around such that on one iteration block 1 runs, and on the next block 2 ... block n ... block 10, and before each one the fuel flag is checked and that code run.
I agree. That's exactly what I was thinking as I was reading the first part of your message. You actually stole my idea before I even had it! :)

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

jbelanger wrote:I agree. That's exactly what I was thinking as I was reading the first part of your message. You actually stole my idea before I even had it! :)
Great minds etc :-)
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: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

Now that I have a greater understanding of the timing involved and latency and interrupt etiquette etc, I 199% agree with Jean about keeping all ISR code very very short. The fueling calcs will be done as discussed above on every main loop iteration IF they are needed, and NOT if they aren't so that the next main loop iteration comes sooner.

In fact, pretty much anything that can be passed off to the main loop with a similar flag should be. All that stuff can be kept neat and tidy with functions etc.

Before I didn't realise that interrupts could not be interrupted. It would be nice if we could get to a certain point in the ISR code and say "ok, interrupt at will now" and continue doing less important clean up stuff sycronously, but given that we can't, the best option is a flagging arrangement like that.

The only stuff that will be excessive and in an ISR will be decode and schedule stuff, but I *could* be convinced around to Alex's way of thinking on this yet. I've got more digging and playing to do to find out how bad that code will be and what RPM it can run up to etc.

I'm feeling really good about making this work sooner and sooner. Though, each time I say that, something pops it's head up in an ugly fashion :-)

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