The title of the last chapter included the phrase, "Real Time". The term, Real Time, is used to describe a computing system that must meet deadlines. We did not define this term in Chapter 7, Real-Time Signal Processing because, in the context of handling audio samples, an implicit deadline is the sampling rate. However, you may recall that our ISR illuminated an error LED if the main super loop did not output the previous sample before a new sample arrived.

The audio application is an example of a soft deadline. It wouldn't be a catastrophe if the system missed this deadline once or twice; the audio quality would suffer, but this may go unnoticed. Contrast this with other applications, such as an embedded system used in fly-by-wire avionic applications, medical equipment, or a nuclear reactor. In these cases, missing a deadline could be catastrophic and result in death. Deadlines in these cases are known as hard deadlines and, in order to meet safety standards, designers need to guarantee that the system meets them. They may even be required to design redundancies to ensure that the system is robust to the catastrophic failure of a processor.

The last chapter illustrated that, although it is possible to design a simple real-time embedded system using a super loop, it gets increasingly tricky to ensure that deadlines are met as the system becomes more complex. An operating system is what is needed, but real-time systems do not use standard desktop operating systems, such as Windows or Linux, because it is impossible to guarantee that such systems will meet deadlines. Imagine a scenario where the pilot was landing an aircraft and the computer avionics system decided that now was a good time to defragment the hard disk! Instead of this, they use so-called real-time operating systems (RTOS), which are sometimes referred to as simply an embedded RTOS. Embedded RTOS are compact because the hardware running an embedded operating system is very limited in resources, such as RAM and ROM. Unlike a desktop operating system, the embedded operating system does not load and execute applications. This means that the system is only able to run a one application that is statically linked as a single executable image.

Operating systems based on the Linux kernel, and known as embedded Linux, are a popular choice as they are free from license fees. Embedded Linux forms the basis of the Android OS developed for smart phones and tablets. Many other examples of open source embedded RTOS exist. Most adopt the Portable Operating System Interface (POSIX) standard that supports open-standard application programming interfaces (APIs). We've adopted ARM's RTOS kernel, called RTX, as the RTOS used by examples in this chapter as it's included in the uVision5 IDE distribution. RTX was originally distributed as a Real-Time Library (RL-ARM™), designed to solve the real-time and communication challenges of embedded systems that are based on ARM processor-based microcontroller devices (refer to www.keil.com/product/brochures/rl-arm_gs.pdf). This library was recently revised and added to the CMSIS middleware standard and is now known as CMSIS-RTOS. A description of the API can be found at https://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html, and advice on migrating from RL-ARM to CMSIS-RTOS is available here at http://www.keil.com/appnotes/docs/apnt_264.asp.

Support for multitasking is a key function of any operating system. Multitasking is a rudimentary form of parallel processing in which several tasks are run at the same time. Multitasking doesn't mean that tasks are executed in parallel. On a uniprocessor, there can be no true simultaneous execution of different tasks. Instead of this, the operating system switches between them, executing part of one task, then part of another, and so on. To the user, it appears that all the tasks are executing at the same time. The job of the operating system is to schedule each task on the CPU. The act of reassigning a CPU from one task to another one is called a context switch.

Embedded systems are at the heart of many everyday devices, such as smartphones, TVs, cameras, dishwashers, and so on. The system may comprise many tasks. For example, the dishwasher may embody a user interface, pump controller, and sensors. It is efficient to partition the software dealing with these elements into separate tasks. At any time, the total number of tasks can be divided into two groups: those that can be executed, and those suspended and waiting for an external event to occur (for example, the water temperature reaching a specific value or user input). RTOS supports preemptive scheduling, which allows tasks to be prioritized and can guarantee that some tasks in waiting will be given the CPU when an external event occurs.

We can illustrate how tasks are executed on the CPU by drawing an execution diagram. Consider three processes (just another name for tasks): a, b, and c that are executed periodically with a period of T seconds and have computation time (that is, they must be allocated on the CPU) of C seconds, as shown in the following table. The tasks are prioritized so that the task with the shortest period is allocated the highest priority (higher numbers imply a higher priority):

All the processes are released at t=0. Processes b and c are both meeting their respective deadlines. Process a gets preempted by b and c and misses its deadline. We can see from the execution trace that, in this case, the tasks cannot be successfully scheduled.

Processes may need to share resources, and this raises the question of how they might communicate. The CMSIS-RTOS API solves both of these problems and more.