Written by Matt Fleming, Director of Read Modify Write
Baylibre collaborates with manufacturers of consumer electronics, providing custom firmware solutions and specializing in Linux-based IoT devices. We’ve worked on several embedded consumer products using the Zephyr Project, including the Sensor Hub in the Blocks modular smartwatch and Ellcie Healthy glasses, and the Embedded Controller for the Gnarbox.
When choosing our Real Time Operating System (RTOS) for these projects, we had a quite a few options because the RTOS market is increasingly fragmented. Top of our priority list was a project using a permissive license, and providing a free solution. This eliminated FreeRTOS from consideration since it was still under a GPL or proprietary license at the time. Mbed OS was another contender, but we felt it was too dependant on the Mbed ecosystem. We considered using NuttX or building a bespoke OS, but ultimately decided that Zephyr best met our needs.
Zephyr is an RTOS hosted by the Linux Foundation. It is scalable, supports multiple hardware architectures, is optimized for resource-constrained devices (everything is statically allocated), and built with security in mind. Collaboration is also actively encouraged, from individual coders to major companies contributing. We liked that it is similar in many ways to Linux (in its coding style and build process), has a strong community focus, and fantastic documentation. The permissive Apache 2.0 license was also an advantage.
Zephyr’s release cycle is three to four months, with (approximately) an 11-week merge window and 3-week stabilization period. Each release is a combination of planned new features and community contributions.
Those community contributions meant that Zephyr gave us a lot of what we wanted out of the box, and made it easy for us to upstream the elements we added for our customers’ products: support for the STMicroelectronics STM32L4 and STM32F0 MCUs. STM32F1 was already supported, so we were able to copy that example, simplifying our development work. That also made porting very fast. We completed a basic port in a day and a half, and a fully-tested port in less than one week.
Overall, we found Zephyr to be well-structured and simple to use. Most of the port time was spent on I2C/SPI testing. Once porting was complete, the Zephyr upstreaming process was straightforward. We:
- Read the contribution guidelines
- Cleaned up our patch to follow Zephyr’s coding standards (with help from uncrustify)
- Verified that the patch met the coding standards using checkpatch
- Committed our changes to github
- Awaited reviews
Fortunately, the Zephyr project provides a community of reviewers and we were able to contact the maintainers on the Zephyr IRC channel to assist with getting patches merged.
Despite challenges during the review process, overall we found Zephyr easy to get started with thanks to its similarities to Linux, thorough documentation, and an active community. This RTOS’s design is good for low memory usage, and as the software and development processes evolve with growing community input and support, flaws are quickly fixed.
If you’d like to hear more about our experience with Zephyr to power consumer electronics products, check out our presentation from Embedded Linux Conference 2017: https://www.youtube.com/embed/XUJK2htXxKw.
Or, to learn more from Matt, please visit his website: https://www.readmodwrite.com.