3. 多协议无线协议栈架构
nRF52/nRF53系列之所以能在一颗芯片上同时承载蓝牙LE、Thread、Zigbee和2.4GHz专有协议，核心并不在于“射频能同时收发”，而在于一套分层的协议栈架构与基于时间片（Timeslot）的射频调度机制。理解这套架构，是判断“哪些协议能共存、以什么代价共存、共存时性能如何”的前提。
一、协议栈的分层与SoftDevice的角色
在nRF52上，协议栈被划分为三个层次：最底层是硬件与射频前端（RADIO、TIMER、PPI、RTC、时钟与电源管理）；中间层是Nordic提供的二进制协议栈组件；最上层是应用固件。SoftDevice正是中间层的统称，它是一段预编译、受保护的二进制镜像，占用固定的Flash与RAM区域，对外只暴露一组SVC（Supervisor Call）软中断接口。
SoftDevice的关键特性是“不可见但可调用”：应用无法直接访问被SoftDevice占用的外设（如RADIO、部分TIMER、CCM/AAR加密单元），必须通过API请求。这种隔离带来两个直接后果：一是协议栈升级只需替换二进制，应用代码不动；二是应用与协议栈之间必须通过事件回调与API调用交互，不能共享底层寄存器。
常见的SoftDevice型号与能力对应关系如下：
| SoftDevice | 支持协议 | 典型角色 | 适用芯片 |
|---|---|---|---|
| S132 | 蓝牙LE（含Central/Peripheral） | 纯BLE | nRF52 |
| S140 | 蓝牙LE | 纯BLE，支持高吞吐/长包 | nRF52840/810 |
| S340 | 蓝牙LE + 802.15.4（Thread/Zigbee） | 多协议并发 | nRF52840/810 |
S140与S340的差别是本节的关键：S140只提供蓝牙LE协议栈；S340在S140基础上额外集成了802.15.4 MAC层，并内置了多协议射频调度器。也就是说，“BLE + Thread/Zigbee共存”在nRF52840上是通过S340实现的，而不是应用层自己拼两个协议栈。
二、802.15.4、Thread与Zigbee的关系
802.15.4是物理层与MAC层标准，工作在2.4GHz，共16个信道（11~26），每信道带宽2MHz，采用DSSS-OQPSK调制，空中速率250kbps。Thread和Zigbee都构建在802.15.4之上，区别在网络层及以上：
- Thread：基于IPv6的6LoWPAN，使用Mesh Link Establishment与MLE路由，强调IP可达性，适合与互联网直连。
- Zigbee：使用自有网络层（NWK）与应用层（APS/ZCL），依赖协调器与信任中心，生态成熟于照明与楼宇。
在nRF52840上，S340只提供到802.15.4 MAC层，Thread的6LoWPAN、MLE、路由，或Zigbee的NWK/APS/ZCL，需要由Nordic的Thread/Zigbee库或第三方栈（如OpenThread、ZBOSS）在应用侧实现。因此“S340 + OpenThread”或“S340 + ZBOSS”才是完整的Thread/Zigbee方案。
三、共存模型：时间片调度与射频仲裁
2.4GHz频段是共享资源，BLE与802.15.4无法真正同时收发。S340的共存模型本质是时分复用：由协议栈内部的调度器把射频时间切成时隙，按优先级分配给BLE连接事件、BLE广播、802.15.4收发、以及应用请求的专有协议时隙。
调度器遵循几条实际规则：BLE连接事件具有最高优先级，因为连接间隔（Connection Interval）一旦错过会导致丢包甚至断连；802.15.4的CSMA/CA退避与ACK窗口次之；应用通过Timeslot API申请的专有协议时隙优先级最低，且只能在剩余空闲时间中插入。若时间不足，调度器会拒绝该次请求，应用需自行重试。
下面这张图展示了S340在nRF52840上的协议栈分层与射频时间片分配关系，是理解共存代价的核心视图：
四、实际工程中的配置与判断
以nRF52840 + S340 + OpenThread为例，一个可复现的共存配置流程如下：
- 烧录S340 SoftDevice（如s340_nrf52840_6.1.1.hex），确认其占用的Flash起始地址与大小，应用链接脚本需避开该区域。
- 在应用侧初始化BLE与OpenThread两个实例，分别注册各自的事件回调。
- 调用
sd_radio_session_open()打开射频会话，使能多协议调度。 - 设置BLE连接参数：连接间隔建议不小于15ms，从设备延迟（Slave Latency）可设为0~4，以给802.15.4留出窗口。
- OpenThread侧配置信道（如channel 15）与PAN ID，启动Thread协议栈。
判断共存是否正常，可观察三个指标：BLE连接事件是否稳定（用sd_ble_gap_conn_param_update后的连接事件计数）；802.15.4的ACK成功率（OpenThread的ot-ctl counters mac中TxAck与TxRetry比例）；以及专有协议Timeslot请求的拒绝率。若TxRetry显著上升而BLE连接事件正常，说明802.15.4在争抢中处于劣势，应增大BLE连接间隔或降低802.15.4的发送频率。
总结来看，nRF上的多协议共存不是“协议叠加”，而是“S340统一调度 + 时间片仲裁 + 应用层参数妥协”的组合。理解S140/S340的边界、802.15.4与Thread/Zigbee的分层关系、以及调度优先级，才能在工程中做出正确的选型与参数取舍。