返回首页

Zephyr 设备驱动开发学习笔记

概述

这页更偏“怎么自己写一个驱动”,而不是只看设备模型概念。

如果你要在 Zephyr 里加一个新器件,最稳定的开发顺序通常是:

  1. 明确它属于哪个子系统
  2. 写 binding / overlay
  3. 打通 config / data / init
  4. 用 sample 或最小应用验证
  5. 最后再补 PM、DMA、中断和错误处理

1. 先判断驱动应该挂在哪个子系统

常见选择:

如果已经有成熟子系统,优先复用; 不要轻易自己发明一套完全独立的上层 API。


2. 驱动文件通常要准备什么

2.1 Kconfig

最少要有:

2.2 CMakeLists

把驱动源文件接入对应目录。

2.3 Devicetree binding

要说明:

2.4 驱动源码

通常包括:


3. 最小实例化套路

#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 驱动习惯。


4. 推荐的验证方法

4.1 先验证设备树

4.2 再验证总线

4.3 最后验证子系统接口


5. 开发时最容易踩的坑


6. 何时再补 PM / 中断 / DMA

建议顺序:

  1. 先做最小可用版本
  2. 再加中断
  3. 再加 runtime PM
  4. 最后视需要加 DMA

如果一开始把这些全做进去,调试成本会很高。


参考入口