1. 课程导入与学习地图
大家好，我是你们这门课的主讲。在嵌入式这行摸爬滚打了十几年，我见过太多项目从“一个人能搞定”慢慢演变成“一群人改不动”的惨痛案例。今天这第一讲，咱们不急着敲代码，先聊聊一个核心问题：为什么你的嵌入式项目，需要分层架构？
从“能跑就行”到“能改才行”
我记得刚入行那会儿，写单片机程序特别“豪放”。一个 main.c 文件，几千行代码，全局变量满天飞。中断服务函数里直接调延时，外设驱动和业务逻辑揉成一团。那时候项目简单，一个人闷头干，产品也能跑。
但后来项目越来越复杂。一个产品要支持多种传感器，要联网，要OTA升级，还要兼容不同硬件版本。这时候，那种“大泥球”式的代码，就成了噩梦。
为什么会这样？你想想看，当你的LED闪烁逻辑和Wi-Fi重连代码写在同一个函数里，当你的按键扫描和PID控制算法共享同一个全局变量，任何一处修改都可能引发连锁崩溃。测试人员提个bug，你定位问题的时间比修bug的时间还长。
说白了，没有架构的项目，前期走得快，后期寸步难行。
低耦合高内聚：架构设计的“黄金法则”
那怎么解决这个问题？核心就四个字：低耦合，高内聚。
- 高内聚：一个模块只干一件事，并且把它干好。比如，LED驱动模块只管控制GPIO电平，别管什么网络状态。
- 低耦合：模块之间依赖尽量少，接口尽量简单。比如，应用层调用驱动层，只需要一个“开灯”、“关灯”的接口，不需要知道底层用的是STM32还是GD32。
我在项目中遇到过最典型的反面教材：一个同事把NFC读卡逻辑和用户登录逻辑写在同一个文件里。后来要换NFC芯片型号，结果不仅驱动要重写，连带着登录流程也崩了。这就是典型的高耦合——牵一发而动全身。
核心思想： 分层架构的本质，就是通过定义清晰的层级和接口，把“变化”隔离在局部。硬件变了，只改驱动层；业务逻辑变了，只改应用层。互不干扰。
嵌入式分层的“三层结构”
在嵌入式领域，我个人习惯把系统分成三个核心层次。当然，实际项目可以根据需要再细分，但万变不离其宗。
| 层级 | 职责 | 典型内容 | 变化频率 |
|---|---|---|---|
| 应用层 | 业务逻辑、状态机、用户交互 | 任务调度、协议解析、UI逻辑 | 高（需求变更） |
| 中间层 | 抽象接口、协议封装、OS适配 | RTOS封装、文件系统、通信协议栈 | 中（平台迁移） |
| 硬件抽象层 | MCU外设驱动、板级支持 | GPIO、UART、I2C、SPI、定时器 | 低（硬件换型） |
这张表你看懂了吗？越往下越稳定，越往上越易变。 这就是分层的好处：把稳定的和易变的隔离开。
一张图看懂分层架构
下面这张SVG图，是我自己总结的嵌入式分层架构核心逻辑。你可以把它当作这门课的总纲。
我的经验： 刚开始做分层时，别追求一步到位。先画出三层，把每个模块的“接口”定义清楚。接口就是契约，契约稳定了，里面怎么改都行。
避坑指南：分层架构的“三个不要”
讲完了理论，我分享几个实战中容易踩的坑。这些都是我曾经的血泪教训。
- 不要跨层调用。 应用层不要直接操作寄存器，驱动层不要处理业务逻辑。我曾经见过一个项目，应用层代码里直接写
GPIOA->ODR |= 0x01，后来换芯片，改得想哭。 - 不要为了分层而分层。 如果项目就一个LED闪烁，一个按键扫描，硬套三层架构反而增加复杂度。分层是工具，不是目的。
- 不要忽视接口文档。 接口定义好了，一定要写清楚。我见过最坑的：驱动层返回0表示成功，应用层以为0表示失败，查了两天bug。
警告： 分层架构不是银弹。它解决的是“复杂度管理”问题，而不是“性能优化”问题。在资源极度受限的MCU上（比如1KB RAM），过度分层可能导致性能开销。这时候需要权衡，甚至在某些关键路径上“打破分层”。
课程目标与学习路径
这门课的目标很明确：让你从“能写代码”进阶到“能设计代码”。我们不讲虚的，每一章都会落地到具体的代码和项目实战。
学习路径我建议这样走：
- 前5章： 打好架构思维基础，理解分层、模块化、接口设计。
- 第6-15章： 深入每一层的具体实现，从HAL到中间件到应用层，手写代码。
- 第16-25章： 实战项目驱动，把一个完整的物联网终端项目从零分层搭建。
- 第26-30章： 进阶技巧，包括测试、重构、性能优化和文档化。