这页更偏“怎么自己写一个驱动”,而不是只看设备模型概念。
如果你要在 Zephyr 里加一个新器件,最稳定的开发顺序通常是:
config / data / init常见选择:
sensorflashinputgpiodisplay如果已经有成熟子系统,优先复用; 不要轻易自己发明一套完全独立的上层 API。
最少要有:
I2C、SPI把驱动源文件接入对应目录。
要说明:
compatiblereg通常包括:
#define MY_DRV_DEFINE(inst) \
static struct my_drv_data my_drv_data_##inst; \
static const struct my_drv_config my_drv_cfg_##inst = { \
.bus = I2C_DT_SPEC_INST_GET(inst), \
}; \
DEVICE_DT_INST_DEFINE(inst, \
my_drv_init, \
NULL, \
&my_drv_data_##inst, \
&my_drv_cfg_##inst, \
POST_KERNEL, \
CONFIG_KERNEL_INIT_PRIORITY_DEVICE, \
&my_drv_api);
DT_INST_FOREACH_STATUS_OKAY(MY_DRV_DEFINE)
这类模式比手写一堆实例更稳,也更符合 Zephyr 驱动习惯。
DEVICE_DT_GET() 能否拿到设备device_is_ready() 是否返回真sample_fetch()channel_get()read()write()compatible 不匹配,导致驱动根本没实例化建议顺序:
如果一开始把这些全做进去,调试成本会很高。
zephyr/samples/driverszephyr/driverszephyr/dts/bindingszephyr/include/zephyr/device.h