Home > On-Demand Archives > Q&A Sessions >

Live Q&A - Building a Modular Codebase with Zephyr RTOS and Devicetree

Mike Szczys - Golioth - Watch Now - Duration: 35:29

Live Q&A - Building a Modular Codebase with Zephyr RTOS and Devicetree
Mike Szczys
Live Q&A with Mike Szczys for the theatre talk titled Building a Modular Codebase with Zephyr RTOS and Devicetree
italicssurround text with
boldsurround text with
**two asterisks**
or just a bare URL
surround text with
strikethroughsurround text with
~~two tilde characters~~
prefix with

Score: 1 | 4 months ago | 1 reply

Reading every possible sensor data seems wasteful, when we only need 1-2, especially if we have timing constrains.

Mike Szczys
Score: 0 | 4 months ago | no reply

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:

Score: 1 | 5 months ago | 1 reply

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).

Mike Szczys
Score: 0 | 5 months ago | 1 reply

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.

Score: 0 | 5 months ago | no reply

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.

Mike Szczys
Score: 0 | 5 months ago | no reply

Code examples from my talk are available in the EOC23 Golioth Weather repository

Score: 1 | 5 months ago | 1 reply

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) ?

Mike Szczys
Score: 0 | 5 months ago | no reply

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.

15:59:07	 From  Chris Gammell   to   Stephane(Direct Message) : can't seem to unmute myself?
15:59:35	 From  Chris Gammell : can't seem to unmute
16:10:31	 From  Mike Foss (NIWC PAC) : How do you handle it when you need something like DMA support for a UART, but the vendor hasn't included that in Zephyr? Is it better to figure out how to put it in yourself or nag the vendor?
16:12:12	 From  Mike Foss (NIWC PAC) : Thank you!
16:14:40	 From  Nathan O. : How does Zephyr works in terms of low power ? I have worked with FreeRTOS and its tickless mode before and am wondering if something similar is available in Zephyr
16:17:20	 From  Rishav Vatsa : Which power management strategy is more convenient for deep sleep/wake up? Handling it using AT command (software) or using hardware gpio pins?
16:17:32	 From  Jay : Is there a good documentation resource for device tree? From experience with LInux, I've found that the documentation is limited and I end up figuring out the device tree parameters by reading through Linux kernel module source code, for example.
16:20:49	 From  Nathan O. : What was the response on the LED / gpio output topic ?
16:20:53	 From  Jay : Thank you for the answer.
16:22:55	 From  Mike Szczys : I think this is the video I remember that helps with a log of insight into how Devicetree works in Zephyr and how to target your DT nodes from C code: https://www.youtube.com/watch?v=sWaxQyIgEBY
16:24:22	 From  Mike Szczys : This might be a little daunting if you've never tried out Devicetree, but the docs have a lot of tricks and example: https://docs.zephyrproject.org/latest/build/dts/index.html
16:26:18	 From  Chris Gammell : we write about this stuff on our blog every week as well! https://blog.golioth.io
16:27:05	 From  Mike Szczys : On the GPIO vs. LED question. In my case, I only needed to set a GPIO pin level at boot time and I was directed to the gpio_hogs system which lets you do that without any C code at all. I is all handled via Devicetree
16:27:23	 From  Herman Roebbers : (How) do you combine CI/CD with energy consumption monitoring?
16:27:32	 From  Amy McNeil : How do you manage revision distribution for embedded devices that don't normally get regular updates in the field, under a CI/DC environment?
16:29:50	 From  Rishav Vatsa : How can we cascade CI/CD for OTA rollouts?
16:38:16	 From  RF : Enthusiastic mix, thanks
16:38:22	 From  Raul Pando : Thanks guys
16:38:23	 From  Jay : Thanks!
16:38:24	 From  arianafaustini : Thank you!