From bare-metal to RTOS: 5 Reasons to use an RTOS

Jacob BeningoOctober 18, 20167 comments

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.

This article is available in PDF format for easy printing

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.


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!

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him here, at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.

[ - ]
Comment by jorickOctober 26, 2016

An excellent article making the argument for an RTOS.  This is one that I'll give to my boss who actually suggested that we dump the RTOS on our next project (which of course I have no intention of doing).

[ - ]
Comment by rdipaoloOctober 19, 2016

--- Added after initial posting:

I was pointed to this article by a posting made by Stephane Boucher on a LinkedIn forum.  That posting said nothing of Jacob's earlier article - it only linked to this one, so I did not know that it existed until just a few minutes ago.  Mr. Boucher might have saved himself from any negative comments in the LinkedIn forum (which I copied also to here) if he had made it clear that this was not a stand-alone article.

I certainly wish that @Stephane Boucher would have made it clear that Jacob did publish an article prior to this one which did explain what a bare metal architecture is and how it can be used.  I did not see that this article even existed until just a minute ago.  Give this is the case I do retract my assessment of Jacob's article as being biased - the article this posting points to, if taken alone, would appear to be exactly as I earlier stated.  If one is to include Jacob's prior article and combine it with this one then my earlier comments should be considered null and void.  It simply wasn't made clear in the LinkedIn forum that this was a follow-on to a previous articleA better way to present it to this LinkedIn group would have been to be clear and point to both the first and second articles.  

Still, my apologies to Jacob for my misunderstanding.

-------------- This is what I had previously wrote, without knowledge that there was a prior article to this one and given that I am now aware of that previous article I retract the following (which would have been valid if that previous article did not exist - which is what I sincerely thought):

Jacob, Your article doesn't say anything that an experienced embedded engineer doesn't already know. Nearly 40 years of embedded experience have taught me that an RTOS is to be considered only after ruling out a bare metal architecture - using an RTOS should not be the default choice. The professional embedded engineer evaluates various architectural approaches to their firmware design and chooses though pragmatism and experience that approach with best serves the needs of the project.  Of course taking into consideration the pro-RTOS points that you made, but also taking into consideration the potential benefits of a bare metal architecture.

You say nothing about the extra maintenance required when using an RTOS, the inefficiencies that may arise due to having to work with a remote vendor when RTOS bugs and issues arise, the required extra testing and validation - especially in regulated industries.  This is real time and money Jacob, and there had better well be a *very* good justification for adding an RTOS that outweighs the extra project time and expense or else you are not doing your professional due diligence.

This is NOT a "bare metal" vs "RTOS" debate, which your article implies it is - if instead you had written a balanced article showing the pros and cons of each approach and explaining that the final decision should be made on what best suits the project's needs then I would take you seriously.  Instead you only say about bare metal architectures "In many circumstances a basic bare-metal scheduler will do".  That one very weak line alone sir IMHO doesn't give bare metal approaches a fair representation in your article.  In addition, you use the term in that sentence "bare metal *scheduler*".  Well, what if even a scheduler isn't needed, what about real "bare metal" - a foreground loop with interrupts - the most common embedded architecture in existence for very good reasons, yet no mention of it from you.
I'm most certainly not against using RTOSes, I've written my own, done development on commercial RTOSes, and used RTOSes on many of my projects.  My objection is in your obvious one-sided bias towards RTOSes without accurately and honestly presenting the pros of using a bare metal architecture.  Very unprofessional, IMHO.

[ - ]
Comment by beningjwOctober 19, 2016

Thanks for the comments. The "Baremetal to RTOS" series is meant to be for engineers who have been working in a baremetal environment and are interested in learning about RTOSes. In time, there were will be many articles that will cover the many nuances but as you might expect it is impossible to cover them all in 500 words or less. 

I have used an RTOS in maybe 15 - 20% percent of my projects with the remainder only requiring a baremetal technique. I get a lot of requests from developers, managers, etc to cover RTOS topics so in this series I'll mostly take the approach that we want to use an RTOS and here are the reasons, techniques, tools, pain points etc. 

There are some very cutting edge applications and processors now where developers are going to have to go straight to an RTOS and among my clients and mailing list I'm finding that younger engineers seem to be ill equipped for the challenge. Hopefully this series will fill in some gaps (hopefully some will come through experience), excite and build-up those engineers that don't have the background right now to be successful in a timely manner.

Thanks again for the comments!

[ - ]
Comment by pawelkOctober 20, 2016

I've been in the embedded world for some time now. And I find it true, that recently there is a greater need for RTOS. My last few project required some serious data throughput via telecommunications, as well as some IoT e.g. server. It makes no sense to do everything over and over again from scratch. Just grab one of free rtos and plug in a server, and off you go in a week. Yes, when there is literally 8-bit micro, with no ram :-) almost then you go loop and struggle with what you have, or mostly not have.

Good article ;) keep up!

[ - ]
Comment by beningjwOctober 21, 2016

Thanks for the comment pawelk! I appreciate you sharing your experience and thoughts! Those are great examples where RTOS is becoming a key factor.

[ - ]
Comment by jkvasanOctober 20, 2016


I read all the articles in the series. The series is comprehensive. It qualitatively describes the path that needs to be taken by a bare metal designer to try out RTOSes.

I feel that there is a need for a more practical treatment of the process as most baremetal(BM) designers have worked on the same state machine approach for years and to approach the design problem through RTOS frameowrk needs more time and effort.

Though RTOS manufacturers provide extensive material on how to implement their OS, the first step is always scary. 

Jacob can address this particular issue by writing more practical articles thus handholding a "Super-loop" engineer along the path, if possible.


[ - ]
Comment by beningjwOctober 21, 2016

Thanks for the comments and suggestions. I am planning to have more example oriented articles in the near future. There will also be some videos and related webinar materials that will help augment the series. 

Thanks again!

To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.

Please login (on the right) if you already have an account on this platform.

Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers: