刚接触Zephyr的小伙伴可能都知道Zephyr比起其他主流嵌入式RTOS，多了设备树这个概念(玩过Linux的伙伴可能不会觉得陌生)，那么设备树有什么作用呢，在实际开发中需要注意什么，这篇我们来聊聊，因为篇幅比较长，预计拆成上下两篇，感兴趣的小伙伴记得关注。
设备树简介
设备树是一种描述特定硬件的数据结构，以便于操作系统更高的使用和管理硬件外设，它是一种树状的形态结构。
刚接触Zephyr的小伙伴可能都知道Zephyr比起其他主流嵌入式RTOS，多了设备树这个概念(玩过Linux的伙伴可能不会觉得陌生)，那么设备树有什么作用呢，在实际开发中需要注意什么，这篇我们来聊聊，因为篇幅比较长，预计拆成上下两篇，感兴趣的小伙伴记得关注。
设备树的引入有这样的作用：
驱动和设备是独立编译出的两个文件，实现了驱动driver和外设device解耦。引用设备树之后，驱动代码只负责处理驱动的逻辑，关于设备的信息放在设备树文件中，如果只是硬件接口发生变化，只需要修改设备树和修改对应的硬件设备，而不需要修改驱动代码。
Zephyr的设备树使用流程
注意：
- 与linux不同的是Zephyr的设备树在使用中不能动态解析设备树dts文件
- Zephyr的驱动编写与设备信息文件是解耦的，驱动driver的编写不用关注硬件外设变更，外设变更不会影响驱动driver
设备树原理
设备树结构和内容
以下截图为例，首行的“/” 表示为根节点， property name部分显示node@0有3个属性（properties）信息 property下方代码表示有两个主节点分别名为node、node1，“@”后面为表示地址（unit address）。 设备节点中也可以包含子节点，如下图中node0包含child-node@0和child-node@1两个子节点，子节点也是完整的形式。
dts通用属性类型参考：
设备树如何参与编译
1、在编译前需要将设备树文件（.overlay、.dts、*.dtsi全部incloud展开解析成对工程项目的总设备树zephyr.dts.pre
2、编译中构建系统会根据.yml文件中的绑定关系判断哪些dts文件需要转化为C宏，通过脚本将dts文件中的节点和.yml文件进行匹配生成对应的C
当执行编译指令 lisa zep build csk6011a_nano.overlay的时，首先BOARD.dts的信息就确认为csk6011a_nano这个开发板型号，然后基于BOARD.dts信息展开设备树的解析。BOARD引用其他的dts和基础的dts汇总到一起展开，但若项目APP中有.overlay文件，.overlay中对应的节点信息就会覆盖展开的总信息，最终生效的是.overlay文件。
因此节点信息查找顺序为：.overlay → board.dts → other.dtsi
生成宏
在Zephyr中生成总的设备树后，总设备树通过脚本再去加载./.sdk/zephyr/bingdings/*.yaml文件中的绑定信息生成C宏。
dts与生成宏的关系
Zephyr C宏生成规则如下，由于论坛放不了外链，详细的关系讲解可以查找官方的同名视频观看
代码中获取设备树
当需要通过程序对某个设备驱动做初始化或调用其规则时可以调用上面生成的这些宏，当做应用开发的时候可以通过调用实例对应宏的API即可，详细解说请点击文末的视频观看。
设备树、驱动、绑定文件的关系
设备树中以设备节点的方式描述设备的信息，这些信息会被绑定文件约束。有效的设备信息才会作为参数通过一系列操作生成C宏，作为C宏参数传递给驱动使设备运行起来。
实战
根据上述内容我们也结合以下实战视频进行详细解说，欢迎各位同学联系我们进行技术相关的探讨，也可以在评论区进行提问。
- 如何通过设备树控制led灯
- 如何通过设备树控制摄像头
