> 1) Are there advantages / disadvantages to the different kinds of groups > supporting and contributing to RIOT vs Zephyr (Europe/US, academic/industry, > ?/?)
The most contributions are coming from academic people, I would say. A lot of people are located in Germany, France and the Netherlands. 2 years ago we had our RIOT OS Summit in Amsterdam. But there are also some industries involved in the project. If you want to have more data on it, you should probably analyze the Github projects. > Are there advantages / disadvantages I should be aware of for using the OS > commercially (compared to Zephyr) Yes, the license. Zephyr is less restrictive, but this comes also with a big disadvantage, I think. You can use all of your changes in a private environment with the Apache 2.0 license. While with the LGPLv2.1 license in RIOT, you have to distribute all changed in the RIOT OS core. It looks more restrictive at first glance, but I think this is one of the biggest advantages of RIOT. You don't need to publish your app business code, only the RIOT core code. Due to the structure and build process of RIOT OS, this is also not complicated to maintain. Just something you have to be aware of. > Are there advantages / disadvantages to the hardware abstraction method RIOT > uses (vs DTS in Zephyr) I am not that familiar with Zephyr OS. But this is probably more of a question of taste. Miri wrote a blog post about porting to a new board. [1] It is not that complicated to port to a new board. I have done it a couple of times for some development reasons. > 4) What is the goal of the development of the OS (use by industry, academic, > educational use, hobby)? https://github.com/RIOT-OS/RIOT/wiki/RIOT-Vision What I personally like about RIOT OS and keeps me in this project, is the openness. There are always people who get their hands dirty with the current IETF/IEEE proposals/standards. Some of them are even involved in defining them. If there is a standard which is really interesting for you, you will definitely find somebody else interested in it as well. In my case this was IPv6 over BLE (RFC7668). To get an IPv6 stack running on legacy hardware. CoAP, CBOR, 6LoWPAN with RPL, you name it, it's there. And, of course, everybody is happy to see more F(L)OSS standards in RIOT OS. > Any technical limitations I should be aware of? Not that I am aware of. There might just be an advantage developing on Unix system such as Linux or Mac. But there are also ways to work under Windows. One thing could be better tbh. There is still a lack of documentation for beginners. But, if you are just a little bit familiar with Linux, it is not that complicated to understand RIOT. It can be even be a benefit in the mid/long run, to understand the structure. Especially if you want to port your driver into the core. Am 2020-03-09 17:01, schrieb Noëlle Clement: > Hi RIOT users! > > 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 RIOT OS would > be a good choice for us? (The main comparison right now is between RIOT-OS, > Zephyr Project 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 > RIOT vs Zephyr): > 1) Are there advantages / disadvantages to the different kinds of groups > supporting and contributing to RIOT vs Zephyr (Europe/US, academic/industry, > ?/?) > > 2) Are there advantages / disadvantages I should be aware of for using the OS > commercially (compared to Zephyr) > 3) Are there advantages / disadvantages to the hardware abstraction method > RIOT uses (vs DTS in Zephyr) > 4) What is the goal of the development of the OS (use by industry, academic, > educational use, hobby)? > 5) Any technical limitations I should be aware of? 6) Any technical > advantages (over Zephyr)? > > Any help is really appreciated! > > All the best, Noelle > > _______________________________________________ > users mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/users Links: ------ [1] https://blog.martine-lenders.eu/riot-board-en.html
_______________________________________________ users mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/users
