1. 课程导论：为什么需要分层架构？裸机开发的痛点与分层思想
各位同学好，我是你们这门课的老周。做了十几年嵌入式，从8位机一路折腾到现在的ARM Cortex-M，踩过的坑比吃过的盐还多。今天咱们开篇第一讲，不急着写代码，先聊聊一个根本问题：为什么你的裸机代码越写越痛苦？
说实话，我刚入行那会儿，写STM32程序就是典型的“一把梭”。main函数里从头写到尾，GPIO初始化、定时器配置、中断服务、业务逻辑全揉在一起。项目小的时候还行，一旦功能多起来，那代码简直没法看。改一个LED闪烁频率，能牵扯出三个bug。你想想看，这滋味好不好受？
裸机开发的真实痛点
咱们先列一列，裸机开发中那些让人抓狂的典型场景：
- 代码耦合严重：硬件操作和业务逻辑混在一起，换个引脚就要改好几处
- 可移植性差：从STM32F103换到F407，几乎要重写底层驱动
- 调试困难：一个bug定位半天，发现是某个全局变量被意外修改了
- 团队协作混乱：A写的模块和B写的模块互相依赖，谁都不敢动别人的代码
- 复用率极低：上个项目的代码，下个项目基本没法直接用
核心矛盾：裸机开发本身并不复杂，复杂的是没有规则的开发方式。当代码量超过3000行，没有分层架构的项目，维护成本会呈指数级上升。
我记得有一次，帮一个客户排查一个智能家居网关的问题。他们的工程师写了大概8000行的裸机代码，全部在一个.c文件里。我打开那个文件的时候，手都在抖。最后花了整整三天，才理清楚一个按键中断的处理流程。嗯，从那以后，我给自己定了个规矩：任何超过1000行的项目，必须分层。
分层思想：把复杂问题拆解
分层架构不是什么新鲜概念。说白了，就是各司其职，互不干扰。就像一家公司，有前台、有研发、有财务，各干各的活，通过标准接口沟通。
在嵌入式软件里，我们通常把代码分成这几层：
| 层级 | 职责 | 典型内容 | 依赖关系 |
|---|---|---|---|
| 应用层 | 业务逻辑、状态机、用户交互 | 按键处理、数据显示、通信协议解析 | 只调用抽象接口层 |
| 抽象接口层 | 硬件无关的API封装 | osDelay()、uartSend()、i2cRead() | 调用驱动层 |
| 驱动层 | 直接操作寄存器、外设配置 | GPIO_SetBits、TIM_Cmd、USART_SendData | 依赖HAL/LL库 |
| 硬件层 | 芯片本身、外设寄存器 | STM32F103数据手册、参考手册 | 物理硬件 |
你可能会问：多了一层抽象，会不会影响性能？我的回答是：会，但微乎其微。一个函数调用的开销，在72MHz的主频下，也就是几十个纳秒的事。而它带来的可维护性提升，是数量级的。
我的个人习惯：在驱动层和抽象接口层之间，我会加一个薄薄的“适配层”。这样换芯片的时候，只需要重写驱动层和适配层，上层的业务代码一行都不用改。这个习惯帮我省了至少三个月的返工时间。
分层架构的核心收益
咱们用实际数据说话。这是我之前一个温控器项目的对比：
- 不分层：代码量4500行，修改一个温度采样周期需要改5个文件，测试回归耗时2天
- 分层后：代码量5200行（多了700行接口代码），修改同样功能只需改1个文件，测试回归耗时4小时
看到了吗？代码量虽然增加了15%，但维护效率提升了6倍。这笔账，怎么算都划算。
一张图看懂分层架构
下面这张图，是我每次给团队新人培训时必画的。它清晰地展示了各层之间的调用关系和依赖方向：
我曾经犯过的错：在应用层直接操作寄存器。当时觉得“就改一个位，没必要封装”，结果换芯片的时候，那个寄存器地址变了，找了整整一天才定位到问题。从那以后，我严格执行上层绝不直接触碰硬件的原则。
什么时候必须分层？
不是所有项目都需要分层。我个人的判断标准是这样的：
- 代码量 < 500行：单文件搞定，分层反而增加复杂度
- 500 ~ 2000行：建议简单分层，至少把硬件操作和业务逻辑分开
- > 2000行：必须分层，否则后期维护会让你怀疑人生
- 多人协作：不管多少行，必须分层，这是团队协作的基本契约
这门课里，我会带着大家从零开始，一步步搭建一个完整的STM32裸机分层架构。咱们不搞花架子，每一层都手写代码，每一个接口都经过实际验证。你跟着走完这30章，以后写裸机项目，心里就有谱了。