15 Dec Getting to know Zephyr
Getting to know Zephyr
Frank Vanbever
15/12/2023
My background is in Embedded Linux, where we have these elaborate build systems that allow us to build complex systems by composing software into a solution – despite the joke that the second thing any C developer does after defining the main() function is starting to implement a linked list. Reinventing the wheel is the favorite pastime of the embedded developer after all.
Us embedded Linux developers don’t have it nearly as bad though as bare-metal developers. Where in embedded Linux-land we do regularly reinvent the wheel, the bare-metal developer generally has to, like Carl Sagan said, make an apple pie from scratch by first inventing the universe.
And that’s where the idea of the first sentence comes in. The idea had occurred to me before of having a Buildroot or Yocto-like build system for microcontrollers, integrated with a Real-Time Operating System that comes with batteries included. I didn’t do anything with that idea, but the developers of the Zephyr RTOS sure did.
They took this idea and ran with it.
We recently had a half day training at Mind about the Zephyr project. This was a gentle introduction to how to build and develop for Zephyr. Toon from Toost Solutions showed us how to build and develop for Zephyr on an STM32 microcontroller. My only experience with Zephyr was getting the toolchain set up beforehand. In those three hours we configured the software for our board and adapted an application to read out the values from the IMU. There’s something profoundly satisfying about getting confirmation from a sensor that the acceleration due to gravity is still approximately 9.8m/s².
For the embedded Linux developer, the whole experience is eerily familiar. After overcoming the hurdle of typing “west“ instead of “bitbake”, you end up in something that looks suspiciously similar to a Linux kernel menuconfig (or U-Boot, or buildroot, or …). Navigating through a menuconfig is a breeze compared to surfing the web for just the piece of software that is missing. Editing the device tree to add the IMU with its I2C address also feels very familiar. The only task is to look up the appropriate “compatible“ definition. Of course, this primer used an off-the-shelf board, so we were spared the “fun” of finding out how to configure the boot loader or other tricky board-specific details.
Three hours is by no means enough to call yourself an expert, but I left the training knowing enough about Zephyr to be dangerous and where to look to become even more dangerous.
Presentations