Why should you use an RTOS in your project?
When starting embedded product development, the biggest question that designers face is which microcontroller would be the best fit for the project? Getting this right is extremely important because reverting this decision further down in the development cycle costs money and more importantly the team loses months to switch to another microcontroller.
But why would you want to switch to another microcontroller?
The reasons could be various….
-
There could be a chip with better features. Like more flash and RAM or with better power consumption.
-
You were able to negotiate a better price with some other chip vendor and if you use this new chip then your cost reduces significantly.
-
You are using the best chip, but you are not able to find people who have experience of designing with this chip. In that case, you might end up spending more on your development.
-
After spending months into development, you found out that the chip lead times are too much, or the support team is sluggish to reply on your queries.
Wouldn’t it be wonderful to be able to switch microcontroller from your design with minimal effort!
Apart from the technical reasons of using an RTOS over bare metal I feel the flexibility to use a range of different microcontrollers from multiple vendors is the biggest advantage that an RTOS can provide.
Why is it so difficult to switch hardware?
To change the microcontroller in your design you must spin new boards which includes designing and prototyping cost. The firmware has to be ported to use with this new chip. For this your firmware team need to learn about the new microcontroller and the tools required to work with it. Tools include chip vendor provided libraries and peripheral drivers, development tools like IDE, compiler, and debugger etc. The firmware team needs significant amount of time in “Getting started” with the new chip.
What should you look for when selecting an RTOS?
You should clearly list your application requirements first. You could select an RTOS based on several things like…
-
Memory footprint and the memory overhead the RTOS requires
-
Power consumption
-
Support of a specific chip
-
How easy it is to find people to work on it
-
Is there any licensing cost involved?
-
Is the license putting any restrictions on your final product (For example not to be used for commercial purposes etc.)
-
Support of a particular feature like a network protocol like BLE
-
Neutral governance.
-
Continued long term support.
Out of the above, neutral governance becomes more and more important when you are trying to scale the product. For example, FreeRTOS is now acquired by Amazon. People using FreeRTOS would feel more inclined to use AWS for their cloud needs without even evaluating the alternatives as it would be easier to use with FreeRTOS. Similar advantage is there for Google apps on Android and for Microsoft on Windows.
Which RTOS to use?
Zephyr RTOS is what I found good for use for the following reasons…
-
1. It is supported by Linux foundation. This means there will be continued support and neutral governance.
-
2. The structure and tools required are similar to the ones in Linux. Anyone who has experience with Linux or Linux based RTOS would be able to work with this RTOS as well. This ensures availability of people to work on Zephyr RTOS.
-
3. Good support for BLE. Since I work frequently on Bluetooth Low energy applications, this is important for me.
There are other good RTOS available, but I would suggest choosing one and try to use it across your project. All the good RTOS would be good enough for generic firmware applications so unless a different RTOS gives you something which you absolutely need, don’t switch RTOS. This would save significant amount of time for you.