First, Concurrency

The efficiency of concurrent programming is low when writing bare-metal software, as there is inevitably a large while(1) loop in the main program that contains almost all business logic of the project. Each business logic section has delay loops, which causes all logic to work in a serial manner. This results in CPU wasting a lot of time in delay functions, leading to very poor software concurrency efficiency.

Second, Modularity: High Cohesion and Low Coupling Principles

From a software engineering perspective, we emphasize high cohesion and low coupling principles in software development. However, modular development in bare-metal programming is very difficult, as the coupling between modules is heavy, making it impossible to use bare-metal development in large projects.

Continuing with the example of the large while(1) loop in the main function, one can imagine how many functions are tightly packed into one function, making modular development extremely challenging.

A very relevant example is in projects that use watchdog timers. If delay functions are used, 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 results in a feeling that a simple delay function also requires consideration of feeding the watchdog, leading to excessive concerns in bare-metal development, making it unsuitable for large projects.

Third, Ecosystem: Many Advanced Software Components Depend on Operating Systems

For example, I open-sourced a Modbus master protocol stack based on FreeModbus a few years ago. Considering platform adaptation issues, I initially planned to support various operating systems, even bare-metal platforms. Adaptation across different operating systems was easy, but adapting to bare-metal proved to be very complex, with some functions being particularly complicated and lacking universality across different bare-metal environments, consuming a lot of effort. Hence, I ultimately abandoned bare-metal adaptation, and to this day, the Modbus master protocol stack cannot be used 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.

Fourth, Real-Time Performance: Complex Functions Cannot Guarantee Real-Time Performance

Real-time performance is required in certain fields, where each step of the software must be triggered within a specified time. The industrial control field is a common scenario; if real-time performance cannot be guaranteed, mechanical devices may fail to act according to specified timing requirements, leading to mechanical accidents and even endangering lives. Looking back at bare-metal software, as the software grows larger, one can imagine the large while(1) loop in the main program, with severe code coupling and numerous delay functions, making it nearly impossible to ensure real-time performance.

Fifth, Reusability: Poor Software Reusability Leads to Repeated Wheel Invention

Reusability is directly related to modularity. Everyone wants to avoid repetitive work, and the same goes for writing code, where one aims to write as little similar code as possible. However, in this fragmented embedded era, 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 low-level hardware, making the process of reinventing the wheel unavoidable.

Advantages Brought by Operating Systems

The first time I encountered an operating system was around 2010, when STM32 began to gain popularity. Many people were running operating systems on these powerful microcontrollers, and I also ported ucos, running ucgui on it. Writing applications at that time was a completely new experience, much more enjoyable. After a year of using ucos, I came across our domestic RT-Thread, which had many ready-to-use components. After trying it out, I found it even better, and I have been using it ever since, about 8 years now. Let me share the advantages of operating systems:

Thread-based concurrent task handling solves modularity issues while ensuring real-time performance.

1. Modularity

After using an operating system, the entire software work is divided into multiple tasks (also known as threads), each thread has its own independent running space, i.e., thread stack. At this point, each thread can operate independently, enhancing the degree of modularity.

2. Concurrency

From the perspective of concurrency, when threads use delay/event wait functions, they automatically yield the CPU to other threads that need it. This not only reduces the effort spent on writing delay functions, but also improves 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 less important threads can be set to lower priority. With proper global planning, the overall real-time performance of the software can be ensured.

4. Development Efficiency

Operating systems provide a unified abstract interface layer that facilitates the accumulation of reusable components, improving development efficiency.

Operating systems are the result of the wisdom of many software experts, who have encapsulated and abstracted many common software functions 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 functions are ready to use, making it very convenient for developers.

Some operating systems, like Linux and our domestic RT-Thread, have unified encapsulated standard hardware operation interfaces for fragmented hardware, generally referred to as device driver frameworks. This allows application software engineers to focus on application work without worrying about changing hardware and the need to reinvent the wheel.

5. Software Ecosystem

The richness of the ecosystem leads to a qualitative change (from self-playing to collective playing).

The improvement in modularity and reusability brought by using operating systems enables 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 in need, maximizing the value of software.

I personally feel this is a meaningful endeavor. 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 opportunities for in-depth communication about embedded software. After all, everyone’s code differs due to different chips or hardware; your code may not run on someone else’s setup. However, since using operating systems, the reusability of software has increased, allowing more people to quickly use my open-source software, leading to more interactions and connections with experts, even friends from abroad. As the saying goes, “A rising tide lifts all boats,” my skills have rapidly improved as well. Therefore, in summary, having a community to discuss embedded software is quite important; working in isolation may lead to redundant efforts in reinventing the wheel.

Common RTOS Advantages Comparison

The reason for choosing ucos/freertos/RT-Thread is that they have been around for a long time, are well-known in the market, and have a significant user base, making them more convincing.

1. Basic Functions and Performance

Differences between various RTOS are minimal, and comparability is not very high.

2. Usability/Readability

In this regard, FreeRTOS is arguably the worst due to its unique Hungarian naming convention and heavy use of macros, resulting in poor readability. ucos has decent readability with comprehensive comments. RT-Thread excels in this area with a Linux-like code style and object-oriented design pattern, ensuring concise and understandable code while maintaining a small footprint (minimum ROM: 3K RAM: 1.5K). It also adopts features like Linux device driver framework, virtual file system, and Shell, making the design more elegant.

3. Component Richness

Compared to traditional UCOS and FreeRTOS, RT-Thread not only has comprehensive basic functionalities, but also offers over 50 reusable software components, along with many IoT components, making it nearly plug-and-play for IoT products. RT-Thread can also run scripts in high-level languages like Python, Java, and Lua, further lowering the development difficulty.

4. Development Resources

UCOS excels in this area, providing related books. FreeRTOS, being a latecomer, has a lot of online resources available. RT-Thread previously lacked in this area, but now it is taking it seriously, as evidenced by the increasing number of application notes and accompanying instructional videos on their official website.

5. Copyright

UCOS commercial use incurs fees, while FreeRTOS and RT-Thread have more lenient copyright policies, especially RT-Thread, which has recently adopted the Apache license.

6. Community Ecosystem

All three RTOS have relatively active communities. It can be observed that the number of users for UCOS is gradually decreasing, while the number of users for RT-Thread and FreeRTOS is on the rise. RT-Thread is also the most widely used domestic RTOS, boasting the largest embedded open-source software community in the country.

Disclaimer:This article is an original work by the author. The content reflects the author’s personal views, and the reprint by Electronic Enthusiast Network is merely to convey a different perspective, not representing the endorsement or support of this viewpoint by Electronic Enthusiast Network. If there are any objections, please contact Electronic Enthusiast Network.

More Exciting Articles to Read

• 135 million confirmed cases worldwide! Work stoppages, unpaid leave, pay cuts, surviving through the winter!

• Facial recognition photos for 20 cents each traded in secret! How to ensure security in facial recognition applications?

• Huawei invests 66 million in Zhongdian Instruments, will the domestic testing instrument landscape change?

• Dissecting Huawei P40: Strengthening “de-A” and furthering domestic production.

• Active noise cancellation and sound quality enhancement, the future direction of TWS headphones.