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

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).

--- 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 article.  A 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.

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!

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!

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

Hi

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.

Thanks.

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!