3、硬件抽象层(HAL)设计：MCU外设封装、GPIO/UART/CAN驱动抽象、寄存器映射
好，咱们进入第三讲。硬件抽象层，简称 HAL。这个名字听起来挺唬人，说白了就是给上层软件一个「干净」的接口，让应用层程序员不用管底层用的是 STM32 还是 NXP 的片子。
我在门控项目里见过太多惨痛的教训：应用代码里直接写寄存器，换了个 MCU 型号，整个项目几乎重写。嗯，这就是没有 HAL 的代价。
3.1 为什么需要 HAL？
你想想看，轨道车门控制器要跑十几年。这期间 MCU 可能会停产、升级，甚至换供应商。如果应用层代码直接操作寄存器，那每次换芯片都是噩梦。
HAL 的核心价值就两点：
- 隔离变化：硬件变了，只改 HAL 层，上层纹丝不动
- 统一接口：不管底层是啥，上层调用的函数名、参数、行为都一样
核心原则：HAL 层只做一件事——把 MCU 外设的复杂性封装成简单、稳定的 API。
3.2 寄存器映射——HAL 的基石
寄存器映射，说白了就是把芯片手册里的地址，变成 C 语言里能直接操作的变量。我习惯用结构体来映射外设寄存器组。
举个例子，一个典型的 GPIO 寄存器映射：
// gpio_regs.h
typedef struct {
volatile uint32_t MODER; // 模式寄存器，偏移 0x00
volatile uint32_t OTYPER; // 输出类型，偏移 0x04
volatile uint32_t OSPEEDR; // 输出速度，偏移 0x08
volatile uint32_t PUPDR; // 上下拉，偏移 0x0C
volatile uint32_t IDR; // 输入数据，偏移 0x10
volatile uint32_t ODR; // 输出数据，偏移 0x14
volatile uint32_t BSRR; // 置位/复位，偏移 0x18
volatile uint32_t LCKR; // 锁定，偏移 0x1C
volatile uint32_t AFR[2]; // 复用功能，偏移 0x20-0x24
} GPIO_Regs;
// 基地址定义
#define GPIOA_BASE ((GPIO_Regs *)0x40020000)
#define GPIOB_BASE ((GPIO_Regs *)0x40020400)我的习惯：所有寄存器指针都用 volatile 修饰。编译器优化有时候会「自作聪明」，把看似没用的读操作优化掉，加上 volatile 就是告诉编译器：别动我的寄存器，每次都要老老实实去读。
3.3 GPIO 驱动抽象
GPIO 是门控系统里用得最多的外设。门到位信号、锁到位信号、紧急解锁信号……全是 GPIO。我建议把 GPIO 抽象成三个层次：
- 底层寄存器操作：直接读写寄存器，不对外暴露
- 中间层封装：提供初始化、读、写、中断配置
- 上层接口：面向应用，比如
Door_GetPosition()
来看中间层的设计：
// hal_gpio.h
typedef enum {
GPIO_PIN_0 = 0, GPIO_PIN_1, /* ... */ GPIO_PIN_15
} GPIO_Pin;
typedef enum {
GPIO_MODE_INPUT, // 输入
GPIO_MODE_OUTPUT_PP, // 推挽输出
GPIO_MODE_OUTPUT_OD, // 开漏输出
GPIO_MODE_AF_PP, // 复用推挽
GPIO_MODE_AF_OD // 复用开漏
} GPIO_Mode;
typedef enum {
GPIO_PULL_NONE,
GPIO_PULL_UP,
GPIO_PULL_DOWN
} GPIO_Pull;
// 初始化结构体
typedef struct {
GPIO_Pin pin;
GPIO_Mode mode;
GPIO_Pull pull;
uint32_t speed; // 0-3 对应低速到高速
} GPIO_Config;
// 对外接口
void HAL_GPIO_Init(GPIO_Regs *port, GPIO_Config *cfg);
void HAL_GPIO_WritePin(GPIO_Regs *port, GPIO_Pin pin, uint8_t state);
uint8_t HAL_GPIO_ReadPin(GPIO_Regs *port, GPIO_Pin pin);
void HAL_GPIO_TogglePin(GPIO_Regs *port, GPIO_Pin pin);我曾经踩过的坑：GPIO 初始化时，一定要先配置模式，再配置上下拉。顺序反了，某些 MCU 会在切换瞬间产生毛刺，导致误触发。嗯，这个 bug 我查了整整两天。
3.4 UART 驱动抽象
UART 在门控系统里主要干两件事：调试输出和与显示屏通信。抽象的关键是「收发缓冲区」和「超时机制」。
// hal_uart.h
typedef struct {
uint32_t baudrate; // 波特率
uint8_t dataBits; // 数据位：7/8/9
uint8_t stopBits; // 停止位：1/2
uint8_t parity; // 校验：0=无, 1=奇, 2=偶
uint32_t rxBufSize; // 接收缓冲区大小
uint32_t txBufSize; // 发送缓冲区大小
} UART_Config;
// 接口
void HAL_UART_Init(UART_Regs *uart, UART_Config *cfg);
int32_t HAL_UART_Send(UART_Regs *uart, uint8_t *data, uint32_t len, uint32_t timeout);
int32_t HAL_UART_Receive(UART_Regs *uart, uint8_t *data, uint32_t len, uint32_t timeout);
void HAL_UART_IRQHandler(UART_Regs *uart); // 中断处理这里有个设计细节：timeout 参数。我见过很多代码用死等的方式收数据，一旦通信异常，整个系统就卡死了。门控系统对实时性要求高，必须加超时。
经验之谈：UART 接收建议用 DMA + 环形缓冲区。中断方式在高速率下容易丢数据，DMA 可以做到零拷贝。我在一个项目里把波特率从 115200 提到 921600，中断方式直接崩了，换成 DMA 后稳如老狗。
3.5 CAN 驱动抽象
CAN 总线是轨道车门控制器的标配。门控器和中央控制器之间、门控器和门控器之间，都用 CAN 通信。CAN 的抽象比 UART 复杂，因为涉及报文过滤、错误处理、总线状态管理。
// hal_can.h
typedef struct {
uint32_t baudrate; // 常见：125K, 250K, 500K
uint8_t mode; // 0=正常, 1=只听, 2=环回
uint32_t filterId; // 过滤 ID
uint32_t filterMask; // 过滤掩码
uint8_t filterMode; // 0=列表, 1=掩码
} CAN_Config;
typedef struct {
uint32_t id; // 标准帧 11bit，扩展帧 29bit
uint8_t idType; // 0=标准, 1=扩展
uint8_t frameType; // 0=数据帧, 1=远程帧
uint8_t dlc; // 数据长度 0-8
uint8_t data[8]; // 数据
} CAN_Msg;
// 接口
void HAL_CAN_Init(CAN_Regs *can, CAN_Config *cfg);
int32_t HAL_CAN_Send(CAN_Regs *can, CAN_Msg *msg, uint32_t timeout);
int32_t HAL_CAN_Receive(CAN_Regs *can, CAN_Msg *msg, uint32_t timeout);
uint32_t HAL_CAN_GetError(CAN_Regs *can);
void HAL_CAN_ResetBus(CAN_Regs *can);避坑指南：CAN 的过滤器配置一定要仔细。我曾经在一个项目里，过滤器掩码配错了，导致本不该接收的报文进来了，门莫名其妙地开关。查了三天，最后发现是掩码的位没对齐。
3.6 HAL 层的设计原则总结
| 原则 | 说明 | 我的建议 |
|---|---|---|
| 接口稳定 | API 签名一旦确定，尽量不改 | 用 typedef 把参数类型都定义好，后期只改实现 |
| 错误处理 | 所有函数返回错误码，不吞错误 | 定义统一的错误码枚举，比如 HAL_OK, HAL_TIMEOUT, HAL_ERROR |
| 可移植性 | 不依赖特定编译器特性 | 用标准 C，避免 GNU 扩展 |
| 性能可控 | 不引入额外开销 | 关键路径用宏或内联函数，非关键路径用普通函数 |
说白了，HAL 层就是给上层一个「承诺」：不管底层怎么变，你调我的接口，行为永远一致。这个承诺值千金。
嗯，这一讲就到这里。下一讲咱们聊聊中间件层，包括任务调度、通信协议栈这些东西。到时候我会分享一个真实项目里的调度器设计，那个故事挺有意思的。