When bare-metal programming fits, when an RTOS is the right embedded architecture choice, and what drives the decision.
The choice between bare-metal programming and a real-time operating system is an architecture decision, not a complexity judgment. Most embedded programs get it wrong not by choosing the wrong approach, but by choosing the right approach for the wrong stage of the product. A bare-metal implementation that serves the prototype well becomes a liability when the product roadmap adds concurrent operations the state machine was never designed to absorb.
This framework covers the technical criteria that drive the decision, the points at which each approach breaks down, and the questions worth answering before the firmware direction is set.
Key Takeaways
- Bare-metal is not simpler. It transfers the coordination burden from a kernel to the developer. That burden is manageable at low complexity and compounds quickly as the product grows.
- An RTOS does not solve timing problems. It gives you a structured scheduler to manage them. If your product does not have concurrent tasks with defined timing relationships, the RTOS adds overhead without solving a problem you have.
- The wrong architecture at the prototype stage is rarely fatal. The wrong architecture after hardware has been built and a feature roadmap has committed to it is expensive.
- This decision should be made against a product requirement, not a developer preference or a platform default.
Bare-Metal Programming: Where It Fits
The advantage is determinism and efficiency. A bare-metal implementation on constrained hardware, 32KB flash, 4KB RAM, can be leaner and faster than anything an RTOS can match on the same silicon. For a product with a well-defined, stable function set and tight cost or power constraints, that is exactly the right tradeoff.
The limitation is scalability. As the product grows, the developer builds the coordination layer manually. Interrupt-driven state machines, polling loops, timing flags, shared resource management through carefully sequenced code rather than a kernel primitive. These patterns work. They also accumulate technical debt that becomes visible when the product needs to do something new.
Bare-metal fits when:
- The function set is limited, well-defined, and unlikely to expand significantly
- Timing requirements are simple enough to manage with interrupts and a main loop
- Memory constraints make an RTOS footprint a meaningful cost
- The product is single-purpose: a sensor node, a simple actuator controller, a low-power device with minimal peripheral interaction
- The firmware will not need to absorb a significant feature roadmap
RTOS: Where It Fits
The value is not speed. A well-written bare-metal system can be faster on simple hardware. The value is structure for concurrent operations. When a product manages a communication stack alongside application logic, handles multiple I/O channels with defined timing relationships, or needs to support a feature roadmap that will add capability over time, the RTOS provides the coordination layer the developer would otherwise build and maintain manually.
FreeRTOS is the most widely deployed option in commercial embedded products. Zephyr has grown significantly in connected device and IoT applications. ThreadX (Eclipse ThreadX) is common where commercial support and certification pathways matter. VxWorks and Green Hills INTEGRITY are used in defense and safety-critical programs requiring DO-178C or IEC 61508 certification.
RTOS fits when:
- The product manages multiple concurrent operations with defined timing relationships
- A communication stack, Modbus, CAN bus, BLE, LoRaWAN, runs alongside application logic
- The product roadmap will add connectivity, a cloud interface, or a mobile app layer
- Hard real-time guarantees are required and the scheduler needs to enforce them
- Regulatory certification, IEC 62304, IEC 61508, requires a qualified or certifiable kernel
- The firmware needs to be maintainable and extensible by a team over a multi-year lifecycle
The Three Variables That Drive the Decision
Timing requirements. Hard real-time means a missed deadline is a system failure. A motor commutation window missed, a dosing interval skipped. Those requirements point to a preemptive RTOS with priority-based scheduling. Soft real-time, where timing matters but bounded variance is acceptable, can be managed in bare-metal with careful interrupt design. Identifying which functions in the product have hard real-time requirements is the first step in the architecture conversation.
Memory and processing constraints. FreeRTOS runs in roughly 6 to 12KB of flash and a few kilobytes of RAM on a Cortex-M device. On a microcontroller with 256KB or more of flash that overhead is negligible. On an 8-bit or 16-bit device with a 32KB flash budget it is a real constraint. The memory question is hardware-specific and needs to be answered against the actual target processor.
Task concurrency. A product that reads a sensor value and transmits it on a fixed interval has no concurrency problem. A product that manages a control loop, a communication stack, a data logging function, and a user interface simultaneously has a concurrency problem that grows harder to manage cleanly in bare-metal with each function added. The inflection point is product-specific, but it is recognizable early if the architecture question is asked before the firmware is written.
Where the Decision Goes Wrong
The most common failure mode is not choosing the wrong architecture. It is choosing the right architecture for the prototype and the wrong one for the product.
A bare-metal proof of concept gets a product to demo quickly. The demo works. The schedule locks in around a firmware architecture chosen for convenience at the prototype stage. Three features later, the state machine touches every peripheral in the system, timing interactions that were invisible at the prototype stage are now bugs, and adding one more feature requires rearchitecting firmware that has been in production for six months.
The reverse happens too. An RTOS gets added to a simple product because it feels like the right professional choice, or because the developer is more comfortable with it. The result is a kernel on hardware that did not need one, with memory overhead and task structure managing a problem that did not exist.
Why DE Design Works
Since 2002, we have made bare-metal and RTOS architecture decisions for embedded products across industrial, medical, military, and IoT programs. We have also been brought in to rearchitect firmware that outgrew its original design before the product shipped.
The embedded architecture decision gets made once. We make it against the product requirement, the target hardware, the regulatory pathway, and the feature roadmap, before the first line of firmware is written.
If you have an embedded program coming up and want that conversation early, reach out.
Frequently Asked Questions
Can a bare-metal firmware be migrated to an RTOS mid-program?
Yes, but the cost depends on how far the firmware has progressed and how tightly it is coupled to a specific execution model. Moving from a state machine or polling loop architecture to a task-based RTOS model typically requires restructuring rather than porting. The earlier the decision is revisited, the less it costs.
What is the actual memory overhead of FreeRTOS on a Cortex-M device?
FreeRTOS kernel code runs in approximately 6 to 12KB of flash depending on configuration. Each task requires its own stack, typically 256 to 1024 bytes depending on the task’s complexity and local variable usage. On a microcontroller with 256KB of flash and 64KB of RAM, the overhead is not a constraint. On a device with 32KB of flash and 4KB of RAM, it may be.
Does an RTOS guarantee hard real-time performance?
A preemptive RTOS with priority-based scheduling provides deterministic task switching, which is the foundation for hard real-time behavior. Whether the system meets a specific timing requirement depends on the scheduling policy, interrupt latency, task priorities, and the behavior of higher-priority tasks. An RTOS makes hard real-time achievable in a structured way. It does not make it automatic.
How does RTOS selection affect regulatory certification for medical or safety-critical products?
Some commercial RTOS products carry pre-existing safety certifications. ThreadX carries IEC 61508 SIL 3 and IEC 62304 Class C certification artifacts. INTEGRITY carries DO-178C DAL A certification. FreeRTOS does not carry certifications out of the box but can be used in certified products with the appropriate validation documentation. If certification is a program requirement, the RTOS selection should be part of the certification strategy from the start.
When does a connected product need an RTOS?
When the communication stack and the application logic need to run concurrently with defined timing relationships. A BLE stack, a Modbus implementation, or an MQTT client running on a bare-metal system typically requires careful partitioning of the main loop and interrupt handlers to avoid timing conflicts. An RTOS manages that partitioning through the task model. The more communication protocols the product supports, the stronger the case for an RTOS.