课程导论与硬件选型：IoT低功耗通信协议栈全景图
各位同学好，我是你们这门课的老周。做了十几年嵌入式，从最早的8051玩到现在，踩过的坑比走过的路还多。今天咱们先不急着写代码，把地基打牢。
IoT低功耗通信，说白了就是让设备在电池里活得更久，同时把数据传出去。你想想看，一个传感器节点装在山顶，没人给它换电池，一待就是三五年。这背后靠的是什么？靠的是协议栈的精打细算，还有硬件选型时的火眼金睛。
核心观点： 低功耗通信不是单一技术，而是一套从芯片、协议栈到应用层的系统工程。选错一个环节，后面全白干。
1.1 IoT低功耗通信协议栈全景图
先给大家画个全景图。目前主流的低功耗无线协议栈，我按应用场景分了四大类：
- 短距、低功耗、自组网： Zigbee、BLE Mesh、Thread。适合智能家居、楼宇自动化。
- 长距、超低功耗、星型： LoRaWAN、NB-IoT。适合广域传感器网络、资产追踪。
- 点对点、低延迟： 私有2.4G、BLE（非Mesh模式）。适合遥控器、键鼠、可穿戴。
- 高速、低功耗： Wi-Fi HaLow（802.11ah）。适合视频监控、工业网关。
我个人习惯把协议栈分成三层来看：物理层（PHY）、MAC层、网络/应用层。物理层决定你能传多远、功耗基线是多少；MAC层决定信道怎么用、碰撞怎么处理；网络层决定拓扑结构——是星型、树型还是Mesh。
举个例子，Zigbee和Thread都跑在802.15.4物理层上，但MAC层和网络层完全不同。Zigbee用树型路由，Thread用IPv6 Mesh。我在项目中遇到过客户非要拿Zigbee做大规模Mesh，结果网络延迟高得离谱。后来换了Thread，问题迎刃而解。所以，选协议栈不能只看物理层，得看上层协议是否匹配你的场景。
1.2 主流MCU平台对比
选MCU就像选兵器，得趁手。目前市面上做低功耗IoT的主流平台，我重点讲三个：STM32U5、EFR32、DA16200。它们代表了三种不同的设计哲学。
| 对比维度 | STM32U5 | EFR32（Silicon Labs） | DA16200（Dialog） |
|---|---|---|---|
| 内核架构 | ARM Cortex-M33 | ARM Cortex-M4/M33 | ARM Cortex-M4F + Wi-Fi MAC |
| 典型功耗（待机） | ~100 nA（Shutdown模式） | ~50 nA（EM4模式） | ~1.2 µA（DTIM10休眠） |
| 无线能力 | 无内置射频（需外挂） | 集成Sub-1G/2.4G多协议 | 集成Wi-Fi 802.11b/g/n |
| 典型应用 | 高端传感器、医疗设备 | 智能家居、Zigbee/Thread网关 | 低功耗Wi-Fi传感器、门锁 |
| 开发难度 | 中等（HAL/LL库） | 中等（Simplicity Studio） | 较低（FreeRTOS + SDK） |
| 成本（批量） | ~$3-5 | ~$2-4（含射频） | ~$4-6（含Wi-Fi） |
我个人的经验是：
- STM32U5 适合做纯MCU控制，外挂LoRa或BLE模块。它的优势是生态好、文档全、低功耗模式丰富。但要注意，它没有内置射频，你得额外花钱买模块，而且射频调试是个坑。
- EFR32 是我做Zigbee和Thread项目的首选。它把MCU和射频集成在一个芯片里，功耗控制非常精细。我记得有一次做智能灯控，用EFR32的EM4模式，待机电流只有50nA，一节CR2032电池撑了两年多。
- DA16200 是Wi-Fi低功耗的另类。它把Wi-Fi MAC层做进了硬件，支持DTIM休眠，待机功耗能做到1µA级别。但它的缺点是Wi-Fi协议栈比较重，OTA升级时容易出问题。我在项目中遇到过DA16200在弱信号下反复重连，功耗反而比正常通信还高。
小技巧： 如果你的产品需要同时支持Zigbee和BLE，选EFR32MG系列，它支持动态多协议切换。我做过一个网关，白天跑Zigbee，晚上切BLE做室内定位，一颗芯片搞定。
1.3 硬件选型避坑指南
这部分是我最想说的。选型时踩的坑，往往比写代码时踩的坑更致命。我曾经因为选错一个晶振，导致整批产品在高温下无法联网，损失惨重。下面我列几个最常见的坑：
坑1：只看待机功耗，忽略平均功耗
很多芯片标称待机电流几十nA，但实际工作时电流可能飙到几十mA。如果你的设备每小时只发一次数据，待机功耗确实重要；但如果设备需要频繁收发（比如每10秒一次），平均功耗才是关键。我建议用公式算一下：
别被厂商的「超低待机」忽悠了。
很多芯片标称待机电流几十nA，但实际工作时电流可能飙到几十mA。如果你的设备每小时只发一次数据，待机功耗确实重要；但如果设备需要频繁收发（比如每10秒一次），平均功耗才是关键。我建议用公式算一下：
平均功耗 = (待机电流 × 待机时间 + 工作电流 × 工作时间) / 总时间别被厂商的「超低待机」忽悠了。
坑2：射频匹配电路不是随便画的
我见过太多工程师直接抄参考设计的射频匹配电路，结果天线效率只有20%。射频匹配需要根据实际PCB板层、天线类型、外壳材质来调。尤其是Sub-1G频段，PCB走线长度、过孔数量都会影响阻抗。我建议：
我见过太多工程师直接抄参考设计的射频匹配电路，结果天线效率只有20%。射频匹配需要根据实际PCB板层、天线类型、外壳材质来调。尤其是Sub-1G频段，PCB走线长度、过孔数量都会影响阻抗。我建议：
- 第一次打板时，预留π型匹配网络的位置
- 用网络分析仪（VNA）实测S11参数
- 天线周围不要铺铜，留出净空区
坑3：电源纹波是低功耗的隐形杀手
射频发射时瞬间电流可能达到几百mA，如果电源纹波太大，会导致射频前端工作不稳定，发射功率下降，甚至掉线。我曾经用LDO给EFR32供电，结果发现发射时电压跌落200mV，通信距离直接减半。后来换成DC-DC + 大电容，问题解决。
经验值： 射频供电纹波控制在50mV以内，电容至少加100µF + 0.1µF组合。
射频发射时瞬间电流可能达到几百mA，如果电源纹波太大，会导致射频前端工作不稳定，发射功率下降，甚至掉线。我曾经用LDO给EFR32供电，结果发现发射时电压跌落200mV，通信距离直接减半。后来换成DC-DC + 大电容，问题解决。
经验值： 射频供电纹波控制在50mV以内，电容至少加100µF + 0.1µF组合。
坑4：协议栈版本兼容性
选MCU时，不光看硬件，还要看协议栈的成熟度。有些芯片厂商的协议栈更新频繁，API不兼容，升级一次要改大量代码。我建议：
选MCU时，不光看硬件，还要看协议栈的成熟度。有些芯片厂商的协议栈更新频繁，API不兼容，升级一次要改大量代码。我建议：
- 优先选Zigbee 3.0、Thread 1.3等成熟标准协议栈
- 确认厂商提供长期维护承诺
- 不要用beta版协议栈做量产
避坑总结： 硬件选型不是看参数表，而是看实际场景。先明确你的通信距离、数据量、电池寿命、成本预算，再反过来选芯片。我习惯先做一份「需求-参数」对照表，把每个维度的底线标出来，再去找芯片。这样不容易被厂商的营销话术带偏。