This article will accurately explore when and where it makes sense to use bare metal, RTOS, and Linux.
In the previous article “How to Choose an Embedded System Operating System: Operating System Features“, we discussed the system features that teams need to consider when choosing an operating system. We saw that characteristics such as lifecycle cost, physical characteristics, real-time performance, library integration, and security play a role (just to name a few). This article will accurately explore when and where it makes sense to use bare metal, RTOS, and Linux. Keep in mind that these are general guidelines that will vary by industry and even by product.
When to Use Bare Metal(No Operating System)
When looking at marketing headlines about cutting-edge topics like connectivity, IoT, and machine learning, one might think that every embedded system requires an operating system. Unfortunately, this impression is far from the truth! While many cutting-edge technologies may benefit from an operating system, we can implement quite a number of applications without RTOS or Linux. If we look at the AspenCore 2019 Embedded Market Survey, we find that about 50% of projects are bare metal!
In several cases, it makes sense not to use an operating system. First, if we are using an 8-bit or 16-bit MCU, we almost always want to use bare metal or a lightweight cooperative scheduler. Many operating system developers do not port their software to smaller architectures because these systems are already constrained by processors and resources. Adding an operating system often consumes too many clock cycles, making the system inefficient.
Next, bare metal solutions make a lot of sense in applications with fewer MCU pins and limited available flash and SRAM. Working in resource-constrained environments, every byte and every clock cycle can impact whether a product is viable. If MCU resources are limited, the most efficient solution may be to go without an operating system.
Finally, if we are developing a “simple” control application with no connectivity or high-performance processing requirements, then bare metal may make sense for our application. One of the major drivers for using operating systems in embedded systems today is the need to support infrastructure code. For example, sensors that connect to the internet must connect to the cloud, manage secure partitions, perform secure updates, run DSP algorithms, and more. An operating system can help us manage the timing and resources of all these activities, but if none of these are involved, an operating system may not be necessary.
When to Use RTOS
When the built-in resources of the MCU reach a minimum clock speed of 40MHz, at least 64KB of flash, and 8KB of RAM, we can start using an operating system. If any resources are insufficient, more time will be spent meeting RTOS requirements rather than application requirements. For example, when using RTOS, each task has its own stack. The stack requires at least 512-1024 bytes of SRAM. If a design requires six tasks, memory will quickly run out. We may need more flash and RAM to build a suitable system.
When I decide whether to use RTOS or bare metal, I ask myself a few questions:
-
Will adding RTOS simplify the software architecture?
-
Will adding RTOS improve software maintainability?
-
Will the real-time performance of the application improve?
RTOS is a tool that should provide value for the application and the entire software development lifecycle. If RTOS is a hindrance, it should not be used just because one wants to use it.
In certain specific applications, using RTOS becomes immediately meaningful. For example, if I am developing an IoT product, I almost always use RTOS. This is because RTOS provides tools and mechanisms to easily manage low-level resources and break the application down into semi-independent programs. When an application is complex, breaking it down into tasks makes a lot of sense. For instance, IoT products often require several tasks to manage connectivity, not to mention the end application. Another example is devices with displays, although sometimes these applications are best suited for multi-core processors.
When to Use Linux
In recent years, using Linux in embedded systems has become a popular choice. Part of Linux’s popularity is due to its provision of a full-featured operating system with all the bells and whistles. Linux comes with a wealth of libraries and features. Developers can take advantage of multitasking and even real-time patches to the kernel. Additionally, the hardware cost of running Linux has significantly decreased over the past five years, making it an exciting solution for specific applications.
When considering whether a project can use embedded Linux, I consider a few points. First, the product must be able to support the financial cost of the hardware. I recently had a client for whom I helped redesign their product for the third time because the first two designers could not meet the manufacturing price target. The target audience for the product was willing to pay about $40. The initial designer built a system using Linux that had a material cost exceeding $100! By redesigning the product using MCU and RTOS for the operating system, I was able to bring the BOM down to about $11. This is the difference between a sustainable company and one that is not sustainable.
The second point to consider when using Linux is the product’s size. If we have a small batch product, the user may have already paid a larger amount. When we look at the trade-offs between non-recurring engineering costs and product costs, we may find that using Linux can significantly reduce one-time engineering (NRE) costs and time to market. If the customer is not price sensitive, Linux may make more commercial sense.
Finally, do not forget that Linux provides us with powerful abstractions, services, and libraries that can simplify engineering. If our product is very complex, we can leverage Linux to simplify our interaction with hardware. More modern programming languages like Python can be used. If needed, the kernel can be customized. Linux is very suitable for many embedded applications. If we need flexibility and the ability to leverage existing libraries, Linux may be an excellent choice for the application.
Conclusion
Choosing an operating system for embedded products can impact the success or failure of a project. Too lightweight an application can lead the development team to spend more energy and time making it work. On the other hand, an application that is too heavy can lead to higher bill of material costs. As we have seen, choosing the right operating system for our application comes down to balancing what is most needed by our team and users.
Author: Jacob Beningo, Source: EDN sister site Embedded
Reference original: How to select your embedded systems operating system: Selection guidelines, compiled by Franklin Zhao.
Copyright: This article is from the September 2022 issue of “Electronic Technology Design”, all rights reserved, no reproduction allowed.
♥Click 👇 the business card, follow me♥
1. How to Choose an Embedded System Operating System: Operating System Features
2. Why Design Patterns Are Rarely Used in Embedded Development?
3. The Bluetooth Chip with a Circuit So Simple It’s Ridiculous, Let’s Take a Look Together
