OnlineCourse/Modeling/Scheduler (2005-04-15 08:40:14)

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 [ethernut.de]


Simple scheduler

Actually rather a task runner, since it just executes what was added with scheduler_add(). The operation solely depends on the conditions aroung scheduler_add().

<This was the one we decided to kill. We now are back at the original idea with 4 queue implementation. Look at scheduler.[c|h] in HEAD. Only main_loop uses this scheduler now, and it's just rescheduling itself immediatly after it has run.>

There are 3 queues that starve (unless scheduler_add() conditions are very tricky), while there should be max 1 queue that can starve.

scheduler_sleep() is putting the AVR to sleep. I think this is very dangerous, this is the easiest to get wrong. For battery powered systems it's worth it, but v3 consumes appr. 100 mA so we cannot save significant power. There are no scheduler_sleep in the new version. Sleeping was mostly for the emulator not running at 100% anyway.

Any task may re-schedule itself either by calling scheduler_add itself, or using the eventqueue to schedule itself sometimes in the future. Can I use the existing eventqueue for this?

We only set schedule flags from interrupt/eventqueue when we are there for other reason (eg. trigger, or action).

Otherwise userspace actions should not use interrupt for this. However if you feel uncomfortable to do many false comparisons (like softelapsed does), a second heap maintained from userspace is perfect. Just like eventqueue, but separate heap and actions from it are only executed when the scheduler thinks right (not asynchronously):

Resolution can be any. Proposed: 1 msec and 16 bit keys on AVR (32 bit on ARM)

Dispatcher actions are also independent. 16 bit is perfect, no need to spare clocks by using 8 bit values.

Yes, we discussed this on the IRC channel. It's not in the current implementation though.


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

Runnable conditions

If we don't use softelapsed type runnable conditions, that means we basically have 2 queues (prio3 is definitely meaningles than)

That gives us 3 useable queues.

The implementation would be trivial:\nÿ1ÿ