2. Silicon Labs多协议硬件基础

多协议并发不是软件层面的“同时跑两个协议栈”那么简单，它首先受制于芯片硬件：射频前端能否快速切换、内存能否容纳两套协议栈、功耗域能否让空闲协议进入低功耗、外设能否被两个协议公平共享。EFR32 系列（如 EFR32MG21、EFR32MG24、EFR32BG24）正是围绕这些约束设计的。理解它的架构，是后续做并发优化的前提。

一、EFR32 的整体架构

EFR32 采用“MCU 内核 + 无线子系统”的双域结构。以 EFR32MG24 为例，主控是 ARM Cortex-M33，主频最高 78 MHz，带 FPU 与 TrustZone；无线部分由独立的 Radio Core（射频协处理器）管理，二者通过共享总线和邮箱寄存器通信。应用代码运行在 Cortex-M33 上，射频收发、调制解调、协议定时由 Radio Core 承担，因此协议栈的实时性不依赖主 CPU 的调度。

这种分工带来一个关键特性：主 CPU 可以在射频工作时进入睡眠，由 Radio Core 在需要时通过中断唤醒。多协议并发的本质，就是让 Radio Core 在多个协议的时间片之间切换，而主 CPU 只处理事件与数据搬运。

二、射频子系统：并发的物理瓶颈

EFR32 的射频前端是单通道的：同一时刻只能工作在一个频段、一种调制方式上。BLE、Zigbee、Thread 都工作在 2.4 GHz ISM 频段，因此它们共享同一套 PA/LNA 和天线。多协议并发的实现方式，是 Radio Core 按时间片在协议间切换，而不是真正并行收发。

切换开销决定了并发能力。EFR32MG24 的射频切换时间在百微秒量级，协议栈（如 Silicon Labs 的 RAIL 与 Zigbee/Bluetooth 栈）通过“无线电调度器”协调：每个协议向调度器申请时间窗口，调度器按优先级和时延要求排布。BLE 连接事件有严格的锚点周期（如 7.5 ms～4 s），Zigbee 的 CSMA 则相对宽松，因此调度器通常优先保证 BLE 的锚点，把 Zigbee 的发送推迟到 BLE 事件之后。

实际配置中，需要关注三个参数：优先级（哪个协议抢占）、时间片长度（单次占用射频的时长）、保护间隔（切换前后的静默时间）。保护间隔过小会导致前一个协议的尾包未发完就被打断，表现为丢包率上升；过大则浪费射频时间，降低吞吐。

三、内存与功耗域

多协议并发对内存的压力主要来自协议栈的静态占用。以 EFR32MG24 为例，256 KB RAM 中，BLE 协议栈约占用 30～40 KB，Zigbee 约 40～50 KB，若再叠加 Matter/Thread，RAM 会迅速逼近上限。Flash 方面，1.5 MB 通常可容纳两套协议栈加应用，但 OTA 双区升级会占用额外空间，需要提前规划。

功耗域方面，EFR32 提供 EM0～EM4 五级能耗模式。EM0 为全速运行，EM1 关闭 CPU 时钟但外设可运行，EM2 保留 RAM 与低频外设（RTC、LEUART），EM3 仅保留状态，EM4 为关断。多协议并发的功耗优化核心是：当某个协议空闲时，让主 CPU 进入 EM2，由 Radio Core 在下一个事件到来时唤醒。若两个协议的事件间隔都很短，CPU 频繁进出 EM2 反而增加切换能耗，此时应评估是否让 CPU 停留在 EM1。

四、外设资源分配

两个协议栈同时运行时，外设冲突是常见问题。典型冲突包括：串口调试口被两个协议同时打印、定时器被重复初始化、DMA 通道争用。EFR32 的 PRS（外设反射系统）可以把一个外设的事件直接路由到另一个外设，无需 CPU 干预，适合做射频事件与定时器的联动。

建议在项目初期就建立一张资源分配表，明确每个外设归属哪个协议或由应用层统一管理。下面是一份可直接参考的分配示例：

五、从硬件约束到优化方向

综合来看，EFR32 的硬件基础给出了三条明确的优化边界：第一，射频是单通道，并发靠时间片，因此优化重点是减少切换次数、拉长单次时间片；第二，RAM 有限，协议栈占用必须精确核算，必要时裁剪功能或降低缓冲区；第三，功耗域支持深度睡眠，但唤醒频率决定实际功耗，需要根据事件周期选择 EM1 或 EM2。