Real-Time Operating Systems (RTOS) are now part of over 50% of embedded projects, helping you manage system timing, memory, and other resources. They provide you with efficient scheduling tools such as time slicing and thread preemption while simplifying inter-task communication.

As more teams shift to 32-bit microcontrollers and continue to adopt IoT technologies, the demand for RTOS will only grow. If you are transitioning to an RTOS or have recently done so, you know that choosing the right RTOS is one of the significant challenges. So, how do you choose an RTOS?

When choosing an RTOS, you should avoid some common mistakes. First, it is not uncommon for teams to immediately rule out commercial RTOS. With so many open-source RTOS available, why would someone choose a commercial RTOS? The reasons usually boil down to considerations like certification, quality, safety, and technical support. For these reasons, you should not immediately dismiss commercial RTOS.

Secondly, do not choose an RTOS just because your chip vendor supports it first. While such support is often encouraging, you may find that they often lag behind the latest versions of the RTOS. When this happens, you may not receive critical security updates as quickly as if you had direct access to the source code.

Finally, do not choose an RTOS just because it is currently popular. Throughout my career, I have seen many trends come and go. In some cases, they change little from year to year. Technologies innovate like shiny toys, but if you are building a product that requires years of support, you may not be able to adopt a trendy, unproven solution.

Choosing an RTOS should be an engineering process. This means you will approach it in a scientific, engineering-centered way. You first identify the key features required in the RTOS. This may include performance, code size, safety features, etc. Starting with a checklist is a good idea.

Next, review your list and assign values to their importance. For example, if licensing costs are critical, you might rank it a 5. If licensing costs are unimportant, give it a 1 or even a 0. These rankings provide crucial insight into the selection process. They tell you the features and characteristics you want in an RTOS. After all, no two RTOS are the same or provide the same features in the same way.

Only after you have determined the feature list and ranked them are you ready to evaluate which RTOS is suitable for your application. Each developer’s biases may distort the selection process. I often suggest teams use a KT matrix for evaluation. Each developer can assess how well each RTOS being considered matches the desired feature list. They can provide a rating from 0 to 5, which can then be used with the feature rankings to generate a weighted value. The weighted sum of the features can then be used to compare how well each RTOS fits the application needs.

The result is an unbiased decision, selecting an RTOS that meets your team’s needs. You may find that more than one RTOS could work for you. When this happens, you can use your personal biases to choose which one you want to use.

Selecting an RTOS that can work with your application and continue to do so into the foreseeable future is not easy. Often, choosing an RTOS only leads to discovering months or quarters later that it does not fully meet your expectations. As we have seen, spending a little extra time upfront to define your expectations for what you need from an RTOS is crucial. Once you understand your requirements, you can carefully evaluate which RTOS best meets your application needs.

Only then can you truly adapt your RTOS choice. If you only consider selecting the most popular, trendy, or chip-provided RTOS, you may find your future development work a bit unstable.