View unanswered posts | View active topics It is currently Thu Oct 22, 2020 10:09 pm



Reply to topic  [ 31 posts ]  Go to page 1, 2, 3, 4  Next
Scheduling of primary pulsewidth and timing calculations 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Fri Feb 29, 2008 4:06 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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


Sat Mar 01, 2008 12:07 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Sat Mar 01, 2008 12:37 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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


Sat Mar 01, 2008 12:47 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Sat Mar 01, 2008 1:35 am
Profile WWW
Post Whore!
User avatar

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


Sun Mar 02, 2008 10:17 am
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Sun Mar 02, 2008 11:06 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
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


Sun Mar 02, 2008 5:14 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Sun Mar 02, 2008 10:12 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15369
Location: Home sweet home!
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!


Mon Mar 10, 2008 5:34 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 31 posts ]  Go to page 1, 2, 3, 4  Next

Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.