1. 多协议并发工程导论
在物联网网关、智能家居中枢、工业边缘节点等产品中，一颗无线 SoC 往往需要同时承担 Zigbee 组网、蓝牙低功耗（BLE）连接、私有 Sub-GHz 或 2.4 GHz 协议通信等多重任务。Silicon Labs 的 EFR32 系列无线 SoC 与 EFR32MG 多协议芯片正是为这类场景设计的：它把多套射频前端、协议栈与调度机制集成到同一颗芯片上，使"一颗芯片跑多种协议"从概念变成可工程化的现实。本节先建立整体认知框架——平台由什么构成、多协议并发到底指什么、优化要追求哪些目标、又会遇到哪些硬约束。
一、Silicon Labs 无线 SoC 平台概览
EFR32 平台的核心结构可以概括为"一颗 Cortex-M 内核 + 一套可重构射频 + 多套协议栈 + 一个调度器"。以 EFR32MG21 为例，它采用 ARM Cortex-M33 内核（主频 80 MHz），片上集成 2.4 GHz 收发器，支持 Zigbee、Thread、BLE 及 BLE Mesh；而 EFR32MG12/MG24 等型号进一步提供 Sub-GHz 射频通道，可同时覆盖 2.4 GHz 与 Sub-GHz 频段。射频部分采用软件定义无线电思路，通过配置调制方式、频段、数据率来适配不同协议，而不是为每种协议单独做一套硬件。
软件侧，Silicon Labs 提供 Gecko SDK（GSDK）与 Simplicity Studio 开发环境，其中包含 Zigbee 协议栈（EmberZNet）、BLE 协议栈（Bluetooth SDK）、Thread 协议栈（OpenThread）以及多协议调度组件（Multi-Protocol / Dynamic Multiprotocol）。多协议并发的关键支撑是 Radio Scheduler（射频调度器）：它把物理射频资源抽象为可被多个协议栈按时间片申请的资源，由调度器决定"此刻谁用射频、用多久"。
二、多协议并发的三种典型形态
工程中常见的并发形态并非只有一种，按射频共享方式可分为三类：
- 动态多协议（Dynamic Multiprotocol，DMP）：同一时刻只有一个协议占用射频，调度器在协议间快速切换。例如设备平时作为 Zigbee 终端保持入网，当手机靠近时临时切换到 BLE 广播/连接，完成配网后再切回 Zigbee。这是最常见的形态。
- 并发多协议（Concurrent Multiprotocol）：依赖多射频通道或多套射频前端，两个协议可真正同时收发。例如 Sub-GHz 与 2.4 GHz 双频并发，或双 2.4 GHz 射频通道。
- 协议共存（Coexistence）：多个协议共享同一频段（如 BLE 与 Zigbee 都在 2.4 GHz），通过时分、优先级与 PTA（Packet Traffic Arbitration）机制减少相互干扰。
三者的资源冲突程度依次递增：DMP 是"时间上错开"，并发多协议是"硬件上分开"，共存是"同频段上抢时间"。优化策略也因此不同。
三、优化目标与核心挑战
多协议并发的优化目标可以归纳为四个维度，它们之间往往互相牵制：
| 目标维度 | 含义 | 典型指标 |
|---|---|---|
| 实时性 | 协议关键事件按时完成 | 连接间隔抖动、Zigbee 轮询响应延迟 |
| 吞吐量 | 单位时间有效数据传输量 | BLE 有效吞吐、Zigbee 上报速率 |
| 功耗 | 平均电流与电池寿命 | 休眠电流、占空比 |
| 稳定性 | 长时间运行不掉线、不丢包 | 丢包率、重连次数 |
挑战主要来自三方面。第一是射频时间冲突：BLE 连接事件有严格的时序窗口，Zigbee 也有自己的 CSMA/CA 与信标周期，两者若在同一时刻请求射频，调度器必须做出取舍，取舍不当就会导致某一方丢包或延迟。第二是内存与算力竞争：多套协议栈同时驻留会占用大量 RAM/Flash，Cortex-M33 的算力也要在协议处理与应用逻辑间分配。第三是功耗叠加：每个协议栈的唤醒、监听、重传都会增加平均电流，多协议并发时功耗并非简单相加，而是可能因频繁唤醒而显著恶化。
四、一个可观察的并发示例
假设用 EFR32MG21 做一个"Zigbee 灯 + BLE 配网"的设备：上电后设备作为 Zigbee 终端加入网络，同时开启 BLE 广播等待手机连接。此时调度器面临的实际问题是：Zigbee 需要周期性发送 Link Status 或响应父节点轮询，BLE 需要按广播间隔（例如 100 ms）发送广播包。若两者时间窗口重叠，调度器按优先级让 BLE 广播先发，Zigbee 的响应被推迟到下一个窗口。
判断并发是否健康，可以观察几个量：BLE 广播是否按 100 ms 间隔稳定发出（用抓包工具看广播包时间戳抖动）、Zigbee 是否仍能维持入网（看父节点是否收到 Link Status）、以及设备平均电流是否在预期范围内（例如休眠电流 2 µA、广播峰值 8 mA、平均电流 50 µA 量级）。如果 BLE 广播抖动超过 ±10 ms，或 Zigbee 出现频繁重连，就说明调度参数需要调整——这正是后续章节要展开的优化工作。
五、工程视角下的优化思路
面对上述挑战，优化并非"调一个参数就完事"，而是围绕调度器展开的一组协同手段：合理设置各协议的优先级与时间片长度、把非关键任务移出射频窗口、利用低功耗模式减少无效唤醒、在内存紧张时裁剪协议栈功能、以及通过抓包与电流测量建立"可观测性"。这些手段将在后续章节逐一展开。本节需要先建立的核心判断是：多协议并发的本质是资源仲裁问题，优化的第一步永远是先看清"谁在什么时候抢射频、抢到了多久、代价是什么"。
理解了平台结构、并发形态与目标挑战这三层，后续讨论调度参数、功耗测量、抓包分析时，才能把每个具体操作放回正确的系统位置。