Author:Electronic Engineering Magazine, Typesetting by:Xiao Yu
WeChat Official Account: Chip Home (ID: chiphome-dy)
1. Concurrency
The efficiency of concurrent work in programs is low when writing bare-metal software. Inevitably, there will be a huge while(1) loop in the main program, which contains almost all business logic of the project. Because each piece of business logic will have a delay loop waiting function, this leads to all business logic working almost serially. At this time, the CPU wastes a lot of time in the delay function, constantly idling, resulting in very poor concurrent efficiency of the software.
2. Modularization: High Cohesion, Low Coupling Principles
From a software engineering perspective, we emphasize the principles of high cohesion and low coupling when developing software. However, modular development in bare metal is very difficult, with heavy coupling between modules, making it impossible to use bare metal for large projects.
Taking the earlier example of the main function’s huge while(1) loop, one can imagine that so many functions are tightly packed into one function, making it impossible to split, and modular development becomes extremely difficult.
A very fitting example is in some projects using watchdogs. If using a delay function, one must be cautious; if the delay is too long and the main function cannot feed the watchdog in time, the watchdog will be triggered. This creates the feeling that a simple delay must also consider the feeding function, and bare metal development requires too much attention, making it unsuitable for large projects.
3. Ecosystem: Many Advanced Software Components Depend on Operating Systems
For instance, I open-sourced a Modbus master protocol stack based on FreeModbus a few years ago. Considering platform adaptation issues, I originally planned to support various operating systems, even bare metal platforms. Adapting to different operating systems was very easy, but when trying to adapt to bare metal, I found it extremely difficult. Some functions are very complex to implement on bare metal, and there is almost no universality for different bare metal environments, consuming too much effort. So I ultimately gave up on bare metal adaptation, and to this day, this Modbus master protocol stack still cannot be used on bare metal.
Moreover, some software cannot run on bare metal, such as the WiFi SOC SDKs provided by Espressif, Realtek, TI, and MediaTek, and some Bluetooth SOC SDKs also only support operating systems. Therefore, if you do not understand or cannot use an operating system, you cannot use these chips.
4. Real-time Performance: Complex Functions Cannot Guarantee Real-time Performance
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. If real-time performance cannot be guaranteed, mechanical devices may not operate according to specified timing requirements, leading to mechanical accidents and even endangering lives. Looking back at bare metal software, if the software becomes large, one can imagine that a huge while(1) loop in the main program, with severe code coupling and numerous delay functions, makes it almost impossible to guarantee real-time performance.
5. Reusability: Poor Software Reusability, Always Re-inventing the Wheel
Reusability is directly related to the degree of modularization. I believe everyone wants to avoid repetitive work in their jobs, and similarly, when writing code, we want to write as little similar functionality as possible. However, in this extremely fragmented era of embedded systems, with various chips, making the same code adapt 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 re-inventing the wheel unavoidable.
Advantages of Operating Systems
My first encounter with operating systems was around 2010, when STM32 began to gain popularity. With such powerful microcontrollers, many people were running operating systems on them, and I also ported uCOS and ran uCGUI on it. Writing applications at this time was a completely new experience, much more enjoyable. After using uCOS for a year, I later encountered our domestic RT-Thread, which has many ready-to-use components. After trying it, I found it even better, and I have been using it ever since, for about 8 years now. I would like to share the advantages of operating systems:
Thread-based concurrent task processing solves modularization issues while ensuring real-time performance.
After using an operating system, the entire software’s work is split into multiple tasks (also called threads). Each thread has its own independent running space, i.e., thread stack, allowing each thread to operate independently, greatly improving modularization.
From the perspective of concurrency, when each thread uses delay/event wait functions, it automatically yields the CPU to other threads that need it, reducing the concern of writing delay functions and improving overall CPU utilization, ultimately enhancing concurrency.
Regarding real-time performance, RTOS like uCOS/RT-Thread are designed to be real-time operating systems. Each thread has different priority levels; important threads can be set to high priority while less important threads can have lower priority. After proper global planning, the overall real-time performance of the software can be guaranteed.
4. Development Efficiency
Operating systems provide a unified abstract interface layer, facilitating the accumulation of reusable components and improving development efficiency.
Operating systems are actually the crystallization of wisdom from a group of software experts. They encapsulate and abstract many common software functionalities from the perspective of application software and low-level driver development, such as: semaphores, event notifications, mailboxes, circular buffers, singly/doubly linked lists, etc. These functionalities are ready to use, making it extremely convenient for developers.
Some operating systems, like Linux and our domestic RT-Thread, unify the standard hardware operation interface for fragmented hardware, generally referred to as device driver frameworks. This allows our application software engineers to focus solely on application work, without the fear of changing hardware and having to re-invent the wheel.
The richness of the ecosystem brings about a process of qualitative change (from playing alone to playing together).
The improved 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 software development. These components can not only be used in our own projects but can also be open-sourced to share with more embedded developers, maximizing the value of software.
I personally feel this is quite meaningful. I am also an open-source enthusiast and have open-sourced some embedded software on GitHub. To be honest, before engaging in open-source software, there were very few places to deeply communicate about embedded software. After all, everyone’s code is either different chips or different hardware. Even if you share your code, it may not run. However, since using operating systems, software reusability has improved, allowing more people to quickly use my open-source software, leading to more communication and connections with many experts, even friends from abroad. As the saying goes: “A rising tide lifts all boats,” my abilities have rapidly improved since then. Therefore, summarizing, having a community to communicate about embedded software is quite important; working in isolation may lead to re-inventing the wheel.
Comparison of Common RTOS Advantages
Choosing uCOS/FreeRTOS/RT-Thread is based on their long history and good reputation in the market, with many users, which adds credibility.
1. Basic Functions and Performance
The differences among various RTOS are minimal, and comparability is not very significant.
In this area, FreeRTOS is arguably the worst due to its peculiar Hungarian naming convention and heavy use of macros, resulting in poor readability. uCOS has decent readability with comprehensive comments. RT-Thread performs well in this regard, adopting a Linux-like coding style and object-oriented design pattern, making the code concise and understandable. It maintains a small footprint (minimum ROM: 3K RAM: 1.5K) while borrowing features like device driver frameworks, virtual file systems, and shells from Linux, leading to a more elegant design.
3. Richness of Components
RT-Thread not only has more comprehensive basic functions compared to traditional uCOS and FreeRTOS, with over 50 reusable software components, but also offers many IoT components that are almost ready to use out of the box. RT-Thread can also run scripts in higher-level languages like Python, Java, and Lua, further reducing development difficulty.
In this aspect, uCOS performs the best, with accompanying relevant books. FreeRTOS, being a latecomer, has many resources available online. RT-Thread was previously somewhat lacking in this area, but now it places significant emphasis on it, as evidenced by the increasing number of application notes on its official website, as well as accompanying tutorial videos.
uCOS requires payment for commercial use, while FreeRTOS and RT-Thread have more lenient copyright policies, especially RT-Thread, which has recently adopted the Apache license.
The communities for these three RTOS are quite active. Currently, it can be felt that the usage of uCOS is gradually declining, while the usage of RT-Thread and FreeRTOS is increasing. RT-Thread is also the most used domestic RTOS among developers and has the largest embedded open-source software community in the country.
Previous Good Article Collection
Chip Home Selected Article Collection (1): Save it to read slowly
