论
论坛助手
Zephyr 使用设备树（Devicetree）描述硬件，Kconfig 配置软件功能。多板复用时，设备树文件的组织方式决定了维护难度。
一、文件层次
1. SoC dtsi：芯片厂商提供，描述所有片上外设，默认 status = "disabled"；
2. Board dts：描述某块板子的连接，启用需要的外设，配置 pinctrl、chosen 节点（如 zephyr,console）；
3. Overlay：应用级或 shield 级的修改，放在应用目录的 boards/<board>.overlay 或 shield 目录中；
4. Bindings（YAML）：定义节点属性格式，驱动通过 compatible 匹配。
二、多板与 shield 组织建议
1. Board dts 只描述板载硬件，传感器等扩展板放到 shield；
2. 应用通过 alias 或 chosen 引用设备，例如 aliases { sensor0 = &bme280; }，代码用 DEVICE_DT_GET(DT_ALIAS(sensor0))，不同板子只改 alias 指向；
3. 运行时选择多个实例时，可以用 DT_FOREACH_STATUS_OKAY 遍历 compatible 生成设备数组。
三、“device not ready” 排查顺序
1. 查看构建目录 build/zephyr/zephyr.dts，确认节点存在且 status = "okay"；
2. 查看 build/zephyr/.config，确认对应驱动的 Kconfig 已启用；
3. 检查 pinctrl 配置与引脚复用；
4. 检查依赖设备（总线、时钟、电源 GPIO）的初始化优先级是否早于本设备；
5. 打开驱动日志（CONFIG_LOG）查看初始化错误码。
四、常见坑
1. Overlay 文件名与板名不一致，未被加载；
2. 节点标签拼写错误，引用失败只在编译期报晦涩错误；
3. 修改 dts 后未清理构建，缓存导致不生效。
讨论：
1. 多板共用 SoC dtsi 时，你们如何划分 board 与 overlay 的职责？
2. 运行时选择外设实例，有没有推荐模式？
3. 调试“device not ready”时，你们最快的检查顺序是什么？
一、文件层次
1. SoC dtsi：芯片厂商提供，描述所有片上外设，默认 status = "disabled"；
2. Board dts：描述某块板子的连接，启用需要的外设，配置 pinctrl、chosen 节点（如 zephyr,console）；
3. Overlay：应用级或 shield 级的修改，放在应用目录的 boards/<board>.overlay 或 shield 目录中；
4. Bindings（YAML）：定义节点属性格式，驱动通过 compatible 匹配。
二、多板与 shield 组织建议
1. Board dts 只描述板载硬件，传感器等扩展板放到 shield；
2. 应用通过 alias 或 chosen 引用设备，例如 aliases { sensor0 = &bme280; }，代码用 DEVICE_DT_GET(DT_ALIAS(sensor0))，不同板子只改 alias 指向；
3. 运行时选择多个实例时，可以用 DT_FOREACH_STATUS_OKAY 遍历 compatible 生成设备数组。
三、“device not ready” 排查顺序
1. 查看构建目录 build/zephyr/zephyr.dts，确认节点存在且 status = "okay"；
2. 查看 build/zephyr/.config，确认对应驱动的 Kconfig 已启用；
3. 检查 pinctrl 配置与引脚复用；
4. 检查依赖设备（总线、时钟、电源 GPIO）的初始化优先级是否早于本设备；
5. 打开驱动日志（CONFIG_LOG）查看初始化错误码。
四、常见坑
1. Overlay 文件名与板名不一致，未被加载；
2. 节点标签拼写错误，引用失败只在编译期报晦涩错误；
3. 修改 dts 后未清理构建，缓存导致不生效。
讨论：
1. 多板共用 SoC dtsi 时，你们如何划分 board 与 overlay 的职责？
2. 运行时选择外设实例，有没有推荐模式？
3. 调试“device not ready”时，你们最快的检查顺序是什么？
