The heart of embedded systems is microcontroller/microprocessor. These processors need to be programmed so that they will do a pre-defined task. These Embedded systems processors require firmware that is specifically designed for them. There are two main approaches to design and develop the firmware i.e. bare-metal and real-time operating system (RTOS). In this post we will discuss the pros and cons of bare metal & RTOS, compare these two and will discuss the points that we should keep in mind while choosing one of them.

RTOS Vs Bare Metal
Bare metal Vs RTOS

Bare-metal Firmware

Let’s have a look at the below code that check the status of a pin A of processor and changes the state of pin B.

int main() {
    init_gpio(); // initialize the GPIO pins
    while (1) {
        if (get_state_gpio(PIN_A) == HIGH) { // check if pin A is high
            clear_gpio(PIN_B); // make pin B low
        } else {
            set_gpio(PIN_B); // make pin B high
    return 0;

This code is self-explanatory and do not need any explanation. We have written the code without using any kind of scheduling/OS. This style of coding is known as “bare metal”. So, we can say that bare-metal firmware is a type of firmware that runs directly on the hardware without using any kind of scheduling of tasks or an operating system. It is designed to interact directly with the hardware and provide low-level control over the system.

Bare-metal firmware is commonly used in simple embedded systems that do not require complex functionality, as it is lightweight and efficient. You might have many appliances at your home that might be working on bare-metal firmware, e.g., a coffee machine, an Oven, washing machine etc. In short, the appliance that do not require complex algorithms can be made using bare-metal firmware.

Let’s discuss the pros and cons of bare metal systems

Pros & Cons of bare metal


  • Low-level control over the hardware
  • Efficient use of resources
  • Small code size
  • Lower development cost and time
  • Fewer points of failure


  • Limited functionality
  • More difficult to develop and debug
  • No support for multitasking
  • No support for complex algorithms

RTOS Firmware

Now, let us take another example of a home automation system. This system has Wifi/Zigbee controlled lightbulbs, fans, blinds, door opener/closer, Air purifier etc., that can be controlled using manufacturer mobile App, Siri, Alexa, Google Assistant, HW buttons etc. Can you imagine writing the code for this application in a single while loop? Although I am not saying that it’s not possible, but it is definitely not a cakewalk. So, we need some mechanism that will do different tasks such

  • Communicate to devices over WiFI/Zigbee
  • Communicate to Mobile App
  • Communicate to Siri/Alexa/Google Assistant
  • Run some algorithms for different features

What if we make various modules that will be doing only one stuff in its while(1) loop? Now, its seems to be a good choice but the processor can run only one while(1) loop. How will be able to execute another modules while loop. Hear comes the RTOS. RTOS is a Real Time Operating System that behaves like a OS but is not a complete OS. It can schedule the tasks and give us an impression that every modules task is running parallel.

So, we can say that, RTOS is a type of operating system that is specifically designed for real-time applications, which require precise timing and scheduling. RTOS-based firmware provides more functionality than bare-metal firmware, as it can make use of the services that are normally provided by the operating systems, such as task scheduling, memory management, and communication between tasks.

So, the code for an RTOS will looks something like this

int main() {
    // Initialize the system

    // Create threads for various tasks
    create_thread(ethernet_communication_task, "Ethernet Task", STACK_SIZE);
    create_thread(zigbee_communication_task, "Zigbee Task", STACK_SIZE);
    create_thread(siri_task, "Siri Task", STACK_SIZE);
    create_thread(alexa_task, "Alexa Task", STACK_SIZE);
    create_thread(google_assistant_task, "Google Assistant Task", STACK_SIZE);
    create_thread(features_task, "Features Task", STACK_SIZE);

    // Start the scheduler

    // Should never reach here
    return 0;

Here each thread will have its own while(1) loop and IPC mechanism are used to communicate between the threads. VxWorks, FreeRTOS, ThreadX are some very popular RTOS.

Pros & Cons of RTOS


  • High-level functionality
  • Real-time responsiveness
  • Support for multitasking
  • Support for complex algorithms
  • Hardware abstraction layer
  • Improved code reuse and modularity


  • More complex and resource-intensive
  • Higher development cost and time
  • More points of failure
  • More difficult to optimize for specific hardware
  • Requires knowledge of operating system concepts

Comparison of Bare metal & RTOS

Now let us have a look on the comparison of Bare metal and RTOS based firmware.

AspectBare MetalRTOS
DefinitionSoftware that directly interacts with the hardware without using any OS or task scheduling algorithmsA kind of operating system designed for real-time performance, allowing multiple tasks to run concurrently
Hardware AccessDirect access to hardware resources such as registers, timers, and interruptsAlthough direct access can be done but is not recommended. Access to the hardware resources is done through the RTOS APIs
Task ManagementNo task management or scheduling provided. Each function is executed in sequenceTask management and scheduling provided by the RTOS, allowing multiple tasks to run concurrently
TimingNo inherent timing or scheduling provided. Execution time depends on the sequence of function callsReal-time scheduling and timing provided by the RTOS, allowing tasks to run with specific priorities and deadlines
Resource ManagementNo built-in resource management. Each function must manage its own resourcesResource management provided by the RTOS, allowing tasks to share resources and avoid conflicts
Code ComplexitySimple and straightforward code, but limited functionalityMore complex code due to the additional RTOS functionality, but more flexible and scalable
Development TimeFaster development time due to the simpler codeLonger development time due to the need to set up the RTOS and implement task management & debugging
Application SizeSmaller application size due to the lack of an operating system overheadLarger application size due to the additional RTOS code and functionality
System RequirementsLow system requirements, suitable for simple applications.Higher system requirements, suitable for more complex applications
Real-Time PerformanceNo inherent support for real-time performance. Timing and responsiveness depend on the function sequence and hardware capabilitiesDesigned specifically for real-time performance, providing real-time scheduling and timing

Choosing Bare metal Vs RTOS

Choosing the bare-metal or RTOS base firmware development depends on various factors. It is straightforward thing and needs to be done very carefully. Let us discuss some points that should be considered while choosing one out of these two.

System Requirements: One of the main factors to consider when choosing between RTOS and bare metal is the system requirements. If the system requires real-time performance, with multiple tasks running concurrently and specific timing requirements, an RTOS is likely a better choice. While on the other hand, if the system is relatively simple, with limited functionality and a straightforward execution flow, bare metal firmware may be good to go with.

Hardware Resources: The available hardware resources can also influence the choice between RTOS and bare metal firmware. If the system has very limited memory and/or processing power then bare metal will be the more practical choice, as it has smaller footprint and requires less overhead as compared to an RTOS. Conversely, if the system has ample resources, an RTOS can provide more flexibility and scalability.

Development Team Expertise: The expertise of the development team is also an important factor to consider. Developing bare metal firmware requires knowledge of low-level programming and direct hardware access. Developing for an RTOS requires additional knowledge of task management, scheduling, and other RTOS-specific concepts. Any development team working on one may find it difficult to work on other as both of these required different kind of approach to the solution.

Time to Market: Developing bare metal firmware can be faster and simpler than developing for an RTOS, as there is no additional setup or configuration required. However, an RTOS can provide more flexibility and scalability, which may be advantageous in the long run, especially for more complex systems.

Cost: The cost of development and deployment is also a factor to consider. Developing for an RTOS can be more expensive than developing bare metal firmware, as it requires more specialized knowledge and may require additional hardware resources. However, the additional functionality and scalability provided by an RTOS may be worth the cost in some cases.

If you want to learn about selection of MCU for your project, then kindly read “A Comprehensive guide to MCU selection“. It has explained more than 15 points that should be considered before selection of MCU.


You might find insightful: