第2章 硬件抽象层(HAL)设计原则：接口与实现分离，面向对象思想在C语言中的应用

大家好，欢迎来到第二章。上一章我们聊了驱动层到底要解决什么问题，这一章咱们直接切入核心——硬件抽象层（HAL）该怎么设计。

说实话，我见过太多工程师一上来就写寄存器操作，代码跑得飞起，但换了个芯片型号，整个项目就得重写。为什么会这样？说白了，就是硬件依赖和业务逻辑搅在一起了。

2.1 接口与实现分离：HAL的基石

先问大家一个问题：你写了一个GPIO控制LED的函数，里面直接操作了某个MCU的GPIO寄存器。三个月后项目换成了另一款MCU，你怎么办？

我早期做项目时就踩过这个坑。当时给一个智能家居产品写红外遥控驱动，直接操作了STM32的TIM和GPIO寄存器。后来客户要求换成GD32，我整整花了两周改驱动代码，还引入了新bug。从那以后，我彻底明白了——接口必须稳定，实现可以换。

2.1.1 接口定义规范

一个标准的HAL接口，应该包含三部分：

• 数据类型定义：比如GPIO引脚号、电平状态、模式枚举
• 函数原型声明：初始化、读、写、控制等操作
• 错误码定义：成功、超时、参数错误等返回值

举个例子，一个通用的GPIO HAL接口头文件：

/* hal_gpio.h */
#ifndef HAL_GPIO_H
#define HAL_GPIO_H

#include <stdint.h>

/* GPIO电平状态 */
typedef enum {
    HAL_GPIO_LOW  = 0,
    HAL_GPIO_HIGH = 1
} hal_gpio_level_t;

/* GPIO方向 */
typedef enum {
    HAL_GPIO_INPUT  = 0,
    HAL_GPIO_OUTPUT = 1
} hal_gpio_dir_t;

/* 错误码 */
typedef enum {
    HAL_OK       = 0,
    HAL_ERROR    = -1,
    HAL_TIMEOUT  = -2
} hal_status_t;

/* 初始化GPIO引脚 */
hal_status_t hal_gpio_init(uint8_t pin, hal_gpio_dir_t dir);

/* 设置GPIO输出电平 */
hal_status_t hal_gpio_write(uint8_t pin, hal_gpio_level_t level);

/* 读取GPIO输入电平 */
hal_status_t hal_gpio_read(uint8_t pin, hal_gpio_level_t *level);

#endif /* HAL_GPIO_H */

注意看，这个头文件里没有任何寄存器地址，也没有任何MCU相关的宏定义。上层业务代码只需要包含这个头文件，就能调用这些函数。至于底层是STM32还是GD32，业务代码根本不用关心。

2.1.2 实现分离策略

接口定义好了，实现放在哪里？我习惯的做法是：

• 接口头文件：放在 hal/inc/ 目录，对所有模块可见
• 实现源文件：放在 hal/src/mcu_specific/ 目录，按MCU型号分文件夹

比如：

hal/
├── inc/
│   └── hal_gpio.h          /* 接口声明 */
├── src/
│   ├── stm32f4/
│   │   └── hal_gpio.c      /* STM32实现 */
│   ├── gd32f3/
│   │   └── hal_gpio.c      /* GD32实现 */
│   └── at32f4/
│       └── hal_gpio.c      /* AT32实现 */

换芯片时，只需要换掉对应的实现文件，重新编译即可。上层业务代码一行都不用改。

2.2 面向对象思想在C语言中的应用

很多人觉得面向对象是C++的事，C语言只能面向过程。其实不然。C语言完全可以实现封装、继承、多态这些思想，只是写法上更“朴素”一些。

我做过一个项目，需要同时驱动三款不同的温湿度传感器：SHT30、DHT22、AM2320。如果每个传感器都写一套独立的API，上层代码就得写三个分支。后来我用面向对象思想重构，一个统一的接口搞定所有传感器。

2.2.1 用结构体实现封装

C语言里，结构体就是天然的“类”。把数据和操作数据的函数指针放在一起，就是封装。

/* hal_sensor.h */
typedef struct {
    uint8_t  (*init)(void);
    uint8_t  (*read_temp)(float *temp);
    uint8_t  (*read_humi)(float *humi);
    void     (*deinit)(void);
    uint32_t delay_ms;       /* 传感器需要的延时时间 */
    uint8_t  addr;           /* I2C地址或单总线ID */
} hal_sensor_t;

/* 使用示例 */
extern hal_sensor_t sht30_sensor;
extern hal_sensor_t dht22_sensor;
extern hal_sensor_t am2320_sensor;

每个传感器都实现自己的 hal_sensor_t 实例：

/* sht30.c */
static uint8_t sht30_init(void) {
    /* SHT30特有的初始化代码 */
    return 0;
}

static uint8_t sht30_read_temp(float *temp) {
    /* SHT30特有的温度读取代码 */
    return 0;
}

hal_sensor_t sht30_sensor = {
    .init      = sht30_init,
    .read_temp = sht30_read_temp,
    .read_humi = sht30_read_humi,
    .deinit    = sht30_deinit,
    .delay_ms  = 100,
    .addr      = 0x44
};

上层业务代码只需要操作 hal_sensor_t 指针，根本不知道底层是哪个传感器：

void app_read_sensor(hal_sensor_t *sensor) {
    float temp, humi;
    sensor->init();
    sensor->read_temp(&temp);
    sensor->read_humi(&humi);
    printf("Temp: %.1f, Humi: %.1f\n", temp, humi);
}

2.2.2 用函数指针表实现“虚函数表”

如果你需要更复杂的继承关系，可以用函数指针表（类似C++的虚函数表vtable）。

我记得有一次做电机驱动，需要支持直流电机、步进电机、伺服电机。它们的接口有共性（启动、停止、设置速度），也有差异（步进电机需要设置步数，伺服电机需要设置角度）。

我的做法是定义一个基础接口表，然后每个电机类型扩展自己的接口：

/* hal_motor.h */
/* 基础操作 */
typedef struct {
    void (*start)(void *obj);
    void (*stop)(void *obj);
    void (*set_speed)(void *obj, int32_t speed);
} hal_motor_ops_t;

/* 步进电机扩展 */
typedef struct {
    hal_motor_ops_t base;
    void (*set_steps)(void *obj, uint32_t steps);
} hal_stepper_ops_t;

/* 伺服电机扩展 */
typedef struct {
    hal_motor_ops_t base;
    void (*set_angle)(void *obj, float angle);
} hal_servo_ops_t;

每个电机实例包含一个指向操作表的指针：

typedef struct {
    const hal_motor_ops_t *ops;
    /* 电机私有数据 */
    uint8_t  pwm_channel;
    uint16_t max_speed;
} hal_motor_t;

调用时统一通过操作表：

void hal_motor_start(hal_motor_t *motor) {
    motor->ops->start(motor);
}

这样，上层代码永远只调用 hal_motor_start()，底层实现可以是直流电机、步进电机或伺服电机。

2.3 HAL设计核心原则总结

讲了这么多，我把自己多年积累的HAL设计原则整理成一张表，方便大家对照：

原则	说明	我踩过的坑
接口稳定	接口头文件一旦发布，尽量不修改函数原型	曾经改了一个参数类型，导致5个模块全部要改
实现隔离	不同MCU的实现放在独立目录，编译时选择	用宏开关控制实现，最后代码里全是 #ifdef，可读性极差
数据隐藏	硬件寄存器地址、MCU特有类型不出现在头文件中	头文件暴露了寄存器地址，被其他模块误用，调试了三天
错误处理	所有HAL函数返回统一错误码，不直接断言	早期用assert，产品发布后现场崩溃，连日志都没有
可测试性	接口设计要方便Mock，支持单元测试	没有Mock接口，自动化测试覆盖率一直上不去

2.4 HAL整体架构图

下面这张图展示了HAL在整个嵌入式软件中的位置和分层关系：

2.5 避坑指南：我曾经的教训

最后分享几个我实际项目中踩过的坑，希望大家能避开：

• 不要在HAL接口里暴露硬件细节：我曾经在 hal_gpio.h 里定义了一个 #define GPIO_PIN_0 (1U << 0)，结果换芯片后位宽不同，整个项目编译不过。现在我的HAL接口里只有抽象枚举，没有硬件宏。
• 函数指针不要滥用：有一次我把所有HAL函数都设计成函数指针，结果每个实例占用了大量RAM。对于简单的GPIO操作，直接用普通函数+条件编译更省资源。
• 接口设计要考虑测试：我早期设计的HAL接口没有考虑Mock，导致单元测试时无法模拟硬件。后来我在接口中增加了 hal_gpio_set_mock() 这样的测试钩子，测试覆盖率从30%提升到了85%。