The use of an RTOS or a bare metal scheduler is a popular topic to debate among embedded system developers. On the bare metal side, developers argue they can use a combination of priority based interrupts and timers to get equivalent behavior with better performance and memory footprint. The RTOS side argues ease of scheduling and system integration for starters. No matter which side of the debate one takes, here are seven reasons a developer may decide to start with an RTOS over a bare-metal scheduler.
Reason 1 – Concurrency
Microcontroller based systems typically only have a single processing core but a need to execute multiple tasks. In applications where tasks need to appear to executing at the same time or concurrently, the use of a RTOS makes sense. A RTOS can have multiple tasks simultaneously in memory and can switch between the tasks based on events and priorities. A bare-metal scheduler could be used but tasks in a bare-metal system usually execute one at a time and not concurrently.
Reason 2 – Pre-emption
Pre-emption is the ability of an operating system to temporarily suspend a task in order to execute a higher priority task. If the embedded software that is being developed requires the need to prioritize tasks and interrupt tasks that are currently running, an RTOS is the go to operating system. The nature of most RTOS systems is to determine which tasks should be executing at any given time based on the priority of the task and the system conditions. A bare-metal scheduler can be developed that emulates this type of behavior using priority based interrupts but the use of an RTOS is more appropriate for the situation.
Reason 3 – Available RAM
The amount of available RAM on a microcontroller can be a big determining factor as to whether an RTOS or a bare-metal scheduler is used. Resource constrained systems that have less than four kilo-bytes of RAM can be difficult to fit within memory due to the fact that each task has its own task control block and stack. A bare-metal system on the other hand typically has just the one stack and doesn’t require the extra overhead necessary to keep track of the state of each system task. At a minimum, microcontroller based systems should have at least four kilobytes of RAM (preferably eight)before going with an RTOS solution.
Reason 4 – Available Flash
Since a developer should look at how much RAM is available on a system before deciding to go with a RTOS, a developer should also look at how much flash space available. RTOS systems don’t take up much flash space, usually on the order of eight to ten kilobytes, but if the microcontroller only has 16 kilobytes of flash space, there really isn’t much room left for the application code. If the microcontroller has at least 32 kilobytes of flash space then the system is a good candidate for the use of a RTOS. Anything less and it might be time to dust off the bare-metal scheduler or upgrade the hardware.
Reason 5 – Synchronization tools
One of the problems with using a bare-metal scheduler is that it lacks synchronization tools that are included by default in a RTOS. For example, an RTOS has Mutexes that can be used to protect a shared resource, Semaphores that can be used to signal and synchronize tasks and message queues to transfer data between tasks. Properly designing and implementing these core software features isn’t trivial and adding them into a bare-metal scheduler from scratch will undoubtedly inject bugs. If a system has multiple tasks and protected resources that require synchronization then the use of an RTOS is the wise decision.
Reason 6 – 3rd Party Software
One of the problems facing many developers today is how to integrate 3rd party software stacks and tools into their embedded system. Few developers want to write a TCP/IP or USB stack. Many of the 3rd party stacks and tools that are available on the market are compatible with various RTOS’s. The use of an RTOS makes these components plug-n-play within the software and can drastically accelerate software development. The decision to use 3rd party software could be a major indicator that an RTOS should be used over a bare-metal scheduler.
Reason 7 – Ease of Use
RTOS systems are readily available for nearly every microcontroller and for nearly application imaginable. Whether a developer just wants to create a rapid prototype or build a robust safety critical system, a RTOS exists that developers can leverage and get up and running fairly quickly. Creating tasks and utilizing RTOS tools is easy and very powerful but developers need to beware that they properly analyze their tasks and think through their system design. A RTOS is a powerful tool but improper use can result in tragic results.
Developers will undoubtedly continue to argue the case of whether to use a bare-metal scheduler or an RTOS. To some degree the decision is based on the skills and experiences of the developers designing the system. In other cases, there is no question that an RTOS is the primary solution. If one thing is clear it is that software developers need to understand the pros and cons of each type of solution and how to properly implement a solution in either scenario.