Real-time OSes

The basic requirement for a real-time OS (RTOS) is that it can guarantee that tasks will be executed and finished within a certain time span. This allows one to use them for real-time applications where variability (jitter) between the execution times of a batch of the same task is not acceptable.

From this, we can draw the basic distinction between hard and soft real-time OSes: with low jitter, the OS is hard real-time, as it can guarantee that a given task will always be executed with practically the same delay. With higher jitter, the OS can usually but not always execute a task with the same delay.

Within these two categories, we can again distinguish between event-driven and time-sharing schedulers. The former switches tasks based on priority (priority scheduling), whereas the latter uses a timer to regularly switch tasks. Which design is better depends on what one uses the system for.

The main thing that time sharing has over event-driven schedulers is that since it gives far more CPU time to lower-priority tasks as well, it can make a multitasking system seem to run much smoother.

Generally, one would only use an RTOS if your project requirements are such that one must be able to guarantee that inputs can be handled within a strictly defined time window. For applications such as robotics and industrial applications, it can be crucial that an action is performed in exactly the same time span every time, with failure to do so resulting in the disruption of a production line or an inferior product.

With the example project that we will be looking at later in this chapter, we do not use an RTOS, but a regular Linux-based OS, as no hard timing requirements exist. Using an RTOS would impose an unneeded burden and likely increase complexity and costs.

One way to regard an RTOS is to get as close to the real-time nature of programming directly for the hardware (bare metal) without having to give up all of the conveniences of using a full-blown OS.