4、外设驱动框架设计原则：高内聚低耦合、可移植性、可配置性
做嵌入式这些年，我见过太多驱动代码写得像一团乱麻。一个GPIO的初始化散落在三个文件里，换个MCU平台就要重写一半代码，改个引脚配置得翻遍整个工程。说白了，这些都是没遵循基本的设计原则。
外设驱动框架到底该怎么搭？我个人习惯从三个维度去考量：高内聚低耦合、可移植性、可配置性。这三个词你可能听过无数遍，但真正落地时，坑比想象的多。
核心观点：驱动框架不是写出来的，是设计出来的。好的驱动框架，能让你的代码在3个不同平台间无缝迁移，能让新同事一周内上手修改，能让产品迭代时只改配置文件不改C代码。
4.1 高内聚低耦合：让每个驱动模块各司其职
高内聚，说白了就是一个.c文件只干一件事。UART驱动就只管UART的收发配置，别把定时器逻辑塞进来。低耦合，就是模块之间通过接口通信，不直接访问对方的全局变量。
我曾经在一个项目里接手过别人的代码，一个"driver.c"文件足足3000行，里面混着I2C、SPI、PWM的初始化，还有几个中断服务程序。改一个I2C的时序参数，结果把PWM的占空比搞乱了。嗯，那周我加了三天班才把代码拆开。
具体怎么做？我建议你遵循这个分层结构：
| 层级 | 职责 | 耦合对象 |
|---|---|---|
| 硬件抽象层 (HAL) | 直接操作寄存器，提供最基础的读写接口 | 只依赖MCU头文件 |
| 驱动逻辑层 | 封装外设协议（如I2C起始条件、SPI时序） | 只调用HAL接口 |
| 应用接口层 | 提供面向业务的功能函数（如"读取温度值"） | 只调用驱动逻辑层 |
你想想看，如果每一层都只向下依赖一层，上层根本不知道底层用的是哪个寄存器。换MCU时，你只需要重写HAL层，驱动逻辑层和应用层几乎不用动。
我的小技巧：在驱动逻辑层里，绝对不要出现"GPIOA->ODR"这种寄存器操作。全部封装成类似 hal_gpio_write(pin, level) 的接口。这样即使底层从STM32换成GD32，你的协议代码一行都不用改。
4.2 可移植性：一次编写，多处运行
可移植性不是玄学，是实实在在的工程需求。你不可能一辈子只用一个MCU系列。项目升级、芯片缺货、成本优化，随时可能换平台。
要做到可移植，核心就一句话：把平台相关的东西隔离出去。
哪些是平台相关的？
- 寄存器地址和位定义
- 中断向量号和优先级
- 时钟配置和延时函数
- DMA通道和硬件资源编号
我习惯的做法是，把这些东西全部扔进一个 platform.h 文件里。驱动代码里只引用这个头文件，不直接包含MCU厂商的库。
// platform.h - 平台抽象层
// 移植时只需要修改这个文件
// 引脚映射
#define UART1_TX_PIN GPIO_PIN_9
#define UART1_TX_PORT GPIOA
#define UART1_RX_PIN GPIO_PIN_10
#define UART1_RX_PORT GPIOA
// 时钟配置
#define UART1_CLK_ENABLE() __HAL_RCC_USART1_CLK_ENABLE()
// 中断号
#define UART1_IRQ_NUM USART1_IRQn
#define UART1_IRQ_HANDLER() void USART1_IRQHandler(void)你看，驱动逻辑层里所有代码都写成 UART1_TX_PIN 这种宏。换平台时，只需要改 platform.h 里的宏定义，驱动逻辑层一行不动。
避坑指南：我曾经在一个项目里把延时函数直接写成了 HAL_Delay(10)。结果换到NXP平台时，发现根本没有这个函数。后来我统一封装成 drv_delay_ms(10)，内部再根据平台去调用不同的底层实现。记住：所有平台相关的函数调用，都必须包一层。
4.3 可配置性：用参数代替硬编码
可配置性，就是让你的驱动能适应不同的硬件场景。同一个I2C驱动，既能接温度传感器，也能接加速度计；既能跑100kHz，也能跑400kHz。
怎么做？用结构体把配置参数集中管理。
// i2c_cfg.h - I2C配置结构体
typedef struct {
uint32_t clock_speed; // 时钟频率 (Hz)
uint8_t slave_addr; // 从机地址
uint8_t addr_width; // 地址宽度 (7或10位)
void (*scl_pin_init)(void); // SCL引脚初始化函数指针
void (*sda_pin_init)(void); // SDA引脚初始化函数指针
uint8_t timeout_ms; // 超时时间
} i2c_config_t;
// 使用时传入配置
i2c_config_t temp_sensor_cfg = {
.clock_speed = 100000,
.slave_addr = 0x48,
.addr_width = 7,
.scl_pin_init = hal_gpio_scl_init,
.sda_pin_init = hal_gpio_sda_init,
.timeout_ms = 100
};
i2c_init(&temp_sensor_cfg);这样设计的好处是：
- 同一个驱动文件，通过不同的配置结构体，可以驱动多个不同的I2C设备
- 配置集中在一个地方，改参数不用翻代码
- 新加一个设备，只需要新增一个配置结构体，驱动代码不用改
我的习惯：把配置结构体放在单独的 _cfg.h 文件里，和驱动实现文件分开。这样硬件工程师改配置时，只需要看头文件，不会误改驱动逻辑。
4.4 三个原则的关系与协同
这三个原则不是孤立的。高内聚低耦合是可移植性的基础，可配置性又是高内聚的体现。它们共同构成了一个稳固的驱动框架。
下面这张图展示了它们之间的关系：
4.5 实战中的取舍与平衡
理论说完了，聊聊实际项目中的取舍。你不可能在所有场景下都完美做到这三个原则。
举个例子：
- 资源受限的MCU（如1KB RAM）：你可能不得不牺牲一些可配置性，用宏定义代替结构体配置，减少代码体积。我曾在Holychip的4位MCU上做驱动，连函数指针都用不了，只能靠条件编译。
- 量产稳定的产品：可移植性可以适当降低，因为产品生命周期内不会换MCU。但高内聚和可配置性还是要保证，方便后续维护。
- 平台级SDK：三个原则必须全部拉满。因为你的代码会被成千上万的开发者使用，任何硬编码都是灾难。
我的建议：先按最高标准设计框架，再根据实际项目裁剪。就像盖房子，先打好地基和框架，装修时可以简配，但结构不能歪。我见过太多项目一开始就"凑合"，结果后期维护成本是开发成本的5倍以上。
最后说一句：驱动框架设计没有银弹。但只要你坚持高内聚低耦合、可移植性、可配置性这三个原则，你的代码至少不会烂到哪里去。剩下的，就是在实战中不断打磨和优化了。