Difference between revisions of "Zephyr drivers"
m (→^ Zephyr Kernel Level Device Support) |
m (Adding explanations and couple of Zephyr driver sample app links to Zephyr RTOS github repo) |
||
| Line 1: | Line 1: | ||
| − | drivers | + | |
| + | == [[#top|^]] OVERVIEW == | ||
| + | |||
| + | 2022 Q4 notes on Zephyr RTOS drivers, driver frameworks and driver design. Current projects include work to extend KX132-1211 Zephyr out-of-tree driver, plus work to craft an IIS2DH driver which supports in Zephyr RTOS context both I2C and SPI bus connections for this sensor. | ||
| + | |||
| + | <!-- comentario --> | ||
| + | |||
| + | == [[#top|^]] Example Zephyr drivers == | ||
| + | |||
| + | Example apps here offer varying amounts of insight into Zephyr RTOS' framework(s) for device driver development. Of particular interest 2022 Q4 are the ways in which developers use Zephyr device tree macros to obtain pointers to devices, in their mostly C based code, at compile time. Though not fully explained in Zephyr's extensive documentation it appears that device pointers which can be correctly passed to and used with API function [https://docs.zephyrproject.org/latest/kernel/drivers/index.html#c.device_is_ready device_is_ready()] and macro [https://docs.zephyrproject.org/latest/kernel/drivers/index.html#c.DEVICE_DT_GET DEVICE_DT_GET()] involve pairings of macros, which must be expanded prior to these calls in order to compile correctly. | ||
* https://github.com/circuitdojo/pcf85063a | * https://github.com/circuitdojo/pcf85063a | ||
| Line 5: | Line 14: | ||
* https://docs.zephyrproject.org/latest/services/smf/index.html | * https://docs.zephyrproject.org/latest/services/smf/index.html | ||
| + | * https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/spi_bitbang | ||
| + | |||
| + | * https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/uart/stm32/single_wire | ||
| + | |||
| + | <!-- comentario --> | ||
== [[#top|^]] Zephyr Kernel Level Device Support == | == [[#top|^]] Zephyr Kernel Level Device Support == | ||
| Line 26: | Line 40: | ||
163 | 163 | ||
</pre> | </pre> | ||
| + | |||
| + | <!-- comentario --> | ||
| + | |||
| + | == [[#top|^]] Understanding Zephyr SPI API == | ||
| + | |||
| + | To make use of Zephyr API for SPI bus, we must in part understand how each of the three parameters passed to [https://docs.zephyrproject.org/latest/hardware/peripherals/spi.html#c.spi_read spi_read()] and [https://docs.zephyrproject.org/latest/hardware/peripherals/spi.html#c.spi_write spi_write()] are defined. Further, when we have a sensor with which we communicate in our Zephyr based app we need to understand how parts of this sensor's data structures in the firmware relate to the SPI bus to which the sensor is connected. Our sensor driver's code which talks with the sensor via SPI must pass certain SPI bus related pointers to Zephyr's SPI Application Programmers' Interface. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | <!-- comentario --> | ||
Revision as of 20:03, 12 November 2022
Contents
^ OVERVIEW
2022 Q4 notes on Zephyr RTOS drivers, driver frameworks and driver design. Current projects include work to extend KX132-1211 Zephyr out-of-tree driver, plus work to craft an IIS2DH driver which supports in Zephyr RTOS context both I2C and SPI bus connections for this sensor.
^ Example Zephyr drivers
Example apps here offer varying amounts of insight into Zephyr RTOS' framework(s) for device driver development. Of particular interest 2022 Q4 are the ways in which developers use Zephyr device tree macros to obtain pointers to devices, in their mostly C based code, at compile time. Though not fully explained in Zephyr's extensive documentation it appears that device pointers which can be correctly passed to and used with API function device_is_ready() and macro DEVICE_DT_GET() involve pairings of macros, which must be expanded prior to these calls in order to compile correctly.
^ Zephyr Kernel Level Device Support
Interesting code excerpt from `zephy/kernel/device.c`, this following routine is the implementation behind a wrapper like function `device_is_read()`. But this routine, and sensibly so, doesn't say anything about how a given device is initialized. It only looks at two data members of a device instance data structure:
150
151 bool z_device_is_ready(const struct device *dev)
152 {
153 /*
154 * if an invalid device pointer is passed as argument, this call
155 * reports the `device` as not ready for usage.
156 */
157 if (dev == NULL) {
158 return false;
159 }
160
161 return dev->state->initialized && (dev->state->init_res == 0U);
162 }
163
^ Understanding Zephyr SPI API
To make use of Zephyr API for SPI bus, we must in part understand how each of the three parameters passed to spi_read() and spi_write() are defined. Further, when we have a sensor with which we communicate in our Zephyr based app we need to understand how parts of this sensor's data structures in the firmware relate to the SPI bus to which the sensor is connected. Our sensor driver's code which talks with the sensor via SPI must pass certain SPI bus related pointers to Zephyr's SPI Application Programmers' Interface.
