In this article, we will discuss the main differences between bare-metal embedded systems and RTOS based embedded systems. Bare metal is also known as super loop embedded systems. Because there will be a single loop and we write every task code inside this super loop except interrupts. On the contrary, in RTOS based embedded systems, every task is scheduled according to a specific period and aperiodic/sporadic tasks can also be scheduled easily.
Before jumping right into the difference, pros and cons of bare-metal programming and RTOS (real time operating system) programming let’s first have a general overview of both of these programming systems.
Bare-metal Embedded Systems
On a simpler note, bare-metal programming means writing an application directly on your hardware without using an external application programming interface i.e. without any operating system. We write embedded applications by directly accessing memory-map hardware registers of microcontrollers.
If you want to know about bare-metal embedded programming, check these posts:
- Accessing Memory Mapped Peripherals Registers of Microcontrollers
- Bare Metal Embedded Systems Build Process using GNU Toolchain
In the early days of embedded systems, the hardware was not so mature and strong to support a complete operating system overhead. At that time the developers preferred using bare-metal programming and saved themselves from the problems and complexity of the operating systems. By the time when the processors of microcontrollers were much matured, they started using the OS interface.
A bare-metal embedded development approach is also known as super-loops or background systems. As you can see in the following diagram, an infinite loop will be running all the time and all tasks will be executed sequentially. For example, first Task1 will execute, then Task2, Task3, and so on unless an interrupt event occurs. A microcontroller will stop sequential execution only when there is an interrupt event.
But bare metal based embedded systems also have a startup file to perform initial hardware initialization, memory stack/heap setup. You can read more about startup file in this article:
We use bare metal or super loop programming when we want to develop,
- An application that does not require task/thread preemption
- Where real-time deadline is not a requirement
- Low-level applications which do not have large memory to fulfill the need of an operating system.
- When you don’t want to use third-party firmware and drivers to interfere with your application
- A low-cost application which can access all the registers of the hardware.
RTOS Based Embedded Systems
With time, the evolution of the embedded world introduced real-time embedded operating system programming. Using RTOS we use an operating system interface between the application and processor. The difference between a normal operating system and real-time operating systems lies in its response time. The simple OS has a non-deterministic response time to external events, RTOS however replies to all the external activities in minimal and deterministic time.
Another major use of RTOS is when we need selective task scheduling. RTOS selects the next task in the scheduler depending on its priority and have the capability of task preemption which normal OS and bare-metal lack.
We use real time operating systems when we want to develop,
- An application at a high level where the cost of the project is not a big deal.
- An application that needs task preemption and where interrupts and tasks need to be prioritized .i.e. hard real-time deadline requirement
- Applications in which modularity is an important point to be followed and code redundancy should be minimum.
- High memory usage and efficient processing are required.
RTOS vs Bare-metal based embedded system
| RTOS | Bare-metal |
| Pre-emption is easy to achieve in RTOS and switching between task will take a lot less time than expected. | Pre-emption is possible in bare-metal also by using interrupts and prioritizing the interrupt but the time of switching between interrupts will be a lot more than the RTOS. |
| RTOS can be a lot less time consuming to work with if you are familiar with it. But if we are not used to working with RTOS it can produce behavioral bugs that will take ages to be fixed. | Bare-metal is time consuming but it is easy to work with as it cannot misbehave and all the work starting from registers to end user peripherals is done by the developer. |
| Code reusability is not guaranteed but it can be achieved by firmware development with a little more effort. | Code reusability is not possible and it does not comes naturally but it can be achieved with extra effort. |
| Middle ware is available in RTOS naturally such as file system and USB and can be integrated easily. | Middleware stack is not supported n bare-metal but obviously one can integrate it as they have access to everything in the hardware. |
| It simplifies the integration effort of all the devices using device drivers. | Integration effort is too much and will require too effort. |
| RTOS uses a lot more memory and code space. | Memory and code space used by bare metal is only of application as no OS is present. |
| Configurability of RTOS is lot less easier and it can be setup to work for a small application also. | Configuring a bare-metal for small application requires equal effort as that of a large application. |
Main Difference
In embedded systems programming, two types of firmware development methods are commonly used such as bare metal (super loop) and RTOS based. In bare metal programming, firmware or application code is written using memory-mapped peripheral registers in such a way that firmware can run directly on microcontrollers hardware without the need of any abstraction layers such as device drivers or operating system.
On the contrary, in RTOS based embedded systems, operating system kernel or device drivers are used between hardware and application code. In other words, OS kernel and device drivers provide an interface between actual application code and microcontroller’s hardware.
Conclusion
It is quite hard to decide what programming method we should use. Choosing one from these too mostly depends on the comfortability level of the developer. Once you get comfortable with RTOS it will be difficult for you to switch to bare metal and vice versa. The pros and cons of bare-metal and RTOS can not help us to pick one of them. In such advanced world of embedded system at the present time it is still an open debate when it come to choose one both these.
In simple words, choosing one from bare-metal and RTOS only depends on the application and its needs as discussed above. RTOS can be more suitable for one application a bare-metal can work more efficiently for others.
Related Articles:
- How to use FreeRTOS with Arduino – Real-time operating system
- Arduino FreeRTOS Queue Management – How to use Queues
- How to use FreeRTOS structure Queue to Receive Data from Multiple Tasks
- Changing the Priority of a Task
- Software Timers with Arduino – Create One-shot and Auto-Reload Timer
- Binary Semaphore – Examples of Tasks Interrupt Synchronization using Arduino
- Counting Semaphore Examples with Arduino
- Mutex tutorial with Arduino – Avoid Priority Inversion
- Interrupt Management Examples with Arduino