There are many different trade-offs when using hardware and software to achieve real-time behavior in a system. The following sections discuss the various ways hardware and software are deployed in real-time systems you might encounter. Also, note that it is possible to have combinations of the following systems working together as subsystems. These different subsystems can occur at the product, board, or even chip level (this approach is discussed in Chapter 15, Multi-Processor and Multi-Core Systems).

Hardware-only

The original real-time system is hardware-only, and it is often the best solution when there are extremely tight tolerances and/or fast timing requirements. It can be implemented with discrete digital logic, analog components, programmable logic, or an application-specific integrated component (ASIC). Other options for the hardware include programmable logic devices (PLDs), complex programmable logic devices (CPLDs), and field-programmable gate arrays (FPGAs). Hardware-based real-time systems can cover anything from analog filters, closed-loop control, and simple state machines to complex video codecs. When implemented with power saving in mind, ASICs can be made to consume less power than an MCU-based solution. In general, hardware has the advantage of performing operations in parallel and instantly (this is, of course, an over-simplification), as opposed to a single-core MCU, which only gives the illusion of parallel processing.

The downsides for real-time hardware development generally include the following:

• The inflexibility of non-programmable devices
• The expertise required is generally less commonly available than software/firmware developers
• The cost of full-featured programmable devices (for example, large FPGAs)
• The high cost of developing a custom ASIC

Bare-metal firmware

Bare-metal firmware is considered (for our purposes) to be any firmware that doesn’t use a preexisting RTOS. Instead, the designer must write firmware for the features that an RTOS would typically provide. Some engineers take this a step further, arguing that true bare-metal firmware can’t use any preexisting libraries (such as vendor-supplied hardware-abstraction libraries)—there is some merit to this view as well. A bare-metal implementation has the advantage that the user’s code has total control of all aspects of the hardware. The only way for the main-loop code execution to be interrupted is if an interrupt occurs, giving control over to an ISR. In this case, the only way for anything else to take control of the CPU is for the existing ISR to finish or for a higher-priority interrupt to occur.

Bare-metal firmware implementations excel when there is a small number of relatively simple tasks to perform—or one monolithic task. If the firmware is kept focused and best practices are followed, deterministic performance is generally easy to measure and guarantee due to the relatively small number of interactions between ISRs (or in some cases, a lack of ISRs).

In some extreme cases for heavily loaded MCUs (or MCUs that are highly constrained in ROM/RAM), bare-metal is the only option. Back when bare-metal development first started, the MCUs were highly constrained, and programming bare-metal was a necessity. However, as the silicon industry has matured, more and more memory fits inside a tiny MCU. There are now many devices available, with plenty of memory, and at a low cost, which makes it unnecessary to limit yourself to bare-metal programming. Often, it makes sense to use an RTOS, which we will explore next.

RTOS-based firmware

As bare-metal implementations become more elaborate when dealing with events asynchronously, they start to overlap with the functionality provided by an RTOS. An important consideration to keep in mind is that by using an RTOS—rather than attempting to roll your own thread-safe system—you automatically benefit from all of the testing the RTOS provider has put in.

You’ll also have the opportunity to use code that has the power of hindsight behind it—many of the RTOSes available today have been around for several years. The authors have adapted and added functionality the entire time to make the RTOSes robust and flexible for different applications. Using one of these mature RTOSes provides a high-quality starting point for your application.

RTOS-based firmware differs from bare-metal firmware in that it runs on top of a scheduling kernel on an MCU. For RTOS-based firmware, the term firmware signifies a type of RTOS that is very limited in regard to its features – typically it operates out of limited flash memory (e.g., 64KB, 256KB, etc.), and it provides a scheduling kernel for use by tasks. It is like bare-metal firmware in that the programmer often has to be very aware of the hardware peripherals and registers offered by the MCU. However, the RTOS often abstracts away some of those details and also provides timing mechanisms that the application firmware can take advantage of.

With an RTOS, having a scheduler and some RTOS primitives allows tasks to operate under the illusion that they have the processor to themselves (discussed in detail in Chapter 6, Understanding RTOS Tasks). Using an RTOS enables the system to remain responsive to the most important events while performing other complex tasks in the background.

There are a few downsides to having several tasks running on the processor. Sharing data between tasks requires the proper use of synchronization methods to avoid problems such as deadlock and priority inversion. Later in the book, we will discuss some of these synchronization methods, although it adds complexity to the code. Interrupts will generally use task signaling to take care of the interrupt as quickly as possible and defer as much processing to a task as possible. If handled properly, this solution is excellent for keeping complex systems responsive, despite many complex interactions.

RTOS-based software

RTOS-based software differs from RTOS-based firmware in that this software runs on a more full-featured RTOS. The features are similar to those found in a general-purpose OS and may include things such as hardware drivers, bootloaders, applications, filesystems, etc. In fact, some general-purpose OSes offer real-time variants (e.g., RTLinux).

These RTOSes typically require significantly more memory (e.g., 1 MB or more) and processors with specific features. For example, the RTOS may make use of the processor’s memory management unit (MMU). Also, the RTOS may provide features such as application loading and a defined driver framework. The software applications for an RTOS can be highly complex, requiring many different interactions between various internal and external systems. The advantage of using this type of RTOS is all of the capabilities that come along with it—both hardware and software.

In addition, on the hardware side, a more complex processor is often used to provide additional event-handling capacity (bandwidth) to the application. For example, there may be multiple CPU cores available running at higher clock rates. There can be GBs of RAM and persistent memory available. Adding peripheral hardware can be as simple as the addition of a card (provided there are pre-existing drivers).

On the software side, there is a plethora of open-source and vendor-proprietary solutions for networking stacks, UI development, file handling, and so on. The availability of these solutions means that certain features of the end product will require less development time to implement. Underneath all of these capabilities and options, the kernel is still implemented in such a way that the critical tasks won’t be blocked for an indefinite period of time, which is possible with a general-purpose OS. Because of this, getting deterministic performance is still within reach, just like with RTOS-based firmware.

Carefully crafted OS software

Similar to RTOS-based software, a standard OS has all of the libraries and features a developer could ask for. What’s missing, however, is a strict focus on meeting timing requirements. Generally speaking, systems implemented with a traditional OS are going to have much less deterministic behavior (and none that can be truly counted on in a safety-critical situation). For example, how many times have you sat at your PC and had a program indicate “not responding”? Now imagine if your PC also happened to be controlling the timer on your toaster – you might end up with some burnt toast!

If there is a lax real-time requirement without catastrophic consequences if a wishy-washy deadline isn’t met on time, a standard OS can be made to work, as long as care is taken in choosing what software stacks are running and their resource use is kept in check. The Linux kernel with PREEMPT_RT patches is a good example of this type of RTOS.

So, now that several of the options for achieving a real-time system with hardware and software have been laid out, it’s time to define exactly what we mean when we refer to an RTOS, specifically an MCU-based RTOS.

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.

In practice, real-time systems often have a combination of firm, hard, and soft real-time requirements. For example, the soldering iron example may have hard real-time requirements for a thermal run-away safety monitor, firm real-time requirements for the temperature measurement and control loop, and soft real-time requirements for updating the user display. Achieving this combination of real-time requirements is made easier by using an RTOS, but it requires careful attention to these constraints when designing the system.

The range of RTOSes

There are many RTOSes on the market. They range widely in their functionality, and in what processor architecture and size they’re best suited to. On the smaller side are 8-bit to 32-bit MCU-focused RTOSes, including FreeRTOS, Keil RTX, Micrium µC/OS, ThreadX, and many more. This class of RTOS is suitable for use on microcontrollers, and a compact real-time kernel is provided as the most basic offering. When moving from MCUs to 32-bit and 64-bit application processors, there are RTOSes such as Wind River VxWorks, Wind River Linux, Green Hills’ Integrity OS, and even Linux with PREEMPT_RT kernel extensions. These full-blown OSes offer a large selection of software, providing solutions for both real-time scheduling requirements as well as general computing tasks. Even with the OSes we’ve just rattled off, we’ve only scratched the surface of what’s available. There are free and paid solutions (some costing well over $10,000) at all levels of RTOSes, big and small.

So, why would you choose to pay for a solution when there is something available for free? The main differentiating factors between freely available RTOS solutions and paid solutions are safety approvals, middleware, and customer support. Because an RTOS provides a highly deterministic execution environment, they are often used in complex safety-critical applications. These systems require deterministic operation because they must behave in a predictable way all the time. Guaranteeing that the code responds to events within a fixed amount of time is a significant step toward ensuring they behave consistently. Most of these safety-critical applications are regulated and have their own sets of governing bodies and standards, such as DO-178B and DO-178C for aircraft or IEC 61508 SIL 3 and ISO 26262 ASILD for industrial applications. To make safety-critical certifications more affordable, designers typically use one of two approaches. One approach is to keep code for these systems extremely simple, and not to use an RTOS. This makes it possible to prove mathematically that the system will function consistently and nothing can go wrong. The other approach is to turn to a commercial RTOS solution, which has been through the certification process, as a starting point. For example, WITTENSTEIN SafeRTOS is a derivative of FreeRTOS that carries approvals for industrial, medical, and automotive use.

Middleware can also be an extremely important component in complex systems. Middleware is code that runs between the user code (code that you, the application programmer, write) and lower layers, such as the RTOS or bare-metal (no RTOS). A value proposition of paid solutions is that the ecosystem offers a suite of pre-integrated high-quality middleware (such as filesystems, networking stacks, GUI frameworks, industrial protocols, and so on), and it minimizes the amount of development required and reduces overall project risk.

The reason for using middleware, rather than rolling your own, is to reduce the amount of original code being written by an in-house development team. This reduces both the risk and the total time spent by the team—so it can be a worthwhile investment, depending on factors such as project complexity and schedule requirements.

Paid solutions will also typically come with some level of customer support directly from the firmware vendor. Engineers are expensive to hire and keep on staff. There’s nothing a manager dreads more than walking into a room full of engineers who are puzzling over their tools, rather than working on the real problems that need to be solved. Having expert help that is an email or phone call away., can increase a team’s productivity dramatically, which leads to a shorter turnaround and a happier workplace for everyone.

The RTOS used in this book

With all of the options available, you might be wondering: why is it that this book is only covering one RTOS on a single model of MCU? There are a few reasons, one being that most of the concepts we’ll cover are applicable to nearly any RTOS available, in the same way that good coding habits transcend the language in which you happen to be coding. By focusing on a single implementation of an RTOS with a single MCU, we’ll be able to dive into topics in more depth than would have been possible if all of the alternatives were also attempted to be discussed.

FreeRTOS is one of the most popular RTOS implementations for MCUs, and it is very widely available. It has been around for over 15 years and has been ported to dozens of platforms. If you’ve ever spoken to a true low-level embedded systems engineer who is familiar with RTOS programming, they’ve certainly heard of FreeRTOS and have likely used it at least once. By focusing our attention on FreeRTOS, you’ll be well positioned to quickly migrate your knowledge of FreeRTOS to other hardware or transition to another RTOS, if the situation calls for it.

The following is a diagram showing where FreeRTOS sits in a typical ARM firmware stack. Stack refers to all of the different layers of firmware components that make up the system and how they are stacked on top of one another. A user in this context refers to the programmer using FreeRTOS (rather than the end user of the embedded system):

Figure 1.5: Typical ARM FreeRTOS firmware stack

Some noteworthy items are as follows:

• User code is able to access the same FreeRTOS API, regardless of the underlying hardware port implementation
• FreeRTOS does not prevent user code from using vendor-supplied drivers, the CMSIS, or raw hardware registers

Having a standardized API that is consistent across hardware means code can be easily migrated between hardware targets without being constantly rewritten. The ability to have code directly control hardware also provides the means to write extremely efficient code when necessary (at the expense of portability).

Now that we know what an RTOS is, let’s have a closer look at when it is appropriate to use an RTOS, and when it is not. And, when it is appropriate, we’ll look at determining the type of RTOS to use.

Occasionally, when someone first learns of the term real-time OS, they mistakenly believe that an RTOS is the only way to achieve real-time behavior in an embedded system. While this is certainly understandable (especially given the name), it couldn’t be further from the truth. Sometimes, it is best to think of an RTOS as a potential solution, rather than the solution to be used for everything. Generally speaking, for an MCU-based RTOS to be the ideal solution for a given problem, it needs to have a Goldilocks-level of complexity—not too simple, but not too complicated.

If there is an extremely simple problem, such as monitoring two states and triggering an alert when they are both present, the solution could be a straightforward hardware solution (such as an AND gate). In this case, there may be no reason to complicate things further, since the AND gate solution is going to be very fast, with high determinism and extreme reliability. It will also require very little time for development.

Now, consider a case where there are only one or two tasks to be performed, such as controlling the speed of a motor and watching an encoder to ensure the correct distance is traversed. This could certainly be implemented in discrete analog and digital hardware, but having a configurable distance would add some complexity. Additionally, tuning the control loop coefficients would likely require twiddling the potentiometer settings (possibly for each individual board), which is undesirable in some or most cases, by today’s manufacturing standards. So, on the hardware solution side, we’re left with a CPLD or an FPGA to implement the motion control algorithm and track the distance traveled. This happens to be a very good fit for either since it is potentially small enough to fit into a CPLD, but in some cases, the cost of an FPGA might be unacceptable. This problem is also handled by MCUs regularly. If existing in-house resources don’t have the expertise required with hardware languages or toolchains, then a bare-metal MCU firmware solution is probably a good fit.

Let’s say the problem is more complicated, such as a device that controls several different actuators (for example, a motor or a solenoid valve). The device reads data from a range of sensors and stores those values in local storage. Perhaps the device also needs to sit on some sort of network, such as Ethernet, Wi-Fi, a controller area network (CAN), and so on. An RTOS can solve this type of problem quite well. The fact that there are many different tasks that need to be completed, more or less asynchronously with one another, makes it very easy to argue that the additional complexity the RTOS brings will pay off.

Some RTOS tasks are lower-priority and more complex, such as networking and filesystem processing. Other tasks are time-critical, such as controlling actuators and reading sensors. The RTOS helps us to ensure the lower-priority and more complex tasks won’t interfere with the time-critical tasks. Also, in many cases, there may be some form of control system that generally benefits from being run at well-defined time intervals—a strength of the RTOS.

Consider a system similar to the previous one, but now there are multiple networking requirements, such as serving a web page, dealing with user authentication in a complex enterprise environment, and pushing files to various shared directories that require different network-based file protocols. This level of complexity can be achieved using an RTOS, but again, depending on the available team resources, this might be better left to a full-blown OS to handle (either an RTOS or a general-purpose OS) since many of the complex software stacks required already exist. Sometimes, a multi-core approach might be taken, with one of the cores running an RTOS and the other running a general-purpose OS.

By now, it is probably obvious that there is no definitive way to determine exactly which real-time solution is correct for all cases. Each project and team will have its own unique requirements, backgrounds, skill sets, and contexts that set the stage for this decision. There are many factors that go into selecting a solution to a problem; it is important to keep an open mind and choose the solution that is best for your team and project at that point in time.

In this chapter, we talked a lot about real-time systems. We defined a real-time system and gave some examples of real-time systems in the real world. At this point, you should understand how real-time systems have different timing requirements and how there are different consequences for not meeting those timing requirements.

We then looked at the ways to use hardware and software to implement real-time systems. We saw that some real-time systems can just use hardware to meet their timing requirements. On the other hand, some real-time systems can get away with just using software on a general-purpose OS. In between those extremes is the focus of this book: applications that depend on an RTOS and run on an MCU.

After better understanding real-time systems, we defined an RTOS and described how it differs from a general-purpose OS. We explored the difference between hard, firm, and soft real-time systems. It is important to remember that the timing requirements of the real-time system determine what type of RTOS is necessary to achieve the desired performance.

We discussed the types of RTOSes that are available and why FreeRTOS was chosen for this book. FreeRTOS is mature and is used widely in industry. It is also free! And, learning FreeRTOS is a way to better understand RTOSes in general.

Finally, we looked at when it is appropriate to use an RTOS, and when it is not. And, when appropriate, we looked at determining the type of RTOS to use.

Upcoming chapters show how FreeRTOS works, and how to use it. The chapters are illustrated with example programs that run on an ST development board. The next two chapters present the development board, and also, the development tools (e.g., the IDE) that we will be using to run the example programs.