1. 课程导论与分层架构思想：为什么需要分层？
各位同学，欢迎来到《嵌入式软件架构分层接口设计与调试实战》的第一章。
先问大家一个问题：你写嵌入式代码时，是不是经常遇到这种情况？
- 一个函数动不动就几百行，里面既有硬件寄存器操作，又有业务逻辑判断。
- 换个MCU，代码几乎要重写。
- 调试时，明明只是改了个显示逻辑，结果串口不工作了。
嗯，我当年刚入行时，也踩过这些坑。那时候我写的代码，说白了就是“一锅乱炖”。
后来我慢慢意识到，问题的根源不在于你用了什么芯片，而在于代码的组织方式。这就引出了我们今天的主角——分层架构。
1.1 为什么需要分层？
分层，听起来高大上，其实道理很简单。你想想看，我们盖房子，是不是先打地基，再砌墙，最后装修？没人会先把墙砌好，再挖地基吧？
嵌入式软件也是一样。分层就是把不同职责的代码，放到不同的“楼层”里。每一层只关心自己的事，通过定义好的接口和上下层通信。
这样做的好处，我总结为三点：
- 隔离变化：硬件换了，只改底层驱动；业务变了，只改上层逻辑。互不干扰。
- 降低复杂度：每一层的代码量都有限，逻辑清晰，容易理解和维护。
- 提高复用性：写好的驱动层，可以复用到下一个项目；写好的业务层，换个平台也能跑。
核心观点：分层不是目的，而是手段。目的是让代码变得可维护、可测试、可移植。
1.2 分层架构的演进历史
分层架构不是一天建成的。我从业十几年，亲眼见证了嵌入式软件架构的演变。
| 阶段 | 特点 | 典型问题 |
|---|---|---|
| 裸机时代 | 所有代码写在一个大循环里，全局变量满天飞。 | 牵一发而动全身，调试全靠点灯。 |
| 前后台系统 | 中断处理紧急事件，主循环处理后台任务。 | 任务优先级难以管理，实时性差。 |
| RTOS时代 | 引入任务调度，任务间通过队列、信号量通信。 | 任务划分不合理，死锁、优先级反转频发。 |
| 分层架构时代 | 明确分层，定义接口，模块化设计。 | 接口设计不合理，层间耦合依然严重。 |
你看，从裸机到分层，其实是一个不断“解耦”的过程。每一次演进，都是为了解决上一阶段的问题。
我记得有一次，我接手一个老项目，代码是典型的“裸机风格”。一个main函数里，既有I2C读写，又有PID计算，还有按键扫描。我想加个新功能，结果改了三天，系统直接跑飞了。后来我花了整整一周，把代码拆成了三层：驱动层、中间件层、应用层。从那以后，再改功能，心里就有底了。
1.3 分层架构的核心价值
说了这么多，分层到底能给我们带来什么？我把它归纳为四个核心价值：
- 可移植性：硬件平台变了，只需要替换最底层的驱动代码。上层业务逻辑几乎不用动。
- 可测试性：每一层都可以独立测试。你可以写单元测试来验证中间件层，而不需要真实的硬件。
- 可维护性：代码结构清晰，新人接手也能快速上手。Bug定位也快，因为你知道问题大概率出在哪一层。
- 团队协作：不同工程师可以并行开发不同层。只要接口定义好了，大家各干各的，互不干扰。
我的建议：不要为了分层而分层。如果你的项目只有几百行代码，强行分层反而会增加复杂度。分层适用于中大型项目，或者你预见到项目会持续迭代。
1.4 典型的三层架构模型
在嵌入式领域，最经典的分层模型是三层架构。我画了一张图，帮你直观理解：
这张图，我希望你牢牢记住。它是我们整个课程的基础。
- 驱动层：直接和硬件打交道。负责初始化外设、读写寄存器。这一层，说白了就是“硬件的翻译官”。
- 中间件层：提供通用的软件服务。比如TCP/IP协议栈、FATFS文件系统、FreeRTOS的API封装。它隔离了应用和硬件。
- 应用层：实现具体的业务功能。比如一个智能家居的控制逻辑、一个传感器的数据采集算法。
避坑指南：我曾经见过一个项目，应用层代码直接调用了GPIO的寄存器地址。结果换了MCU，所有应用代码都得改。这就是典型的“层间越界”。记住：上层永远不要直接访问下层的内部细节，只能通过接口通信。
1.5 接口：分层的“粘合剂”
分层架构里，层与层之间怎么通信？靠的就是接口。
接口，说白了就是一组函数声明。上层调用下层时，只能通过这些函数，不能直接访问下层的全局变量或寄存器。
举个例子，驱动层提供了一个SPI接口：
/* driver_spi.h */
int32_t SPI_Init(SPI_HandleTypeDef *hspi);
int32_t SPI_Transmit(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size);
int32_t SPI_Receive(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size);中间件层（比如一个LCD驱动库）只能调用这三个函数，而不能直接操作SPI的寄存器。这样，即使底层换了SPI硬件，只要接口不变，LCD库就不用改。
这就是接口的价值——解耦。
1.6 本章小结
好了，第一章的内容就到这里。我们回顾一下重点：
- 分层是为了隔离变化、降低复杂度、提高复用性。
- 嵌入式架构经历了从裸机到分层的演进，每一次都是对“解耦”的追求。
- 三层架构（驱动层、中间件层、应用层）是最经典的模型。
- 接口是分层的核心，它定义了层与层之间的契约。
我个人习惯，在开始一个新项目前，先花半天时间把分层结构和接口定义好。这看起来是“浪费时间”，但到了项目后期，你会发现这半天省下的时间，可能是几周甚至几个月。