Defining RTOSes

An RTOS is a version of an OS that is carefully designed to offer real-time mechanisms to programmers. General-purpose OSes (such as Windows, Linux, and macOS) were created to provide a consistent programming environment that abstracts away the underlying hardware to make it easier to write and maintain computer programs. They provide application programmers with many different primitives, such as threads and mutexes.

Threads are sections of software that have their own stack and operating context. Threads are like tasks in that they run independently from each other. Mutexes are primitives offered by OSes. Mutexes provide a means for threads to synchronize their processing.

Threads (or tasks) and mutexes can be used by application software to create more complex behavior. For example, it is possible to create a multi-threaded program that provides protected access to shared data:

Figure 1.4: Multi-threaded shared memory

The preceding application doesn’t implement thread and mutex primitives, it only makes use of them. The actual implementations of threads and mutexes are handled by the OS. This has a few advantages:

• The application code is less complex
• It is easier to understand—the same primitives are used regardless of the programmer, making it easier to understand code created by different people
• There is better hardware portability—with the proper precautions, the code can be run on any hardware supported by the OS without modification

In the preceding example, a mutex is used to ensure that only one thread can access the shared data at any given time. In the case of a general-purpose OS, each thread will happily wait indefinitely for the mutex to become available, before moving on to access the shared data. This is where an RTOS diverges from a general-purpose OS. In an RTOS, all blocking system calls are time-bound; instead of waiting for the mutex indefinitely, an RTOS allows a maximum delay to be specified. For example, with a general-purpose OS, if Thread 1 attempts to acquire Mutex and still doesn’t have it after 100 ms, or even 100 seconds, it will continue waiting for Mutex to become available—even if it takes forever.

In an RTOS implementation, the maximum amount of time to wait for Mutex to become available is specified by the programmer. The programmer could specify that Thread 1 must acquire Mutex within 100 ms. If Thread 1 still hasn’t received Mutex after 101 ms, Thread 1 will receive a notification that Mutex hasn’t been acquired by the specified time. This is called a timeout, and it is specified to help create a deterministic system.

An OS that provides a way of executing a given piece of code, within specified timing requirements, can be considered a real-time OS. This definition of an RTOS covers a fairly large number of systems.

There are a couple of characteristics that tend to differentiate applications that use an RTOS: how often not meeting a real-time deadline is acceptable, and the severity of not meeting a real-time deadline. The different ranges of applications that use an RTOS are usually lumped into three categories—hard, firm, and soft real-time systems.

Hard real-time systems

A hard real-time system must meet its deadline 100% of the time. If the system does not meet a deadline, then it is considered to have failed. This doesn’t necessarily mean a failure will hurt someone if it occurs in a hard real-time system—only that the system has failed if it misses a single deadline.

The severity of a failure is generally deemed safety-critical if a failure will cause the loss of life or significant property. There are also hard real-time systems that have nothing to do with safety.

Some examples of hard real-time systems can be found in medical devices, such as pacemakers and control systems with extremely tightly controlled parameters. In the case of a pacemaker, if the pacemaker misses a deadline to administer an electrical pulse at the right moment in time, it might kill the patient (this is why pacemakers are defined as safety-critical systems).

In contrast, if a motion control system on a computer numerical control (CNC) milling machine doesn’t react to a command in time, it might plunge a tool into the wrong part of the item being machined, ruining it. In these cases that we have mentioned, one failure caused a loss of life, while the other turned some metal into scrap—but both were failures caused by a single missed deadline.

Firm real-time systems

As opposed to hard real-time systems, firm real-time systems need to hit their deadlines nearly all of the time. If video and audio lose synchronization momentarily, it probably won’t be considered a system failure, but will likely upset the consumer of the video.

In most control systems (similar to the soldering iron in a previous example), if a few samples are read slightly outside of their specified time, it is unlikely the system will be destroyed. If a control system has an ADC that automatically takes a new sample, and the MCU doesn’t read the new sample in time, it will be overwritten by a new one. This can occur occasionally, but if it happens too often, the temperature stability will be ruined. However, other systems cannot tolerate missed samples. Motor control loops, for example, might lose control of the motor if even a few samples are missed. This highlights the need for the programmer to understand the real-time requirements of the system and to design accordingly.

Soft real-time systems

Soft real-time systems are the most lax when it comes to how often the system must meet its deadlines. These systems often offer only a best-effort promise to keep deadlines. These real-time systems don’t consider it a failure when their deadlines are not met, though the user of the system might consider it an annoyance.

Cruise control in a car is a good example of a soft real-time system because there are no hard specifications or expectations of it. Drivers typically don’t expect their speed to converge to within +/- X mph/kph of the set speed, within N seconds. They expect that given reasonable circumstances, such as no large hills, the control system will eventually get them close to their desired speed most of the time. However, they might still be annoyed when they have to step on the gas to get the car to climb that large hill!

Next, we’ll look at the various types of RTOSes that are currently available, and the RTOS used in this book.