RTOS Vs Bare Metal: A Strategic Guide for Developers

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.

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

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
    system_init();

    // 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
    start_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

Comparison of Bare metal & RTOS

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

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.

References

• Real-time operating system – Wikipedia
• FreeRTOS – Market leading RTOS (Real Time Operating System) for embedded systems with Internet of Things extensions
• ThreadX – Wikipedia
• VxWorks | Industry Leading RTOS for Embedded Systems (windriver.com)

You might find insightful:

• Pipe – an IPC mechanism
• Sockets
• Message Queue
• Named Pipe in Linux