RTOS vs bare metal: understanding the best approach for embedded systems

Like a successful stand-up comedian’s routine on stage, an embedded control system depends on timing.

In embedded systems, the precision of the timing is often resolved in increments as small as microseconds. And when the system has real-time requirements, events have to be triggered and tasks have to be completed within strict constraints imposed by the nature of the application and the hardware it runs on.

The concept of real-time systems can be visualised in the context of an everyday activity such as driving a car: in a brake-by-wire system, in which the link from the driver’s brake pedal to the wheels passes through an electronic control unit (ECU), the software running on the ECU’s microcontroller (MCU) must be guaranteed to respond to the input (a press on the brake pedal) and deliver the appropriate output (triggering the by-wire brake actuator to increase hydraulic pressure in the braking system, applying the discs to the wheels) within a maximum time window.

If the actuation instruction were delayed, for instance because it had to wait for various system management routines to execute first, braking response would be slowed, potentially causing a collision that would have been avoided had braking response been instantaneous.

In this example, the real-time constraint on the system is also safety-critical – lives depend on a car’s brakes working properly.

But in any real-time embedded system, proper operation requires that the timing of the application’s response to triggers is guaranteed.

RTOS and bare metal pros and cons

Developers have two choices when considering how to meet the real-time requirements of an embedded system: bare metal programming, or using a real-time operating system, or RTOS.

In a bare metal system, raw code runs directly on the hardware, with no software ‘middleman’ negotiating different threads’ access to hardware resources. This means that the main function of the application runs as an endless control loop. Interrupts can trigger exceptional actions when unusual or unexpected events occur.

Bare metal programming is an unmediated type of development environment:

• Refining the operation of a prototype system calls for adjustment of register settings in the hardware
• System operation is controlled by state machines
• State and timings are managed by hand

Use of an RTOS puts a software middleman between the hardware and the application software: the job of the RTOS is to schedule tasks and manage the allocation of hardware resources between competing tasks and threads.

An RTOS provides a level of abstraction between the software developer and the hardware, so that tasks such as managing timing are configured and adjusted via a development tool. An RTOS provides a framework and aids which greatly ease the handling of potential timing conflicts in more complex embedded systems. Tasks such as deterministic scheduling, interrupt handling, task management, context switching and managing resource constraints can be performed in a convenient and intuitive development environment.

The choice between the bare metal approach in embedded systems and an RTOS has profound consequences for the developer: in a more complex system development, the difficulty of managing timing conflicts directly in hardware can become overwhelming, whereas an RTOS provides a simple way to resolve conflicts and achieve stable, bug-free operation.

But in simple systems, an RTOS occupies a potentially unnecessary memory footprint, and gets in the way of the direct control of hardware operations provided by the bare metal approach.

The choice affects not only system performance. Depending on the nature of the application, either an RTOS or bare metal might offer higher reliability, and be easier to maintain as product variants and updates are implemented over time.

This article explains the benefits and drawbacks of both the bare metal and RTOS approaches, addressing technical, practical and cost issues. The reader will gain a good understanding of the pros and cons of each, helping to guide the decision for any type of embedded development project.

The features and advantages of an RTOS

An RTOS is a software layer between the hardware and the application layer which schedules operations and allocates resources, such as processor cycles and memory accesses, to threads according to the priority and the timing requirements of each. Popular RTOSes are supported by the integrated development environments (IDEs) available for development on the main microcontroller and microprocessor platforms.

Examples of RTOS products which are popular in embedded system design are FreeRTOS (an Amazon product), Zephyr (hosted by the Linux Foundation), ThreadX (open-source software), and INTEGRITY (from Green Hills Software). 

The essential features of an RTOS are:

Determinism: an RTOS guarantees that time-sensitive tasks will be completed within a predictable and specified time frame. This predictability is essential for applications in which a late response can lead to system failure, or could compromise safety: a vehicle’s brake-by-wire system is an example of a safety-critical application. Hard real-time operating systems offer very strict determinism, while soft real-time systems have less rigid timing constraints.

Responsiveness: an RTOS must respond to events and perform interrupt handling extremely fast – in fact, the maximum latency of its response should be guaranteed. Its responses will include fast context switching between tasks, and low interrupt latency, ensuring that the system reacts promptly to external stimuli.

Priority-based scheduling: an RTOS uses scheduling algorithms which assign different priority levels to different tasks or threads: higher-priority tasks are given access to hardware resources before lower-priority ones, ensuring that mission-critical or safety-critical operations are executed within their specified timing windows. Common scheduling algorithms include rate monotonic scheduling (RMS) and earliest deadline first (EDF).

Pre-emptive scheduling: here, a higher-priority task can interrupt a lower-priority task which is already running. This ensures that critical tasks are executed as soon as they are ready, even if a less important task is already in progress.

These are the ways in which an RTOS maintains the timing integrity of a real-time embedded system design.

But what are the most important real-time operating system advantages?

Resource management: an RTOS efficiently manages system resources such as CPU availability, memory accesses and peripherals. This ensures predictable performance, and prevents contention over resources, which could lead to missed deadlines.

Memory management: an RTOS employs memory management techniques optimized for real-time constraints, such as static allocation or memory locking, to avoid fragmentation and to ensure predictable access times. These techniques may include the use of virtual memory, depending on the specific requirements and the hardness of the real-time constraints. 

Task synchronization and inter-process communication: an RTOS provides mechanisms such as semaphores, mutexes, message queues, and event flags to enable tasks to synchronize their actions, and to communicate with each other safely and efficiently.

Interrupt handling: an RTOS provides efficient and predictable mechanisms for handling hardware and software interrupts, enabling the system to respond quickly to external events.

Small footprint and efficiency: an RTOS is lightweight, with a very small memory footprint. In a typical implementation, the popular FreeRTOS product’s kernel requires between 5kB and 10kB of ROM or Flash. The total Flash footprint depends on the developer’s choice of compiler, the hardware platform on which the RTOS runs, and the chosen RTOS kernel configuration.

Reliability and stability: an RTOS is often used in mission-critical or safety-critical applications in which failures can have damaging consequences, for instance by putting users at risk of death or injury, or exposing the host system to the risk of damage or destruction.

An RTOS is highly reliable and stable, as it often incorporates features such as fault tolerance and error handling.

The bare-metal approach in embedded systems: pros and cons

In a complex embedded system design, an RTOS simplifies the scheduling of tasks and the management of resources. But the RTOS interposes an additional software component between the application and the hardware on which it runs.

In a simple system, the bare-metal approach enables the developer to directly program the operation of hardware resources such as the CPU, memory and peripherals. Direct programming offers several benefits:

Control and predictability: bare-metal programming eliminates the overhead and abstraction layers introduced by an RTOS, allowing for fine-grained optimization and the most predictable timing behaviour. By eliminating the overhead of an RTOS’s dynamic scheduling and resource management, bare-metal programming can make execution flow more deterministic. This might be crucial for the most time-sensitive applications, in which even the small timing variations introduced by an RTOS are unacceptable. 

Small resource footprint: bare-metal programs typically have a substantially smaller code footprint than RTOS-based systems, as they don’t include the RTOS kernel and its associated libraries. This is advantageous in MCUs that have limited Flash memory and RAM capacity. In addition, bare-metal programming frees up more RAM for the application itself, because there are no RTOS services running in RAM.

Faster boot: bare-metal systems often boot up faster because they do not need to initialize an RTOS kernel and its components.

Simpler software architecture: for straightforward applications with a limited number of tasks or sequential execution flow, a bare-metal approach can lead to a simpler and easier-to-understand software architecture. Bare metal eliminates the need to manage tasks, or to configure deterministic scheduling, or to perform inter-process communication.

Easier debugging: in simpler systems, debugging can sometimes be easier without the added layer of abstraction and the complexities of RTOS task interactions.

Lower development cost: the bare-metal approach avoids the need to pay the licensing fee for a commercial RTOS. It’s worth noting that an open-source RTOS such as ThreadX does not levy a licence fee.

For a developer who is familiar with an MCU architecture, it can also be quicker to get started on a project in bare metal, as this avoids the need to learn to use an RTOS.

Application-specific optimization: developers can tailor the code and hardware interactions precisely to the specific requirements of the application, leading to highly optimized performance and power consumption.

These benefits can be attractive in simple systems which have few sensors and only one main function. But the drawbacks of the bare-metal approach grow in significance the more complex an embedded system design becomes:

Intensifying system complexity: managing concurrency, scheduling, and resource constraints is much more complex and engenders many more errors in bare metal when programming systems with multiple functions.

Compromising real-time operation: achieving deterministic and responsive behaviour in complex bare-metal systems can be very challenging without the structured mechanisms provided by an RTOS.

Harder to maintain: bare-metal code can become monolithic and difficult to maintain, modify, and scale in complex systems.

Lack of pre-built services: in bare metal, developers need to implement common functions such as timers, communication protocols, and memory management from scratch – they are provided ready-made in an RTOS.

Comparative analysis: RTOS vs bare metal

The analysis above shows that the main differences between an RTOS and the bare-metal approach are in:

• Performance and scheduling: the control loop is potentially tighter in bare metal, but in anything bigger than a simple embedded system with one main function, the complexity of scheduling in bare metal tends to become overwhelming, and a design based on an RTOS is less prone to errors.
• Memory and resource footprint: bare metal reduces system memory footprint to a minimum, while an RTOS’s abstractions add overhead. But many of today’s RTOSes have a lean kernel, and their total memory footprint is often negligible when compared with the memory capacity available in the latest microcontrollers and microprocessors.
• Ease of development and maintenance: in simple embedded systems, bare metal provides an easy way to configure system operation. But in more complex systems, an RTOS provides a clear framework for programming code, helping to reduce error and making it easier for development teams to understand, maintain and modify the application’s code base.
• Debugging and testing: built-in debugging and trace tools provided in RTOS platforms and IDEs greatly enhance developer productivity compared to working in a bare-metal environment.
• Cost: while there is zero licence overhead for bare-metal programming, a commercial RTOS attracts a licence fee. Payment of the fee entitles the developer to the support and maintenance services provided by the RTOS vendor.

In summary, the decision to use a bare-metal approach in embedded systems often depends on the requirements:

• Choose bare metal when the application is very simple, resource-constrained, requires maximum low-level control and predictable timing (without complex concurrency), and development costs need to be minimized in simple projects.
• Choose an RTOS when the application is complex, involves multiple concurrent tasks, has real-time requirements, needs modularity and maintainability, and development time and access to pre-built services are important considerations.

Best practices for deciding on an embedded system architecture

The decision about whether to pursue a bare-metal approach or to use an RTOS should be made in the light of systematic analysis of the application’s requirements, and testing of the chosen approach in a prototype setting.

Requirements analysis should be based on a thorough resource and timing analysis.

Testing should be performed on a proof-of-concept design implemented in hardware. This enables the developer to measure actual performance, latency, and overhead in an environment which resembles that of the eventual product design.

If it is the case that the balance of factors is not clear-cut in favour of either bare metal or RTOS, developers might choose to implement a hybrid solution, in which a small real-time kernel or lightweight scheduler is used to combine some of the benefits and features of both an RTOS and bare-metal programming.

Conclusion

As this guide has demonstrated, the choice between an RTOS and bare-metal programming is determined principally by a judgement about the complexity of the system, the constraints on resources such as memory and processor time, the extent to which developers need to learn to use an RTOS or IDE, and the amount of code to be maintained and modified.

Over time, the balance of factors will change: technology developments made by the semiconductor industry mean that the hardware available to embedded developers continually gains higher compute capability, with access to ever greater memory capacity. This means that the overhead of an RTOS will represent over time a smaller proportion of a system’s total hardware capacity, reducing the weight of the resource constraint objection to the use of an RTOS.

In simple systems, however, bare-metal programming will remain an attractive option because of the ease with which a control loop can be configured, and the fast and deterministic performance that it can provide.

To help you to work out whether bare metal or an RTOS is right for your next design, you can try any of the wide range of evaluation boards and development kits on ipXchange.

And to make sure you never miss out on the latest electronics component news, subscribe at www.youtube.com/@ipXchange.