选型避坑ESP32 vs STM32模组 vs NB-IoT不同场景怎么选专栏第 3 篇这是一篇能帮你在立项阶段省掉两个月返工时间的文章。选错了主控方案后期改起来牵一发而动全身——PCB 要重画固件框架要重写有时候连产品定义都得跟着调整。一个选错芯片的真实代价2021 年我们接了一个户外停车场地磁传感器的项目。甲方要求 3 年免维护电池供电覆盖范围包括地下车库和城市各处停车位。当时团队有人提议用 ESP32理由是「开发快、资料多」。我拦下来了。为什么ESP32 深睡眠电流约 10µA听起来不错。但它每次上报数据都需要重新连 Wi-Fi——扫描、关联、DHCP、TLS 握手一次唤醒周期大约 1~3 秒电流峰值 200mA。按照每 5 分钟上报一次、每次唤醒 2 秒的算法平均电流大约是2.2mA。一节 3000mAh 的锂亚电池理论续航不到 60 天。更致命的是地下车库根本没有 Wi-Fi 信号。最终方案是 STM32L431 BC660KNB-IoT 模组NB-IoT 的 PSM 模式下待机电流 3µA每次唤醒通信约 300ms平均电流 0.015mA同样电池的理论续航超过 20 年。选型阶段的 3 天决策决定了产品能不能活下去。三种方案的本质差异在对比具体参数之前先理解三种方案的「基因」各是什么。ESP32 的基因是「集成」。Wi-Fi BLE 双核 Xtensa 4MB Flash全塞在一颗芯片里开箱即用。它的设计哲学是让你最快速度跑起来一个原型牺牲的是极致的功耗和灵活性。Arduino 生态、ESP-IDF 文档、乐鑫官方社区——新手 3 天能让设备联网这是它最大的优势。STM32 模组的基因是「分离与专业化」。MCU 只跑业务逻辑通信交给专门的模组。这个架构的好处是每个部分都可以独立选型优化MCU 选 STM32L4 超低功耗系列通信模组根据场景换 4G/以太网/LoRa/NB-IoT两者通过 AT 命令或 SPI 接口通信。代价是开发复杂度上升需要写 AT 命令解析、处理模组的各种异常状态、自己做 EMC 测试。NB-IoT 的基因是「极限优化」。它是专门为「低频上报、超长续航、广域部署」场景设计的蜂窝标准。PSM省电模式和 eDRX扩展不连续接收两个机制让模组在不通信时进入接近断电的睡眠状态。运营商网络覆盖你不需要部署网关设备插上 SIM 卡就能接入。代价是带宽极窄单次上行包通常不超过 512 字节不适合任何需要大数据量或低延迟的场景。深入方案一ESP32真正适合 ESP32 的场景ESP32 在以下场景几乎没有竞争对手室内 Wi-Fi 覆盖良好设备靠近 AP常电供电或电池允许每周充电需要 BLE 和 Wi-Fi 并存比如蓝牙配网 Wi-Fi 上报团队嵌入式经验有限需要快速验证产品逻辑原型阶段不确定方向需要快速迭代智能家居设备插座、灯控、传感器集线器、桌面 IoT 设备、工厂内网环境的边缘节点——这些都是 ESP32 的主场。ESP32 的功耗真相很多人看到 ESP32 规格书上「Deep Sleep: 10µA」就以为功耗没问题这是一个非常危险的误读。10µA 只是 MCU 核心在深睡眠时的电流。实际系统还有RTC 域保活约 6µA如果用 RTC 定时唤醒Flash 保持部分 Flash 在 Deep Sleep 时仍有静态电流约 50~100µA取决于 Flash 型号外围电路传感器、电平转换芯片、LED 状态灯如果没关掉都在耗电一个没有仔细优化的 ESP32 系统Deep Sleep 实测电流经常在 200~500µA而不是规格书上的 10µA。我见过一个团队他们测完觉得「10µA 没问题」但实际部署后电池 1 个月就没电了查了一周才发现是 SD 卡模块的上拉电阻在睡眠期间一直拉电流。ESP32 功耗优化的核心原则Deep Sleep 前把所有外设的电源轨关掉用 GPIO 控制 MOS 管切断供电而不是依赖软件 disable。ESP32 开发中最常见的 3 个坑坑 1Wi-Fi 重连时间不稳定。ESP32 连 Wi-Fi 有时候 500ms 搞定有时候要 5 秒取决于信道扫描情况和 AP 响应速度。如果你的业务逻辑假设「连网最多 2 秒」弱信号环境下会频繁超时。解决方案固化信道号和 BSSID跳过扫描阶段连接时间可以缩短到 200ms 以内。wifi_config_tcfg{.sta{.ssidyour_ssid,.passwordyour_pass,.channel6,// 固化信道跳过扫描.bssid_settrue,// 固化 BSSID.bssid{0xAA,0xBB,0xCC,0xDD,0xEE,0xFF},}};坑 2NVS 写入次数限制。ESP32 的 NVS非易失性存储底层是 FlashFlash 的写入次数有限通常 10 万次。如果你每次上报数据都顺手更新一个「上报计数器」到 NVS10 万次很快就耗尽了设备开始出现奇怪的存储错误。解决方案不需要掉电保持的数据放 RAM只把真正需要持久化的配置写 NVS。坑 3TLS 握手内存峰值。ESP-IDF 的 mbedTLS 默认配置下TLS 握手期间内存峰值可达 60~90KB。ESP32 只有 320KB DRAM如果你的应用本身内存用量大TLS 握手时会 OOM 崩溃。解决方案在 menuconfig 里开启CONFIG_MBEDTLS_DYNAMIC_BUFFER握手完成后释放缓冲区可以把内存峰值降到 40KB 左右。深入方案二STM32 通信模组这个方案的适用场景STM32 模组适合以下情况工业现场需要接 RS485/CAN/4-20mA 等工业接口ESP32 支持不好可靠性要求高需要硬件看门狗、工业级温度范围-40℃ ~ 85℃需要深度定制低功耗MCU 和模组分开管理睡眠状态未来需要换通信方式比如从 4G 换 5G只换模组不动 MCU大规模量产需要自建 PCB 控制 BOMESP32 模组形态成本偏高选 STM32 系列的学问STM32 系列型号繁多选错了功耗差距可以有 10 倍以上。一个快速决策框架场景推荐系列典型型号典型 Stop 模式电流普通工业 MCUSTM32F4STM32F407~1mAStop 1低功耗工业STM32L4STM32L432 / L451~400nAStop 2超低功耗传感器STM32L0STM32L031~210nAStop 模式高性能 低功耗STM32U5STM32U575~200nAStop 2对于 IoT 场景STM32L4 或 STM32L0 是首选F4 系列功耗太高除非需要大量浮点运算。模组选型的关键参数通信模组的选型比 MCU 还要复杂因为直接决定了网络覆盖、功耗和流量成本。以下是常见模组的选型参考4G 模组SIM7600、EC21、ML307适合需要较大带宽、实时性要求高的场景。代价是待机功耗 2~5mA 量级电池场景慎用。NB-IoT 模组BC660K、BC26、M5311适合低频上报、超长续航。BC660K 是目前主流PSM 模式下 3µA价格约 ¥20~30。以太网模块W5500、ENC28J60工厂内网场景有线连接最可靠没有无线的信号问题但需要布线。LoRa 模组SX1276、LLCC68私有网络需要自建网关适合园区内部大量传感器节点的低成本部署。AT 命令交互的工程规范STM32 和通信模组通过 UART 发 AT 命令通信。这里有一套工程规范不遵守的话调试起来会很痛苦// 规范的 AT 命令发送与响应解析框架typedefenum{AT_OK0,AT_ERROR,AT_TIMEOUT,}AT_Result;AT_Resultat_send_cmd(constchar*cmd,constchar*expected_resp,uint32_ttimeout_ms){// 1. 清空 RX 缓冲区重要防止上一条命令的残留响应干扰uart_flush_rx();// 2. 发送命令带 \r\n 结尾uart_write(cmd,strlen(cmd));uart_write(\r\n,2);// 3. 等待响应超时处理uint32_tstartsystick_ms();while(systick_ms()-starttimeout_ms){if(uart_recv_contains(expected_resp))returnAT_OK;if(uart_recv_contains(ERROR))returnAT_ERROR;delay_ms(10);}returnAT_TIMEOUT;}// 使用示例初始化 NB-IoT 模组voidnb_init(void){AT_Result r;rat_send_cmd(AT,OK,1000);// 基础通信测试if(r!AT_OK){/* 模组未响应检查硬件 */return;}at_send_cmd(ATCFUN1,OK,5000);// 开启全功能at_send_cmd(ATCEREG1,OK,1000);// 开启网络注册上报// 等待入网最多 60 秒uint32_tstartsystick_ms();while(systick_ms()-start60000){at_send_cmd(ATCEREG?,CEREG: 1,1,1000);// 1,1 表示已注册if(/* 解析结果已注册 */)break;delay_ms(2000);}}最重要的一条每个 AT 命令都必须有超时处理和重试逻辑。模组有时候会因为信号弱、网络拥塞等原因不响应没有超时处理的代码在生产环境会直接死在那里。深入方案三NB-IoT真正理解 PSM 和 eDRXNB-IoT 的低功耗秘密在两个机制很多人只知道名字不知道原理导致配置错了还不知道。PSMPower Saving Mode省电模式设备向基站申请一个 TAU 周期T3412 定时器通常 1 小时~24 小时可配在这个周期内设备大部分时间完全关闭射频只在需要上报时唤醒发完数据等一个 Active Time 窗口T3324 定时器通常 2~30 秒接收下行消息然后重新进入 PSM。// 配置 PSMTAU 1 小时Active Time 10 秒// T3412 格式5位单位 3位值见 3GPP TS 24.008 Table 10.5.163a// 00100001 单位1小时 × 1 1小时// T3324 格式同上// 00000101 单位2秒 × 5 10秒at_send_cmd(ATCPSMS1,,,\00100001\,\00000101\,OK,1000);eDRXExtended Discontinuous Reception扩展不连续接收比 PSM 更灵活设备在 eDRX 周期内定期醒来「听」一下有没有下行消息周期可以设到 5 分钟~40 分钟。eDRX 比 PSM 功耗高但下行延迟更低——如果你需要云端能相对及时地推消息给设备eDRX 比 PSM 更合适。PSM 的最大坑下行延迟。设备进入 PSM 后云端推下来的消息要等到设备下次主动唤醒才能收到这个延迟可能是几小时。如果你的场景需要云端实时控制设备比如开关阀门PSM 完全不适合。NB-IoT 天然适合「设备主动上报、云端被动接收」的单向模型双向实时控制不是它的强项。NB-IoT 的 MQTT 特殊性NB-IoT 上跑 MQTT 有几个和 Wi-Fi 环境不同的地方必须特别处理心跳周期要配合 PSM。MQTT 的 keepalive 时间必须大于 PSM 的 TAU 周期否则 Broker 会因为心跳超时把连接断掉。但 PSM 期间 TCP 连接本来就已经断了所以每次唤醒后要重新建立 MQTT 连接。这意味着 NB-IoT 场景下MQTT 重连频率高、每次重连的 TLS 握手开销需要纳入功耗预算。包大小严格控制。NB-IoT 单帧最大传输单元约 1280 字节MQTT payload 建议控制在 512 字节以内。数据格式推荐用 CBOR 替代 JSON——相同数据量CBOR 编码通常比 JSON 小 30~50%在低带宽场景意义显著。// JSON37字节{t:26.5,h:58.2,b:87}// CBOR 等价约 15 字节节省 60%// 83 F9 43 90 F9 44 66 18 57// 使用 TinyCBOR 库编码入网时间纳入功耗预算。NB-IoT 首次入网Attach可能需要 10~60 秒这段时间射频全开是功耗最高的阶段。优化策略每次 PSM 唤醒后不重新 Attach而是利用之前保存的 eDRX/PSM 上下文直接恢复入网时间可以缩短到 2~5 秒部分运营商网络支持。选型决策树把上面的内容浓缩成一棵决策树供立项时快速参考设备需要部署在室外或没有 Wi-Fi ├─ 是 → 需要双向实时控制延迟 1 秒 │ ├─ 是 → STM32 4G 模组 │ └─ 否 → 上报频率高于每小时一次 │ ├─ 是 → STM32 4G 模组 │ └─ 否 → NB-IoT首选 └─ 否 → 电池供电且需要超过 1 年续航 ├─ 是 → NB-IoT室内 NB-IoT 穿墙能力比 Wi-Fi 强 └─ 否 → 团队嵌入式经验少或原型阶段 ├─ 是 → ESP32 └─ 否 → 需要工业接口RS485/CAN或大规模量产 ├─ 是 → STM32 模组 └─ 否 → ESP32简单场景首选三种方案的切换成本有一个问题很多工程师立项时没有想清楚如果选错了改方案有多贵从 ESP32 迁移到 STM32 模组固件几乎全部重写不同 SDK、不同 HAL硬件 PCB 要重新设计预计 1~2 个月工作量。从 STM32 Wi-Fi 模组换成 STM32 NB-IoT 模组硬件改动相对小模组接口类似固件的 AT 命令层和网络配置要重写大约 2~4 周。从 NB-IoT 换回 Wi-Fi比如觉得带宽不够硬件和固件都要重来同时意味着产品定义变了需要网络覆盖要求降低可能连部署方案都要重设计。结论越早想清楚越便宜。选型评审不是形式是真实的技术决策。一个被忽视的维度运维成本大多数选型讨论只看 BOM 成本但运维成本往往是 BOM 的 10 倍以上。NB-IoT 的 SIM 卡流量费按照每台设备每月上报 1000 条数据、每条 200 字节计算每月约 200KB 流量现在运营商物联网卡大约 ¥2~5/台/年10 万台设备就是 20~50 万/年。这个数字要在立项阶段就纳入商业模型而不是产品出来了才发现流量费吃掉了利润。Wi-Fi 方案的运维成本在于「设备是否能稳定连上路由器」。消费电子场景里用户家里的路由器换密码、换设备都会导致你的设备断连。如果没有好的重新配网流程售后服务成本会很高。STM32 4G 方案的运维成本主要是 SIM 卡管理——几万台设备的 SIM 卡如果分属不同运营商管理平台的复杂度和费用都不低。最后的建议我在团队里推行一个原则选型决策要写成一页纸的文档列出候选方案、评估维度和最终决策理由让 3 年后的人能看懂当时为什么这么选。因为产品迭代的时候新人接手不知道当时的约束条件很容易做出「为什么不换成 ESP32 / 换成 NB-IoT」这类质疑。有文档一切清晰没文档每次都要重新讨论一遍。技术选型没有标准答案只有适合当前约束条件的最优解。下一篇[MQTT 协议精讲QoS 0/1/2 背后的工程权衡不是文档翻译]作者15 年嵌入式软件工程师专注物联网设备端开发专栏嵌入式物联网工程实战从连接到上云这篇文章对你有帮助点赞收藏下次选型的时候翻出来对照着用。