toggle quoted messageShow quoted text
Since I have participated in similar comparison efforts in the past, I thought I may post my two cents here.
Please do bear in mind the following disclaimers:
- I work for a company that contributes to Zephyr
- I have been involved with Zephyr for a number of years
- My knowledge of other open source RTOS is limited to very basic use and examination of the codebase, as well as feedback from experience users
- ThreadX is currently (still) proprietary and, AFAIK, there’s no way to inspect its source code
Trying to reply to your questions here:
- Yes, there is quite a big difference. Without any hard numbers to support that statement (though those should be easy to collect from commit
logs), I believe the situation is quite different for both projects
- Contributions to Zephyr tend to come from silicon vendors (Intel, NXP, Nordic and others), from organizations that work closely with silicon
vendors (Linaro) or from companies that use Zephyr as an RTOS in their products
- Contributions to RIOT seem to come more often from Universities (FU Berlin, INRIA and HAW Hamburg mainly)
- The Zephyr contributor base seems to be about 3x the one in RIOT (as per GitHub)
- When it comes to advantages and disadvantages, I think the obvious advantage for Zephyr is that silicon vendors tend to know their ICs very
well, which makes optimizing for their hardware is more easily achieved. I assume the advantage with more research-oriented contributions (i.e. for RIOT) is the possibility to get access to more innovative (proven or unproven) technologies in some cases
- Well, the license is completely different. Zephyr uses the Apache v2.0 license, which is much more permissive than RIOT’s LGPLv2. IANAL, but
with RIOT any changes you make to the RTOS codebase you will be obliged to contribute back to the community. With Zephyr anyone can take the codebase at any point in time and modify it at will without any obligations (except for attribution)
- Don’t really know RIOT’s model today, but Zephyr uses proven technologies (Devicetree and Kconfig) to describe the hardware and configure the
software. RIOT is actually currently working on integrating support for those very technologies in the RTOS, following Zephyr’s steps. Zephyr uses vendor-provided HAL libraries to implement drivers in most cases, which benefit from additional testing and maturity
since those HALs are typically used in several other software products, not only Zephyr
- I am not sure if there’s a clear, stated goal in terms of using the RTOS, but from experience the goal of the different companies using it
seems to be to use it in actual, real-world products. In our case we use it as a building block for our SDK, which is the provided to our customers. Those customers end up making end-products which, by extension, run Zephyr
- Yes, power management in particular is under heavy development. I cannot compare to RIOT since I don’t know how much it supports. There are
also upcoming changes identified as important by the community such as better timeout handling in the kernel, multiple improvements to the various driver APIs and more.
- Likely a few in some areas, but again, without an in-depth comparison it is difficult to share. There are likely some technical advantages
to RIOT as well (especially in the area of networking, since RIOT seems to focus more on that). Typically things like userspace support, multiple architecture support (including Xtensa and now Cortex-A), TEE support are features that are not common in other
RTOS outside Zephyr.
From: users@... <users@...>
On Behalf Of Noëlle Clement via Lists.Zephyrproject.Org
Sent: 09 March 2020 13:21
Subject: [Zephyr-users] Opinions / experiences requested regarding choosing the right IoT embedded OS
Hi users part of the Zephyr project!
My team is looking into the possibility to transition from a bare-metal application to an OS for our embedded controllers. We develop IoT and wireless sensors solutions, for which we have also
developed our own controller and platform. A lot of in-house development and maintenance!
Would some of you be willing to answer some questions about why Zephyr OS would be a good choice for us? (The main comparison right now is between
Zephyr Project, RIOT-OS and ThreadX)
To give a summary of the reasons for even looking into a more advanced architecture: there are a few features common in embedded (IoT) OS' that would be very convenient for future development of
the controller. Things like hardware abstraction and task scheduling are very welcome. In general we want to make it easier to maintain the code (pre- and post release) and decrease time-to-market for new controller versions (with new/upgraded hardware modules).
A common requirement that also applies to us are the resource constraints and the ultra low power features (we need to be able to use the low power modes for the STM32L151CC, but that can be added in the port). Real-time isn’t a priority for us at all, although
the priority (pre-emptive)-based scheduling would be very useful.
The controller is part of the in-house developed IoT system, which currently is mostly used for Smart Waste and Smart Silo products
(detecting fill rates in both).
A few questions that popped up during my own research on this (mostly about Zephyr vs RIOT):
1) Are there advantages / disadvantages to the different kinds of groups supporting and contributing to
Zephyr vs RIOT (US/Europe, industry/academic, ?/?)
2) Are there advantages / disadvantages I should be aware of for using the OS commercially (compared to RIOT)
3) Are there advantages / disadvantages to the hardware abstraction method Zephyr OS uses (DTS vs HAL?)
4) What is the goal of the development of the OS (use by industry, academic, educational use, hobby projects)?
5) Any technical limitations I should be aware of?
6) Any technical advantages (over RIOT)?
Any help is really appreciated!