2. 硬件选型与架构：主流无线MCU芯片对比
做IoT性能调优，第一步不是调代码，而是选对芯片。芯片选错了，后面再怎么优化协议栈，天花板就在那里。我个人习惯是先看架构，再看外设，最后才看厂商宣传的“理论功耗”。
今天咱们就掰开揉碎，聊聊三款最主流的无线MCU：ESP32、nRF52系列、STM32WB系列。它们各自擅长什么，短板在哪，以及内部架构到底怎么影响你的协议栈性能。
2.1 三款主流芯片核心参数对比
先上一张硬核对比表。这些参数我建议你收藏，选型时直接翻出来对照。
| 参数维度 | ESP32 (乐鑫) | nRF52840 (Nordic) | STM32WB55 (ST) |
|---|---|---|---|
| 核心架构 | 双核 Xtensa LX6 @240MHz | 单核 Cortex-M4F @64MHz | 双核 Cortex-M4 + M0+ @64MHz |
| 无线协议 | WiFi + BLE + 蓝牙Mesh | BLE + 蓝牙Mesh + Thread + Zigbee | BLE + 蓝牙Mesh + Thread + Zigbee |
| SRAM | 520KB | 256KB | 256KB + 64KB (专用) |
| Flash | 4MB (外置) | 1MB (内置) | 1MB (内置) |
| 典型Tx电流 | ~180mA (WiFi) / ~10mA (BLE) | ~5.3mA (0dBm) | ~5.2mA (0dBm) |
| 深度睡眠 | ~5μA (RTC保持) | ~0.4μA (唤醒保持) | ~1.2μA (唤醒保持) |
| DMA通道 | 2个GDMA (每个8通道) | EasyDMA (外设专用) | 2个DMA (每个8通道) |
核心结论：没有绝对的“最好”，只有“最合适”。ESP32强在算力和WiFi，nRF52强在极致低功耗和Mesh生态，STM32WB强在双核隔离和ST生态。
2.2 内部架构对协议栈性能的影响
芯片的内部架构，说白了就是数据怎么在CPU、内存、无线外设之间流动。这个流动路径一旦有瓶颈，协议栈性能直接打折。
2.2.1 ESP32：双核共享总线的甜蜜与陷阱
ESP32的双核设计很讨喜。你可以把协议栈跑在一个核上，应用逻辑跑在另一个核上。听起来完美，对吧？
但我在项目中踩过一个坑：两个核共享一条总线去访问外置Flash。当WiFi协议栈频繁从Flash取指令时，另一个核的应用代码就会被卡住。你想想看，一个240MHz的双核芯片，实际吞吐量可能还不如一个跑得顺的100MHz单核芯片。
我的建议：用ESP32做WiFi应用时，把协议栈中断优先级调高，同时把关键数据放到SRAM里，别放在Flash上。IRAM和DRAM的分配要手动优化，别信默认配置。
2.2.2 nRF52：单核但高效，EasyDMA是灵魂
nRF52系列只有单核Cortex-M4F，主频才64MHz。很多人第一反应是“这够用吗？”
其实够用。Nordic的杀手锏是EasyDMA——几乎所有外设（UART、SPI、I2C、ADC、Radio）都内置了独立的DMA控制器。数据从无线收发器到内存，全程不走CPU。CPU只在包处理完成时被中断唤醒一次。
我记得有个低功耗传感器项目，用nRF52840跑BLE连接，平均电流能做到1.2μA。换成其他芯片，同样的协议栈配置，电流至少翻倍。
注意：nRF52的EasyDMA虽然高效，但每个外设的DMA缓冲区有地址限制。比如SPI的DMA只能访问RAM的前64KB。我曾经因为把缓冲区定义在64KB之外，导致DMA传输静默失败——数据没发出去，也没有任何错误标志。排查了两天。
2.2.3 STM32WB：双核隔离，但核间通信是瓶颈
STM32WB55很有意思，它把Cortex-M4（应用核）和Cortex-M0+（无线核）放在一颗芯片里。无线协议栈跑在M0+上，应用跑在M4上，物理隔离。
好处很明显：无线协议栈不会干扰应用逻辑，实时性有保障。但坏处也明显——两个核之间通过共享IPCC（核间通信控制器）和共享SRAM2来交换数据。每次数据交互都要走一次“核间握手”，延迟大概在几微秒到几十微秒。
如果你做的是高吞吐量应用（比如OTA固件升级），这个核间通信延迟就会成为瓶颈。我建议在这种场景下，用大块数据一次性传输，别频繁小包交互。
2.3 外设与DMA的合理配置
选对了芯片，还得配对外设。很多开发者把外设配置当成“填寄存器”的体力活，其实这里面的门道很深。
2.3.1 外设时钟与功耗的平衡
每个外设都有独立的时钟门控。不用的外设一定要关掉时钟，这个大家都知道。但有一个细节容易被忽略：外设时钟频率不是越高越好。
比如SPI，如果你只跑1MHz的传感器，把SPI时钟设到40MHz，除了浪费功耗，还会引入更多的信号噪声。我习惯的做法是：外设时钟刚好满足需求带宽的1.5倍，留一点余量就行。
2.3.2 DMA配置的三个关键点
DMA用得好，CPU占用率能降到5%以下；用得不好，反而比中断还慢。我总结了三个关键点：
- 传输粒度匹配：DMA的传输宽度（8/16/32位）要和外设FIFO宽度一致。比如UART的FIFO是8位，你就用8位传输。用32位传输会导致字节错位。
- 循环模式慎用：很多开发者喜欢用DMA循环模式做数据采集。但循环模式下，DMA不会产生完成中断，你无法知道缓冲区什么时候被写满。我建议用双缓冲模式（ping-pong buffer），一个缓冲区被DMA写，另一个被CPU读，交替使用。
- 优先级别乱设：DMA通道优先级不是越高越好。高优先级DMA会抢占CPU的总线访问权，导致CPU响应中断变慢。我一般把无线收发相关的DMA设成中等优先级，把音频、显示等高吞吐外设设成低优先级。
避坑指南：我曾经在一个项目中，把SPI DMA的优先级设成了最高。结果WiFi协议栈的中断响应延迟从3μs飙升到50μs，直接导致WiFi连接频繁断开。后来把SPI DMA降了一级，问题立刻解决。
2.3.3 无线外设的专用DMA配置
无线MCU的Radio外设通常有专用的DMA或数据路径。以nRF52为例，Radio和内存之间通过PPI（可编程外设互联）和EasyDMA直接连接。配置时要注意：
- Radio的DMA缓冲区必须放在RAM中，不能放在Flash或外设地址空间
- 缓冲区地址必须4字节对齐（否则DMA传输会异常）
- 对于BLE协议栈，建议为每个连接事件分配独立的DMA缓冲区，避免数据覆盖
2.4 知识体系结构图
下面这张图梳理了本章的核心逻辑：从芯片选型到架构分析，再到外设配置，最终影响协议栈性能。
2.5 选型决策流程
最后，我分享一个自己常用的选型决策流程。遇到新项目时，按这个步骤走，基本不会出大错：
- 确定无线协议：需要WiFi？选ESP32。需要Thread/Zigbee？nRF52或STM32WB。只做BLE？三者都可以，但nRF52功耗最优。
- 评估算力需求：应用层有复杂算法（如音频处理、机器学习）？选ESP32。只是数据采集和转发？nRF52或STM32WB足够。
- 计算功耗预算：电池供电且要求年抛？nRF52是首选。市电供电或大电池？ESP32性价比更高。
- 检查外设资源：需要的传感器接口数量、DMA通道数、定时器数量，对照数据手册逐一确认。
- 考虑生态与成本：团队熟悉哪个平台？开发工具链是否成熟？批量采购单价是否在预算内？
一个小技巧：如果你拿不准选哪款，先买开发板做POC（概念验证）。用实际协议栈跑一下你的典型场景，测功耗、测吞吐量、测响应延迟。数据比任何宣传手册都靠谱。