Live Q&A - Building a Modular Codebase with Zephyr RTOS and Devicetree
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.