Discussion

We first give an overview of the architecture of our RTOS in a block diagram. In the last part of this page we briefly mention the differences in API of this RTOS and other RTOSes implemented in previous years. We conclude this section be briefly mentioning some strengths and limitations of current approach in scheduling periodic tasks.

Overall Architecture

Figure 1 shows the overall architecture of this RTOS. The most important thing to notice how interrupts get enabled and disabled through out. Kernel tasks are protected from interruption by hardware interrupts before entering the kernel by disabling the interrupt. Also, when kernel tasks return they enable interrupts so that user tasks can be pre-empted, interrupted and RTOS tick can take place. Also, notice the event architecture. Only one task can wait for an event. In the previous implementations each event cell was a queue so that many tasks can wait for the same event.


Figure 1: Overall architecture of the RTOS.


Differences in API with previous RTOSes of this class

The primary differences are:
  • Only one task can wait for an event.
  • No Periodic Process Plan.
  • No Task_Sleep.
We think the first improves predictability in RTOS scheduling. It is uncertain which task gets the CPU when multiple tasks with varying priorities wait for the same event. The second has some benefits as well some drawbacks. The most prominent drawback we see that with the current method we cannot schedule a periodic task that has sub-phases. Sub-phases can be helpful when a number of tasks exceeds the maximum allowed tasks. In that case, two unrelated tasks can be merged into one periodic task with sub-phases. However, the current method has many advantages as well. An application engineer can specify the start time. This was not possible previously. With this one can wait for initialization before starting a periodic task. The third item, that is, the lack of Task_Sleep may be a problem. For an under-utilized CPU, RR tasks -- which we assume need only infrequent CPU are scheduled most of the time (e.g. 98% of the time for our Sentry Robot). This is not exactly a problem for a system that does not care about conserving power. However, for systems that want to conserve power as much as possible it is probably advisable to put the CPU to sleep during the idle time. For RR tasks that do not wait for events this may not be possible without Task_Sleep.