You will also need interrupt handlers. Just as the user "registers" his tasks that your RTOS schedules and calls, he/she will also need to register ISRs, i.e. to have more predictable interrupts, an ISR will also be have to defined as a task, maybe a lightweight task.

So you have your own code at the interrupt vector which does something similar (or identical) to what your scheduler does. It will slow down interrupt handling, but the alternative is to have the user be more careful in his design.

Alternately you can provide a simple interface for interrupt handling and disable the SCHEDULER interrupt during other interrupts. That seems more feasible.

Priority can lead to starvation, so be careful... some lower priority task may never get executed due to higher priority tasks. Maybe a safer way to handle priority would be to simply allocate a bigger time slice to higher priority tasks? May not be good design, but if it works worth trying. Or have the user set and clear a certain flag in tasks to indicate critical sections, which signal that a task should not be pre-empted. Anything outside the critical section has the same priority.

All this really is difficult and often unnecessary for 8-bit uCs... Maybe it would make more sense to port the code for 16-bit 8051-based variants. Like maybe the 8096, a 16-bit uC with loads of on-chip goodies which has an identical instruction set to the 8051. An RTOS which not only schedules tasks but also handles external interrupts and manages on-chip peripherals (Timers, ADCs, PWM, Serial/I2C etc) would be a really good idea.

kundi