In embedded system development, one of the most critical technical decisions appears right at the planning stage: should the firmware run directly on the hardware, or should it rely on a real-time operating system (RTOS)?

Choosing between bare-metal firmware and an operating system like FreeRTOS, Zephyr, or others depends on various technical, functional and operational factors. This decision should not be based on developer preferences or habits, but on an objective analysis of the project’s requirements.

At Detus, we assess this decision carefully with each client, taking into account aspects such as predictability, system complexity, scalability requirements and the level of robustness expected from the final product.

What it means to work without an operating system

Bare-metal firmware is code that runs directly on the microcontroller, with no abstraction layer or automatic task scheduling. It is up to the developer to manually manage interrupts, timing, task coordination and the overall system state.

This model is suited for simple systems that are highly predictable and resource-constrained. It provides full control over the hardware, minimal latency, and typically results in a smaller codebase. However, it requires strict management of concurrency, priorities and scalability, which can make development and maintenance more complex as the system evolves.

What a real-time operating system offers

A real-time operating system (RTOS) allows the concurrent execution of multiple tasks through mechanisms such as semaphores, queues, timers and synchronized events. It also introduces a modular structure to the firmware, which makes code maintenance and system expansion over time easier.

Using an RTOS is especially advantageous when:

• There are multiple tasks with different priorities running simultaneously

• The system requires precise timing or reliable periodic cycles

• There is a need for event logging, diagnostics or persistent logging

• The firmware is modular, with separate and independent functions

• The final product is expected to evolve and receive functional updates after launch

Objective criteria to support the decision

Practical example

An autonomous environmental sensor that reads values every thirty seconds and sends the data to a central system can be implemented simply and effectively with bare-metal firmware. Its predictable behaviour and lack of multiple concurrent tasks make the use of an operating system unnecessary.

On the other hand, a medical device with multiple sensors, control buttons, event logging, and a communication interface with diagnostic functions would benefit significantly from an operating system. In this case, task management, functional separation and responsiveness to simultaneous events make an RTOS the right choice.

Performance considerations

It is common to assume that bare-metal firmware always performs better. In very simple systems with extremely limited resources, this can indeed be true. However, a well-configured RTOS, with proper priority management and efficient use of its scheduling mechanisms, can in many cases be more efficient at managing wait cycles, asynchronous communication and rapid response to external events.

Additionally, using an operating system enables more robust development practices, such as modular testing, secure firmware updates, and a more structured approach to product lifecycle management.

Conclusion

There is no universal answer. The decision between bare-metal firmware and an operating system must be based on the architecture, the type of product, its expected evolution and the required level of stability.

At Detus, we assess this decision alongside the selection of the microcontroller, power consumption considerations, and the system’s operating logic.