Another method is to have a counter for each task and when a task is dispatched it down-counts its task counter and executes when the counter expires. This allows some process tuning. You can even have the interrupt or another task jam load this counter if you are careful to state map the possible result.

In fact I was using this scheme within a timer interrupt for precise timing. In interrupt routine I decrement counters and decide which function I should run or which event I should send to main(). So I can run critical code in interrupt context with 0 delay and non-critical code in main() in idle time.

This works, but you should be carefull that total run duration in one scheduler-tick not to exceed the scheduler-period.

In fact, the main driving problem to use a real task mechanism with this mechanism is its distributed nature. You should divide your task to multiple parts if you're waiting some events. Say, if you need to wait for 2 secs inside a task, you should divide it to two, and run the last part in a timer interrupt. You come to, say, 3 tasks from a single task.

In fact I would be using this mechanism again but the power of the UC to be used made me thinking about the advantages of using an OS. The code will run a 8051 derivative from Dallas which can reach up to 50MIPS speed.

Again, thanks for your enlighting comments...