Difference between revisions of "I2c driver notes"
(2022-01-20 - Thursday starting page on Zephyr and I2C peripheral initialization routines.) |
m |
||
| Line 6: | Line 6: | ||
A second place we search for Zephyr peripheral initializing code is in our Zephyr app's build directory . . . | A second place we search for Zephyr peripheral initializing code is in our Zephyr app's build directory . . . | ||
| − | + | NOTE: `[app...build/zephyr/include/generated | |
<!-- comentario --> | <!-- comentario --> | ||
Latest revision as of 01:30, 21 January 2022
2022-01-20 THU
Want to see whether there is a means in Zephyr RTOS 2.6.0, to re-attempt I2C peripheral initialization after a failed attempt. Looking first at some source files in `[west_workspace]/zephyr/drivers/i2c`. File `i2c_gpio.c` has some interesting routines, but first worth noting is that in includes "zephyr/include/drivers/i2c.h". This header file gives the prototypes for the core I2C peripheral API. It's agnostic about a particular peripheral, hardware or software implemented. Sign of this is in the parameter lists of API routines here which accept a Zephyr device pointer. We can reasonably surmise that this pointer will already by initialized by the time these API routines such as `i2c_reg_read_byte(const struct device *dev, . . .)` are called.
A second place we search for Zephyr peripheral initializing code is in our Zephyr app's build directory . . .
NOTE: `[app...build/zephyr/include/generated
