4、硬件抽象层（HAL）设计：HAL层的作用与分层思想、GPIO/UART/SPI/I2C驱动封装、设备树与板级支持包（BSP）概念

各位同学，今天我们聊一个非常核心的话题——硬件抽象层，也就是HAL层。说实话，我在做嵌入式开发的头几年，对HAL层的理解一直停留在“就是封装一下寄存器操作”这个层面。直到有一次，我接手了一个项目，需要在三个月内把一套配电终端从STM32平台移植到GD32平台……嗯，那段时间我几乎每天都在改驱动代码，改到怀疑人生。从那以后，我才真正理解了HAL层的价值。

4.1 HAL层的作用与分层思想

HAL层，说白了就是在硬件和上层软件之间加一层“翻译官”。它的核心作用就两个：隔离变化和统一接口。

你想想看，一个智能配电终端里，可能有MCU、传感器、执行器、通信模块。这些硬件来自不同厂商，寄存器配置千差万别。如果没有HAL层，上层应用代码里到处都是寄存器地址和位操作——换一个MCU，整个项目几乎要重写。

我个人习惯把嵌入式软件分成三层：

  • 应用层：业务逻辑，比如数据采集、故障判断、通信协议。
  • HAL层：硬件抽象，提供统一的API接口。
  • 硬件层：具体的芯片、外设、电路。

这里有个关键点：HAL层只对上提供服务，不对下依赖具体硬件。什么意思呢？就是HAL层的接口定义里，不能出现某个芯片特有的寄存器名称。比如你不能写GPIOA->ODR，而应该写HAL_GPIO_WritePin()。

核心原则：HAL层的接口设计，应该以“功能”为导向，而不是以“硬件”为导向。

举个例子，一个配电终端需要读取温度传感器的值。应用层调用的是HAL_Temperature_Read()，至于底层是用I2C还是SPI，是用的DS18B20还是PT100，HAL层内部去处理。这样，即使换了传感器型号，应用层代码一行都不用改。

4.2 GPIO/UART/SPI/I2C驱动封装

好，我们来看具体的驱动封装。这部分我建议你记住一个口诀：“初始化、读写、控制、回调”。每个外设驱动，基本上都逃不出这四类操作。

4.2.1 GPIO驱动封装

GPIO看似简单，但封装不好很容易出问题。我在项目中遇到过，有人把GPIO的初始化参数直接写死在代码里，结果换了一个板子，LED不亮了，排查了半天才发现是引脚号变了。

正确的做法是定义一个结构体，把所有可配置的参数都放进去：

typedef struct {
    uint8_t  pin;          // 引脚号
    uint8_t  mode;         // 输入/输出/复用
    uint8_t  pull;         // 上拉/下拉/浮空
    uint8_t  speed;        // 速度等级
    uint8_t  outputType;   // 推挽/开漏
} GPIO_Config_t;

// 统一的初始化接口
void HAL_GPIO_Init(GPIO_Config_t *config);

// 读写接口
void HAL_GPIO_WritePin(uint8_t pin, uint8_t level);
uint8_t HAL_GPIO_ReadPin(uint8_t pin);

这样设计的好处是，上层代码只需要填充结构体，然后调用HAL_GPIO_Init()。底层实现可以针对不同MCU做适配，但接口不变。

4.2.2 UART驱动封装

UART的封装，我个人习惯把环形缓冲区集成进去。为什么？因为配电终端经常需要接收不定长的数据帧，如果不用缓冲区，很容易丢数据。

typedef struct {
    uint32_t baudRate;
    uint8_t  dataBits;
    uint8_t  stopBits;
    uint8_t  parity;
    uint8_t  *rxBuffer;
    uint16_t rxBufferSize;
    void (*rxCallback)(uint8_t data);  // 接收回调
} UART_Config_t;

void HAL_UART_Init(UART_Config_t *config);
void HAL_UART_Send(uint8_t *data, uint16_t len);
uint16_t HAL_UART_Receive(uint8_t *buffer, uint16_t maxLen);

小技巧：UART的接收回调函数，建议在中断里只做“把数据放入缓冲区”这件事，不要做复杂处理。我曾经见过有人在中断里做协议解析，结果导致中断响应超时，系统直接挂了。

4.2.3 SPI与I2C驱动封装

SPI和I2C都是总线协议，封装思路类似。关键是要把片选信号和时钟频率抽象出来。

// SPI
typedef struct {
    uint32_t clockSpeed;
    uint8_t  mode;          // 0-3
    uint8_t  bitOrder;      // MSB/LSB
    uint8_t  csPin;         // 片选引脚
} SPI_Config_t;

void HAL_SPI_Init(SPI_Config_t *config);
void HAL_SPI_Transmit(uint8_t *data, uint16_t len);
void HAL_SPI_Receive(uint8_t *data, uint16_t len);
void HAL_SPI_TransmitReceive(uint8_t *txData, uint8_t *rxData, uint16_t len);

// I2C
typedef struct {
    uint32_t clockSpeed;
    uint8_t  ownAddress;
} I2C_Config_t;

void HAL_I2C_Init(I2C_Config_t *config);
void HAL_I2C_MasterTransmit(uint8_t slaveAddr, uint8_t *data, uint16_t len);
void HAL_I2C_MasterReceive(uint8_t slaveAddr, uint8_t *data, uint16_t len);

这里要注意，I2C的从机地址有7位和10位之分，封装时最好统一处理。我建议在配置结构体里加一个标志位，让上层决定用哪种模式。

4.3 设备树与板级支持包（BSP）概念

好，接下来我们聊聊设备树和BSP。这两个概念，很多初学者容易混淆。我简单解释一下：

  • BSP：板级支持包，是针对特定硬件平台的驱动和初始化代码集合。说白了，就是让操作系统或应用层知道“这块板子上有什么硬件，怎么用”。
  • 设备树：是一种描述硬件资源的数据结构，用文本文件的形式，把CPU、内存、外设、中断、GPIO映射等信息描述清楚。

在Linux系统中，设备树用得比较多。但在嵌入式RTOS或裸机开发中，我们通常用BSP的概念。我个人习惯把BSP分成两部分：

  1. 硬件初始化代码：时钟配置、GPIO复用、中断向量表等。
  2. 外设驱动实例化：根据实际硬件连接，创建具体的驱动对象。

举个例子，一个配电终端板子上有一个SPI Flash和一个SPI LCD，它们挂在同一个SPI总线上，但片选引脚不同。在BSP中，我会这样写：

// bsp_spi.c
SPI_Config_t spiFlashConfig = {
    .clockSpeed = 10000000,
    .mode = 0,
    .bitOrder = SPI_MSB_FIRST,
    .csPin = GPIO_PIN_4   // Flash的片选
};

SPI_Config_t spiLcdConfig = {
    .clockSpeed = 20000000,
    .mode = 0,
    .bitOrder = SPI_MSB_FIRST,
    .csPin = GPIO_PIN_5   // LCD的片选
};

void BSP_SPI_Init(void) {
    HAL_SPI_Init(&spiFlashConfig);
    HAL_SPI_Init(&spiLcdConfig);
}

避坑指南：我曾经在一个项目里，把BSP的配置和HAL层的实现混在一起写。结果换了一个板子，需要同时修改HAL层和BSP层，工作量翻倍。记住：BSP只负责“配置”，不负责“实现”。

设备树的概念，在裸机开发中也可以借鉴。比如我们可以用一个结构体数组，来描述板子上的所有外设：

typedef struct {
    const char *name;       // 外设名称
    uint8_t    type;        // 外设类型（GPIO/UART/SPI/I2C）
    void       *config;     // 指向配置结构体的指针
    void       *driver;     // 指向驱动实例的指针
} DeviceTreeNode_t;

// 板级设备树
DeviceTreeNode_t boardDeviceTree[] = {
    {"LED1", DEVICE_TYPE_GPIO, &led1Config, NULL},
    {"UART1", DEVICE_TYPE_UART, &uart1Config, &uart1Driver},
    {"SPI_FLASH", DEVICE_TYPE_SPI, &spiFlashConfig, &spiFlashDriver},
    // ...
};

这样设计的好处是，增加或更换外设时，只需要修改这个数组，不需要动其他代码。嗯，这就是设备树思想的精髓——把硬件描述和软件逻辑解耦。

4.4 小结

这一章的内容比较多，我帮你梳理一下重点：

  • HAL层的核心是隔离变化、统一接口。
  • 驱动封装要遵循“初始化、读写、控制、回调”的框架。
  • BSP负责硬件配置和驱动实例化，不要和HAL层实现混在一起。
  • 设备树的思想可以借鉴到裸机开发中，用数据结构描述硬件资源。

下一章，我们会把这些知识用到一个具体的配电终端项目中，手把手带你搭建一个完整的HAL层。到时候你会发现，前期把HAL层设计好了，后面写应用代码简直是一种享受。

← 上一章 📖 返回目录 下一章 →