Sometimes the Best RTOS Is No RTOS: When Bare-Metal Firmware Makes Sense

What is bare-metal firmware?

In my previous article, I explained why FreeRTOS is a strong go-to option for many microcontroller projects. I still think it is, especially when a system must coordinate several activities, communication stacks, and timing requirements.

However, choosing a good RTOS does not mean that every product needs one. Being able to run an RTOS is not the same as benefiting from one. For sufficiently small and stable applications, bare-metal firmware may be a simpler, more suitable architecture.

Bare-metal firmware runs directly on the hardware without an operating system. This does not mean that the developer must write everything from scratch. A bare-metal application can still use the microcontroller (MCU) manufacturer’s Hardware Abstraction Layers (HAL), low-level drivers, CMSIS components, and third-party software libraries.

When developing bare-metal firmware, the developer is responsible for coordinating everything: configuring the hardware, reacting to events, and so on. This can make the firmware very small and its execution paths easy to predict. It also means that responsibility for the application architecture sits entirely with the developer.

When does bare metal make sense?

When the device has one clear job

Modern embedded systems often handle several activities, which is one reason they commonly use an RTOS. When a system is responsible for a single, specific, and stable task, bare-metal firmware may be a better choice.

Consider a device that controls output pins based on an analog voltage. The firmware may only need to convert the analog voltage to a digital value and set the output accordingly.

An RTOS could run this application, but it would have very little to manage. If the functionality is unlikely to expand, a bare-metal implementation may use fewer resources and allow the product to use a smaller, less expensive MCU.

When the hardware can do most of the work

Many MCUs include features such as analog watchdogs and Direct Memory Access (DMA) controllers that can operate with little CPU involvement.

An analog watchdog can monitor whether an input crosses a configured threshold. A DMA controller can move data between peripherals and memory without requiring the CPU to process every value.

In an event-driven application, the firmware may configure these hardware features during startup and then put the MCU into a low-power state. The processor wakes only when an event requires attention.

When the hardware handles most of the time-critical behavior, an RTOS may have very little to schedule.

When the response path must be short and easy to inspect

Some applications require a fast and predictable response to a hardware event. A simple bare-metal design can make the path from the event to the required action direct and easy to measure.

If an action can safely be completed within a short interrupt handler, no task-scheduling decision is needed before it occurs. Fewer software layers may also make timing behavior easier to inspect.

This advantage applies mainly to small applications with short execution paths. If work must be deferred, coordinated with other activities, or protected from concurrent access, the architecture becomes more complex regardless of whether an RTOS is used.

What do you gain by going bare metal?

A smaller resource footprint

Bare-metal firmware does not require task control structures, synchronization objects, or separate stacks for application tasks.

This reduces flash and Random Access Memory (RAM) use. It may allow the product to use a smaller MCU or leave more memory available for application data and features.

A carefully configured RTOS can also be compact. Bare metal simply avoids kernel and task-management overhead from the outset.

Straightforward low-power behavior

In a small application, low-power operation can be easier to reason about when there are fewer software states, task stacks, and timing services to consider.

If the application can reconstruct its state after waking, it may also be possible to use a deeper low-power state that does not retain all RAM. Whether this is practical depends on the MCU and the product’s wake-up and state-retention requirements.

RTOS-based systems can also support efficient low-power operation, including tickless modes. The difference is that their sleep and wake-up behavior may require additional configuration and validation.

Use of special hardware features

Bare-metal firmware can use an MCU manufacturer’s HAL or low-level drivers directly. This gives the application access to hardware-specific capabilities that may not be available through a generic software interface.

Some RTOS platforms and vendor Software Development Kits (SDKs) provide common driver interfaces. These can simplify development, but they may not expose every feature supported by the hardware. When a needed capability is missing, the developer may still need to use a hardware-specific driver or access the peripheral directly.

With bare metal, this direct relationship with the hardware is already part of the design.

Fewer kernel restrictions for high-priority interrupts

MCUs often support several interrupt priorities. High-priority interrupts may be able to pre-empt most other software activity.

Depending on the MCU architecture and RTOS configuration, the highest-priority interrupts are not allowed to call RTOS services. Data or work may instead need to be transferred to RTOS-managed code through a deferred-processing path.

Bare metal avoids this particular kernel restriction. Interrupt priorities, execution time, and shared data must still be designed carefully.

A simple debugging model

Without task switches and multiple task stacks, it can be easier to follow execution from a hardware event to the resulting output. MCU vendor tools also tend to provide strong support for peripheral configuration and low-level debugging.

This benefit depends on the size of the application. Once many interrupt handlers, timers, state machines, and shared resources begin interacting, a bare-metal system can be just as difficult to understand as an RTOS.

When should you avoid bare metal?

When several activities must progress independently

If a device has several independent activities that must continue concurrently, an RTOS should be considered.

In a bare-metal application, the main loop may check each software component in turn and give it an opportunity to run. This cooperative approach can work when there are only a few short activities.

As timing requirements, priorities and dependencies increase, the main loop can gradually become a scheduler created specifically for that product. At that point, the development team may be solving problems that an established RTOS already addresses through tasks, queues, timers, semaphores and mutexes.

When the product is expected to grow

A bare-metal architecture may work well for the first version of a product but become difficult to extend later.

A device that initially handles only sensors and outputs may eventually gain communications, diagnostics, data logging or firmware-update functionality. Each addition can introduce new buffers, timeouts, event flags and interactions with existing functionality.

Networking and Over-the-Air (OTA) firmware updates are possible without an RTOS. They do, however, often add communication stacks and background activities that must coexist with the rest of the application.

If significant growth is already visible on the product roadmap, an RTOS may provide a more scalable structure even when bare metal would be sufficient for the first implementation.

When portability is important

Portability does not come automatically from adding an RTOS. Code that directly uses MCU-specific registers or HAL functions will remain tied to that hardware unless the architecture separates those details from the application logic.

An RTOS ecosystem or embedded software platform may provide reusable middleware, board-support packages and common interfaces across several devices. These can reduce the amount of platform-specific work when moving to another MCU.

In either architecture, portability depends on maintaining clear boundaries between application logic, platform services and hardware-specific code.

When low-level hardware knowledge becomes a burden

Working close to the hardware requires an understanding of the MCU and its peripherals.

When controlling an MCU through memory-mapped registers, the developer may need to study the datasheet and reference manual to understand clock configuration, interrupt priorities, peripheral states and other register dependencies.

An RTOS introduces a different learning curve. Developers need to understand tasks, priorities, queues, semaphores, mutexes, timers and interrupt-safe Application Programming Interfaces (APIs). They may also need to inspect the implementation of a driver or platform service to understand its behavior if their documentation is vague.

Choosing bare metal or an RTOS does not remove the learning curve. It determines whether more of the learning takes place at the hardware level or at the operating-system and software-platform level.

How do you decide?

Well, that can be difficult as there are pros and cons on both. I think it comes down to simplicity, and what the system needs to achieve.

The choice between bare metal and an RTOS is not only a firmware decision. It can affect MCU selection, power consumption, timing behavior, testability, maintainability, and the effort required to add future features.

A good decision is based on the system design and requirements rather than a preference for a particular technology. Bare metal can be an excellent choice for a focused and stable product. When activities, priorities, and integrations begin to multiply, an RTOS can provide the structure needed to keep the firmware understandable and maintainable.

I also think it would be beneficial to write bare-metal firmware for a microcontroller even if you plan to use an RTOS later. It is a really good way to learn how the microcontrollers work and can make it easier to understand what the RTOS is doing on top of it.