RTOS Vs Bare Metal: A Strategic Guide For Developers

Table of Contents show

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

Pros

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

Cons

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

Pros

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

Cons

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.

Aspect	Bare Metal	RTOS
Definition	Software that directly interacts with the hardware without using any OS or task scheduling algorithms	A kind of operating system designed for real-time performance, allowing multiple tasks to run concurrently
Hardware Access	Direct access to hardware resources such as registers, timers, and interrupts	Although direct access can be done but is not recommended. Access to the hardware resources is done through the RTOS APIs
Task Management	No task management or scheduling provided. Each function is executed in sequence	Task management and scheduling provided by the RTOS, allowing multiple tasks to run concurrently
Timing	No inherent timing or scheduling provided. Execution time depends on the sequence of function calls	Real-time scheduling and timing provided by the RTOS, allowing tasks to run with specific priorities and deadlines
Resource Management	No built-in resource management. Each function must manage its own resources	Resource management provided by the RTOS, allowing tasks to share resources and avoid conflicts
Code Complexity	Simple and straightforward code, but limited functionality	More complex code due to the additional RTOS functionality, but more flexible and scalable
Development Time	Faster development time due to the simpler code	Longer development time due to the need to set up the RTOS and implement task management & debugging
Application Size	Smaller application size due to the lack of an operating system overhead	Larger application size due to the additional RTOS code and functionality
System Requirements	Low system requirements, suitable for simple applications.	Higher system requirements, suitable for more complex applications
Real-Time Performance	No inherent support for real-time performance. Timing and responsiveness depend on the function sequence and hardware capabilities	Designed 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.

References

You might find insightful:

RTOS Vs Bare Metal: A Strategic Guide for Developers

ByAdmin