Developers can come up with amazing and convoluted reasons to not use an RTOS. I have heard excuses ranging from they are too expensive (despite open source solutions) all the way to they aren’t efficient and use too much memory. In some circumstances some excuses are justified but there are many reasons why a developer should look to an RTOS to help with their real-time scheduling needs.

From bare-metal to RTOS Quick Links

Reason #1 – Can simplify complex integration efforts

Many modern embedded systems that are going to be internet connected have more complex scheduling needs than a traditional stand-alone system. A few example components include file systems, USB, TCP/IP and GUI components just to name a few. Attempting to integrate these components into a bare-metal system would not only be time consuming but would be a nightmare to the average developer. In many circumstances these software components are designed to work alongside an RTOS which makes integrating them very simple. Integration efforts that might have taken weeks or a month at the bare-metal level can now be done in less than a few days just by employing an RTOS into the solution.

Reason #2 – Pre-emptive scheduling

There are times when a software application needs to stop what it is doing and pay attention to another task or activity. For a bare-metal scheduler, the only way that this can happen is if an interrupt is used and then code returns to where it was previously executing. An RTOS is designed to allow each task to be provided with a priority that helps ensure that the task is executed in a deterministic manner. A bare-metal scheduler can be designed to mimic pre-emption but in a true real-time system, the real deal is needed and that can only be found in an RTOS.

Reason #3 – Configurability

The go to excuse for many bare-metal developers is that an RTOS uses too much code space and memory. The fact is that RTOSes today are so configurable that they can fit in flash sizes smaller than two kilobytes just by adjusting the RTOS settings. An RTOS is very configurable for the application at hand and can even be setup to behave as simple cooperative scheduler! RTOS configurability allows a developer to enable the features that are needed for the application while disabling features that otherwise would take up too much memory.

Reason #4 – Portability and reuse

An RTOS comes with a pre-defined application program interface (API) that tends to stay fixed from one version to the next. The RTOS API provides a consistent interface that developers can use in their application code that can be reused and ported from one application to the next. Many popular RTOSes are developed so that they can be easily moved from one microcontroller architecture to the next. This organization can be it easier to develop software once the RTOS API’s are understood.

Reason #5 – Common toolset

RTOSes come in many shapes and sizes but there are some features that are common between all flavors. For example, every RTOS comes with a way to create tasks, destroy tasks, synchronous tasks, communicate between tasks and lock resources. Some RTOSes may even allow data pools to be created for various application purposes. The RTOS is convenient because these features are all provided and available immediately. In a bare-metal application, if these tools are necessary then the developer has to create them. Recreation wastes time, is never as fast as one thinks and comes with validation and maintenance issues. When using any RTOS, you can be certain that there is a minimal common toolset available to write the application.

Conclusions

There are many reasons why a developer should decide to use an RTOS. In many circumstances a basic bare-metal scheduler will do. In connected and IoT applications, where complex connectivity stacks need to be included, starting off with an RTOS might just be what the doctor ordered. Next time we will begin examining the basic tools included in every RTOS that developers need to understand. Stay tuned!