RTOS or bare metal - five decisive factors
The decision whether to run firmware under a real-time operating system (RTOS) or to develop a bare-metal solution can be critical to the success of the embedded system. Deciding which direction to go can be difficult, however. Here are five factors every developer should consider before making the decision.
Factor #1 – Preemption
The major factor in deciding between an RTOS and a bare-metal scheduler is whether the system needs preemption. If preemption is a requirement then an RTOS is the way to go! The ability to suspend a task and have a higher priority task execute is one of the RTOS's major advantages. The system's real-time performance can be greatly enhanced if the priorities of tasks are set appropriately. At the bare-metal level, a developer might argue that preemptive behavior can be obtained by using interrupts and setting interrupt priorities. To some degree this is true, but such interrupts should be fast, short, and sweet. Attempting to use an interrupt to preempt a currently running function could affect the system's real-time performance.
Factor #2 – Memory
The first instinct of many developers nowadays is to jump straight to the use of an RTOS while at the same time trying to select a part with a minimum set of RAM and flash. But they do so with little to no understanding of the end software memory footprint. The result is a "will not fit in region" error just waiting to happen. Many RTOS’s by default set each task or thread stack size to 0x200, which is an indicator of stack depth not size. On a 32-bit machine that size could be as much as 2kB of RAM per task by default! Obviously, that amount can be tuned to the application but the default does start to provide some insights into what is the minimum amount of RAM required to use an RTOS.
Flash usage of an RTOS should be considered as well. A typical RTOS can use at a minimum 6 – 8 kB of flash. This sounds like a pretty small footprint, unless only 16 kB of flash space is available in the chosen MCU. When considering the use of an RTOS, then, a good rule of thumb is that the system at a minimum should consist of 32 kB of flash and 4 kB of RAM. My personal preference is to have at least 8 kB of RAM.
Factor #3 – Middleware
Available middleware can be an important deciding factor on whether or not to use an RTOS. Many RTOS’s have middleware stacks such as file systems, USB, or TCP/IP that easily integrate into the RTOS. Attempting to integrate these stacks into a bare-metal system would be time consuming and error prone while they would be simple and drop-in with the RTOS. A developer should consider what middleware stacks might be necessary for the application and with which solution they will best "play nice."
Factor #4 – Portability and Reuse
The use of an RTOS doesn’t guarantee portability or code reuse but neither does a bare-metal solution. The design of an RTOS based firmware solution does, however, tend to result in firmware that has clearly defined tasks and can lend itself to being reused. Bare-metal firmware can be written to be portable and reusable but that usually feels like it requires more effort and doesn’t come naturally.
Factor #5 – Experience
The selection of an RTOS or bare-metal solution might be based on the experience of the developers. Inexperience with RTOS’s can result in a painful and bug-ridden development cycle. AN RTOS is quick to set up but can be time-consuming to debug. Some of the worst bugs I ever encountered have been due to an RTOS misbehaving. The layers of abstraction can make peering into the OS's real behavior difficult. A team inexperienced with RTOS may be better off using a bare-metal solution and test-driving an RTOS on smaller projects to gain the necessary experience.
What other factors do you consider when deciding to go bare-metal or RTOS?
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 firstname.lastname@example.org, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.