The use of a real-time operating system (RTOS) or a bare-metal scheduler is a popular topic of debate among embedded system developers. The supporters of bare metal argue that they can use a combination of priority-based interrupts and timers to get RTOS-equivalent behavior with better performance and memory footprint. The RTOS side stresses ease of scheduling and system integration, for starters. No matter which side of the debate one takes, here are seven reasons why a developer may decide to start with an RTOS over a bare-metal scheduler.
(Source: cooldesign at FreeDigitalPhotos.net)
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 be executing at the same time or concurrently, the use of an RTOS makes sense. An RTOS can have multiple tasks simultaneously in memory and can switch between them 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 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 4 kilobytes 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 4 kilobytes of RAM (preferably 8 kB) 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, he or she should also look at how much Flash space is available. RTOS systems don't take up much Flash space, usually on the order of eight to 10 kB, but if the microcontroller only has 16 kB of Flash space, there really isn't much room left for the application code. If the microcontroller has at least 32 kB of Flash space, then the system is a good candidate for the use of an RTOS. Anything less and it might be time to dust off the bare-metal scheduler or upgrade