第一章：课程导论——为什么需要分层架构？嵌入式软件的痛点与分层思想的价值
各位同学，大家好。我是你们这门课的老周。在嵌入式这行摸爬滚打了十几年，踩过的坑比吃过的盐还多。今天咱们开篇第一讲，不急着上代码，先聊聊一个根本问题：我们到底为什么需要分层架构？
说白了，分层不是某个理论家拍脑袋想出来的。它是被现实逼出来的。你想想看，一个嵌入式项目从几个人写到几十个人维护，从几千行代码膨胀到几十万行，如果没有清晰的层次，那代码就是个“大泥球”——谁碰谁倒霉。
核心观点：分层架构不是为了炫技，而是为了控制复杂度、提升可维护性、实现团队并行开发。
1.1 嵌入式软件的“原生痛点”
我刚开始做嵌入式那会儿，用的还是8位单片机。那时候写程序，基本就是“大循环+中断”一条路走到黑。代码结构？不存在的。所有逻辑、驱动、协议处理全揉在一个文件里。当时觉得挺爽，反正一个人干，改起来也快。
但后来项目越来越大，问题就来了。我总结了一下，嵌入式软件常见的痛点有这么几个：
- 硬件耦合太紧：换个MCU，代码基本重写。我有个项目从STM32F1换到F4，光改底层驱动就花了两周。
- 代码复用率低：每个项目都是“从零开始”，同样的I2C驱动、同样的LCD显示逻辑，换个项目就得重新移植一遍。
- 调试效率低下：业务逻辑和硬件操作混在一起，出了问题你根本分不清是算法错了还是寄存器没配对。
- 团队协作困难：两个人改同一个文件，合并冲突能让你崩溃。更别说让新人接手老项目了——那简直是噩梦。
- 测试几乎不可能：没有分层，你没法单独测试业务逻辑。每次测试都得把硬件搭好，烧录、运行、看现象。效率极低。
我曾经踩过的坑：有一回做工业控制项目，客户要求紧急修改一个逻辑判断条件。我自认为只是改了个if语句，结果因为代码耦合太严重，把定时器中断里的一个标志位给影响了。设备在现场直接死机，被客户骂得狗血淋头。从那以后，我下定决心——必须分层。
1.2 分层架构的核心思想
分层架构，说白了就是“各司其职，各管一摊”。每一层只关心自己的事，层与层之间通过明确的接口通信。这样做的好处是什么？
- 隔离变化：硬件换了，只改驱动层；业务逻辑变了，只改应用层。互不影响。
- 提升复用：写好的驱动模块、中间件，可以直接拿到下一个项目用。
- 便于测试：每一层都可以单独测试。业务逻辑甚至可以在PC上模拟运行。
- 支持并行：A写驱动，B写中间件，C写应用。只要接口定好了，各干各的，最后集成。
我个人的习惯是，把嵌入式软件分成这么几层：
| 层次 | 职责 | 典型内容 |
|---|---|---|
| 应用层 | 业务逻辑、状态机、算法 | 用户需求、控制策略、数据处理 |
| 中间件层 | 协议栈、文件系统、RTOS封装 | TCP/IP、FATFS、FreeRTOS API |
| 硬件抽象层 (HAL) | 屏蔽硬件差异，提供统一接口 | GPIO、UART、I2C、SPI抽象 |
| 驱动层 | 直接操作寄存器，与硬件打交道 | MCU外设驱动、外设芯片驱动 |
小提示：实际项目中，层数可以根据需求增减。比如小项目可以合并HAL和驱动层，大项目可能还要加一个“服务层”。关键不是层数多少，而是依赖方向要单一——上层依赖下层，下层绝不依赖上层。
1.3 分层架构的直观理解
光说理论可能有点抽象。我画了一张图，帮你直观理解分层架构的样子：
你看这张图，每一层都像一块积木，堆叠起来。箭头方向是依赖方向——上层知道下层，下层对上层一无所知。这就是分层架构最核心的原则：单向依赖。
1.4 接口隔离：分层的关键
分层架构光有“层”还不够，还得有“接口”。层与层之间怎么通信？靠接口。接口设计得好不好，直接决定了分层架构的成败。
我见过不少团队，口口声声说分层了，结果HAL层直接暴露了寄存器地址给应用层调用。这叫什么分层？这叫“换了个文件夹放代码”。
接口隔离的核心原则：
- 接口要稳定：一旦定下来，尽量不改。改接口意味着所有上层代码都要跟着改。
- 接口要抽象：不要暴露实现细节。比如“发送数据”这个接口，应用层只管调用，不用管你是用UART还是SPI发的。
- 接口要最小化：只暴露必要的功能，不要什么都往外抛。接口越多，耦合越重。
举个例子：一个LED控制接口，好的设计是 void led_set(uint8_t id, uint8_t state)。应用层传个ID和状态就行。差的设计是 void led_set_gpio_pin_high(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin)——这等于把硬件细节全暴露了。
1.5 任务调度与驱动开发的关系
说到这儿，你可能要问了：分层架构和任务调度、驱动开发有什么关系？
关系大了。你想想看，如果没有分层，你的任务调度代码里可能直接嵌着寄存器操作。任务切换的时候，还得考虑硬件状态保存恢复的问题——那复杂度直接爆炸。
有了分层之后：
- 驱动层负责和硬件打交道，提供最基础的硬件操作接口。
- HAL层把这些接口封装成更通用的API。
- 中间件层（比如RTOS）负责任务调度、同步、通信。
- 应用层只管写业务逻辑，调用中间件和HAL的接口就行。
这样，每一层的职责清晰，开发和调试都变得简单。我在项目中遇到过最爽的一次经历：一个产品需要从FreeRTOS换成RT-Thread，因为分层做得好，只改了中间件层的调度接口封装，应用层一行代码没动。两天搞定移植。
1.6 本章小结
好了，咱们第一讲的内容就这些。总结一下核心要点：
- 嵌入式软件不分层，项目越大越痛苦。
- 分层架构的核心是“各司其职，单向依赖”。
- 接口隔离是分层成功的关键，接口要稳定、抽象、最小化。
- 分层让任务调度和驱动开发各归其位，互不干扰。
下一讲，咱们会深入讨论硬件抽象层（HAL）的设计原则，手把手教你写出真正可移植的驱动接口。到时候我会拿一个实际的UART驱动例子，带你看看好的分层和差的分层到底差在哪里。
今天就到这儿。记住一句话：分层不是银弹，但不分层一定是毒药。