2. 嵌入式系统基础回顾
硬件抽象层，说白了就是给上层软件一个统一的接口，让它们不用关心底下跑的是什么芯片。我做了十几年嵌入式，见过太多项目因为硬件耦合太紧，换了个MCU就得重写大半代码。嗯，HAL就是来解决这个问题的。
HAL的层次结构
一个设计良好的HAL，通常分三层。我习惯这么画：
最上层是应用代码，中间是HAL API，底层是驱动适配。每一层只依赖它的下一层，绝不跨层调用。这个规矩，我在项目里吃过亏才真正理解它的重要性。
接口设计原则
接口怎么设计？我总结了四条铁律：
| 原则 | 说明 | 反例 |
|---|---|---|
| 统一性 | 同类外设接口签名一致 | UART1用`send_byte`，UART2用`uart_write` |
| 最小化 | 只暴露必要操作，隐藏寄存器细节 | 让应用层直接操作`REG_BAUD` |
| 可移植 | 不依赖特定编译器或芯片特性 | 使用`__attribute__((packed))`这种GCC扩展 |
| 可测试 | 接口能通过Mock硬件进行单元测试 | 接口内部直接读写物理地址 |
核心观点：接口设计不是给硬件看的，是给人看的。你想想看，半年后回来维护代码的人，大概率就是你自己。
解耦策略
解耦这件事，说起来简单做起来难。我常用的策略有几种：
1. 回调函数注册
让底层驱动注册回调，上层按需订阅。比如GPIO中断：
/* HAL层定义回调类型 */
typedef void (*gpio_callback_t)(uint8_t pin, uint8_t level);
/* 驱动适配层实现注册接口 */
void hal_gpio_register_callback(uint8_t pin, gpio_callback_t cb);
/* 应用层使用 */
void my_app_init(void) {
hal_gpio_register_callback(5, button_pressed_handler);
}2. 配置结构体抽象
把硬件相关的配置参数封装成结构体，上层只传结构体指针。我在一个项目中用这个办法，把STM32的代码无缝移植到了GD32上。
/* 统一的UART配置结构体 */
typedef struct {
uint32_t baud_rate;
uint8_t data_bits; /* 5, 6, 7, 8 */
uint8_t stop_bits; /* 1, 2 */
uint8_t parity; /* 0=none, 1=odd, 2=even */
} hal_uart_config_t;
/* 初始化接口 */
int32_t hal_uart_init(uint8_t port, hal_uart_config_t *cfg);3. 设备句柄机制
不直接操作硬件地址，而是通过句柄访问。句柄可以是一个索引，也可以是一个指针，上层根本不知道底层是什么。
我的经验：句柄用`int32_t`类型，返回负数表示错误。这样错误处理非常自然，而且兼容性好。
分层思想
分层不是把代码拆开就完事了。真正的分层，要保证每一层都能独立替换。我见过太多所谓的分层，其实就是把函数放在不同文件里，调用关系还是乱成一团。
正确的分层应该满足：
- 单向依赖：上层依赖下层，下层绝不反向依赖上层
- 接口稳定：接口一旦发布，尽量不修改。真要改，也要向后兼容
- 关注点分离：应用层只管业务逻辑，驱动层只管寄存器操作
注意：分层不是越多越好。层数太多，性能损耗大，调试也麻烦。我一般控制在3-4层，超过这个数就要重新审视设计是否过度工程化了。
举个例子，一个典型的GPIO控制流程：
/* 应用层：只管逻辑 */
void led_toggle(void) {
static uint8_t state = 0;
state = !state;
hal_gpio_write(LED_PIN, state);
}
/* HAL API层：统一接口 */
void hal_gpio_write(uint8_t pin, uint8_t value) {
/* 调用驱动适配层 */
drv_gpio_set_pin(pin, value);
}
/* 驱动适配层：操作寄存器 */
void drv_gpio_set_pin(uint8_t pin, uint8_t value) {
if (value) {
GPIO->BSRR = (1 << pin);
} else {
GPIO->BRR = (1 << pin);
}
}你看，每一层只做自己的事。换芯片时，只需要重写最底层的`drv_gpio_set_pin`，上面两层完全不用动。我曾经用这个结构，三天内把一套产品从STM32F1系列移植到了GD32F1系列，测试一次通过。
嗯，这里要补充一点。分层设计最怕的就是「穿透」——上层代码直接调用底层驱动。我定了个规矩：代码审查时看到这种调用，直接打回。规矩虽然严格，但确实管用。
最后说一句，HAL设计没有银弹。不同的项目、不同的团队、不同的时间节点，适合的方案都不一样。但分层和解耦的思想是通用的，掌握了这个，你就能在设计时多一份从容。