"Main Loop" Task Scheduling Algorithm Discussion

[Fred]

To handle many IOs while keeping time-critical non-interrupt things realtime (like the teeth counter/decoder for instance), we'd need to introduce concurrent loops with various priorities, etc. This increases complexity and introduces the risk of concurrency issues (like deadlocks, livelocks, racing, etc, and no you cannot test of even debug this easily)

Clearly you have some ideas on this, perhaps you would like to share them even if you think it's a bad idea?

Fred.

[shameem]

Engaging idle control based on RPM might lead to idle hunting and other instabilities i think - especially if an engine is tuned poorly and cannot rev past certain rpms. If TPS is a required sensor then idle control should be engaged on a certain TPS value... i think...

[Fred]

It depends what we mean by "idle control". Either way it served as a good example in this discussion.

If by idle control you mean PWM control, sure that could be bad, however if you mean "fix pulse width and timing to x and y" then the TPS RPM dual lock out is a good idea I would think. Perhaps other conditions too. We'll cross those bridges when we come to them :-)

Fred.

[Fred]

I was linked to this book :

Google Books - Embedded System Design

Which prompted me to search a bit and read up on it :

http://en.wikipedia.org/wiki/Scheduling_(computing)
http://en.wikipedia.org/wiki/Category:S ... algorithms
http://en.wikipedia.org/wiki/Round-robin_scheduling
http://en.wikipedia.org/wiki/Fair-share_scheduling
http://en.wikipedia.org/wiki/Deadline-m ... scheduling
http://en.wikipedia.org/wiki/Rate-monotonic_scheduling

Which got me thinking...

At boot time, we know from config what exactly will and will not run. We know how long each thing will take. We know how often we want it to run. etc. In the case where a block of code depends on some runtime condition like RPM < 4589 or something, there could be an else statement with a short sleep in it to balance execution time.

If we treat it like that we could calculate groupings at boot time with some slow heuristic and load the results into some runtime array that gets cycled through and adhered to.

Basically that fair sharing setup, but with per boot scheduling and then consistent running.

Period specific stuff like maybe PID idle code could be included and have a condition based on a clock that generates a flag each time it needs running.

Alternatively it could be generated by the tuning tool based on what is running and what isn't in our particular setup. That way boot up would be shorter, we have external non recompile control over various aspects of the scheduling.

If we didn't care about consistency, and only wanted minimum latency, we could just run through all tasks requiring running sequentially and do them if they need doing. flags set by clocks could take care of frequency and overheads would be minimal. Average and peak latencies would both be minimal, but latency would be unpredictable.

Well, we have a few plans to further consider anyway.

Fred.