4、经典分层架构：硬件抽象层(HAL)、驱动层、中间件层、应用层的职责与划分原则

嵌入式软件的分层架构，说白了就是把代码按「离硬件的远近」排个队。我做了十几年嵌入式，见过太多「一锅炖」的项目——中断里调业务逻辑，驱动里写算法，最后改一个传感器型号恨不得重写整个工程。嗯，分层就是用来治这个病的。

今天咱们聊的这四层——硬件抽象层、驱动层、中间件层、应用层——是嵌入式领域最经典的分层模型。你想想看，不管你是做MCU还是MPU，跑RTOS还是Linux，这套思路基本都能套得上。

4.1 四层架构总览

先看一张整体结构图，把各层的位置和关系理清楚。

这张图我建议你存下来。每次做架构设计时，拿它当对照清单——你的代码能放进对应的格子里吗？能，说明结构清晰；不能，说明该重构了。

4.2 硬件抽象层（HAL）—— 给芯片「翻译」

HAL是离硬件最近的一层。它的职责就一个：把芯片手册里的寄存器地址、位定义、外设基址，封装成C语言能用的宏和函数。

我个人习惯把HAL分成两部分：芯片级HAL和板级HAL。

类型	内容	示例
芯片级HAL	寄存器地址、位掩码、外设基址	#define GPIOA_BASE 0x40020000
板级HAL	引脚复用、时钟配置、板级外设映射	#define LED_PIN GPIO_PIN_5

HAL层输出的东西长什么样？看个例子：

// 芯片级HAL：stm32f4xx_hal.h
#define GPIO_MODE_INPUT  0x00
#define GPIO_MODE_OUTPUT 0x01
#define GPIO_PIN_0       ((uint16_t)0x0001)

// 板级HAL：board_def.h
#define LED_RED_PORT     GPIOA
#define LED_RED_PIN      GPIO_PIN_5
#define LED_GREEN_PORT   GPIOB
#define LED_GREEN_PIN    GPIO_PIN_0

注意，HAL层里不能有任何「逻辑」。不能有if判断，不能有循环等待，不能有延时。它就是一本「硬件字典」——查得到，用得上，但不替你思考。

4.3 驱动层（Driver Layer）—— 让外设「动起来」

驱动层在HAL之上。它调用HAL提供的宏和函数，完成外设的初始化、配置、数据收发。

驱动层的核心产出是设备操作接口。我一般会为每个外设定义一个结构体，里面放函数指针：

typedef struct {
    int32_t (*init)(void);
    int32_t (*write)(uint8_t *data, uint32_t len);
    int32_t (*read)(uint8_t *data, uint32_t len);
    int32_t (*ioctl)(uint32_t cmd, void *arg);
} uart_drv_t;

为什么要这么写？因为这样上层代码就不关心底层用的是STM32的USART还是NXP的LPUART。只要实现了这个接口，应用层就能无缝切换。

驱动层的典型职责清单：

• 外设初始化序列（时钟使能、引脚复用、参数配置）
• 中断服务函数（ISR）——只做最轻量的数据搬运
• DMA传输配置与回调
• 电源管理接口（休眠/唤醒）
• 错误状态上报（不处理，只上报）

4.4 中间件层（Middleware Layer）—— 提供「通用能力」

中间件层是四层里最容易被忽视的一层。很多人觉得「不就是个库吗，直接调不就行了？」——结果就是应用层代码里到处是socket操作、文件读写、加密计算，乱成一团。

中间件层的定位是：与业务无关的通用软件组件。它封装了复杂的算法和协议，给应用层提供简洁的API。

中间件类型	典型实现	对上提供的API
通信协议栈	lwIP、FreeModbus	tcp_connect()、modbus_read()
文件系统	FatFS、LittleFS	f_open()、f_write()
图形引擎	LVGL、emWin	lv_btn_create()、GUI_DrawLine()
加密/安全	mbedTLS、WolfSSL	mbedtls_aes_encrypt()

中间件层和驱动层的接口怎么对接？我习惯用一个适配层来做桥接。比如FatFS需要底层存储设备的读写函数，我就写一个diskio.c，里面调用驱动层的SPI接口去操作SD卡。这样中间件本身不用改一行代码。

4.5 应用层（Application Layer）—— 只关心「做什么」

应用层是四层的最顶层。它的代码里不应该出现任何寄存器地址、中断向量号、DMA通道号。应用层只做三件事：

• 业务逻辑：比如「温度超过阈值就报警」
• 任务调度：决定什么时候做什么事
• 状态管理：维护系统的运行状态机

看一个对比，你就明白分层的好处了：

// ❌ 坏代码：应用层直接操作寄存器
void app_handle_temperature(void) {
    uint32_t temp = *(volatile uint32_t*)0x40012004; // 直接读ADC寄存器
    if (temp > 500) {
        GPIOA->BSRR = (1 << 5); // 直接点灯
    }
}

// ✅ 好代码：应用层调用中间件/驱动接口
void app_handle_temperature(void) {
    float temp = temp_sensor_read();       // 调用中间件层
    if (temp > 50.0f) {
        alarm_trigger(ALARM_OVER_TEMP);    // 调用应用层内部函数
    }
}

你想想看，第一种写法，换一个ADC芯片或者换一个LED引脚，你得改多少地方？第二种写法，底层随便换，应用层一行代码都不用动。

4.6 划分原则与常见误区

说了这么多，总结几条硬性原则。这些是我在代码评审里反复强调的：

1. 单向依赖：上层可以调用下层，下层绝不能调用上层。回调函数除外，但回调的注册方向必须是从上往下。
2. 接口稳定：层与层之间的接口一旦确定，尽量不改。要改就加新接口，别删旧接口。
3. 各司其职：HAL只做映射，驱动只做配置，中间件只做通用能力，应用只做业务。谁越界谁重构。
4. 可替换性：每一层都应该能被整体替换而不影响其他层。换芯片就换HAL+驱动，中间件和应用不动。

4.7 实际项目中的分层示例

最后，用一个智能家居网关的案例，把四层串起来看看：

层级	内容	文件示例
应用层	设备配网逻辑、数据上报策略、本地联动规则	app_network.c、app_rule_engine.c
中间件层	MQTT客户端、JSON解析器、OTA升级库	mqtt_client.c、cJSON.c、ota_manager.c
驱动层	Wi-Fi模组驱动、传感器驱动、继电器驱动	esp8266_drv.c、dht22_drv.c、relay_drv.c
HAL层	芯片寄存器定义、引脚映射表、时钟配置	stm32f4xx_hal.h、board_pinmap.h

你看，每一层的职责清清楚楚。Wi-Fi模组从ESP8266换成ESP32，只需要改驱动层和HAL层，中间件层的MQTT代码不用动，应用层的业务逻辑更不用动。这就是分层架构的价值。