Kunvar Chokshi is an embedded development engineer with over ten years of embedded experience. The Edian team provided the translation.
Embedded developers typically start their projects in the bare metal domain—without an operating system, no multitasking, just raw code running directly on the hardware. This approach is all about direct register manipulation and peripheral control in tight loops. It is known for its efficiency and precise operation, making it an ideal choice for resource-constrained systems where every cycle counts. However, as project scale increases, with more sensors, connectivity needs, and feature expansions, this streamlined bare metal loop and interrupt setup may begin to become overwhelming. This raises the question: is it time to upgrade to a Real-Time Operating System (RTOS)?
What is Bare Metal?
Bare metal programming means there is no operating system intermediary: only your software interacts directly with the hardware. Imagine:
-
The main() function runs in an infinite loop
-
Interrupts capture unexpected events
-
Manually adjusting hardware registers
-
Manually managing timing and states
This approach tightly couples your firmware to a specific microcontroller or SoC. It is streamlined, fast, and occupies little memory, making it suitable for scenarios such as:
-
You have only one or two core tasks
-
Timing precision is critical
-
RAM is limited (e.g., less than 32 KB)
-
Startup speed must be lightning fast
For example, an affordable smart thermostat, a USB-to-serial bridge, or a motor controller handling ADC readings and PWM signals—all benefit from the simplicity of bare metal.
So, what is an RTOS?
A Real-Time Operating System (RTOS) adds a software layer for managing tasks, scheduling, inter-task communication, and timing. Examples include FreeRTOS, Zephyr, Micrium OS, ThreadX (Azure RTOS), RTX (CMSIS), and embOS.
Most have the following features:
-
Preemptive task switching
-
Predictable timing
-
Tools like semaphores for synchronization
-
Built-in timers
-
Power-saving features
When your project involves multiple tasks that need to run simultaneously or meet strict deadlines, a Real-Time Operating System (RTOS) shines.
Real-World Use Cases
Bare Metal – Automotive ECU: Engine or brake Electronic Control Units (ECUs) are among the best candidates for bare metal. They require precise timing control (e.g., fuel injection within microseconds), rock-solid predictability, and a streamlined codebase. Fast startup is critical, and there is often no dynamic memory—all is locked at compile time. Imagine a drive-by-wire throttle system: it must respond instantly to pedal input, meet ISO 26262 safety rules, and handle high-speed CAN bus data. Bare metal ensures stable performance with no jitter.
RTOS – Smart Wearable Devices: Imagine a fitness band responsible for handling low-power Bluetooth (BLE), heart rate tracking, step counting, battery life, and wireless updates. An RTOS breaks these functions into multiple threads:
-
BLE_Thread: Manages advertising, pairing, and data pushing
-
Sensor_Thread: Reads and smooths sensor data
-
Display_Thread: Refreshes the screen to receive input or alerts
-
Logger_Thread: Stores data and blinks on schedule
-
Power_Thread: Monitors sleep state and charging
Suppose your phone syncs workout logs via BLE while the heart rate sensor polls—RTOS would set BLE_Thread to high priority and Power_Thread to low priority to ensure both run simultaneously, avoiding screen stutter. It is modular, streamlined, and easy to adjust.
Hybrid – Motor Drive with Communication Layer: Some projects involve both domains. An industrial motor driver might run its torque loop on bare metal with the highest priority interrupt for strict timing control while relying on FreeRTOS for additional features like CANopen protocol stack, diagnostics, or Ethernet configuration. Imagine a robotic arm adjusting speed during task execution: bare metal ensures torque precision, while RTOS handles sending status pings to the control panel, ensuring every beat is accurate. This is the best of both worlds.
Trade-offs: Bare Metal vs. RTOS
Refer to the table below for a high-level trade-off analysis.
Table 1: Bare Metal vs. RTOS: Comparison Table
When Should You Switch?
While there are no hard rules, consider the following:
-
You are using cumbersome switch-case logic and intricate state machines to fake multitasking
-
The number of interrupt routines is skyrocketing, and shared resource handling is a mess
-
You are handling more than three independent processes simultaneously (e.g., sensors, communication, user interface)
-
New features easily break old functionality
-
You are busy fixing timing conflicts or priority conflicts instead of focusing on building features
For example, consider a bare metal weather station with added Wi-Fi: the loop gets stuck processing sensor readings and HTTP sends—welcome to switch-case hell. Or, you added an LED blinking mode, but it interferes with the motor PWM signal because they share a timer—vulnerability arises. If your lookup table calls exceed your code commits, then complexity has the upper hand. RTOS might be your lifeline.
RTOS Decision Tree
The diagram below can help you decide whether to continue with bare metal or switch to RTOS based on system requirements.
Figure 1: RTOS Decision Tree
Clarifying Misconceptions
“RTOS is too heavy.”
Modern RTOS like FreeRTOS can be configured to run with less than 10 KB of flash and less than 2 KB of RAM. Many RTOS even support tickless idle modes, reducing CPU activity and power consumption.
“RTOS will degrade real-time capabilities.”
A properly configured RTOS can provide deterministic scheduling using fixed-priority preemption. However, poorly written, CPU-hogging tasks or misconfigured priorities can lead to delays.
“Bare metal is always faster.”
While this is true in isolation, the complexity of managing multiple event sources, concurrency, and timing often leads to reduced overall code efficiency. Debugging efforts and maintenance costs may outweigh the raw performance of bare metal.
Migration Tips
-
Start small: Port existing modules to run as RTOS tasks. Use a minimal configuration of FreeRTOS.
-
Understand priority inversion: Use priority inheritance mutexes to avoid hard-to-debug race conditions.
-
Measure overhead: Analyze context switch times and memory usage to validate the feasibility of RTOS.
-
Keep ISRs short: Use interrupts only to signal tasks, not to process data.
-
Document task behavior: Clearly define the function of each thread and the resources it accesses.
Broader Considerations: Team, Tools, and Certification
Team experience, certification requirements, and toolchain support will influence your migration decisions. RTOS can introduce abstractions but also requires attention to issues like priority inversion, task starvation, and debugging concurrent processes. Certified RTOS is crucial in automotive and medical fields. Debuggers that support RTOS (e.g., SEGGER Ozone or Tracealyzer) will be very helpful.
Migration Pitfalls: What to Watch Out For
Common pitfalls include misuse of blocking code, unsafe access to shared resources, and underestimating stack sizes. Each RTOS task has its own stack, so performance analysis is critical.
Choosing the Right RTOS
Consider licensing, community support, supported hardware, and the richness of its peripheral stack. FreeRTOS and Zephyr are open-source options; Micrium OS and SafeRTOS meet commercial and safety certification needs.
Conclusion
Choosing between bare metal and RTOS? It’s not a binary choice—it depends on your system requirements. Simple low-concurrency tasks benefit from the speed and intuitiveness of bare metal. But as complexity escalates (e.g., wireless, interfaces, cloud links, or AI), RTOS can shorten engineering time and keep code manageable. With MCUs like the RP2040 equipped with 264 KB of RAM or processors like the ESP32 boasting dual-core performance, RTOS is no longer a luxury but more of a default choice. Next-generation wearables may run machine learning models to recognize gestures—bare metal’s scalability is limited.
From IoT startups to automotive giants, the adoption of Real-Time Operating Systems (RTOS) is on the rise across industries as devices become smarter. As firmware scales, RTOS is your framework for handling tasks, scheduling, and resources. If you’re wrestling with interrupts and flags like a circus performer, now might be the time for RTOS to shine. Why not give it a try in your next hobby project—the learning curve will benefit you greatly, and the community will support you.