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 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, and 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 – Third-Party Software
One of the problems facing many developers today is how to integrate third-party software stacks and tools into their embedded system. Few developers want to write a TCP/IP or USB stack. Many of the third-party stacks and tools that are available on the market are compatible with various RTOSs. The use of an RTOS makes these components plug-and-play within the software and can drastically accelerate software development. The decision to use third-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, an 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. An 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, software developers need to understand the pros and cons of each type of solution and how to properly implement a solution in either scenario.
Jacob Beningo is a Certified Software Development Professional (CSDP) whose expertise is in embedded software. He works with companies to decrease costs and time to market while maintaining a quality and robust product. Feel free to contact him at [email protected], at his website www.beningo.com, and sign up for his monthly Embedded Bytes Newsletter here.