1. 课程导论与分层架构全景：为什么需要分层架构？

各位同学，欢迎来到《嵌入式软件分层架构与中间件集成实战》的第一章。

先问大家一个问题：你写嵌入式代码时，是不是经常遇到这种情况？

• 换了一个MCU，整个工程几乎要重写
• 驱动代码和应用逻辑混在一起，改一个LED闪烁，结果把通信协议搞崩了
• 团队里三个人同时改同一个文件，合并时生不如死

嗯，这些坑我全都踩过。而且不止一次。

我刚开始做嵌入式那几年，写的是“裸奔”的单片机程序。一个main.c文件，从寄存器配置到业务逻辑全塞进去。当时觉得挺爽，代码跑得飞快。直到有一次，客户要求把STM32F103换成GD32F103——我熬了三个通宵改驱动，改完发现应用逻辑也跑偏了。从那以后，我开始认真思考一个问题：代码到底该怎么组织，才能既灵活又可靠？

答案就是——分层架构。

1.1 为什么需要分层架构？

说白了，分层就是把不同职责的代码隔离开。每一层只关心自己的事，层与层之间通过明确的接口通信。

这样做的好处，我总结为三点：

你想想看，一个没有分层的系统，就像一间堆满杂物的房间——你知道东西就在里面，但每次找都要翻个底朝天。分层架构就是给这间房间打了隔断、贴了标签。

1.2 嵌入式软件分层模型全景图

嵌入式软件的分层模型，业界没有绝对统一的标准。但根据我多年实战经验，最通用的模型是四层架构：

层次	名称	核心职责	典型内容
第4层	应用层	业务逻辑、用户交互	任务调度、状态机、协议解析、UI
第3层	中间件层	通用功能组件、协议栈	文件系统、TCP/IP、MQTT、加密库
第2层	OSAL层	操作系统抽象	任务/信号量/队列/时间接口封装
第1层	HAL层	硬件抽象	GPIO/UART/SPI/I2C/定时器驱动

这张表看起来简单，但每一层的设计都有很多门道。下面我逐一展开。

1.2.1 HAL层（硬件抽象层）

HAL层是离硬件最近的一层。它的任务就是把MCU和外设的寄存器操作封装成统一的API。

举个例子，同样是点亮一个LED：

// 不封装：直接操作寄存器
#define GPIOB_ODR (*(volatile uint32_t *)0x40020C14)
GPIOB_ODR |= (1 << 12);   // 点亮PB12

// 封装后：调用HAL接口
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_12, GPIO_PIN_SET);

你可能会说：“封装了反而多了一层调用，效率低了。” 没错，确实有微小的性能损失。但换来的是：换MCU时，应用层代码一行都不用改。我在一个工业控制项目中，把STM32F4换成国产GD32F4，只改了HAL层和链接脚本，应用层200多个文件零改动。这个收益，远远大于那点性能损失。

1.2.2 OSAL层（操作系统抽象层）

OSAL层解决的是RTOS的替换问题。

今天用FreeRTOS，明天想换RT-Thread，后天客户指定用uC/OS-III。如果没有OSAL层，你就要把应用层里所有的任务创建、信号量、消息队列全部重写一遍。

OSAL层的设计思路很简单：定义一套通用的OS接口，然后为每个RTOS写一个适配层。

// OSAL接口示例
typedef void *osal_task_handle_t;

osal_task_handle_t osal_task_create(const char *name,
                                    void (*entry)(void *),
                                    void *param,
                                    uint32_t stack_size,
                                    uint32_t priority);

osal_status_t osal_sem_create(osal_sem_handle_t *sem,
                              uint32_t initial_count);

osal_status_t osal_sem_take(osal_sem_handle_t sem,
                            uint32_t timeout_ms);

我个人习惯把OSAL层做得尽量薄，只封装最常用的OS原语：任务、信号量、互斥锁、消息队列、软件定时器。太冷门的功能（比如FreeRTOS的流缓冲区）就不封装了，需要时可以直接调用RTOS原生API，但要做好隔离标记。

1.2.3 中间件层

中间件层是可复用的功能组件集合。它不依赖具体的硬件和业务，只依赖OSAL层提供的OS原语。

常见的中间件包括：

• 通信协议栈：TCP/IP、MQTT、CoAP、HTTP
• 存储组件：FATFS文件系统、LittleFS、FlashDB
• 安全组件：mbedTLS加密库、TinyCrypt
• 工具组件：环形缓冲区、日志系统、命令行Shell

中间件的设计原则是高内聚、低耦合。每个中间件应该是一个独立的模块，通过OSAL层获取OS服务，通过HAL层访问硬件（如果需要）。

1.2.4 应用层

应用层是业务逻辑的所在地。它调用中间件和OSAL层的接口，完成具体的功能。

应用层应该做到：

• 不直接操作硬件（不调用HAL层接口）
• 不直接调用RTOS原生API（通过OSAL层）
• 只关注“做什么”，不关心“怎么做”

举个例子，一个温控器的应用层代码：

void temperature_control_task(void *param)
{
    float temp;
    osal_sem_handle_t sem = (osal_sem_handle_t)param;

    while (1) {
        osal_sem_take(sem, OSAL_WAIT_FOREVER);  // 等待传感器数据就绪
        temp = temp_sensor_read();               // 调用中间件接口
        if (temp > TARGET_TEMP + HYSTERESIS) {
            heater_off();                        // 调用中间件接口
        } else if (temp < TARGET_TEMP - HYSTERESIS) {
            heater_on();
        }
    }
}

你看，这段代码里没有GPIO操作，没有RTOS任务创建细节，甚至不知道传感器是I2C还是SPI。这就是分层架构的魅力。

1.3 分层架构全景图

下面我用一张SVG图，把整个分层架构的关系画出来。这张图是我在培训时经常用的，你可以把它当作整个课程的地图。

1.4 分层架构的核心原则

看完这张图，你应该对分层架构有了整体认识。最后，我总结几条核心原则，你在实际项目中一定要记住：