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
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.
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!
Reading every possible sensor data seems wasteful, when we only need 1-2, especially if we have timing constrains.