Real-Time Operating System

RTOS Introduction

A Real-Time Operating System (RTOS) is analogous to more familiar desktop operating systems in that it provides a platform for application-specific programs to operate seemingly at the same time. This is often called multithreading or concurrency. Of course, on a single processor system, the illusion of multithreading is achieved by sharing the processor between the various programs. This act of sharing is accomplished by a technique called context-switching, where a thread executing is stopped and saved before a new thread is started. All of this happens behind the scenes inside of the operating system. This is where the similarities between RTOS and desktop operating systems generally end.

Unlike most desktop operating systems, an RTOS also provides real-time functionality. An application can rely on the RTOS to schedule processing necessary to meet the most demanding of application timing constraints. Think of a medical, industrial or automotive application that must detect, process, and respond to sensor input in less than 1ms. This is relatively easy for an RTOS, but typically very difficult or even impossible for most desktop operating systems. In addition, many small embedded devices have less than 1MB of memory and have a limited amount of power - sometimes even battery operated. Typical desktop operating systems (like embedded Linux) simply can’t operate on such resource constrained devices. Market research projects that 7 billion of such resource constrained processors (MCUs) will be shipped annually starting in 2025, which shows the importance of the RTOS.

RTOS Why/When

Not all applications need multithreading – or an RTOS by extension. If an application only has one main set of processing, the real-time multithreading capabilities of an RTOS can be overkill. A “super loop” is often the choice for very simple applications without real-time constraints. Of course, as application code becomes more intricate and/or has real-time constraints, the processing allocation responsibility quickly becomes untenable. One small change in one part of the program can easily break the real-time requirements of the application. Perhaps even worse, each developer on the team has to have intimate knowledge of the entire application to prevent breaking it when making updates or adding features. This means that it is difficult to add developers to a non-RTOS development team.

As the complexity and real-time requirements increase, an RTOS quickly becomes necessary. Generally, applications greater than 32KB in size and/or applications that have network connectivity are good candidates for using an RTOS. It’s also worth mentioning that some simple designs will use an RTOS just for the purpose of “future proofing,” leveraging the fact that adding functionality to the application in the future will be both easier and safer.

RTOS Benefits

There are many benefits to using an RTOS, including the following:

1. Faster time-to-market

Using an RTOS improves development, thereby reducing the overall development time. Development is improved by:

1. Removing processor allocation logic from the application code
2. Helping break the application into more manageable pieces, e.g., threads
3. Rich set of documentation and processor/tool/middleware support
4. Enabling more developers to work on the application, since application is more easily divided and developers don’t need to know about everything else
5. Leveraging functional safety certification of the RTOS (commercial RTOS only)
6. Providing professional support (commercial RTOS only), which prevents development stalls when issues arise

2. Enhanced product quality

Using an RTOS reduces code interdependency and therefore helps improve testability, which in turn improves quality. In addition, many commercial RTOS products are functional safety certified, which means that they have achieved 100% statement and branch-decision coverage testing. Since the RTOS is the foundation of the entire application, this can greatly enhance product quality.

3. Safer and more secure products

Many commercial RTOS offerings are functional safety certified. A safer foundation is also a more secure foundation. Some newer commercial RTOS products also provide security-specific enhancements for memory corruption detection and mitigation, including checks on all function pointers for corruption. Doing so helps prevent the most serious remote execution attacks.

4. Easier to maintain and upgrade products

Since the RTOS is responsible for all processor allocation (including real-time requirements), maintaining and upgrading the product in the future is much easier. One small change or even adding a completely new threads will not affect the overall responsiveness.

5. More portable/reusable application code

Using an RTOS makes code more portable across different processors and development tools. An RTOS that supports the POSIX pthread API also make application code portable between RTOS and embedded Linux platforms. This enables sharing code between different products and also makes it possible to migrate software to embedded Linux or from embedded Linux to an RTOS. All of this helps protect the software investment.

6. Reduced engineering training

Given the POSIX pthread API is an industry standard and is known by many engineers, applications using an RTOS with POSIX pthread support have reduced engineering training. This saves both time and money.

RTOS Costs

Nothing in life is free. While an RTOS provides many benefits, it does introduce some costs as well, including the following:

1. License fees

Commercial RTOS products have a license fee. Open source RTOSes do not. However, the quality, performance, documentation, and support of commercial RTOSes is much better, which results in enhanced application development. This enhanced development can easily offset the license cost. In addition, many commercial RTOSes have been functional safety certified, which is a benefit even for applications that don’t yet require function safety certification.

2. Memory Overhead

Good RTOSes generally require less than a few kilobytes of memory for minimal usage. However, for some very resource constrained devices (< 3KB RAM), this can be prohibitive.

3. Processing Overhead

Context-switching and API call overhead is typically less than a few microseconds on most good RTOSes and usually isn’t noticeable. In some situations, a good RTOS will actually reduce overhead in comparison with a non-RTOS implementation. This is because the “super loop” implementations inherently has to poll for work to be done. As the application becomes more complex, this additional polling can result in more overhead than an RTOS. The “super loop” polling also grows as the application code grows, while the RTOS processing overhead is constant.

4. Complexity

An RTOS introduces the complexity of multithreading, but this too could be less complex than a non-RTOS, “super loop” implementation as the application complexity increases. The important takeaway here is that the RTOS complexity is a constant, where the “super loop” complexity continues to grow as functionality is added.

---

RTOS Summary

An RTOS might not be appropriate for every embedded application. However, an RTOS will be the right choice for a large majority of the 7 billion devices that will be shipping annually by 2025.