Your definition of RTOS may be different than mine. I called mine a background threaded tasker.

I use a reserved timer to fire at a set TICK count. When the timer fires, the interrupt vector branches to the tasker.

It has a RAM list of bytes representing tasks to which it will pass momentary execution during the interrupt interval if the task is active.

One reserved list code is for a task that is turned off, in which case a jump is created that loops the tasker to pick up the next item in the list.

As a task segment is completed, it returns to the tasker and the tasker works down the list until complete. It then restores the environment and releases the interrupt.

The tasker runs at a relatively low priority, but one thing it can do is trigger a higher or lower level software interrupt which I use for certain magic I won't discuss.

Its a little tricky getting use to writing drivers for a tasker. Its something beginners would not be quick to try.

Instead of using timing loops, which hog the processor down, instead you write phases of code that are threaded now and then to keep track of a process that may be running to completion in milliseconds or hours. The threads in a single task may pass back and forth to frame bits or bytes or may follow protocol logic of EEPROMS or IRDA such.

A task is not a single routine, but a list of entry points that countdown TICKS, activate its key controls, and then pass control to another entry point based upon timing or protocol phase.

In my system, the tasker handles all physical I/O in background and hands it off to foreground through flags and bytes. I've got higher level interrupts dealing with mission critical I/O that reside higher than the tasker, but they are woven nicely. In fact the tasker schedules a higher level software interrupt to process that high I/O regularly. Its quite nice. :)

Each task has an initializer which presets values for the task to run on the next TICK and then threads itself into the list. Likewise, a task often has a terminator that reports results to foreground via flags or bytes and then removes itself from threading on future ticks.

Most tasks don't run at the full TICK speed and so most of the time the only thing the threaded task does is a DJNZ back to the tasker. This way, it can count TICKS until it activates waiting milliseconds or hours or days depending upon the level of DJNZs.

Quick example, our EEPROM driver runs through the tasker. We can make sure that the write cycle time is respected by writing a block, linking the task entry point to another that counts down 10 to 20ms of write cycle delay time and then it links it back to write another block, etc until the buffer is done. Then the task signals foreground and the buffer is available and the task releases itself until foreground triggers it again.

Well that's some information. I didn't give up many coding tricks - they're too good to give away. But the above might get someone to thinking about tasker structures.

Its a great way to code. I find it easy to open a ew driver, reserve a few memory blocks and write the task phases with little trouble. waiting milliseconds or hours is just as easy. A task is just a state-machine and if you can draw one, you can easily write the drivers.

aka j