Today, most embedded software runs on top of an RTOS. However, many embedded applications are better of without a preemptive scheduler, as cooperative scheduling strategies alleviate the developers from paying attention to all kinds of race conditions which can result in sporadic errors that are hard to track down. Even with a cooperative scheduling strategy, it is still possible to satisfy hard realtime requirements. Especially in small applications it is often sufficient to let all realtime code run in interrupt context. A mainloop based approach even results in the best overall performance and shortest possible response times, because it involves no context switching overhead of a preemptive scheduler.
It seems that some people choose an embedded RTOS with a preemptive scheduler, because they believe that a TCP stack or a USB stack can otherwise not be integrated. This is certainly not true, but may be the reason why preemptive scheduling is sometimes chosen for embedded applications, even though a cooperative strategy is much more appropriate.
The redBlocks Mainloop Operating System implements an easy to use run-to-completion scheduling system that supports timing and event services. It is totally independent of the underlying hardware and especially well suited for resource limited systems that do not require a preemptive scheduling strategy.
It provides the following features:
- Event generation can be initiated from interrupt service routines as well as from normal application context. All events are processed in application context - their associated handlers are not preempted by other event handlers, thus no race conditions can arise among the different event handlers.
- Timers can generate one-shot or periodic events. In order to meet critical timing requirements, so-called ISR timers are available. They generate asynchronous callbacks from the system tick interrupt context (either once or periodically).
- For maximum application portability, time intervals of timers are specified in real time units, not in system ticks, i. e. changing the system tick interval does not require any application code changes. In spite of this convenient feature, there is still no risk of experiencing strange runtime effects, if a specified time interval cannot be met, because the system tick resolution is not sufficient. This is, because the compiler will report an error in this case.
- Integrating the Mainloop Operating System on a hardware platform is very simple: It is only necessary to provide a periodic trigger by a system tick ISR and to provide a means to globally disable and re-enable the interrupts.
- It scales perfectly with the used features, i. e. if no timing services are needed, no system tick is necessary and the resulting binary code will be smaller.
- It is ideally suited for power sensitive applications (e. g. battery powered devices), as it provides hooks that can be used to send the processor to sleep mode, whenever possible. This way, it also switches off the system tick (this feature is often called tickless mode).