What can the Zephyr RTOS do for you as a developer? (Part 2)

Welcome back to the second article about the Zephyr RTOS, and how it can make your life as a developer easier. In the previous article, I focused on the topics of set-up and configuration. Now I want to present two further features which go beyond that. To give a more rounded view, I included a critical look at aspects of Zephyr that could be problematic for your use case.

 

The test runner: Automate testing on hardware without hassle

Another part of tooling that you usually must set up yourself, but which comes pre-packaged with Zephyr is built and test automation. Zephyr includes a test runner called twister which is geared towards building and testing applications on different platforms. It supports both emulators and connected boards as targets.

Following the modularity of Zephyr’s source, each application can individually configure how twister should interact with it in great detail. That way, it can set e.g. the value of Kconfig options, which architectures it supports, and which hardware features it needs. This makes test automation and CI integration a breeze.

 

The interactive shell: Inspect and modify your device live

A feature which you probably didn’t know you needed (until now) is an interactive shell. At first glance, it might seem to be a weird addition to an embedded system. However, once you were able to just view the list of devices on an I2C bus on run-time, you will never want to miss it again. Of course, it can also display the currently running threads and their state and various other statistics. But it goes a step further and offers commands to interact with many types of devices, such as GPIOs, I2C, SPI, ADC.

These commands allow to not just query information, but also to manipulate them live. That means not only that the state of a GPIO pin can be displayed, but it can also be configured and set arbitrarily.

This feature reduces the pain of debugging hardware behavior drastically because it makes a loop of “inspect behavior -> modify state -> inspect…” possible without needing any recompilation or additional tools.
On top of that, custom shell commands can be added very easily. With that, self-implemented systems can be made just as observable and responsive as the built-in drivers.

 

Does this sound too good to be true?

After all this praise, the question about downsides is justified. The answer is: Yes, there are issues which may speak against utilizing Zephyr. Many of its benefits stem from the project’s focus on novel features over stability. The development pace is quite rapid, and multiple big contributors potentially aim to develop in different directions. As a result, quite a few features were, and still are, unstable and may lead to spurious errors. Stability has improved within the last years, however. A portion of the time you save through the benefits can easily be eaten up by debugging unexpected behavior originating from Zephyr’s code rather than yours.

Another downside of the rapid development is that the internals and even APIs are quite volatile and subject to fundamental changes between releases. This problem is further exacerbated by the fact the documentation often lacks detail and is not always kept up to date with the current state of the system.
Therefore, when stability and maturity are necessary, an older RTOS with longer release cycles may be preferable. If you don’t want to miss out on the benefits and only want a little more stability, you should have a look at the LTS version of Zephyr.

I hope I could give you some insight into the benefits of Zephyr and why you might want to give it a try. The list I compiled in these posts is by no means complete and features are added and refined constantly. So, even if you pass on it for now, check back a few months later and your pain points might have been resolved already!