1. 课程导论：为什么需要分层架构？从裸机开发到分层设计的思维转变

1.1 一个让我翻车的项目

先讲个真事。几年前我接手过一个智能家居网关项目，代码量大概两万行，全部写在 main.c 里。你想想看，两万行，一个文件。当时团队觉得「单片机嘛，跑个裸机就够了，搞什么架构？」

结果呢？

• 改一个 LED 闪烁频率，要翻遍整个文件找 GPIO 操作
• 换了一颗 Wi-Fi 模块，所有网络相关代码重写
• 新同事入职两周，连编译都过不了

最要命的是，产品上市后客户反馈了一个 Bug——按键偶尔无响应。我查了三天，最后发现是定时器中断里调了一个阻塞式的 I²C 读取函数。嗯，这种问题在裸机大循环里太常见了。

那次之后我彻底想明白一件事：单片机的代码量一旦超过 5000 行，没有分层架构就是在给自己挖坑。

1.2 裸机开发的「三座大山」

很多工程师觉得裸机开发简单直接，确实，写个流水灯、读个按键，main 函数里一个 while(1) 搞定。但项目一复杂，问题就来了。

痛点	具体表现	后果
耦合严重	业务逻辑和硬件操作混在一起	换 MCU 或外设，代码几乎重写
可读性差	全局变量满天飞，函数动辄几百行	自己写的代码，三个月后也看不懂
调试困难	Bug 定位靠猜，改一处崩一片	项目延期、加班、背锅

我见过最夸张的一个项目，工程师为了修一个按键抖动问题，在中断里加了 50ms 的 delay。结果整个系统的实时性全毁了。为什么？因为没有把「按键检测」和「业务处理」分开。

1.3 分层架构到底在分什么？

说白了，分层就是把代码按「职责」拆开。每一层只关心自己的事，层与层之间通过接口通信。

我习惯把单片机软件分成三层：

• 硬件抽象层（HAL）：直接操作寄存器，封装 MCU 和外设的底层驱动
• 中间层（Middleware）：协议栈、算法、数据缓冲等通用模块
• 应用层（Application）：业务逻辑、状态机、用户交互

你想想看，如果哪天要换 MCU，只需要重写 HAL 层，应用层代码几乎不用动。这就是分层最大的价值——隔离变化。

1.4 从裸机到分层：思维转变的三个关键点

很多工程师不是不会写分层代码，而是思维没转过来。我总结了三个最关键的转变：

1. 从「面向寄存器」到「面向接口」
   以前写代码：GPIOA->ODR |= (1<<5)；现在写代码：led_on()。至于 led_on 内部怎么操作，那是 HAL 层的事。
2. 从「大循环」到「状态机」
   裸机开发最常见的模式是 while(1) 里轮询所有任务。分层之后，每个模块有自己的状态机，主循环只负责调度。
3. 从「全局变量」到「模块封装」
   我以前也喜欢用全局变量，后来发现调试时根本不知道谁改了它。现在每个模块只暴露必要的接口，内部变量用 static 隐藏。

1.5 分层会带来额外开销吗？

这个问题我经常被问到。说实话，会。函数调用多了，代码体积大了，执行效率低了那么一点点。

但你要算一笔账：

• 一个函数调用开销：几十个 CPU 周期
• 一个 Bug 定位时间：几小时到几天
• 一次项目延期损失：几万到几十万

你选哪个？

而且现代 MCU（比如 Cortex-M 系列）性能已经很强了，那点调用开销完全可以忽略。我做过测试，一个三层调用的函数链比裸机写法多花不到 1μs，但代码可维护性提升了不止一个量级。

1.6 本课程能给你什么？

这门课不是讲理论，是讲实战。我会带着你从零开始，把一个裸机项目一步步改成分层架构，再引入状态机设计，最后教你如何高效调试。

章节模块	核心内容	你能学到什么
分层驱动封装	HAL 层设计、接口规范、模块解耦	写出可移植、可复用的驱动代码
状态机设计	有限状态机、事件驱动、状态表	让复杂逻辑变得清晰可控
调试实战	断言、日志、Trace、单元测试	快速定位 Bug，不再靠猜

我会把我在项目中踩过的坑、总结的经验、积累的代码模板，全部拿出来分享。你不需要成为架构大师，但学完这门课，你写出来的代码至少能让三个月后的自己看得懂、改得动。