Scheduling of primary pulsewidth and timing calculations

Official FreeEMS vanilla firmware development, the heart and soul of the system!
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 »

This may be more for my general knowledge than anything, but as I understand it, interrupts cannot be interrupted by anything equal to or lower than their own priority, but will be paused if something more important comes in, allowing you to put things in an importance order. Perhaps you could even self-interupt when you realize (wow, I have a fueling event coming up, need to calc some stuff) though I think that's a stretch.
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 »

No, it's not like that, there is a scheduler for interrupts that at any time starts the most important one. Once started, its running to the end. Then the next one starts. At silly loads, I imagine that it could back up a queue and fail to operate correctly. Some bike guys will need to test that for us :-)
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 »

At least the rev limit in the main loop would never get to run. :-P

Hmmm, ok, so yeah - at best you could have a very short interupt which does the BARE essentials and triggers a lower priority inte.....
No, I guess not. Flag setting is about it. If only there were some sort of 80Mhz RISK processor to blaze through this handling....
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 »

You STILL have the same number of timers. So you are still bit banging, just faster at it :-)

i.e. our algorithms for banging now will transfer fairly easily to the new core when the time comes.

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: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

I just thought of another way to achieve the lowest possible latency of fueling/ignition calculations :

SWI : software interrupt
Instead of waiting till the start of each main loop iteration, just trigger it directly.

clear flag
because its not time critical, enable nesting of interrupts
do calcs

In this way it will run as often as possible as soon as possible, not hold up any other critical process, and run to the exclusion of other less important code at heavy high loads. sounds perfect. have to think about it a lot more though :-)

I've partially implemented a banked data set system where by things are reading from one set, and another is being worked on. This means you will always get the dwell that goes with your pulse width, and your key inputs will be data logged as a set, rather than random ones that happened to get updated sooner than others.

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 »

yes yes! I think that is what I was getting at - some way to run interuptable interupt code immediately after the timing has been recorded - which shouldn't be interupted.
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 »

Sure, but recording the time isn't enough, you need to go "oh, it's time to fire XYZ, lets do it" and then exit.

If I had my way those calcs would be in the wheel section, but, i don't think they will end up fast enough, and as discussed, that will be too slow at lower rpm also.

You could do it without the SWI on the end of the rest of your wheel code, just clear the bit and it can happen, but, thats the most important thing, and needs to be run first anyway...
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 »

OK, as it stands the code for this is run in the main loop, but that doesn't really matter much. I want to post up the semantics so that A I am clear about them and B you can criticise them, and C there is a record of what I have implemented.

Requirements :

The input data being used for a calculation remains constant during the calculation
The output of that calculation is not used until the calculations are complete
The previous output is used until the calculations are complete
While the calculations are being done, a second set of input data is being constantly written to ready for the next cycle of calculations

There are 2 lots of 2 sets of data :

2 x Input ADC readings
2 x Output from calculations

At boot up time, we want the data to be read straight into the first lot of Inputs and a flag set to say "calc it"
When the calc code comes across that flag it should swap the variable such that the second lot of Inputs are being written to
It should then use the first lot of inputs to write to the second lot of outputs
It should then switch the pointer to the outputs such that the latest ones start being read from and
Then set a flag stating that the outputs are now valid to be read from

In this way there are four states :

write to first, read from first
write to second, read from first
write to second, read from second
write to first, read from second

etc that get cycled through.

Additionally, because RPM is a large factor in the calculations, they should not be done unless the RPM figure is valid.
The outputs should not be used until after the first calculation. If the RPM is not valid, the calcs valid flag should be cleared.

Well, that's helped me clear it up in my mind, hopefully it helps you see what I'm up to :-)

I'll code that up and then knock out another release after I test it.

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: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

Implemented and functioning nicely, after I suss out ignition, I'll try to move it to a software interrupt. Does anyone think that is a bad or good idea?

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: Scheduling of primary pulsewidth and timing calculations

Post by Fred »

Admin wrote:Implemented and functioning nicely, after I suss out ignition, I'll try to move it to a software interrupt. Does anyone think that is a bad or good idea?
After reviewing how SWI works, I can tell you that this will not work. It is not implemented as an interrupt request bit that gets scheduled like the rest. Instead you do

asm("SWI");

and that code runs right now... even if it's inside another ISR... I.E. it's pretty much totally useless for this task. In consequence the "math" can stay exactly where it is right now.

This would have been nice if it had worked that way, BUT, doing it how I already am is very much the same in reality.

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