OnQ Blog

The role of the realtime operating system in mobile

Jul 9, 2019

Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries.

What is an “RTOS” or “real time operating system” and why should embedded system and mobile developers care about it?


To understand the importance of RTOS, let’s start by looking at what a “general-purpose OS” (GPOS) is. You’re probably already familiar with GPOSes, as they’re the kind 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 user experience, the ability to run different types of programs on different types of hardware and provide features like customization options and others.

GPOS’s tend to work in concert with hardware in which each processor 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 the other hand, an RTOS is designed to provide a predictable execution pattern, and is employed when it’s necessary to ensure that processing conforms 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 in size compared to a GPOS, and generally provides only the functionality required to run certain types of applications on specific hardware.

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 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

Amongst 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 preemptive 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 process and threads are time bound. RTOSes also provide 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.

QuRT™ Software

Qualcomm Technologies processors like our Qualcomm® Hexagon™ DSP found on the Qualcomm® Snapdragon™ 8 series mobile platform, have their own embedded RTOS called QuRT1.

QuRT offers features like multithreading, mutexes, semaphores, timers, interrupt handling, memory management, etc., and enables 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 as stated on our Hexagon DSP SDK page on QDN, the programmer does not need to focus on the underlying threading model since QuRT maps user software threads onto the processor’s hardware threads. QuRT can globally schedule the highest-priority runnable software threads and directs interrupts to the lowest-priority hardware thread.

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


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.

The QuRT RTOS provides developers with a platform to fulfill these goals, and SDKs like the Hexagon DSP SDK provide a rich API for taking advantage of the RTOS’s functionality.

Now that we’ve shed some light on what an RTOS is, we’d love to hear how you take advantage of RTOS’s in your development. If you have an interesting project, considering submitting it to our Projects page.

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

1QuRT can also be found on other chipsets such as Qualcomm® QCA4020.

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries ("Qualcomm"). Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.

Rajan Mistry

Sr. Staff Engineer, Qualcomm Technologies

©2021 Qualcomm Technologies, Inc. and/or its affiliated companies.

References to "Qualcomm" may mean Qualcomm Incorporated, or subsidiaries or business units within the Qualcomm corporate structure, as applicable.

Qualcomm Incorporated includes Qualcomm's licensing business, QTL, and the vast majority of its patent portfolio. Qualcomm Technologies, Inc., a wholly-owned subsidiary of Qualcomm Incorporated, operates, along with its subsidiaries, substantially all of Qualcomm's engineering, research and development functions, and substantially all of its products and services businesses. Qualcomm products referenced on this page are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Materials that are as of a specific date, including but not limited to press releases, presentations, blog posts and webcasts, may have been superseded by subsequent events or disclosures.

Nothing in these materials is an offer to sell any of the components or devices referenced herein.