One of the most important components that go into today’s embedded systems is the “RTOS” or “real time operating system,” which is responsible for everything from scheduling tasks to enabling high-level languages like C and Python.

So, what makes an RTOS tick, and why should embedded system developers care about it?

RTOS vs. GPOS

To understand the RTOS, let’s take a step back and look at what a “general-purpose OS” (GPOS) is. You’re probably already familiar with GPOSes, as they’re found on devices you use every day, like your smart phone and work PC (e.g., Android, Windows, etc.).

The “general” in general-purpose OS means the OS must fulfill many goals such as providing a good end-user experience, supporting different types of programs and hardware, and providing capabilities like customization options.

GPOS’s tend to work in concert with processors where each core runs a single thread of execution at a time. Here, the operating system’s scheduler decides which program to run and when, rapidly switching between each program. This results in the illusion of simultaneous execution, and hopefully provides a good overall user experience. On top of this, GPOS’s may provide additional functionality such as sophisticated graphic user interfaces, complex file I/O systems, etc.

On the other hand, an RTOS is designed to provide a predictable execution pattern and is employed when processing must conform to the time constraints of a time-bound system (i.e., processing is completed at a certain frequency or the system as a whole will fail). As such, an RTOS is typically light weight and small compared to a GPOS, and generally provides only the functionality required to run certain types of applications on specific hardware. In some cases, developers may modify an existing RTOS, reducing it down to only the functionality required for their particular application, and/or customizing its functionality or performance characteristics.

An RTOS can be classified as:

• Soft: The RTOS can usually meet time-constrained deadlines; the pre-emption period is usually within a few milliseconds.
• Firm: The RTOS has certain time constraints, which are not strict and may cause undesired yet acceptable effects.
• Hard: The RTOS can meet timing deadlines deterministically. A Hard RTOS is generally preferable for use cases involving mission critical applications such as those found in robotics and drones. The pre-emption period for a hard RTOS is usually less than a few microseconds.

Like a GPOS, an RTOS provides some or all of the fundamental functionality you’d expect from an OS such as thread synchronization, cross-boundary communication (e.g., named pipes), timers, memory management, etc. However, an RTOS strives to deliver this functionality in a manner that conforms to the time-constrained requirements of the underlying system and target application.

Meeting Deadlines

Among the many factors that allow an RTOS to fulfill these time constraints, task scheduling and interrupts deserve special mention.

With a GPOS, scheduling is handled in a manner that generally achieves high throughput (i.e., the total number of processes whose execution completes per unit time). However, this can mean that the execution of a high-priority process will be delayed in order to complete multiple low-priority tasks. On the other hand, the value of an RTOS is gauged on how quickly or predictably it can respond rather than the amount of work it can perform in a given period of time.

In an RTOS, scheduling is usually priority based. Most RTOS’s use a pre-emptive task scheduling method based on priority levels. Here, a high-priority process will be executed over the low priority processes. With a GPOS, latencies can accumulate as more threads need to be scheduled. An RTOS has no such issues because the latencies of all the processes and threads are time bound. The RTOS also provides a way for you to ensure that the shared system resources are protected from concurrent access.

The kernel of an RTOS is preemptible whereas a GPOS kernel is not preemptible, which is important when serving high-priority processes and threads first. Without a preemptible kernel, a request from within the kernel, such as that from a driver or a system service, would override all other process and threads. With an RTOS, only very important service requests are kept within the kernel call and all other service requests are treated as external processes and threads. The kernel-based service requests are associated with the bounded latency of the RTOS to maintain fast and predictable responses.

RTOS’s Today

There are several RTOS’s available that developers can employ in their projects, including commercial (e.g., VxWorks, Red Hat Linux, etc.) and open source offerings (e.g., FreeRTOS, RTEMS, etc.). Some organizations also have their own proprietary RTOS developed specifically for their hardware products.

One such example is Qualcomm Technologies’ QuRT™ RTOS, which is employed on the Qualcomm® Hexagon™ DSP found on the Qualcomm® Snapdragon™ 8 series mobile platform[1], and serves as a great example for a discussion on RTOS’s because of its rich feature set.

For example, QuRT offers multithreading, mutexes, semaphores, timers, interrupt handling, memory management, etc., and allows programs and threads to execute in separate protected address spaces for improved system security and stability. Developers can write user programs designed to utilize QuRT in C/C++ and/or assembly using the Hexagon DSP SDK and use the QuRT APIs to access the RTOS services. Each user program has access to the global heap, and contains a main thread call stack, data and text sections, and the ability to allocate additional heaps and threads. And since QuRT maps user software threads onto the processor’s hardware threads, the programmer does not need to focus on the underlying threading model. QuRT can globally schedule the highest-priority runnable software threads and always directs interrupts to the lowest-priority hardware thread.

QuRT also manages software and hardware watchdog timers to detect and reset system failures.

For additional information, see the Hexagon DSP SDK overview page on Qualcomm Developer Network (QDN).

Conclusion

An RTOS is a critical component for ensuring predictable and timely execution on embedded devices such as those used in IoT, robotics, and mobile. Thus, its goals are to provide facilities for time-constrained applications that must execute within a certain time frame while minimizing delays such as latencies caused by interrupts and switching threads.

And as we’ve seen, there are commercial, open-source, and proprietary RTOS’s that can be used in embedded systems. They offer a variety of options and functionality such as customizability, cross platform or specialized support, and rich SDK support.

Author’s Bio

Rajan Mistry is a Sr. Applications Engineer at Qualcomm Technologies, Inc. with the Qualcomm Developer Network team. His role is to help grow the developer community and work on the next generation of solutions that leverage Qualcomm® technologies.

Qualcomm Snapdragon, Qualcomm Hexagon, QuRT and Qualcomm QCA4020 are products of Qualcomm Technologies, Inc. and/or its subsidiaries.