AVR Freaks

Soft delays are of no use in a (preemptive) RTOS but think about it - your tasks are being switched in/out on a timer (probably 10ms or 100ms or something) anyway so the simplistic way to get a task to delay() is simply to have it make some kind of "yield and now don't call me for N ticks" mechanism. So if the task wants a 150ms delay and your task switching tick is 10ms the task just needs to be "put to sleep" for 15 ticks. Maybe add a "sleep_count" field added to the TCB for each task and when one calls delay(150) you set sleep_count to 150/10 (where 10 is the tick rate) and then on subsequent scheduling ticks you just decrement any non-0 sleep_count fields and perhaps priortize things so that for any task where sleep_count makes the last 1 to 0 transition it is then scheduled in next.

For example see:

http://www.freertos.org/vtaskdel...

Again there's a lot of "prior art" on all this. RTOS prioritization is well researched. Look again at the FreeRTOS site - they have a walkthrough of the implementation and the one they happen to explain is the AVR one.

Ultimately you have a regular ticker interrupt and every time it ticks (typically 10ms..100ms) you interrupt and "put away" the task that was executing then you "unpack" and set up to continue running the next one in the list. The choice of "which one should I run next" is basically a question of prioritization.

One way to do that (for example) would be to have each task have a counter. When the timer "ticks" you decrement all the counters and any that hit 0 you then schedule in to run. You then reload the counter with a "priority" so the ones with the lowest numbers actually have a high priority. Say you had two tasks. One set to "priority" 3 and one to priority 7 then you start each with their max priority value: one set to 3 one to 7. Then ticks occur:
 

tick  1 2 3 4 5 6 7 8 9 10 11 12...

task  3 2 1 0 3 2 1 0 3 2  1  0 ...
task  7 6 5 4 3 2 1 0 7 6  5  4 ...

so the top task counts down its priority from 3 and when it hits 0 it runs and then sets the count back to 3. The other task does it with 7. As you can see the prio=3 taks gets more CPU time than the prio 7 one.

Of course this scheme is not great as there's some time slots where nothing runs so maybe you should add a rule that "if nothing hits 0 in a time slot go back round and decrement all their timers until one does.

Of course this could be affected by something like the delay thing I suggested above. If a task is in a "wait 10 ticks before you run" delay then that takes priority over anything affecting actual task priority. but when it's delay counter reaches 0 perhaps it's priority countdown should also be set immediately to 0 so it runs as soon as possible?

This is all just simplistic example and needs some thinking about but it just illustrates the kind of approach you could think about. Far better though is to search out the prior work on this. I'm sure there are examples codes, articles and books all to be found on the internet where "best solutions" are explored so I'd examine those first.

One fairly well known pre-emptive RTOS is called Linux and it has a ./doc/ directory that contains a lot of files that explain how various parts of it works. If that has something on how the task scheduling works I'll bet that could be a VERY interesting read!

EDIT: yup Google finds things like this: http://en.wikipedia.org/wiki/Com... and http://en.wikipedia.org/wiki/Sch... I'd then follow links there to find out more about what "fair scheduling" and things are.