Developer info to improve scheduler

The simple scheduler used now (mainloop) will be improved so latency of some high-priority actions is improved. So we can


See the priority ideas on GenBoard/UnderDevelopment/FirmWare (TODO: delete from there)

Even though it is relatively simple, it's a good idea to model it in JAVA first (see package org.vemsgroup.firmware.scheduler in JTune CVS) to verify operation (and maybe tune some variables).

Similar scheduler is implemented in most real-time operating systems.

See task-states on an [an x86 RTOS].

However we don't need preemptive multitasking. Cooperative is fine. So no need for separate stack for each process. When the process returns, it's stack is back to normal anyway. Timing sensitive tasks must be done in interrupt or high-priority process.

A nice OS with non-preemptive multitasking running on the atmega16 (gpl and compilable with avr-gcc) can be found here []

Non starving scheduler - actually max 1 queue (prio3) can be allowed to starve

Runnable conditions

If scheduler does not see softelapsed type runnable conditions (because conditions are hidden inside the functions, so the scheduler itself does not see them; the conditions hidden in the functions can still be there and result in some functions decide themselves to not take their turn and return without doing much), that means we basically have 2 queues (prio3 is definitely meaningles than)

The simplification in STABLE1_1 from the Ultimate solution is that we cannot tell by a quick look if there is sg. runnable in prio1 or prio2. We just execute something that has it's turn, that can have it's own condition (eg. softelapsed()) and might not do anything.

In general lack of the knowledge of "explicite" (known by the scheduler) "runnable conditions" of tasks in a queue makes any lower priority queue of little use.

The trick of if ( not much time passed since time_old){ might be a simple yet efficient way to know if we have a free slot right now to execute sg. from prio3(). Not exactly the same condition as "if prio1 and prio2 has no runnable at all", though.

TODO: meet the EEPROM-write requirement

can probably be met as well.

That allows any number of upto 16x16 tables (psychological benefit...);painless, 0 overhead switching to alternative (95-98 octane) fuel ignition-map, etc...

The rx21 rip (already in STABLE1_0) allows easy addition of individual (per table) RPM and MAP ranges for each tables.