3. 软件架构分层：应用层、中间件层、驱动层、硬件抽象层（HAL）的职责划分

做嵌入式系统设计这么多年，我见过太多人一上来就写代码，结果项目后期改得想哭。说白了，软件架构分层就是给代码画个「地盘」。每层管好自己的事，别越界。今天咱们就聊聊这四层到底该干什么。

3.1 为什么非要分层？

你想想看，如果所有代码都揉在一起，换个MCU就得重写整个工程。我早期一个项目就吃过这个亏——客户临时换了传感器，我熬了三个通宵改驱动代码。从那以后，我坚决要求团队做分层设计。

分层的核心好处就三个：

• 解耦：上层不关心底层怎么实现，底层不关心上层业务逻辑
• 可移植：换硬件平台时，只需要改驱动层和HAL层
• 可测试：每层可以单独测试，出问题能快速定位

3.2 四层架构全景图

先看一张我手绘的架构图，帮你建立整体认知：

嗯，这张图我每次培训都会拿出来讲。注意箭头方向——上层依赖下层，但下层绝不能依赖上层。这是铁律。

3.3 各层职责详解

3.3.1 硬件抽象层（HAL）

HAL是离硬件最近的一层。它的任务就是把MCU的寄存器、外设接口封装成统一的API。举个例子，同样是GPIO写引脚，STM32和NXP的寄存器地址完全不同，但HAL层可以让上层调用同样的 HAL_GPIO_WritePin()。

典型的HAL接口长这样：

// HAL层：硬件抽象接口
void HAL_UART_Init(uint32_t baudrate);
void HAL_UART_Send(uint8_t *data, uint16_t len);
uint8_t HAL_UART_Receive(uint8_t *data, uint16_t len);

// 底层实现（以STM32为例）
void HAL_UART_Init(uint32_t baudrate) {
    // 配置USART寄存器
    USART1->BRR = SystemCoreClock / baudrate;
    USART1->CR1 |= USART_CR1_UE | USART_CR1_TE | USART_CR1_RE;
}

3.3.2 驱动层

驱动层在HAL之上，负责管理具体的外设芯片。比如一个温湿度传感器SHT30，驱动层要处理它的初始化序列、读写时序、数据校验。

我习惯把驱动层分成两类：

• 片内驱动：MCU内部外设，如UART、SPI、I2C、定时器
• 片外驱动：外部芯片，如传感器、LCD、Flash、以太网PHY

// 驱动层：SHT30温湿度传感器驱动
typedef struct {
    float temperature;
    float humidity;
} sht30_data_t;

// 驱动接口
int sht30_init(i2c_handle_t *i2c);
int sht30_read(sht30_data_t *data, uint32_t timeout_ms);

// 实现细节
int sht30_read(sht30_data_t *data, uint32_t timeout_ms) {
    uint8_t cmd[] = {0x2C, 0x06};
    uint8_t buf[6];
    
    // 发送测量命令
    if (HAL_I2C_Master_Transmit(i2c, SHT30_ADDR, cmd, 2, timeout_ms) != HAL_OK) {
        return -1;  // 超时或错误
    }
    
    // 等待并读取数据
    // ... 具体时序处理
}

3.3.3 中间件层

中间件层是「工具箱」。它提供各种通用服务，让应用层不用重复造轮子。常见的中间件包括：

• TCP/IP协议栈（如LwIP）
• 文件系统（如FatFS、LittleFS）
• RTOS内核（如FreeRTOS、RT-Thread）
• 加密算法库（如mbedTLS）
• 数据解析库（如JSON、Protobuf）

中间件层的特点是：它不直接操作硬件，而是调用驱动层的接口。比如LwIP协议栈通过驱动层的网卡接口收发数据包。

3.3.4 应用层

应用层是「老板层」。它只关心业务逻辑，不关心底层怎么实现。比如一个智能家居网关，应用层负责：

• 读取传感器数据（调用中间件层或驱动层接口）
• 判断是否需要报警（业务逻辑）
• 上报数据到云端（调用网络中间件）
• 处理用户按键（调用输入驱动）

应用层的代码应该是最干净的。我要求团队在应用层里不能出现任何寄存器操作、不能直接调用HAL接口。所有硬件操作必须通过中间件层或驱动层转发。

// 应用层：温度监控任务
void temperature_monitor_task(void *param) {
    sht30_data_t sensor_data;
    
    while (1) {
        // 读取传感器（通过驱动层）
        if (sht30_read(&sensor_data, 100) == 0) {
            // 业务逻辑判断
            if (sensor_data.temperature > 50.0f) {
                // 触发报警（通过中间件层）
                mqtt_publish("alarm/temp", "overheat");
                // 控制风扇（通过驱动层）
                fan_control(FAN_SPEED_HIGH);
            }
        }
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

3.4 层间通信规范

层与层之间怎么传数据？我总结了一套规则：

调用方向	允许方式	禁止方式
应用层 → 中间件层	函数调用、回调注册	直接访问驱动层或HAL
应用层 → 驱动层	通过中间件层转发	直接调用驱动接口（紧急情况除外）
中间件层 → 驱动层	标准接口调用	绕过驱动层操作HAL
驱动层 → HAL层	API调用	直接写寄存器
HAL层 → 硬件	寄存器操作	无

3.5 实际项目中的分层案例

拿我最近做的一个物联网数据采集终端举例：

• HAL层：封装了STM32L4的GPIO、UART、SPI、ADC寄存器操作
• 驱动层：实现了SHT30温湿度驱动、MAX30102心率驱动、SIM800C 4G模块驱动
• 中间件层：集成了FreeRTOS、LwIP协议栈、FatFS文件系统、MQTT客户端
• 应用层：数据采集任务、上传任务、本地存储任务、OTA升级任务

有一次客户要求把MCU从STM32L4换成GD32。我只改了HAL层和驱动层里跟寄存器相关的部分，应用层和中间件层一行代码没动。三天就完成了移植。这就是分层设计的力量。

好了，这一章就聊到这儿。记住：好的架构设计，是让每一层都做自己该做的事，别越界。