Practical real-time systems

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.