RTOS vs. bare-metal: a decision framework, not a religion

The RTOS versus bare-metal debate generates more heat than light.

Both are good answers. Each is a bad answer for the wrong product. Here's a framework for making the decision from your product's actual constraints, not from internet opinions.

When bare-metal wins

Bare-metal firmware is a main loop plus interrupts, usually with DMA, and no scheduler underneath. Its strength is that you can see everything the processor will do, in the order it will do it.

• Single-purpose devices with deterministic timing requirements. When the product does one job on a tight schedule, a scheduler is one more layer between your code and the timing you have to prove.
• Ultra-low-power applications where every microamp matters. In a bare-metal design, sleep and wake are explicit. The processor wakes for the interrupts you enabled and nothing else, which makes the power budget easier to reason about.
• Small microcontrollers where RTOS overhead is significant. Below roughly 32 KB of RAM, the kernel, the per-task stacks and the synchronization objects take a real share of what you have.
• Teams with deep hardware expertise but limited RTOS experience. An RTOS used badly is worse than none. Priority inversion, stack overflows and races between tasks are new failure modes, and a team meeting them for the first time on a product schedule pays for the lesson.

When an RTOS wins

• Multiple concurrent tasks with different priorities. When a control loop, a user interface and a logger all need the processor, a preemptive scheduler lets the urgent work interrupt the rest instead of waiting its turn in a loop.
• Network stacks that need background processing. TCP/IP, BLE and Wi-Fi stacks keep their own timing. They need servicing whether or not your application is busy, which is awkward to guarantee from a single loop.
• Complex state machines that benefit from task isolation. Giving each subsystem its own task, with queues between them, keeps one subsystem's state from leaking into another's.
• Products that will grow in feature complexity over time. If the roadmap adds features after launch, a structure built to take one more task is cheaper than retrofitting a scheduler into a main loop that was never designed for one.

The decision matrix

Five questions, answered honestly, settle most cases:

1. Tasks. How many independent things does the device do at once, and do they have different priorities?
2. Timing. What is the tightest deadline in the system, and what happens when it's missed?
3. Power. What is the sleep budget, and how often does the device have to wake?
4. Memory. How much RAM is left after the application, its buffers and any communication stack?
5. Team experience. Who will maintain this firmware in two years, and what do they already know?

If the answers point both ways, that's information too. It usually points to the hybrid.

The hybrid approach

There's a middle path: a bare-metal main loop with interrupt-driven peripherals. Interrupts and DMA handle the time-critical work and move data into buffers. The main loop processes whatever is waiting.

It keeps bare-metal's transparency and gives you much of the responsiveness people reach for an RTOS to get. For a lot of products, it's the right place to stay.

When to migrate

Bare-metal architectures don't fail all at once. They outgrow themselves, and the signs are recognizable:

• Adding a feature changes the timing of an unrelated one.
• The main loop has grown flags and counters to decide what runs on each pass. That's a scheduler, written by hand.
• Interrupt handlers keep growing because the loop can't get to the work in time.
• A communication stack is being serviced from several places in the loop to keep it alive.

One of these is a warning. Several together mean it's time to plan the migration deliberately, before the next feature rather than in the middle of it.

The bottom line

None of this is exotic. It's rigorous.

The choice is cheap to make well at the start of a program and expensive to reverse once the firmware is built around it. Make it from the product's constraints, write down why, and revisit it when those constraints change.