Hello! Welcome to Embedic!
This website uses cookies. By using this site, you consent to the use of cookies. For more information, please take a look at our Privacy Policy.
Home > Embedded Events > How to Choose an Embedded System Operating System: A Selection Guide

How to Choose an Embedded System Operating System: A Selection Guide

Date: 08-09-2022 ClickCount: 238

In the previous article, "How to Choose an Embedded System OS: OS Features," we discussed the system features that teams weigh when choosing an OS. We saw features such as product lifecycle cost, physical characteristics, real-time performance, library integration, and security come into play (to name a few). Today's post will explore exactly when and where it makes sense to use bare metal, RTOS, and Linux. Remember that these general guidelines vary from industry to product and even from product to product.

 

When to use bare metal (no OS)

As you look at marketing headlines about connectivity, IoT, machine learning, and other cutting-edge topics, you might think every embedded system needs an operating system. Unfortunately, that impression is far from the truth! While many cutting-edge technologies may benefit from an operating system, you can survive without an RTOS or Linux for a significant number of applications. If you look at the 2019 Embedded Market Survey, you'll find that about 50% of projects are bare metal!

 

There are several situations where it would make sense not to use an OS. First, if you use an 8-bit or 16-bit microcontroller, you will almost always want to use bare metal or a lightweight collaborative scheduler. Many OS developers will not port their software to smaller architectures because these systems are already processor and resource constrained. Adding an OS typically consumes too many clock cycles and makes the system inefficient.

 

Next, bare-metal solutions make sense in applications where the microcontroller pin count is low and available flash and SRAM are limited. When working in a resource-constrained environment, every byte and every clock cycle impacts whether the product is available. If the microcontroller is resource constrained, the most effective solution may be not having an operating system.

 

Finally, bare metal may make sense for your application if you are dealing with a "simple" control application that does not have any connectivity or high-performance processing requirements. One of the key drivers for using operating systems in embedded systems today is the need to support infrastructure code. For example, sensors connected to the Internet must connect to the cloud, manage security partitions, perform security updates, run DSP algorithms, and so on. An operating system can help manage the time and resources for all of these activities, but if you don't have these components, you may not need an operating system.

 

When to use a real-time OS

The door to an operating system begins when the microcontroller's onboard resources reach a minimum clock speed of 40 MHz and have at least 64 kilobytes of flash memory and 8 kilobytes of RAM. By doing less, you will spend more time fighting the demands of the RTOS than the demands of the application. For example, each task has its stack when you use the RTOS. The stack requires at least 512 - 1024 bytes of SRAM. You will quickly run out of memory if your design requires six tasks. You may need more flash and RAM to build a proper system.

 

When deciding whether to use an RTOS or bare metal, I asked myself a few questions.

  • Will adding a real-time operating system simplify the software architecture?
  • Would adding a real-time OS improve software maintainability?
  • Will the real-time performance of the application be improved?

The RTOS tool should provide value to the application and the entire software development lifecycle. If RTOS is a barrier, I should not use it just because I want to use it.

 

There are specific applications where it makes immediate sense to use RTOS. For example, I almost always use RTOS if I'm developing an IoT product. This is because RTOS provides tools and mechanisms to manage low-level resources and break applications into semi-independent programs easily. When the application is complex, it makes sense to break it down into tasks. For example, IoT products often require several tasks to manage connectivity, not to mention the final application. Another example is a device with a display, although sometimes these applications are best suited for multi-core processors.

 

When to use Linux

Using Linux in embedded systems has become a popular choice in recent years. Part of the reason for Linux's popularity is that it offers a full-featured operating system with all the bells and whistles that come with it. Linux comes with a large number of libraries and features. Developers can take advantage of multitasking and even real-time patching of the kernel. In addition, the hardware cost to run Linux has dropped dramatically over the past five years, making it an exciting solution for specific applications.

 

I would consider the following points when considering whether a project can use embedded Linux. First, the product must be able to support the financial cost of the hardware. I recently had a client I helped redesign their product for the third time because the previous two designers could not meet the manufacturing price target. The product's target audience was willing to pay about $40 for the product. The original designers had built a system using Linux with a bill of materials cost over $100! Redesigning the product using a microcontroller and the OS's RTOS, I reduced the BOM to about $11. That's the difference between having a sustainable company and one that doesn't exist.

 

The second point to consider when using Linux is the volume of the product. If you have a small volume of products, the user may have paid more than that amount. When you look at the trade-off between non-recurring engineering costs and product costs, you may find that using Linux can significantly reduce NRE and time to market. Linux may make more business sense if the customer does not price sensitive.

 

Finally, we must not forget that Linux provides powerful abstractions, services, and libraries that can simplify engineering. We can use Linux to simplify how we interact with the hardware if we have a very complex product. We can use more modern programming languages such as Python. We can customize the kernel if needed. Linux is very well suited for many embedded applications. If you need flexibility and the ability to take advantage of existing libraries, Linux may be a great choice for your application.

 

Conclusion

Choosing an operating system for an embedded product can make or break a project. Being too lightweight can lead to more effort and time the development team spends to make things work properly. On the other hand, too much weight can lead to a higher bill of materials costs. As we have seen, choosing the right operating system for your application comes down to weighing what is most important to your team and your users.

  • How to choose an embedded system operating system: operating system features
  • Introduction to the features of some EOS

Hot Products

  • PIC16F627-20/SO

    Manufacturer: Microchip

    IC MCU 8BIT 1.75KB FLASH 18SOIC

    Product Categories: 8bit MCU

    Lifecycle:

    RoHS:

  • TMS320C6746BZCED4

    Manufacturer: Texas Instruments

    IC DSP FIX/FLOAT POINT 361NFBGA

    Product Categories: DSP

    Lifecycle:

    RoHS:

  • TMS320C6746BZWTA3

    Manufacturer: Texas Instruments

    IC DSP FIX/FLOAT POINT 361NFBGA

    Product Categories: DSP

    Lifecycle:

    RoHS:

Customer Comments

  • Looking forward to your comment

  • Comment

    Verification Code * 

Compare products

Compare Empty