1. 课程导论与嵌入式系统全景图
各位同学好，我是你们这门课的老张。做了十多年嵌入式，从8位单片机一路折腾到多核ARM，踩过的坑比走过的路还多。今天咱们先不急着敲代码，把整个嵌入式系统的地图摊开看看——你心里有了全景图，后面选型、调试才不会迷路。
什么是嵌入式系统？
说白了，嵌入式系统就是“专门干一件事的计算机”。你的手机不是嵌入式，但手机里的蓝牙芯片是；你的电脑不是，但电脑键盘里的主控是。
我习惯用一个公式来定义它：
嵌入式系统 = 专用硬件 + 固化软件 + 特定功能
它藏在设备内部，用户通常看不见，也不需要看见。
举个例子。你家的智能电饭煲，按一下“煮饭”，它就开始检测温度、控制加热、计算时间。用户只关心饭熟没熟，没人关心里面跑的是FreeRTOS还是裸机循环。这就是嵌入式——功能固定、资源受限、实时性要求高。
我早年做过一个车载OBD项目，客户说“这不就是个带CAN的STM32嘛”。结果呢？电磁兼容没做好，车一启动就死机。嗯，嵌入式系统的边界往往不在芯片本身，而在它和物理世界的接口上。
硬件选型的核心要素
很多新手一上来就问：“哪个芯片性能最强？” 我通常会反问：“你的产品要卖多少钱？电池能用多久？工作温度多少？”
选型不是选最强的，而是选最合适的。我个人习惯按下面这张表来打分：
| 维度 | 关键问题 | 常见陷阱 |
|---|---|---|
| 性能 | 主频、MIPS、RAM/Flash够用吗？ | 余量留太大，成本失控 |
| 功耗 | 休眠电流多少？唤醒时间多长？ | 只看运行功耗，忽略漏电流 |
| 外设 | 需要几路UART/SPI/I2C？ADC精度？ | 外设复用冲突，PCB改版 |
| 成本 | BOM总价、供货周期、封装大小 | 只算芯片价，忽略外围器件 |
| 生态 | IDE、SDK、例程、社区活跃度 | 选冷门芯片，遇到问题没人问 |
| 环境 | 温度范围、湿度、振动、EMC | 工业级当商业级用，现场批量挂 |
我曾经踩过的坑：一个温控器项目，选了某款性价比极高的国产MCU。样机跑得挺好，小批量也没问题。结果夏天高温天，现场30台设备陆续死机。查了三天，发现芯片结温超过85°C后内部LDO会周期性复位。嗯，从此以后，选型必看结温范围，绝不只看商业级标称。
还有一个容易被忽略的点：供货稳定性。2021年的芯片缺货潮，多少项目因为一颗电容、一个MOS管停产而被迫改板？我建议选型时至少准备两个pin-to-pin兼容的备选方案，哪怕现在用不上。
软件分层架构概览
嵌入式软件最怕什么？最怕“一锅粥”。所有逻辑揉在main函数里，中断里做延时，定时器里跑算法。这种代码，三个月后连你自己都看不懂。
我推荐的分层架构，从上到下大概是这样的：
┌─────────────────────────────────┐
│ 应用层 (App) │ ← 业务逻辑、状态机、协议解析
├─────────────────────────────────┤
│ 中间件层 (Middleware) │ ← 文件系统、TCP/IP、GUI、RTOS
├─────────────────────────────────┤
│ 驱动抽象层 (HAL) │ ← 统一API，屏蔽硬件差异
├─────────────────────────────────┤
│ 芯片外设层 (LL/Reg) │ ← 寄存器操作、中断向量、DMA
└─────────────────────────────────┘
每一层只和相邻层通信。应用层不直接写寄存器，驱动层不关心业务逻辑。这样做的好处是什么？可移植、可测试、可分工。
举个例子。你换了一颗MCU，只需要重写最下面两层，上面的业务代码几乎不用动。我在一个物联网网关项目里，用这套架构把代码从STM32F4无缝迁移到了GD32F4，只花了两天时间。
一个小建议：哪怕你的项目很小，也请至少把硬件操作和业务逻辑分开。哪怕用个简单的函数指针表，也比直接操作寄存器强。相信我，后期调试时你会感谢这个决定的。
调试与故障定位的全局方法论
调试不是“瞎试”，而是有章法的推理过程。我把它总结成五个步骤：
- 复现 —— 稳定复现问题是第一步。不能复现的bug，基本没法修。
- 隔离 —— 是硬件问题还是软件问题？是这一层还是那一层？用二分法缩小范围。
- 测量 —— 示波器、逻辑分析仪、串口打印、JTAG断点。用数据说话。
- 假设 —— 根据现象提出一个合理的根因假设。
- 验证 —— 修改代码或电路，看现象是否消失。一次只改一个变量。
你想想看，很多时候我们卡住，是因为跳过了“隔离”这一步，直接去猜根因。结果改了一堆代码，问题还在，反而引入了新bug。
下面这张图，是我自己一直在用的调试决策流程：
这个流程看起来简单，但真正做到的人不多。为什么？因为人天生喜欢“猜”。看到现象，脑子里立刻蹦出一个原因，然后就去改代码。结果呢？十有八九猜错。
我的习惯：每次调试前，先在纸上写下“现象”、“可能原因”、“验证方法”三栏。哪怕只写三分钟，也能帮你理清思路。这招帮我省了无数通宵。
还有一个关键点：善用工具。串口打印是最基础的，但别只靠它。逻辑分析仪看时序、示波器看信号质量、静态分析工具查代码缺陷——每样工具都有它的用武之地。我在项目中遇到过一个问题，串口打印一切正常，但设备就是随机死机。最后用示波器抓到电源纹波在WiFi发射瞬间跌了300mV，这才找到根因。如果只靠打印，这个bug永远查不出来。
好了，这一章我们搭好了整个课程的地图。你知道了嵌入式系统是什么，选型要看哪些维度，软件怎么分层，调试该走什么流程。后面的每一章，都会在这张地图上展开具体的实战细节。