Introduction to Real-Time Operating Systems (RTOS) for Use in Embedded Systems
Discover how and when to use Real Time Operating Systems (RTOs) in your own tech product. This tutorial will cover all the basics and how to use an RTOS in embedded systems based on microcontrollers.
Written by Andrey Solovev, Chief Technical Officer at the design firm Integra Sources. Andrey is also one of the experts available to help you inside the Hardware Academy.
There is a perception that a real-time operating system is closely connected with high-end technology and complicated devices that perform life or death operations. This is just partially true.
Today, an RTOS can be used in almost every chip to complete different kinds of tasks, and they don’t need to all be critically important. This article and tutorial will help you explore RTOS opportunities for your own project.
What is an Operating System (OS)?
Before we start talking about RTOS, let’s look briefly at what an operating system is. Generally, an operating system, or OS, is the life support system of a computer.
This is a piece of software that ensures the operation of the hardware and is responsible for the interaction between the hardware and the applications that run on the computer.
An operating system fulfills a number of significant functions including the management of the CPU, memory, and peripheral devices of the computer. Also, an OS mediates between the user and the machine providing a user interface and services for all applications.
However, there are cases where you may not need an operating system. In these cases, all the operations should be preset by a developer, and the task execution is ensured by the developed algorithms.
This works well for simple systems with plain hardware and a small number of tasks or when a microcontroller (MCU) or any other chip does not support an operating system.
Overall, an operating system is still the most effective solution for multi tasking. Using an OS saves the user time and effort by eliminating the need for a significant amount of programming.
What is a Real-Time Operating System (RTOS)?
An operating system deals with many different tasks, some of which are critical and must be executed immediately, for example with real-time applications. Other tasks may be lower-priority, and there are also cases when non-performance or even late performance of a high-priority task can be crucial.
An operating system, which may also be called a general-purpose operating system, is able to execute both critical and noncritical tasks according to the prioritization set by the developer.
The main problem is that what a GPOS is able to do in theory, may not translate into practice. For example, A GPOS may switch from a critical task to another operation, completing the critical task only when the opportunity arises.
So how can you get a guarantee that a high-priority task will be executed in due time without any delays? By using a real-time operating system or RTOS. This is a type of OS that ensures the execution of tasks takes place within the specified time frame.
By applying limitations to the execution time, an RTOS allows for running real-time applications that need an immediate response. This type of response is normally measured in milliseconds or even microseconds.
The use of RTOS is extra important for systems involved with the healthcare, automotive and aerospace industries, or any other system where failure could be catastrophic or life threatening.
RTOS is commonly used in embedded systems based on microcontrollers, so let’s elaborate on this further.
RTOS Concepts and Principles
A real-time operating system provides a deterministic approach that excludes anything that is random from the sequence of operations performed on a system. In other words, the system behaves in a predictable way.
Provided that the algorithms are developed and implemented correctly, an RTOS ensures proper resource management so that a task is executed with exact timing. The timing behavior of an RTOS is considered deterministic.
Except for the guaranteed timing, an RTOS ensures task switching at the interval of every quantum. Tasks get interrupted and preempt each other according to the prioritization set by a developer. This is called preemptive scheduling.
Scheduling is an important procedure for an OS performance which manages the waitlist of tasks and determines the event sequence in accordance with the predefined priorities.
In RTOS scheduling, which is preemptive, any process can be interrupted by a high-priority task whenever it is assigned. Thus critical tasks will always preempt low-priority tasks.
The opposite of preemptive scheduling is non-preemptive or cooperative scheduling. An RTOS with a cooperative scheduler was the early version of a real-time operating system and it didn’t allow interrupting and switching to another task until one of them is completed or put in a waiting state.
In preemptive scheduling, tasks switch in equal time periods while in non-preemptive scheduling, there is no strict timing in task switching.
Another important principle established by an RTOS is priority inheritance. This takes place when lower-priority and higher-priority tasks share one and the same system resource.
To release the resource as soon as possible for a high-priority task, a thread with low priority gets blocked and then restored so it passes its critical section.
In other words, the task inherits priority and as soon as the critical part of the operation is completed, the prioritization returns to the initial state.
The priority inheritance does not work for a GPOS: a high-priority task will have to wait until a low-priority task passes all the sections and then gets executed. It means that a high-priority task may be delayed for an unpredictable amount of time.
Low-priority threads in a GPOS do not inherit the priority of higher-priority threads. This chart shows a system with two threads, but it can have many more.
The principles described above show the reliability of RTOS, especially for real-time applications that need predictable latencies. This is how RTOS works: you always know the exact response time of any operation that runs on your system.
Thus, a real-time operating system is the absolute leader in RTOS vs. OS competition when it comes to responsiveness.
RTOS in Embedded Systems
Modern systems require better functionality, more options, and opportunities. That is why the popularity of real-time operating systems is rapidly growing in the world of embedded solutions.
Guaranteeing the timely execution of high-priority tasks is extremely important for critical or life saving applications and real-time systems that have strict deadlines.
Today, an RTOS can be installed in almost every modern MCU. In fact, my team implemented RTOS applications in almost all MCU-based projects that we delivered within our electronic design services in the past six years.
This type of operating system gives a broad range of opportunities. So why use embedded RTOS in MCUs?
One of the most obvious reasons is multitasking. This is unnecessary with a simple system that only has a couple of tasks running in sequence. But if you need to perform many tasks simultaneously, RTOS is at your service. It allows the developer to run a number of tasks concurrently.
In case your embedded system has strict task prioritization, the preemptive scheduler of an RTOS makes it possible to switch to a high-priority operation at any time, ensuring that it will be completed first. A developer has no need to control the task execution because an RTOS takes care of it.
An RTOS gives developers the ability to multithread and synchronize, which makes their job easier. Without RTOS, the implementation of these options will take much more effort.
One side effect you may encounter when using an RTOS is memory issues. It isn’t the RTOS itself that needs the memory resources but rather the multiple tasks that you can complete in real-time. So you need to make sure your MCU has enough RAM to accommodate a real-time operating system.
The lack of CPU core resources may also be a matter of concern for an RTOS solution. The overhead will depend on a particular microcontroller and its functionality.
The chip characteristics together with the project requirements should be taken into consideration if you decide to go with an RTOS.
For example, the nRF52832 is a multi-purpose system on a chip (SoC) offered by Nordic Semiconductor which is widely used with BLE-based applications. It is certainly compatible with an RTOS solution.
In one of our projects, we developed a tracking system with BLE devices based on the nRF52832. We had to abandon the idea of using an RTOS with this chip so that we could reduce power consumption.
Another example is connected with the development of an ECG device based on the BGM113 which is a BLE module developed by Silicon Labs. We did not use an RTOS solution in this project so we could save memory resources of the MCU.
Of course, you can do without an RTOS and still keep to the deadlines of real-time applications.
For example, you can use a state machine and interrupt handlers to design all the necessary algorithms for an MCU to enable some kind of multitasking, synchronization, and other helpful features.
To implement all of this, however, you will need additional development resources. That’s something that most companies try to avoid. That is why RTOS is preferred over bare-metal programming.
A real-time operating system distributes resources, takes control of all the operations, and saves time.
How to Choose an RTOS
An RTOS can assist your project in a number of ways. Before choosing an RTOS, make sure your MCU-based system really needs an RTOS solution.
RTOS solutions are needed for the following:
- If you need to run numerous tasks simultaneously for meeting specified deadlines
- If high-priority tasks need a guarantee of immediate execution
- If a timely response is crucial for the system and the latency should be predicted
To make the use of an RTOS efficient in our firmware development, we always pay careful attention to the capabilities of the hardware and the requirements of the software.
Here is a brief checklist of the most important things you should keep in mind when deciding on an RTOS solution:
- Check out the potential of the CPU core that is used in the microcontroller and whether an RTOS can run on it.
- Check out the RAM capabilities. If there is not enough RAM available, you should probably think of selecting another chip.
- Make sure you are able to get all the necessary software to adjust an RTOS to your hardware. These may include board support packages, drivers, libraries, etc.
- Check out the availability of development and debugging tools.
- Ensure the availability of the required RTOS documentation and/or a vast developer community.
Also, think about the budget you are prepared to allocate for RTOS integration. Choosing between a commercial RTOS and an open-source solution depends on both the development and financial resources available.
There are various options available among either open-source or commercial products. Real-time operating systems provided under a paid license are normally backed up by technical support, documentation, and development tools. However, it depends on the vendor.
So before buying a license, make sure you have everything you need to smoothly install and run an RTOS on your device.
Commercial vendors provide regular updates and security patches that facilitate the maintenance of the system.
Some examples of commercial RTOSes include VxWorks by Wind River Systems, QNX by Blackberry, Integrity by Green Hills Software, embOS by SEGGER, ThreadX by Microsoft Express Logic.
These RTOSes are generally designed for embedded systems and are able to support the most frequently used hardware platforms. In any case, you should double-check the compatibility of an RTOS with your MCU architecture.
An open-source RTOS is a flexible solution that provides more opportunities for customization. However, it puts additional load on a developer due to the absence of regular support and off-the-shelf tools necessary for RTOS operation.
So if you decide on an open-source solution, we highly recommend you choose an RTOS with a large developer community. You will be more likely to get assistance with development tools, updates, and security patches.
Among the open-sources RTOSes there are FreeRTOS, Zephyr, RTLinux, eCos, RIOT, and many others.
FreeRTOS is one of the most popular open-source RTOSes used in MCU-based embedded systems. We used it in a number of recent projects. We also recommend it newbies in the development of real-time applications and OS integration.
FreeRTOS is compact so it can run on any small-sized chip. It is quite fast and it maintains task concurrence at high speeds, providing a timely response for the required operations.
One of the most important advantages of FreeRTOS is its high portability. It is supported by all major hardware platforms including ARM, Atmel AVR, PIC, x86, and many others.
All in all, it is really hard to single out the best RTOS in an open-source vs commercial RTOS comparison. A commercial RTOS may not be as cost-effective and flexible as an open-source RTOS. However, you will not benefit from an open-source solution if you don’t have in-house expertise or a strong developer community.
The basic characteristics such as RTOS security, performance, and platform compatibility depend mostly on each particular product irrespective of the license type.
Conclusion
A real-time operating system provides an immediate response within a predictable timeframe. It is the most obvious option for systems that need to perform high-priority tasks with critical deadlines.
The major advantage of using an RTOS in a microcontroller is that it makes the development process less painful, which saves you time and effort.
When compensating for the microcontroller’s limited capabilities, an RTOS undertakes resource management, sorts out priorities, and keeps task concurrence.
As soon as you have made up your mind about using an RTOS in your project, you can find a suitable solution among a wide range of various embedded RTOS solutions. There are options for any hardware platform offered by either proprietary vendors or open-source projects.
It’s always best to try to optimize the development process to make it more efficient and less time-consuming. One way to do that for many projects is through the use of an RTOS.
Other content you may like:
- Microcontroller or Microprocessor: Which is Right for Your New Product?
- How to Create a Graphical User Interface (GUI) for Your Product
- 5 Common Pitfalls to Avoid in Hardware Design
- How to Use the ESP32 Wireless Microcontroller with the Arduino IDE
- How to Choose the Right Arduino Board for Your Project
A nice introduction, but it does suggest that using an RTOS will ensure the desired real time behavior. Whilst it mayl yield deterministic behavior it will only do so if the designer has performed sufficient analysis of the implementation e.g. if you have a medium priority task that must be scheduled every 1mS, but a high priority task that is scheduled to run every 100mS but executes for 1.3mS then your medium priority task is going to miss its deadline every 100mS.
Another issue if you are going to achieve the desired response to an event is to ensure that the kernel is pre-emptable and the maximum latency from an event trigger is suitable (if the kernel is not pre-emptable and is currently executing a task that takes 1ms then you may have a 1ms latency between an event and its response.
Using a commercial RTOS is no guarantee of reliability or fast turn around when the product has a bug (and NO software is bug free). When you encounter a problem you are placed somewhere in the vendors priority queue and if you are low priority you make not get serviced for a long time 🙂
Given the low cost / availability of hardware and the relatively high cost of software development it is well worth considering offloading the hard real time code to a simple dedicated subsytem and then the less critical functionality can be readily implemented in a Linux environment
Hello Robert!
You’re right, but the main idea of this article was to introduce RTOS at a high level without giving deep details.