Home > On-Demand Archives > Theatre Talks >
Building a Modular Codebase with Zephyr RTOS and Devicetree
Mike Szczys - Golioth - Watch Now - Duration: 25:29
If there’s one thing the chip shortage has taught us, it’s to be ready to pivot to different hardware on a short timeline. I’ve found that the Zephyr Real-Time Operating System makes this much less painful for firmware engineers. It borrows many concepts from the Linux ecosystem, delivering Devicetree, Pin Control, and Kconfig to microcontroller-land.
In this talk I will detail how I use Zephyr to maintain one codebase that can be built for many different hardware combinations. Once a Kconfig and Devicetree overlay files have been created for each target, compiling the same project for Nordic, Espressif, or NXP chips (to name just a few) is simple. Changing vendors or models of sensor and other peripherals is a similar experience. The C code grabs all necessary hardware information like what pins are connected and which peripheral bus should be used for a particular build. From there it’s just a matter of changing the board name in the build command.
Join me for a tour of what this looks like in real-world examples where changing out a microcontroller or sensor no longer leads to premature hair loss and hypertension.
This sensor only has 3 channels, so if you want all three values the fetch is not wasteful.
You may have also guessed there is an api call to fetch just one channel if that's what you need:
https://docs.zephyrproject.org/latest/hardware/peripherals/sensor.html#c.sensor_sample_fetch_chan
Hi, I was wondering how the Zephyr runtime sensor selection works. You quickly mentioned it in your presentation (e.g. the sensor has changed and it should be managed with the same code base).
I just added the sample code in a reply to this talk. You can see there that I'm not switching out sensors at run-time, it's all at compile time for this example. As long as the sensor uses Zephyr's Sensor API, includes the SENSOR_CHAN_AMBIENT_TEMP channel, and has the "weather" alias assigned in the Devicetree, the C code will work.
If you're looking for a more nuts-and-bolts explanation. Here are the two different sensor drivers assigning readings to the SENSOR_CHAN_AMBIENT_TEMP channel:
The fetch() API call uses the specific sensor driver "get" function to retrieve a standardized set of sensor channel values.
Thank you Mike.
So my general question would be if the Zephyr drivers concept foresees a run-time switch of the sensor type, preferably based on an auto-detection of the mounted sensor, or if one has to implement this management from scratch.
I guess what you are depicting ( a static selection by mounting a different code base) covers only a part of the problem. Nowadays with global delivery problems, one must be quite flexible with things like that, meaning that the code base shall support different sensors at the same time.
Code examples from my talk are available in the EOC23 Golioth Weather repository
Hi. Great intro to Zephyr. In your opinion, what is the best way to handle custom PCBAs (with fully layed out MCU, no dev kit) : copying device tree from dev kits and modify it ? or just create an overlay that maps to a dev kit (even though we are using the chip and not the dev kit) ?
I have copied from dev-kits in the past. Much of the work of including the SoC and other tasks is already done in the zephyr/boards/... definitions so it's a time saver to start from there and modify to match your custom board.
Reading every possible sensor data seems wasteful, when we only need 1-2, especially if we have timing constrains.