Arguments for continuing to use FreeRTOS

Hello,
I’m not sure if this topic really belongs here,
but there is currently a big discussion going on here at the company about why we should continue to use FreeRTOS,
because there seems to be a lot going for Zephyr OS. It’s free, functional safety, very small, fast, etc. and it is supported by the Linux Foundation, and according to the media, it will replace all real-time operating systems and is therefore more future-proof.
I want to continue using FreeRTOS, but I really don’t have any arguments against it, except that it’s difficult to configure, but my boss doesn’t think that’s a valid argument.
Can anyone provide me with counterarguments? I need some help here.

Thanks

footprint comes to mind. FreeRTOS may in the future be confined to platforms where storage is sparse, with the market heading towards hardware with abundant memory where a few MBit more or less do not make a difference.

Note that a corollary factor is power consumption and thus heat; for certain types of sensor applications, you can simply not design abundant memory or CPU power (cheap as it may be) on it for the simple reason that the circuit must not generate more heat than absolutely necessary.

Startup time may be another issue. But I know your dilemma, these discussions have been around forever, and with hardware becoming cheap and qualified developers becoming expensive, hungry hardware running stock software is becoming very attractive.

And another observation from experience is this: When your system runs on a small RTOS like FreeRTOS, you can get away with a team of a few developers that can maintain all components (but it is true that those gurus are in the critical path and turn out indispensable - something managers hate). When you switch to a more complex generic system, you will need one team to maintain the platform (in this case, Zephyr), one to watch over the BSP (and let us be frank - it is an illusion that that can be outsourced), and one for the application software. To managers, all of that looks neatly doable and separable - and you can get it to work, I have seen it happen -, but it will not cut costs because after the switch to the “in” platform, you will have more people on the payroll.

1 Like

Yes, unfortunately, that’s all true.
And because Zephyr OS is now also aiming for functional safety and remains free of charge, it will unfortunately be very difficult to find good arguments for FreeRTOS or other RTOSs.
There are few arguments against Zephyr OS.
It offers many embedded features, it is free, it will receive “Safety Out Context” status, and the community finds all the bugs. The days of embedded software developers are numbered.
That can’t be it, can it?

I would’t go that far, but it is true that the number of jobs for people with system background will decrease. It is also true, as mentioned earlier, that in practice, even though the idea is that all system knowledge is sourced out to the BSP suppliers, there will always be developers who have some kind of knowledge of those BSPs as those are never bug free - and do not count on the suppliers to fix every bug in real time, in particular if your company is not a major customer (ie purchases less than 1000 units of their SOCs). So a “local SOC/BSP guru” is always an option.

no :slightly_smiling_face:
Also if you encounter a problem and you have to progress with your product development .. then you’ve to get dirty yourself. I think, local in depth know how is and most likely will be crucial at least for serious business.

One possible argument against Zephyr OS, is that having an Apache license, means you need to be careful about any “fixes” you put into the Kernel code to handle special cases that you needed.

As has been mentioned, it appears to be a higher footprint system to incorporate more functionality into the kernel. IF you need that level of functionality, it can be useful, but it does raise the minimum system, and minimum power level, of the system it can be deployed on.