1. MCU编程概述：嵌入式系统简介、MCU选型考量、C语言在嵌入式中的角色、高效编程的意义
1.1 嵌入式系统到底是什么？
说实话，我入行这么多年，每次跟非技术朋友解释「嵌入式系统」，都觉得挺费劲的。你想想看，你手里的智能手表、家里的空调遥控器、汽车里的ABS控制器——这些东西里面都藏着一个微型计算机，这就是嵌入式系统。
它跟咱们桌上的电脑不一样。电脑是通用的，你可以装游戏、写文档、看视频。但嵌入式系统是「专用」的。它只干一件事，而且得干得漂亮、干得省电、干得稳定。我在一个智能家居项目里遇到过，一个温控器因为代码里一个毫秒级的延时没处理好，导致继电器频繁通断，硬是把一个好好的产品搞成了「电蚊拍」——嗯，客户投诉说晚上能听到啪啪响。
嵌入式系统的核心组成其实不复杂：
- 处理器（MCU/MPU）：大脑，负责运算和控制
- 存储器（Flash/RAM）：存代码和临时数据
- 外设（GPIO/UART/SPI/I2C等）：跟外界打交道的接口
- 传感器/执行器：感知物理世界，或者做出动作
- 软件（固件）：灵魂，决定了硬件怎么工作
核心要点：嵌入式系统是「软硬结合」的艺术。你写的每一行C代码，最终都会变成引脚上的电平变化、总线上的数据流、或者电机的一圈转动。这种「代码即物理」的感觉，是嵌入式开发最迷人的地方。
1.2 MCU选型：别光看主频和价格
很多新手问我：「老师，选MCU是不是主频越高越好？」我每次都会反问一句：「你开跑车去买菜，图啥？」
选MCU，说白了就是找平衡。我在一个工业控制项目里吃过亏——当时图便宜选了一款8位MCU，结果项目做到一半发现RAM不够用，外设也不够灵活，最后只能换芯片，整个软件架构推倒重来。那次教训让我养成了一个习惯：选型阶段至少留出30%的余量。
我个人习惯从这几个维度来考量：
| 考量维度 | 关键问题 | 我的经验 |
|---|---|---|
| 处理性能 | 需要多少MIPS？实时性要求多高？ | 别只看主频，要看实际算力。有些Cortex-M0跑72MHz比某些8位机跑20MHz还快 |
| 存储资源 | 代码量多大？需要多少RAM？ | Flash留50%余量，RAM留30%。你永远不知道后期会加什么功能 |
| 外设需求 | 需要几个UART？要不要DMA？ | 我曾经为了省5毛钱选了个没有DMA的芯片，结果CPU占用率飙到80% |
| 功耗要求 | 电池供电还是市电？待机电流多少？ | 低功耗设计要从选型开始，别指望后期靠软件「省」回来 |
| 开发生态 | IDE好不好用？库函数完善吗？社区活跃吗？ | ST的HAL库虽然被吐槽，但人家文档全、例程多，这就是生态优势 |
| 成本与供货 | 单价多少？交期稳定吗？ | 2021年芯片缺货时，我亲眼看着某款MCU从8块涨到80块 |
我的建议：选型时先画一张「外设需求清单」，把每个外设需要的引脚、中断、DMA通道都列出来。然后拿着这张表去对比芯片手册。别嫌麻烦——这一步省下的时间，后面十倍百倍地还给你。
1.3 C语言在嵌入式中的角色：为什么是它？
你可能会问：「现在Python、Rust这么火，为什么嵌入式还在用C？」
原因其实很简单。C语言是唯一一种既能让你直接操作寄存器，又能写出可移植代码的语言。它不像汇编那样跟硬件绑死，也不像高级语言那样隔着一层厚厚的运行时环境。
我在一个物联网项目里试过用MicroPython——开发确实快，但到了优化阶段就傻眼了。一个简单的GPIO翻转，Python要经过解释器、字节码、底层驱动好几层，延时完全不可控。最后只能把关键部分用C重写，混着用。
C语言在嵌入式中的角色，我总结为三点：
- 硬件控制者：直接读写寄存器、配置外设、处理中断。这是C的看家本领。
- 性能调优师：通过指针、位操作、内联汇编等手段，榨干MCU的每一滴性能。
- 可移植桥梁：只要遵循一定的编码规范，C代码可以在ARM、RISC-V、8051之间轻松迁移。
一句话总结：在嵌入式领域，C语言不是「最好的语言」，但它是「最合适的语言」。它让你离硬件足够近，又离抽象足够近——这种平衡，目前还没有其他语言能完美替代。
1.4 高效编程的意义：不只是「跑得快」
很多人以为高效编程就是让代码跑得快。其实不然。在MCU上，高效编程至少包含三个维度：
- 时间效率：CPU占用率低，响应速度快
- 空间效率：代码体积小，RAM占用少
- 功耗效率：能睡就睡，能省则省
我曾经接手过一个项目，前任工程师用了一堆全局变量和忙等待循环。代码倒是能跑，但CPU占用率常年95%以上，电池两天就没电了。我花了三周时间重构——引入状态机、用定时器代替延时、优化数据结构。结果呢？CPU占用率降到15%，电池续航从2天变成了2周。
这就是高效编程的意义。它不只是技术上的炫技，而是实实在在的产品竞争力。
注意：高效编程不等于「过早优化」。我见过太多人在项目初期就纠结于「这个循环用for还是while更快」，结果架构设计得一塌糊涂。正确的做法是：先让代码正确运行，然后通过性能分析找到瓶颈，最后有针对性地优化。
嗯，说到这儿，我想起一个经典的例子。很多人在写延时函数时喜欢用for(i=0; i<100000; i++)这种空循环。这种做法在低主频MCU上勉强能用，但到了高速MCU上，编译器优化一开，这个循环可能直接被优化掉了——你想要的延时没了，代码直接飞了。
// 不推荐的做法：依赖编译器不优化的空循环
void delay_bad(void) {
volatile uint32_t i;
for(i = 0; i < 100000; i++);
}
// 推荐的做法：使用硬件定时器
void delay_good(uint32_t ms) {
// 假设TIMER已配置为1ms中断一次
uint32_t target = timer_get_tick() + ms;
while(timer_get_tick() < target);
}你看，同样是延时，用硬件定时器不仅更精确，而且CPU可以在等待期间进入低功耗模式。这就是高效编程的思维——不是跟编译器较劲，而是利用硬件特性来解决问题。
1.5 这门课你会学到什么？
这门课不是教你怎么写C语言——我假设你已经会了。这门课要教的是：在资源受限的MCU上，怎么把C语言用到极致。
我们会从位操作、指针、内存管理这些基础讲起，然后深入到中断优化、DMA使用、RTOS应用、低功耗设计等进阶话题。每一章都会有我在实际项目中踩过的坑、总结的经验。
你想想看，同样的功能，别人用100KB Flash实现，你只用50KB；别人CPU占用率80%，你只用20%；别人电池用一周，你用一个月——这就是这门课的价值。
给新手的建议：如果你刚开始接触MCU开发，别急着看那些花哨的优化技巧。先把基础打牢——理解MCU的启动流程、学会看数据手册、掌握调试工具的使用。这些基本功，比任何「一招鲜」都重要。
好了，第一章就到这里。下一章我们会深入C语言在MCU上的内存布局——说白了，就是你的代码和数据到底是怎么在芯片里安家的。到时候见。