1、课程导论：为什么低功耗与高实时性总是矛盾的？一个电池供电的IoT传感器实例
各位同学好，我是老张。做嵌入式这行快十五年了，今天咱们来聊聊一个让无数工程师头疼的问题——低功耗和高实时性，这俩家伙怎么就那么不对付？
先别急着翻书，咱们从一个真实的场景说起。
1.1 一个电池供电的IoT传感器，到底有多难？
想象一下，你设计了一个温度传感器，装在野外的输油管道上。要求很简单：
- 一节AA电池，撑两年
- 温度超过80度，50毫秒内必须报警
听起来不难？我当年第一次接这种项目时，也觉得不就是个测温嘛。结果一算账，傻眼了。
咱们来算笔账：
| 工作模式 | 电流消耗 | 时间占比 |
|---|---|---|
| 运行模式（采集+处理） | 10 mA | 0.1% |
| 休眠模式 | 5 μA | 99.9% |
表面上看，99.9%的时间都在睡觉，功耗应该很低对吧？
但问题来了——实时性要求。50毫秒内响应，意味着MCU不能睡得太死。你想想看，如果MCU进入深度睡眠，醒来需要10毫秒，再初始化外设又花5毫秒，留给你的处理时间就只剩35毫秒了。万一这时候温度刚好在临界点附近跳动，你连滤波的时间都不够。
核心矛盾就在这里：低功耗要求MCU尽量睡觉，高实时性要求MCU随时待命。这两个需求，本质上是在争夺同一个资源——时间。
1.2 为什么它们天生就是死对头？
说白了，低功耗设计的核心思路就一条：没事别干活，干活要快。
但高实时系统恰恰相反：随时准备干活，而且不能耽误。
我给大家拆解一下，这矛盾具体体现在三个层面：
1.2.1 时钟频率的博弈
功耗和频率的关系，基本是线性的。频率翻倍，功耗差不多也翻倍。但实时性呢？频率越高，响应越快。你选哪个？
我在项目中遇到过这种情况：为了省电，把主频从48MHz降到8MHz，结果一个中断服务程序跑了2毫秒，把整个系统的调度都打乱了。后来我学乖了，动态调频才是正道——平时跑低频，关键时刻提频。
1.2.2 休眠深度的取舍
MCU的休眠模式，一般分好几级：
- 浅睡（比如STOP模式）：唤醒快（几微秒），但功耗高（几十μA）
- 深睡（比如STANDBY模式）：功耗极低（几μA），但唤醒慢（几毫秒）
你想想看，如果要求50毫秒响应，你敢用深睡吗？万一唤醒就花了10毫秒，剩下40毫秒够干啥？
我的经验：对于实时性要求高的场景，别用最深的休眠模式。宁可多花几μA，也要保证唤醒时间在可接受范围内。我曾经在一个项目中，为了省那2μA，选了最深休眠，结果产品在低温环境下唤醒失败，整批货都召回了。
1.2.3 外设电源管理的麻烦
传感器、无线模块这些外设，才是真正的电老虎。一个LoRa模块发射时能到100mA，比MCU本身高两个数量级。
但实时性要求你随时能采集数据。外设不能断电，一断电再上电，初始化时间可能比MCU唤醒还长。
怎么办？我个人的习惯是：外设分两级供电。关键传感器常供电，非关键的用MOS管控制。这样既保证了实时性，又不会浪费电。
1.3 一个真实的案例：我踩过的坑
2018年，我做了一个智能水表项目。要求是：电池用5年，阀门响应时间小于100毫秒。
一开始，我按照常规思路：MCU大部分时间休眠，定时醒来采集流量数据。阀门控制用外部中断唤醒。
结果测试时发现一个问题：阀门动作时，电机启动电流会拉低电池电压，导致MCU复位。我加了电容滤波，但电容充电又需要时间，影响了响应速度。
折腾了两周，最后方案是这样的：
- MCU平时跑在2MHz，功耗约1.5mA
- 阀门动作前，提前把主频升到16MHz
- 用独立的DC-DC给电机供电，和MCU电源隔离
最终，功耗只增加了3%，但响应时间从120毫秒降到了45毫秒。
注意：低功耗和高实时性不是非此即彼。很多时候，问题出在架构设计上，而不是某个具体参数上。别一上来就盯着数据手册看功耗数字，先想清楚你的系统到底需要什么样的实时性。
1.4 这门课能给你什么？
说了这么多，其实就是想告诉大家：低功耗和高实时性，不是不能共存，而是需要技巧。
这门课里，我会分享：
- 如何选择合适的MCU和休眠模式
- 动态电压频率调节（DVFS）的实战技巧
- 中断优先级和任务调度的优化方法
- 外设电源管理的几种实用电路
- 以及……我这些年踩过的坑和填坑经验
嗯，咱们不聊虚的。每一章都会有具体的代码示例和电路图，你拿回去就能用。
下一章，咱们先从MCU的休眠模式讲起。我会告诉你，为什么有些休眠模式看起来省电，实际上却是坑。