device tree 预研
linux kernel 引入 dts 的背景
http://www.wowotech.net/linux_kenrel/why-dt.html
什么是 device tree
device tree 是一种描述硬件资源的数据结构。device tree 可以描述的信息包括 cpu 的数量和类别、内存基地址和大小、clock 控制器和 clock 使用情况、外设基地址以及配置信息、中断控制器和中断使用情况。
设备树解决了什么问题
本质上，device tree 改变了原来用 hardcode 方式将 HW 配置信息嵌入到内核代码（驱动程序）的方法，改用 bootloader 传递一个 DB 的形式。对于基于 ARM CPU 的嵌入式系统，我们习惯于针对每一个 platform 进行内核的编译，但是随着 ARM 在消费电子上的广泛应用，我们期望 ARM 能够像 x86 那样用一个 kernel image 来支持多个 platform。
其实，就是将驱动程序中硬编码的定义改为由设备树来描述，优化了驱动程序，同时，让 kernel image 相对独立，同一份 image 可在不同的 soc 上运行。
总之，设备树是为 kernel 服务的，让内核与设备尽可能的保持独立。
Linux 与 Zephyr 的 dts
linux
以下是 at5050_codec.c
// 通过 platform 驱动框架，将驱动注册到系统中去.
// 驱动程序解析 dts, 避免硬编码到该文件中
static struct platform_driver at5k_codec_driver = {.driver = {.name = "at5050-codec",.owner = THIS_MODULE,.of_match_table = of_match_ptr(of_at5k_codec_match),},.probe = at5k_codec_probe,.remove = at5k_codec_remove,
};module_platform_driver(at5k_codec_driver);
linux 中的驱动程序会通过 一套设备树接口获取设备树节点，通过这些节点的描述实现驱动程序，注意，这里驱动程序是强依赖设备树的，驱动程序不可能做到通用（不同的 soc 之间，寄存器操作存在差异），通用的是驱动框架，如上述 platform 框架，或者字符设备、块设备、mtd 设备框架等等。
驱动程序需要有一套 设备树解析接口 。注册到系统中之后，应用程序就能够使用设备了。
zephyr
以下是 gpio_stm32.c :
// 操作 pin 设备的虚函数表,注册到系统中去（这里是真正意义上的驱动代码，通常是直接操作寄存器或者调用 hal 层提供的接口）
static const struct gpio_driver_api gpio_stm32_driver = {.pin_configure = gpio_stm32_config,.port_get_raw = gpio_stm32_port_get_raw,.port_set_masked_raw = gpio_stm32_port_set_masked_raw,.port_set_bits_raw = gpio_stm32_port_set_bits_raw,.port_clear_bits_raw = gpio_stm32_port_clear_bits_raw,.port_toggle_bits = gpio_stm32_port_toggle_bits,.pin_interrupt_configure = gpio_stm32_pin_interrupt_configure,.manage_callback = gpio_stm32_manage_callback,
};// 注册 pin 设备，系统初始化期间会处理好
DEVICE_DT_DEFINE(__node, \gpio_stm32_init, \PM_DEVICE_DT_GET(__node), \&gpio_stm32_data_## __suffix, \&gpio_stm32_cfg_## __suffix, \PRE_KERNEL_1, \CONFIG_GPIO_INIT_PRIORITY, \&gpio_stm32_driver)#define GPIO_DEVICE_INIT_STM32(__suffix, __SUFFIX) \GPIO_DEVICE_INIT(DT_NODELABEL(gpio##__suffix), \__suffix, \DT_REG_ADDR(DT_NODELABEL(gpio##__suffix)), \STM32_PORT##__SUFFIX, \DT_CLOCKS_CELL(DT_NODELABEL(gpio##__suffix), bits),\DT_CLOCKS_CELL(DT_NODELABEL(gpio##__suffix), bus))// 根据 dts 文件中对于 gpio 的描述，注册该 pin 设备到系统中
#if DT_NODE_HAS_STATUS(DT_NODELABEL(gpioa), okay)
GPIO_DEVICE_INIT_STM32(a, A);
#endif /* DT_NODE_HAS_STATUS(DT_NODELABEL(gpioa), okay) */
以下是应用代码 main.c:
// led0 这个名字在设备树文件中定义
#define LED_BLUE DT_ALIAS(led0)
#define LED_RED DT_ALIAS(led1)// 根据设备树中的描述,得到操作该 pin 设备的句柄
static const struct gpio_dt_spec led_blue = GPIO_DT_SPEC_GET(LED_BLUE, gpios);
static const struct gpio_dt_spec led_red = GPIO_DT_SPEC_GET(LED_RED, gpios);int main(void)
{printk("hello zephyr.\n");// 通过统一设备树接口,操作 pin 设备，而不是直接操作 hal 层方法if (!gpio_is_ready_dt(&led_blue) && !gpio_is_ready_dt(&led_red)) {return 0;}if (gpio_pin_configure_dt(&led_blue, GPIO_OUTPUT_ACTIVE) < 0 || gpio_pin_configure_dt(&led_red, GPIO_OUTPUT_ACTIVE) < 0) {return 0;}sdram_test();while (1) {if (gpio_pin_toggle_dt(&led_blue) < 0 || gpio_pin_toggle_dt(&led_red)) {return 0;}k_msleep(SLEEP_TIME_MS);}return 0;
}
// 可以看出，应用程序在使用 pin 设备时，使用的是一套带有 dt 字符的抽象接口，这里让应用程序感受到了设备树的存在
- zephyr 支持两种设备驱动的注册，一种是使用设备树相关宏
DEVICE_DT_DEFINE，另外一种是不使用设备树相关宏DEVICE_DEFINE - 如果使用设备树，应用程序中操作设备时，需要
依赖设备树，具体操作如下：ADC_DT_SPEC_GET使用该宏，获取adc设备，需要知道该设备在设备树中的命名static inline int adc_read_dt(const struct adc_dt_spec *spec,const struct adc_sequence *sequence)，读取struct adc_dt_spec设备static inline int adc_channel_setup_dt(const struct adc_dt_spec *spec)配置 adc 设备- 这里略微不合理，我们希望应用程序不要考虑那么多，不要知道设备树的存在。
- 如果不使用设备树，而是使用
DEVICE_DEFINE注册设备，那么应用程序对设备的操作如下static inline const struct device * device_get_binding(const char * name)，返回一个device对象，如果该设备是个 adc 设备，使用如下接口操作设备static inline int adc_read(const struct device * dev, const struct adc_sequence * sequence)，读取 adc 设备，会调用到驱动层实现的虚函数表static inline int adc_channel_setup(const struct device * dev, const struct adc_channel_cfg * channel_cfg)，配置 adc 设备- 这里应用程序通过
binding接口得到了设备句柄
抛开 linux 历史原因，直接从内核源码来看，目前 dts 目前为什么是 linux 的标配？
- linux kernel 已经依赖 dts，如 kernel 内部稳定的驱动框架（platform、spi、i2c 等等）。
- 从驱动框架来看，dts 是必须的，从使用驱动框架的人（linux 驱动开发人员）来看，dts 也是必须的。Linux 驱动开发人员需要使用 dts 中描述的信息来写驱动。
为什么各大主流 rtos 不引入 dts ?
- 首先 rtos 面向的是小型嵌入式设备，业务逻辑没那么复杂
- 其次，如果引入 dts，那么 dtb 文件如何放入 mcu / mpu 里面？需要额外引入其他依赖。设备开机重启后，需要保证 dtb 文件依然存在，需要预留持久化存储空间。
- 这可能也是 zephyr 为什么改变 dts 常规使用方法（编译 dts 成为 dtb，再使用一些工具把 dtb 放到持久化存储的地方），而是改为编译时解析，不用再考虑 dtb 文件放哪里了，系统启动流程不用那么复杂了，甚至系统都没起来（堆都没初始化）都能先初始化设备了。
综上，dts 对于 rtos 来说，意义不大，甚至会引入副作用。
dts 文件如何使用 dtc 工具编译成 dtb
先使用 c / cpp 预处理器展开头文件
cpp -nostdinc -I /home/null/zephyrproject/zephyr/dts/arm/ -I /home/null/zephyrproject/zephyr/dts/common -undef -x assembler-with-cpp stm32h750_art_pi.dts stm32h750_art_pi.dts.preprocessed
然后使用 dtc 工具
dtc -I dts -O dtb -o example.dtb example.dts
如果 dts 文件中使用了 include 关键字，则需要通过 c/cpp 预处理器来展开头文件，dtc 工具是不负责展开头文件的，只是编译，否则会报错。