Technical Articles
2025-01-03

Should You Use RTOS?

Follow+Star Public Account Number, don’t miss wonderful content

Should You Use RTOS?

Author | strongerHuang

WeChat Public Account | Embedded Column

RTOS：Real-Time Operating System.

Some beginners and engineers who have just started working have such doubts, so today I will share this topic: Should you use RTOS?

Review of Bare-Metal Era

When first learning microcontrollers, it basically starts with bare-metal programming, and the classic “project” is the running light, which is also the beginning of your learning of microcontrollers. However, as learning deepens, the problems exposed by bare-metal programming become more and more numerous. Here I will summarize them:
1. Concurrency: Low efficiency of concurrent program execution
When writing bare-metal software, there inevitably exists a super large while(1) loop in the main program, which almost contains all the business logic of the project.
Because each business logic will basically have a delay function like a loop waiting function, this leads to almost all business logic working serially.
At this time, the CPU will waste a lot of time in the delay function, running in circles, resulting in very poor software concurrency efficiency.
2. Modularity: High cohesion, low coupling principle
From the perspective of software engineering, we emphasize the principle of high cohesion and low coupling when developing software. However, modular development of bare-metal is very difficult, with heavy coupling between modules, which also leads to the inability to use bare-metal for large projects.
Still using the example of the large while(1) in the main function, one can imagine that so many functions are tightly squeezed into one function, making it impossible to split, and modular development faces numerous difficulties.
A very relevant example is in some projects using watchdogs, where if a delay function is used, one must be cautious; if the delay is too long and the main function cannot feed the dog in time, the watchdog will be triggered.
This ultimately creates a feeling that even a simple delay has to consider the watchdog function, causing too much worry during bare-metal development, making it naturally unsuitable for large projects.
3. Ecosystem: Many advanced software components must rely on the operating system to function
For example, a few years ago, a Modbus master protocol stack based on FreeModbus was planned to support various operating systems and even bare-metal platforms, due to the need to consider platform adaptation. Adapting to various operating systems was very easy, but when attempting to adapt to bare-metal, it turned out to be very challenging. Some functions are very complicated to implement on bare-metal, and there is almost no universality for different bare-metal environments, which is too time-consuming. Therefore, I ultimately gave up on adapting to bare-metal, and to this day, I have not used this Modbus master protocol stack on bare-metal.
Some software cannot run on bare-metal, such as WiFi SOC SDKs provided by Espressif, Realtek, TI, and MediaTek, as well as some Bluetooth SOC SDKs, which only support operating systems.
Therefore, if you do not understand or cannot use an operating system, these chips will not work.
4. Real-time performance: Real-time performance cannot be guaranteed in complex functional situations
Real-time performance of software has certain requirements in some fields, where each step of the software must be triggered within a specified time.
The industrial control field is the most common scenario where if real-time performance cannot be guaranteed, mechanical devices may not be able to act according to specified timing requirements, leading to mechanical accidents and even threatening human life.
Returning to bare-metal software, if the software becomes large, one can imagine that in the main program, such a large while(1) loop with severe code coupling and numerous delay functions makes it almost impossible to guarantee real-time performance.
5. Reusability: Poor software reusability, always reinventing the wheel
Reusability is directly related to the degree of modularization. I believe that everyone does not want to do a lot of repetitive work at work, and similarly, when writing code, one also wants to write as little similar functionality as possible.
However, in this era of extreme fragmentation in embedded systems, with various chips, making the same code adaptable to different hardware in a bare-metal environment is very challenging. This leads to bare-metal code being overly dependent on underlying hardware, making the process of reinventing the wheel inevitable.

Advantages Brought by Operating Systems

The first time I encountered operating systems was when I was in college, when STM32 had already become popular. This powerful microcontroller had many people running operating systems on it, and I also ported uCOS and ran ucgui on it. Writing applications at this time was a completely new experience.
Later, in projects, I basically used RTOS unless under special circumstances.
Having used RTOS for years, I would like to share the advantages of operating systems:
Thread-based concurrent task processing, solving modularity issues while ensuring real-time performance.
1. Modularity
After using an operating system, the work of the entire software is divided into multiple tasks (also known as threads), each thread has its own independent running space, namely thread stack, allowing each thread to operate independently without interference, greatly improving the degree of modularity.
2. Concurrency
From the perspective of concurrency, when various threads use delay/event waiting functions, they will automatically yield the CPU to other threads that need it. Not only does this reduce the concerns about writing delay functions, but it also improves the overall CPU utilization, ultimately enhancing concurrency.
3. Real-time performance
Looking at real-time performance, RTOS like uCOS/RT-Thread are designed to be real-time operating systems, where each thread has different priority levels. Important threads can be set to high priority, while unimportant threads can be set to lower priority, ensuring that overall planning is well managed, thus guaranteeing the real-time performance of the entire software.
4. Development Efficiency
Since operating systems provide a unified abstract interface layer, they facilitate the accumulation of reusable components and improve development efficiency.
Operating systems are the crystallization of wisdom from a group of software experts, who, from the perspective of application software and low-level driver development, have encapsulated and abstracted many common software functionalities, such as: semaphores, event notifications, mailboxes, circular buffers, singly linked lists/doubly linked lists, etc. These functionalities are ready to use, making it very convenient for developers.
Additionally, some operating systems, such as Linux and our domestic RT-Thread, have unified encapsulated a standard hardware operation interface for fragmented hardware, generally referred to as device driver frameworks. This allows our application software engineers to focus on application work without worrying about changing hardware and having to reinvent the wheel.
5. Software Ecosystem
The richness of the ecosystem brings a process of qualitative change (from self-play to collective play).
The improvement in software modularity and reusability brought by using operating systems also allows us to encapsulate a set of reusable components based on operating systems suitable for embedded systems during our software development, which can not only be used in our own projects but can also be open-sourced to share with more embedded developers in need, maximizing the value of software.
Personally, I feel this is a very meaningful thing. I am also an open-source enthusiast and have open-sourced some embedded software on GitHub. To be honest, before doing open-source software, there were very few places for in-depth exchanges on embedded software. After all, everyone’s code is either different chips or different hardware, and giving your code to someone else may not work. However, since using operating systems, the reusability of software has improved, allowing more people to quickly use my open-source software, leading to more exchanges and encounters with many experts, even friends from abroad. As the saying goes: “A rising tide lifts all boats”; my abilities have also rapidly improved since then. Therefore, summarizing, having a community to exchange embedded software is quite important. Building in isolation may just mean reinventing the wheel.

Common RTOS Advantages Comparison

μC/OS、 FreeRTOS、RT-Thread，The reason for choosing these three OS is that they have been around for a long time, are quite well-known in the market, and have been used by many people, making them more persuasive.
1. Basic Functionality and Performance
The differences between various RTOS are minimal, and comparability is not very high.
2. Usability/Readability
In this regard, FreeRTOS is probably the worst, with its peculiar Hungarian naming convention and extensive use of macros, making it very difficult to read.
μC/OS has decent readability, with comprehensive comments. The best in this regard is RT-Thread, which adopts a Linux-like coding style and object-oriented design pattern, with clean and understandable code. While ensuring a small footprint (minimum ROM: 3K RAM: 1.5K), it also borrows features from Linux such as device driver frameworks, virtual file systems, and shells, resulting in a more elegant design.
3. Richness of Components
Compared to traditional UCOS and FreeRTOS, RT-Thread not only has a complete set of basic functionalities but also boasts over 50 reusable software components, including many IoT components that can be used out of the box for IoT products. RT-Thread can also run scripts in high-level languages like Python, JavaScript, and Lua, further reducing development difficulty.
4. Development Resources
In this regard, μC/OS does the best, with related books available. FreeRTOS and RT-Thread are relatively newer and have a lot of related resources available online. However, RT-Thread is currently very focused on this area, as can be seen from the increasing number of application notes on their official website, along with some accompanying teaching videos.
5. Copyright
μC/OS 、FreeRTOS and RT-Thread all use open-source licenses, and their copyrights are quite permissive, see: µC/OS、FreeRTOS、RT-Thread、ThreadX open-source licenses.
6. Community Ecosystem
The communities for these three RTOS are quite active. It can be felt that the number of users for ucos is gradually decreasing, while the number of users for RT-Thread and FreeRTOS is increasing. RT-Thread is also the most used domestic RTOS among developers, and it also has the largest embedded open-source software community in the country.

Disclaimer:This article’s materials are sourced from the internet, and the copyright belongs to the original author. If there are any copyright issues with the work, please contact me for removal.

———— END ————

Reply in the background 『RTOS』『Operating System』 to read more related articles.

Welcome to follow my public account, reply “Join Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Welcome to follow my video account:

Should You Use RTOS?

Click “Read Original” to see more shares, welcome to share, collect, like, and view.

Related posts

Leave a Comment

Your email address will not be published. Required fields are marked *