Silicon Labs 软件设计基础以物联网（IoT）应用的主要决策点为主线，系统介绍了无线网络解决方案的设计过程。从无线协议选择到架构范式（SoC 或 NCP），再到 Zigbee 网络 commissioning 和消息传递，每一层决策都深刻影响着最终产品的功耗、成本与开发复杂度。Silicon Labs Gecko SDK 提供了统一的软件基础设施，使开发者能够在多种无线协议和平台之间高效切换。Documentation Index
Fetch the complete documentation index at: https://mintlify.com/dsyx/docs.silabs.com_zh/llms.txt
Use this file to discover all available pages before exploring further.
可用协议栈
Silicon Labs 在 Wireless Gecko（EFR32）系列上提供以下协议栈供应用开发选择：Silicon Labs Flex SDK
包含基于 IEEE 802.15.4 的 Connect 协议栈（适用于星形/多跳网络拓扑），以及用于真正专有射频设计的 RAIL（Radio Abstraction Interface Library）。
EmberZNet PRO
基于 Zigbee PRO 规范的 Mesh 网络协议栈，提供完整的 ZCL（Zigbee Cluster Library）支持，适合家庭自动化、智慧能源等标准化场景。
Silicon Labs Bluetooth SDK
完整的 Bluetooth LE 协议栈，提供预配置 GATT 结构和示例代码，支持点对点连接与 Bluetooth Mesh 网络扩展。
Bluetooth Mesh SDK
Bluetooth SDK 的配套扩展，支持 Bluetooth mesh 网络，可与 Zigbee 动态多协议组合使用，实现多协议并发。
选择协议栈时，应根据标准合规性、网络拓扑、互操作性、频率范围和消息吞吐量综合评估。Simplicity Studio 提供了基于 AppBuilder 的 IDE 和各协议的示例程序，帮助加速选型和开发。
SoC 与 NCP 架构选型
架构范式是软件设计中最关键的早期决策，它决定了协议栈与应用逻辑的部署位置，影响芯片数量、功耗、成本和开发灵活性。SoC 方案
在 SoC（System-on-Chip）方案中，整个系统（协议栈 + 应用）运行在单一芯片（如 EFR32™）上。协议栈以预编译库形式提供，与应用代码链接生成单一二进制映像。 SoC 方案优势：- 单芯片设计，功耗低、BOM 成本低、PCB 面积小
- 应用与协议栈紧密集成，可实现精确的时序控制
- 应用框架（AFV2）处理大部分协议合规细节
- Flash 和 RAM 容量受芯片规格约束
- Zigbee/Bluetooth 动态多协议应用需要 IAR Embedded Workbench 工具链
- CPU 必须与协议栈共享，存在时序约束
NCP 方案
在 NCP（Network Coprocessor）方案中，Silicon Labs 芯片（预加载协处理器固件）处理协议栈功能，并通过串行接口（SPI 或 UART）与独立的 Host 处理器通信，Host 处理器运行应用层逻辑。 NCP 通信协议：- EZSP（EmberZNet Serial Protocol）：用于 Zigbee 解决方案，支持 SPI 同步或 UART 异步运行
- CSP（Connect Serial Protocol）：用于 Connect 解决方案，通过 UART 接口传输，封装在 ASHv3 协议中
- Host 处理器可从 8 位 MCU 到运行 Linux 的 64 位计算机，灵活性极高
- 协议栈升级只需更新 NCP 固件，Host 应用无需改动
- 适合在现有系统上添加无线功能，充分利用既有软硬件积累
SoC 与 NCP 关键差异对比
| 功能 | SoC | NCP |
|---|---|---|
| 协议栈参数配置 | 编译时静态定义 | NCP 启动后由 Host 运行时配置 |
| 事件响应 | 实时逐事件处理 | 提前配置策略，事后通知 |
| 消息缓冲区管理 | 应用与协议栈共享内存，需手动分配 | NCP 自行管理，Host 仅处理载荷数组 |
| 源路由表 | 驻留在 SoC 有限 RAM 中 | Host 可缓存更多路由数据，适合 High RAM Concentrator |
| 核心功能变更 | 仅修改单一应用 | 需同步修改 Host 应用和 NCP 固件 |
Zigbee 设计选择
单网络与多网络
EmberZNet PRO 4.7 引入了单芯片同时参与最多两个网络的能力（多网络支持）。多网络通过对唯一无线电进行时间分片实现，对应用完全透明。多网络节点角色限制
多网络节点角色限制
由于协调器/路由器节点必须始终保持射频接收，多网络节点只能在一个网络上担任协调器或路由器，在其他网络上必须以嗜睡终端设备（Sleepy End Device）角色参与。若在所有网络上均为嗜睡终端设备，则可在无活动时进入睡眠模式以节省电量。
网络 Discovery 与 Commissioning
Commissioning 是将设备接入网络的过程。设计时需考虑：信道掩码与 Extended PAN ID 规划
专有网络可使用协商好的 Extended PAN ID 掩码来缩小信道扫描范围；或将信道扫描限定在避开常用 Wi-Fi 信道（802.11 的 1、6、11）之外的 Zigbee 信道（如 11、14、15、19、20、24、25）上。
许可加入控制
设备不得永久竖立
permitJoining 标志，应通过按钮、串行接口或首次上电时限时开启等方式触发。可通过 emberPermitJoining() API 或 ZDO 标准请求远程更改许可加入状态。设备发现与供给（Provisioning）
供给是将 PAN 中相关设备（客户端与服务端）配对用于应用级通信的过程。常见方法包括：标识与分组方法
将目标节点置于标识（Identify）模式，发送 “Add Group If Identifying” 命令批量加组。适合一对多供给，要求设备支持
Groups server cluster 和 Identify server cluster。按钮方法
通过按钮触发设备进入供给状态或发送供给消息。灵活性高，无需第三方设备，但可能涉及专有消息协议，降低跨厂商互操作性。
匹配描述符请求
广播 ZDO Match Descriptor Request，根据端点描述符（配置文件、簇 ID、客户端/服务端支持）查找匹配的供给伙伴。使用标准 ZDO 帧，互操作性好，但无法发现嗜睡终端设备。
供给工具方法
由第三方设备（如网关或 commissioning 工具）收集网络设备信息，提供用户界面供安装人员手动配对。适合复杂网络，但需要专用工具支持。
路由建立与消息传递
多对一路由（MTOR） 允许集中器（网关）向整个网络广播多对一路由请求，使所有节点建立到集中器的入站路由，无需每个节点单独发现。结合源路由技术，集中器存储从路由记录有效载荷中获得的反向路径，实现双向通信。 消息发送的三种基本类型：| 消息类型 | 描述 | EmberZNet API |
|---|---|---|
| 单播（Unicast） | 发送到指定节点 ID | emberSendUnicast() |
| 广播（Broadcast） | 发送到所有设备或所有非嗜睡设备 | emberSendBroadcast() |
| 多播（Multicast） | 发送到共享相同分组 ID 的所有设备 | emberSendMulticast() |