Originally published May 24, 2017
Edited and reformatted to publish with a new WP Host, May 27, 2024.
Email Header:
To: DEV_GROUP_FIRMWARE, DEV_GROUP_SOFTWARE
From: Doug@yourco.com
Subject: Choosing an RTOS
All,
I need to clear the air about the RTOS we chose in yesterday’s group meeting. In a few paragraphs, you will understand the reasoning behind the decision.
First, some of you have come to speak to me personally about the choice. Yes, I did cut off the discussion before all the alternatives were looked at in detail. The news about our choice has reached other groups in the company as well. Please if you discussed this decision with others, send them this email.
Second, yes, as a manager, I did have another meeting. That’s not the reason the discussion was ended so abruptly.
Third, I do believe the choice I made was the correct one. Thank you to those of you who stopped by to say it was the right choice.
Now, as to the way it happened. It was my mistake to just say at the end of the meeting, “For the new project and the next we will use this RTOS. Meeting is over, I have to run.” Selection of the Real Time Operating system is a big decision. The RTOS is the basis of the whole product and a tool we will all be living with for years. Please believe me, the choice was not made lightly.
What is the best way to chose an important part of a new design? That is really the question I hope to answer in this email.
I do appreciate the healthy debate on the topic. I know some of you have strong feelings both for and against our choice. Open source tools are great, always improving, and that has to be a consideration. Getting support from a vendor is also important. I realize free software is free like a puppy, not free like a beer. We will keep this puppy for a long time.
It was suggested we look at alternatives. No, the team not going to do that.
Consider the alternative universe where we looked at all of the options and made a “proper engineering decision”.
First we should look at what is available. I keep an eye on the RTOS market. There are dozens of commercial offerings. Off the top of my head I can think of Nucleus, uCOS, Keil, QP and VxWoks. There are more open source choices like Linux, RTEMS, or FreeRTOS and many small projects. We also have large Linux like distributions like Zephyr, Yocto and BitBake used in OpenEmbedded.
If everyone finds their favorites, and eliminate the redundancies, in about a weeks time, let’s guess we could have 12-15 choices. Now, how do we decide?
Well, we should eliminate any that do not include required features. Based on the document from marketing, I am not sure what the required features would be. I would summarise the specification as “better, smaller, and faster”. Now maybe we need to go and find out what those requirements really should be. Some meetings and discussion and we will have a better idea. So we cut the list down to 8.
So, for the commercial offerings, we need to get some information. There are licenses to think about, and per device royalties. What is the full cost and how many units are we planning to sell? Back to marketing and sales for an estimate. There are demo versions of course. Can we build them, and get them running on our processor? What about driver support.
If all goes well now we have 2-3 top contenders. The people who worked on the demo probably don’t want to toss out there work. We should have a meeting to discuss the alternatives.
Now, if no one threatens to quit, we have the RTOS we will use for this project, maybe the next one. We can get by on the demo license to start if the lawyers get involved in the purchase contract.
How long did that take? 1 week for proposals, 1 for requirements, 1 for demo evaluation and 1 for prototyping. So 4 weeks give or take a few. Yes, I am throwing up a straw man argument, but you have to agree, it will not take zero time.
The decision is made, and the first steps are already happening to get the code running on the demo board. Others are looking into the application, and starting to look at driver code for our unique peripherals.
The most precious resource we have is time. A schedule slips one day at a time. Because the deadline feels far away, it seems like being slow here will not hurt us. I would argue the opposite is true. A slip at the start is the same as a slip in the schedule the day before the deadline.
If it turns out to be unusable, or the wrong choice, we can always try another. Nothing is set in stone. I prefer progress over debate, so let’s build something great.
I hope that answers your questions.
Thanks,
Doug
Leave a Reply