Actions
Forum Thread Details
  • State Not Answered
  • Replies 1 reply
  • Subscribers 473 subscribers
  • Views 153 views
  • Users 0 members are here
Related

RTOS selection methodologies – what’s your experience?

squadMCU

A business colleague recently described the problems he had several years ago convincing developers to us an RTOS that didn’t seem to fit the standard expectations of what an RTOS should look like. “SSX5 was a sales flop, in great part because it met no standards and appeared to be missing lots of features that were considered RTOS basics.”
His experience highlights the difficulty that developers have when evaluating new embedded software, such as RTOSes. The embedded market has rather narrowly defined what an RTOS is (and what it isn’t).
Here are some RTOS selection approaches that we have observed but do not recommend. Perhaps these resonate with your experience:
Assume you need a traditional RTOS and then find a free or open source RTOS like FreeRTOS to try/play with and learn. It then becomes a de facto standard for how an RTOS should work. It is not examined very critically because it is free.
Start working with a free RTOS. If you can get a propotype or proof of concept running then go with it for the project.
License a brand name traditional commercial RTOS because ‘everyone else is using it’ (back in the 80s the saying was, “You never get fired for buying IBM.) yet never take the time to understand how it is structured or why. Just start coding.
Use a standard feature checklist or other generic comparison matrix to try to make an RTOS decision. This is obviously flawed if there is no understanding of how the RTOS or scheduling model will meet your particular application requirements.
Use the RTOS that you used in the last company/project. Because the devil you know is better than the devil you don’t know.
The most senior engineer picks the RTOS that he is most comfortable with, ignoring your pleas for a better selection process.
You start by addressing the perceived “pain points” in a new design (which is not usually believed to be the RTOS) but could be USB, Wi-Fi or some communications protocol you have never used before. You give little thought to the underlying design aspects of the RTOS since you expect it to work like any other RTOS.
Write your own RTOS or scheduler. Perhaps your assumption is that the DIY project will be exactly what you need (as opposed to a multi-purpose tool) or that your application is so simple that a commercial RTOS would add too much overhead.

A business colleague recently described the problems he had several years ago convincing developers to us an RTOS that didn’t seem to fit the standard expectations of what an RTOS should look like. “SSX5 was a sales flop, in great part because it met no standards and appeared to be missing lots of features that were considered RTOS basics.”

 

His experience highlights the difficulty that developers have when evaluating new embedded software, such as RTOSes. The embedded market has rather narrowly defined what an RTOS is (and what it isn’t).

 

Here are some RTOS selection approaches that we have observed but do not recommend. Perhaps these resonate with your experience:

 

1. Assume you need a traditional RTOS and then find a free or open source RTOS like FreeRTOS to try/play with and learn. It then becomes a de facto standard for how an RTOS should work. It is not examined very critically because it is free.

2. Start working with a free RTOS. If you can get a propotype or proof of concept running then go with it for the project.

3. License a brand name traditional commercial RTOS because ‘everyone else is using it’ (back in the 80s the saying was, “You never get fired for buying IBM.) yet never take the time to understand how it is structured or why. Just start coding.

4. Use a standard feature checklist or other generic comparison matrix to try to make an RTOS decision. This is obviously flawed if there is no understanding of how the RTOS or scheduling model will meet your particular application requirements.

5. Use the RTOS that you used in the last company/project. Because the devil you know is better than the devil you don’t know.

6. The most senior engineer picks the RTOS that he is most comfortable with, ignoring your pleas for a better selection process.

7. You start by addressing the perceived “pain points” in a new design (which is not usually believed to be the RTOS) but could be USB, Wi-Fi or some communications protocol you have never used before. You give little thought to the underlying design aspects of the RTOS since you expect it to work like any other RTOS.

8. Write your own RTOS or scheduler. Perhaps your assumption is that the DIY project will be exactly what you need (as opposed to a multi-purpose tool) or that your application is so simple that a commercial RTOS would add too much overhead.

 

 

Read the complete entry

  • 0

    As with any component, an RTOS needs to fit a long term product requirement.  If you are looking at a sustained reuse and upgrade cycle for your product or product family, then you have a solid reason to evaluate an RTOS.

    Define the RTOS features you need.  Look at the RTOS options available, make sure they are mature, not new products.  You do not want to get caught debugging someone elses new product.

    Select the RTOS that meets your requirements, reguardless of cost.  Cheap or free RTOS sometimes come with hidden costs that will be far more expensive than a solid product, even if you have to pay royalty fees.

    Verify the RTOS on a current version of your product.  If you can't make it work for your existing product, then it will not meet your future requirements.  The verification testing gives you a feel for how easy the RTOS will be to use by the organization.  It will also show you if the RTOS is reliable and stable.  If you keep getting updates from the supplier, go to the next one on the list.

     

    Basically, you will only trust an RTOS after it has demonstrated that it can work for your product.  Usually, you will need to do this testing on your own time.  Though it is worth pitching to management the value of a full R&D task and funding to see if the RTOS could be of value to the entire organization.  It works some of the time.

     

    After you select an RTOS, learn everything you can about its options, timing, responses, etc.  Treat it as your holy grail and learn it well.  Only then will you be fully confident to use it on all of your projects.  Even when I used to roll my own OS, I reused it repeatedly until it proved that it could no longer do the job.

     

    Bottom line, you want a simple and easy to use RTOS.  The more bells and whistles, the more likely that you will get into trouble.  Just because it has neat functions is no reason to use them.  Remember, you could get stuck upgrading the product one day, so write down everything you learn.

     

    Thanks,

    DAB