What is a "Real Time Operating System" or "RTOS"? Why should embedded systems and mobile developers care about it?
RTOS and GPOS
To understand the importance of an RTOS, let's first understand what a "General Purpose Operating System" (GPOS) is. As you may already be familiar with GPOS, a general-purpose operating system is the operating system on the devices we use every day, such as smartphones and PCs (eg, Android, Windows, etc.).
The "universal" in a general-purpose operating system means that the OS must achieve multiple goals, such as providing a good user experience, being compatible with different hardware to run different types of programs, and providing customization options.
GPOS tends to work in conjunction with hardware, with each processor core running a single thread of execution at a time. The operating system's scheduler decides which program to run and when to quickly switch between programs, giving the user the illusion of programs executing concurrently to provide a good overall user experience.
Real-time operating systems, on the other hand, are designed to provide predictable execution patterns, ensuring that processes obey the timing constraints of time-constrained systems (i.e., processes execute at a specific frequency, otherwise the system as a whole fails). Therefore, RTOSs are usually lightweight and small compared to GPOSes, and are usually only capable of running certain classes of applications on specific hardware.
RTOS can be divided into:
• Soft RTOS: Timing constraints can usually be met; the preemption period is often only a few milliseconds.
? Quasi-real-time RTOS: has a certain time limit, but not strict, may cause undesired but acceptable effects.
• Hard RTOS: Make sure the timing constraints are met. Hard RTOSs are typically chosen for mission-critical applications, such as real-time systems in robotics and drones. The preemption period of a hard RTOS is generally within a few microseconds.
Like GPOS, RTOS provides some or all of the basic functions of the operating system, such as thread synchronization, inter-process communication (eg, well-known pipes), timers, memory management, etc. However, an RTOS must meet the timing constraints of the underlying system and target application to provide this functionality.
meet the time limit
There are many factors that allow an RTOS to meet timing constraints, however, task scheduling and interrupts deserve special mention.
For GPOS, processing scheduling is often accompanied by high throughput (ie, the total number of processes completing execution per unit time). However, this may mean delaying the execution of a high-priority process in order to handle multiple lower-priority tasks. On the other hand, the value of an RTOS is in the speed or predictability of the system's response, not in the amount of work performed in a given amount of time.
In an RTOS, scheduling is usually based on priority. Most RTOS use a priority-based preemptive task scheduling method, and the low-priority process is processed after the high-priority process is executed. When using GPOS, latency can accumulate as more threads need to be scheduled. However, RTOS does not have such a problem, because the delay of all processes and threads is time-limited. Additionally, RTOSs provide a means of securing shared system resources from concurrent access.
RTOS's kernels are preemptible, while GPOS kernels are not, which is important when dealing with high priority processes and threads first. Without a preemptible kernel, requests in the kernel (such as those from drivers or system services) override all other processes and threads. With an RTOS, only very important service requests are kept in kernel calls, other service requests are treated as external processes and threads. Kernel-based servicing requests are associated with RTOS bounded latencies to maintain fast and predictable responses.
QuRT® software
Qualcomm Technologies processors, such as the Qualcomm® Hexagon™ DSP in the Qualcomm® Snapdragon™ 8 Series Mobile Platform , come with an embedded RTOS: QuRT1.
QuRT has many features, such as multi-threading, mutual exclusion, semaphore, timer, interrupt handling, memory management, etc. It can execute programs and threads in a separate protected address space, improving system security and stability. Developers can write C/C++ user programs, utilize QuRT, and/or write assemblies using the Hexagon DSP SDK, and utilize QuRT APIs to access RTOS services . User programs can access the global heap and contain the main thread call stack, data and text segments, and have the ability to allocate other heaps and threads.
As explained on the QDN Hexagon DSP SDK page , because QuRT maps user software threads to the processor's hardware threads, the programmer does not need to be concerned with the underlying threading model. Furthermore, QuRT can globally schedule the highest-priority runnable software thread and direct interrupts to the lowest-priority hardware thread.
Additionally, QuRT manages software/hardware watchdog timers to detect and reset system faults.
in conclusion
RTOSs are a critical part of ensuring predictable and timely execution of embedded devices, such as those used in IoT, robotics, and mobile devices. Therefore, the goal is to provide time-constrained applications with assistance services that must execute within a certain time frame, while minimizing latencies, such as those caused by interrupts and switching threads.
QuRT RTOSs provide developers with a platform to achieve these goals, and SDKs like the Hexagon DSP SDK have rich APIs that help developers leverage the capabilities of RTOSs.
Now that we've roughly explained what an RTOS is, I'd love to hear how you've leveraged an RTOS in your development process. If you are working on an interesting project, you may wish to submit it to our project page.
1QuRT can also be found on other Qualcomm Technologies chipsets such as QCA4020.
1Qualcomm Technologies other chipsets, such as the QCA4020 , are also equipped with QuRT.
For more Qualcomm development content, please refer to: Qualcomm Development Community .