Bare Metal vs RTOS: Which Is Better for Your Embedded System?
Bare Metal vs RTOS: Which Is Better for Your Embedded System?
Honest answer: There is no "better" approach to
developing and deploying embedded systems (i.e., a certified solution versus a
non-certified solution) across all use cases. The best way to determine which
will meet your specific needs is to review your system's hardware requirements,
your application goals, and your management preferences. Unfortunately, making
the wrong decision early in the lifecycle of an embedded project can cost you a
significant amount of time and money — money and time which most product teams
cannot afford.
The following guide provides information about both
development methods including their definition, the advantages of each method,
their disadvantages, and considerations to help you select the best option for
your next embedded project.
What does Bare Metal Programming Mean?
Bare metal programming means coding firmware that runs on a
microcontroller without an operating system. In other words, your program
interacts directly with registers, interrupts and peripherals through raw
hardware, and you have no operating system to manage scheduling or other
processes, so your code knows exactly when to run, how to use memory, and how
to handle interrupt signals. In addition, since there is no operating system
overhead (i.e. other tasks running in the background), your application will
execute all of the functions of your firmware directly on the microcontroller
hardware.
Typical structure of a bare-metal application:
- A main function that is executed continuously; either
polling the microcontroller for data or waiting for an event.
- An interrupt
service routine (ISR) that is executed when a hardware interrupt occurs.
- Raw, non-abstracted access to the hardware peripherals of
the microcontroller via function calls made directly to memory locations.
- Each peripheral device (e.g., serial port) is manually set
up for its respective operation.
- No dynamic memory
allocation (usually).
Bare-metal programming is by far the oldest and most
fundamental way of developing embedded software. There are many
production-grade embedded products currently in existence based on the
bare-metal programming paradigm; these include simple sensor devices and
consumer remote controls.
What Is an RTOS?
A Real-Time Operating System, or RTOS, is a lightweight
operating system built specifically for embedded systems. It utilizes a
scheduling system to operate multiple tasks, and provides a number of services
including inter-task communication, synchronization primitives (mutex and
semaphore), as well as timers.
The most popular RTOS options on the market today are:
-FreeRTOS - An open source, extremely well-known RTOS
-Zephyr - A highly modern RTOS that is project of the Linux
Foundation and has strong support for security concerns
-ThreadX (formerly known as Azure RTOS) - A deterministic RTOS that is free of any royalty or licensing fees from Microsoft
-CMSIS-RTOS - The standard API layer for ARM-based RTOS
-EMBos - A certified
commercial RTOS which is designed to be used in safety-critical applications
An RTOS does not make your system "smarter." What an RTOS provides is the ability to structure your application in a way that can use concurrent processing, versus having to create one very large loop that does everything you want. Instead, you create multiple tasks, and the RTOS kernel is responsible for determining how each of those tasks will run.
Head-to-Head Comparison
When Bare Metal Is an Ideal Option
Bare metal can be smart, since it is not "retro"
if used in the right application. Use it if:
1. Your Firmware/Application Is Clearly Defined
& Simple
If your firmware performs only one function (e.g., reading a
sensor, controlling a motor) bare metal makes for cleaner code by providing a
very specific and single purpose for each line of code without having to deal
with any task scheduling or context switching overhead.
2. You Are Creating an IoT Device That can
Communicate to Other IoT Devices
IOT communications
protocols use different methods to communicate and therefore have different
levels of timing, state machines, and stack sizes. Using an RTOS-based firmware
will allow you to handle these different requirements in a seamless manner due
to how the scheduler operates.
This means that an
RTOS scheduler handles processing of communication and application logic (by
filling up Protocol Stack memory before filling up Application Logic Memory).
3. In Order to Communicate Between or Among Various
Tasks Within Your Application, You Will Need to Have Reliable Inter-Task
Communication
Using inter-task communication methods (e.g., semaphores,
queues and mutexes) to safely communicate your shared data between concurrent
tasks is not optional or providing additional safety measures. Attempting to
accomplish this through creating ‘volatile’ flags utilizing ‘shared’ data
buffers and/or utilizing bare metal programming methods is going to create a
situation that creates race conditions and hard-to-reproduce errors in your
application.
4. For Your Product Design to Support Many Years of
Ongoing Maintenance, You Will Want to Consider Using Firmware Built on an RTOS
Architecture
The main architectural benefits
of using a firmware design based on an RTOS architecture are: task modularity; separation
of responsibilities; and ability to add new tasks (i.e., new features) without modifying
other functions. Proper architecture, especially with how you develop the
application, will pay off with future product developments and additions as the
product continues being produced for years to come.
5. The Certification You Are Targeting (IEC 62443, ISO 26262, IEC 60730
A large number of RTOS safety critical platforms already have pre-certified kernels completed, with developed & documented evidence, safety case artifacts.
Conversely, building the equivalent level of rigor on bare-metal from scratch will take considerably longer and cost much more.
Examples of actual use; include smart wearables, industrial gateways, medical engineering monitors, home automation hubs, connected motor controllers.
Many guides pertaining to firmware do not discuss a key aspect of architecture: a bare metal or RTOS (real-time operating system) can be used together.
Many manufacturing applications are based on hybrid models, including
• A
lightweight RTOS for coordinating task scheduling and communication
•
Time-critical ISRs that are coded in bare metal style outside the scheduler
•
Bootloaders that are coded in bare metal that pass off control to application
firmware using an RTOS.
In practice, RTOS provides coordination; bare metal provides the hard real-time edges. Various industrial and medical devices are designed using this approach.
Five Questions to Help You Decide
Running your project through these five question before doing is a good idea:
1. How many truly independent tasks will your firmware be performing at the same time?
Two or less → you can use bare metal. Three or more → you will need RTOS.
2. Is a networking/protocol stack required?
Yes → most likely you will need RTOS as your base.
3. What are your flash/RAM budgets?
If your flash memory is under 32 KB and/or you have less than 4 KB of RAM → you probably need to consider bare metal.
4. How stringent are your real-time requirements?
If you require sub-microsecond timing → bare metal ISRs. If you're on millisecond level tasks → RTOS will suffice.
5. What is the expected lifetime of this product and what kind of firmware upgrades will occur?
If the product has a multi-year life with multiple feature additions → you should invest in an RTOS architecture; it will pay off in the long run!
The Conclusion: It's Not A Battle but A Choice
RTOS and bare metal are two very important tools in engineering environments. The question will never be "which one is better in principle?" The question is always going to be: "which of those is right for the system, for this developer team, & for the timeframe to develop?"
-Choose
bare-metal when the system must be simple, deterministic, and have resource
constraints.
-Choose
RTOS when concurrency, connectivity, and long-term scalability are the
priorities.
-Use a hybrid approach when the environment requires both a system with strict hard real-time criteria and for complex systems requiring coordination.
The best firmware engineers will become fluent in BT and RF and will not ever use them by default; instead, they will choose one or the other based on their requirements.
Don't Know Exactly How to Proceed with Your Firmware Decision?
No matter if you have just started or are in the middle of developing, you should seek outside advice before making any major decision — this will save you money over time because the cost of fixing a problem will always exceed the original cost of a solution.
Let our team evaluate how you are approaching firmware, including identifying any risks, and assist you in moving forward confidently.
→ Get Your Free Project Assessment - Send Us An Email.
Expect to hear from us within 24 hours.
Comments
Post a Comment