Zephyr Driver Model 深入：struct device、Init Level、Config/Data/API、DEVICE_DT_DEFINE 到底是怎么串起来的摘要：本文深入剖析 Zephyr Driver Model 的核心机制，系统讲解struct device、Config/Data/API 三大组成、Init Level 与 Priority 的二维排序，以及DEVICE_DT_DEFINE()宏如何将 Devicetree、Driver 与设备实例串联成可运行的设备对象。文章从基础概念出发，逐步揭示系统启动时设备初始化的完整流程，并给出完整 Driver 骨架示例，帮助读者真正理解"把公司 SoC 加入 Zephyr"所需掌握的关键层次。这一篇非常关键。到这里，真正需要搞懂的已经不是"怎么写一个 Driver"，而是：Zephyr 到底是怎么把 Devicetree、Driver、struct device、初始化函数和 Driver API 串成一个可以运行的设备对象？这也是以后你把公司自己的 SoC 加入 Zephyr时必须真正理解的一层。一、先看最终关系先把整篇文章最重要的一张图建立起来：也就是说：Devicetree ↓ 描述"这是什么硬件"↓ Driver ↓ 描述"怎么驱动这个硬件"↓ DEVICE_DT_DEFINE()↓ 创建一个 struct device 实例 ↓ 系统启动时调用 init()↓ 应用通过 device pointer + API 使用它Zephyr 官方文档把 struct device 定义为每个 Driver instance 的运行时设备结构；其中 config、data、api 分别连接设备的固定配置、运行时状态和操作接口。二、struct device 到底是什么？这是 Zephyr Driver Model 的核心。在当前 Zephyr 中，可以把它理解成：structdevice{constchar\*name;constvoid\*config;constvoid\*api;void\*data;structdevice_state\*state;...};实际结构比这个复杂，还包含 flags、dependency、PM 等信息。但对于学习 Driver，先抓住这几个：struct device │ ├── name │ ├── config ──────► const configuration │ ├── data ────────► runtime data │ └── api ─────────► driver operations可以把它理解成：struct device 是 Zephyr 对"一个具体硬件设备实例"的抽象。三、为什么需要 struct device？假设你的 SoC 有两个 UART：UART0 UART1它们使用的是同一个 Driver。如果没有 Device Model，你可能需要：uart0_init();uart0_send();uart1_init();uart1_send();然后 Driver 里面到处判断：if(uart==0){...}else{...}Zephyr 更希望把它组织成：UART Driver │ ├── device instance0│ └── device instance1也就是：UART Driver │ ┌──────────┴──────────┐ │ │ ▼ ▼ struct device struct device UART0 UART1两个 struct device：UART0 device │ ├── config → UART0 configuration ├── data → UART0 runtime data └── api → UART operations UART1 device │ ├── config → UART1 configuration ├── data → UART1 runtime data └── api → UART operations所以：一个 Driver 可以对应多个 Device Instance。这对你的目标尤其重要。因为以后你的公司 SoC 很可能有：SOC_UART0 SOC_UART1 SOC_UART2 SOC_I2C0 SOC_I2C1 SOC_SPI0...Driver 代码可以复用，而每个硬件实例拥有自己的 struct device。四、Config / Data / API 是什么？这是这一篇最重要的三个概念之一。1. Config：硬件的"固定配置"例如：structmy_uart_config{uintptr_tbase;intirq;uint32_tclock_frequency;};然后：staticconststructmy_uart_configuart_cfg={.base=0x40000000,.irq=5,.clock_frequency=48000000,};注意：staticconst它表示：这些信息通常是在编译时确定的，运行过程中不会改变。例如：Base Address IRQ number Clock frequency Pin configuration DMA channel这些都是典型的 config。Zephyr 官方文档也明确把 config 描述为 build-time 的只读配置，例如 MMIO 地址、IRQ 等固定硬件属性。五、Data：运行时状态例如：structmy_uart_data{bool initialized;uint32_tbaudrate;uint32_ttx_count;};然后：staticstructmy_uart_datauart_data;这里通常不是：const因为运行过程中会变化。例如：uart_data │ ├── initialized=true├── baudrate=115200└── tx_count=128所以：config ↓"这个硬件是什么"data ↓"这个硬件现在是什么状态"Zephyr 官方文档也明确说明 data 位于 RAM，用于保存 Driver instance 的运行时状态信息，例如计数器、同步对象、临时缓冲区等。六、API：Driver 到底能做什么再看：structmy_uart_api{int(*poll_in)(conststructdevice*dev,unsignedchar*c);void(*poll_out)(conststructdevice*dev,unsignedcharc);};然后：staticconststructmy_uart_apiuart_api={.poll_in=my_uart_poll_in,.poll_out=my_uart_poll_out,};这就是：设备提供给上层使用的操作接口。所以最终：structdevice│ ├── config │ ├── data │ └── api │ ├──poll_in()├──poll_out()└──...七、把三者放到一起例如：structmy_uart_config{uintptr_tbase;intirq;};structmy_uart_data{bool initialized;};structmy_uart_api{int(*send)(conststructdevice*dev,constuint8_t*buf,size_tlen);};然后：staticconststructmy_uart_configuart_cfg={.base=0x40000000,.irq=5,};staticstructmy_uart_datauart_data;staticconststructmy_uart_apiuart_api={.send=my_uart_send,};最终：这就是 Zephyr Device Model 最核心的结构。八、Driver Init 又在哪里？现在还有一个问题：struct device 创建出来之后，谁负责初始化硬件？答案：init_fn例如：staticintmy_uart_init(conststructdevice*dev){conststructmy_uart_config*cfg=dev-config;structmy_uart_data*data=dev-data;/* 初始化硬件 */data-initialized=true;return0;}注意这里非常重要：dev-config dev-data所以 init() 并不是孤立存在的。它拿到的是：const struct device *dev然后：dev │ ├── config → hardware configuration ├── data → runtime data └── api → operations因此：struct device 是 Driver init 和
