Zephyr RTOS驱动开发基础：驱动模型架构
从一次诡异的GPIO中断丢失说起
去年做的一个工业数据采集项目，STM32F407主控，外挂三个传感器通过GPIO中断上报数据。调试到凌晨三点，发现一个诡异现象：系统运行半小时后，某个传感器的中断响应越来越慢，最后干脆不响应了。用逻辑分析仪抓波形，中断信号确实来了，但CPU就是没反应。
排查了三天，最后发现是驱动模型里一个细节问题——中断处理函数里调用了k_sem_give，而这个信号量被一个高优先级线程长期持有。更坑的是，这个线程在等待另一个低优先级线程释放资源，形成了优先级反转。Zephyr的驱动模型里，中断处理上下文和线程上下文之间的交互，如果不遵循驱动框架的约定，就会埋下这种定时炸弹。
那次之后我彻底把Zephyr的驱动模型架构翻了个底朝天。今天这篇笔记，就把这些用血泪换来的理解写下来。
驱动模型的核心：设备对象与API抽象
Zephyr的驱动模型不像Linux那样庞大复杂，但设计思路一脉相承——通过抽象层把硬件操作和业务逻辑解耦。核心就三个东西：设备结构体、设备配置数据、设备运行时数据。
看一个典型的UART驱动定义：
// 设备结构体，每个设备实例对应一个
