sliabs zigbee choose design

Silabs zigbee choose design

着重点

1. 使用哪个堆栈或应用程序框架？
2. SoC还是NCP？
3. Zigbee设计选择

1. 背景

  Silicon Labs正在开发旨在满足客户需求的产品，因为我们正在转向家庭中不断连接的设备世界，通常被称为物联网（IoT）。在高层次上，Silicon Labs物联网的目标是：

1. 无论是zigbee PRO，Thread，Bluetooth Smart还是其他新兴标准，都可以通过一流的网络连接家中的所有设备。
2. 利用公司在节能微控制器方面的专业知识。
3. 增强已建立的低功耗，混合信号芯片。
4. 实现云服务和与智能手机和平板电脑的连接，促进易用性和为客户提供通用的用户体验。

实现所有这些目标将提高Connected Home中物联网设备的采用率和用户接受度。

随着应用程序设计人员可用的选项范围的增加，早期设计选择的影响也会增加。本文档根据必须针对如何构建无线网络解决方案的主要决策描述了应用程序设计过程。基本设计选择包括：

1. 使用Silicon Labs的无线技术
2. 是使用SoC（片上系统）设计还是NCP（网络协处理器）设计
3. 如果使用NCP模型，如何选择兼容的NCP和主机应用程序

开发zigbee解决方案时的设计选择包括：

1. 如何创建网络（表单，加入或离开）
2. 将使用哪些安全模型
3. 在网络中采用什么样的路由优化
4. 如何通过网络传递消息

一旦考录了这些悬着，就可以开始实施系统设计了。

1. 一般设计选择

  在开始使用Silicon Labs的无线微控制器进行无线设计之前，您应该首先考虑哪种可用的网络技术最适合您的项目。一旦您决定使用您想要用于设计的网络协议，请考虑您的产品是否最适合片上系统（SOC）范例或网络协处理器（NCP）范例，对于NCP，用于控制协处理器的一种串行通信。

  2.1、您应该使用哪种无线协议

1. Silicon Labs提供以下用于Wireless Gecko系列开发的堆栈：
2. Silicon Labs Flex SDK，包括用于多跳“星形”网络拓扑的基于IEEE 802.15.4的“连接”堆栈（在UG103.12：应用开发基础：Silicon Labs Connect中描述）和无线电抽象接口库（RAIL）用于具有定制RF配置的真正专有设计。
3. EmberZNet，一个基于zigbee PRO的网状网络堆栈，在UG103.2：应用程序开发基础：Zigbee中有详细描述。
4. Silicon Labs Thread，一个基于Thread 1.1的IPv6网状网络堆栈，在UG103.11：Application Development Fundamentals：Thread中有详细描述。
5. Silicon Labs蓝牙SDK是一种基于蓝牙2.3的网络堆栈，在UG103.14：应用程序开发基础：蓝牙智能技术中有详细描述。

 

  熟悉这些协议的详细信息后，您可以根据自己对标准合规性，网络拓扑，互操作性，频率范围和消息吞吐量的需求进行选择。

  2.2、SOC还是NCP？

  无论您是否使用应用程序框架进行设计，设计范例（SoC（片上系统）模型或NCP（串行网络协处理器）模型）的选择都是至关重要的。它规定了软件和硬件的要求和约束。此选择控制应用程序相对于核心堆栈功能所在的位置。在SoC模型中，整个系统（堆栈和应用程序）驻留在单个芯片上，而在NCP模型中，堆栈处理在单独的“协处理器”中完成，该协处理器通过外部串行接口与应用程序自己的微控制器交互。

  2.2.1、片上系统方法

  在SoC方法中，单个芯片（例如Wireless Gecko（EFR32™）产品组合中的一个IC）提供所有堆栈功能（包括集成闪存，RAM和RF收发器）以及应用层组件（应用）配置文件，集群，属性管理和堆栈交互）。堆栈功能是作为预编译的库文件实现的，然后您必须在最终构建过程中与您自己的应用程序相关的代码链接，以生成包含完整功能无线应用程序所需的所有内容的单个单片二进制映像。应用程序框架虽然由Silicon Labs提供，但仍被视为应用程序层的一部分。

  注意：虽然引导加载程序通常用于已部署的无线网络设备，但该引导加载程序固件不是此单片二进制映像的一部分。但是，Silicon Labs确实提供了构建后工具，可用于将应用程序固件和堆栈固件进一步组合到单个HEX记录文件中，以便于分发和制造。有关EmberZNet PRO应用程序的这些软件实用程序的更多信息，请参阅文档UG107：EM3x实用程序指南，UG162：Simplicity Commander参考指南和文档UG103.6：应用程序开发基础知识：引导加载。

  在SoC开发方法中，应用程序（包括应用程序框架）与堆栈共存。应用程序调用堆栈库提供的API（应用程序编程接口函数），并且堆栈触发应用程序代码实现的处理程序函数。当应用程序框架用于应用程序设计时，框架会处理调用这些API并实现必要的处理函数，然后将它们包含在更高级别的API和应用程序回调中，以简化设计过程并帮助确保协议合规性。

  由于SoC模型仅需要单个芯片，因此与需要多个IC的NCP模型和传统设计架构相比，SoC模型具有更低的功耗，更低的BOM（物料清单）成本以及更小的可能布局。此外，当所有内容都驻留在单个芯片上时，可以实现与堆栈软件和无线电硬件的更紧密集成，从而允许更精确和及时地控制与堆栈活动相关的应用程序行为。但是，一旦您致力于SoC模型，您就会受到该SoC系列中可用产品的限制。其中包括：

1. 闪存和RAM内存限制
2. 工具链约束，例如对基于zigbee和基于线程的SoC使用IAR Embedded Workbench的要求
3. HAL限制，例如某种类型的外围设备数量有限，或缺少可能与您的硬件设计不可或缺的专用外设
4. 基于必须与堆栈共享CPU的时序约束，其具有其自己的一组要求以便维持IEEE

802.15.4和协议合规性如果这些限制中的任何一个具有太大的威慑力，那么NCP模型可能是更具吸引力的替代方案。

  2.2.2、NCP方法与串行协议

   注意：本节不适用于蓝牙SoC或NCP型号。有关更多信息，请参阅AN1042：在网络协处理器模式下使用SiliconLabsBluetooth® 堆栈和UG136：SiliconLabsBluetooth®C应用程序开发人员指南。

  在NCP方法中，带有集成闪存，RAM和RF收发器的Silicon Labs芯片通过预先加载的协处理器固件自行运行大多数堆栈功能，并具有运行时可配置性，然后使用串行接口，如串行外设接口（SPI）或通用异步接收器/发送器（UART）与第二个设备（称为“主机”处理器）通信，其中应用层功能与核心堆栈组件分开“托管”。NCP可能是一种特殊的集成电路，具有有限的I / O和减少的功能，可用作协处理器的明确目的，或者它可能是一个功能齐全的微控制器，恰好将协处理器固件加载到其上，使其表现为NCP。

  促进应用程序主机和堆栈的NCP之间的通信，Silicon Labs提供了两个串行命令集。第一种称为EZSP（EmberZNet串行协议），用于开发zigbee解决方案（有关EZSP的更多信息，请参阅文档UG100：EZSP参考指南。）第二种称为线程管理串行协议（TMSP），用于开发Thread解决方案。Silicon Labs Flex SDK中的Silicon Labs Connect堆栈还提供NCP解决方案，用于专有开发。

  EZSP可以通过SPI同步运行或通过UART异步运行（带或不带流量控制），模拟EmberZ-Net PRO API和EZSP特定的命令帧（有时可能与EmberZ-Net中基于SoC的对应物略有不同）与EmberZNet相关的处理程序具有回调响应帧。Silicon Labs提供EZSP驱动程序源代码，将这些串行命令和响应抽象为一组API和处理函数，类似于SoC模型中使用的函数。当应用程序框架用于实现应用程序层时，它负责调用必要的API函数并实现所需的处理函数，从而允许设计人员专注于使用客户端API和框架回调的更高级别的应用程序处理。

  在TMSP协议中，也提供SPI和UART变体，主机端API不是专用于与基于SoC的Thread应用程序使用的API“相似”的功能。相反，它们实际上与基于SoC的系统上使用的API和回调相同，并且提供了由提供的TMSP驱动程序代码处理的主机端接口的抽象。此外，TMSP驱动程序包含一些功能来管理NCP上的底层IP层，以改善在NCP及其主机上共享的堆栈的上层之间的协调。

  NCP平台的主要优势在于其灵活性。主机处理器可以像8位微控制器一样简单，也可以像64位计算机那样复杂，具有千兆字节的内存和Windows或Linux操作系统。这意味着NCP设计非常适合在现有系统上添加或改装设备的场景，这样可以利用OEM在软件和硬件方面的专业知识和知识产权来加速设计周期和加快上市时间。NCP方法的另一个优点是主机可以为应用程序提供比可用SoC选项更多的资源（闪存和RAM）和不同的外设集。这允许使用新功能开发更复杂的应用程序，

  通过将堆栈处理与应用程序分离，可以在堆栈端安装修复程序和新功能，并对NCP进行简单的固件更新，而无需对主机上的应用程序固件进行任何更改。这种去耦还消除了与堆栈共享处理器的CPU时间限制。由于NCP固件管理NCP的睡眠状态以最小化其活动和当前消耗，因此当应用程序具有不直接涉及堆栈的任务时，仅需要主机处理器处于活动状态。如果CPU在没有无线电的情况下处于活动状态时主机处理器的有效电流消耗低于SoC的有效电流消耗，则运行非网络应用任务时主机和NCP消耗的总电流实际上可能低于SoC在类似的情况下。

  NCP方法的主要缺点是增加了第二个主机处理器，这增加了额外的成本和PCB实际值，并可能影响器件的整体功耗。另一个权衡是解耦堆栈和应用程序处理意味着堆栈和应用程序之间的某些时间敏感的交互不再能够“实时”发生，而必须作为关于事后堆栈做出的决策的通知而发生。因此，主机应用程序在确定某些决策出现时的结果的机会较少。相反，在NCP上配置“策略”以指导这些情况下的堆栈行为。此外，由于NCP固件是Silicon Labs提供的预构建固件，一旦您承诺使用NCP方法，您必须决定使用哪个主机平台进行设计。该平台可能与原型设计和最终设计阶段不同，具体取决于材料的可用性和调试初始阶段所需的灵活性。在选择主机平台时，请考虑您在该平台上的现有专业知识和可用工具和资源，该平台的成本和功耗要求，以及可用于应用程序开发的内存量，包括未来增强所需的任何空间。在开发zigbee解决方案时，还应考虑是否使用UART或SPI进行EZSP通信。EZSP-UART需要更复杂的驱动程序，通常用于符合POSIX标准的操作系统，与EZSP-SPI驱动程序相比，它具有更复杂的逻辑和更大的内存占用，并且其支持的最大吞吐量并不高。但是，EZSP-SPI实现需要比EZSP-UART设计更多的接口引脚。（适用于EZSP的兼容便携式操作系统接口（POSIX）的SPI驱动程序也可用，但嵌入式Linux操作系统的可移植性通常低于符合POSIX标准的UART驱动程序。）因为并非所有微控制器或操作系统都支持SPI，主机的架构限制可能决定了这种设计选择。Thread的TMSP对SPI和UART有类似的权衡。看到AN912：用于线程的SPI主机接口指南，有关设置线程主机SPI驱动程序的更多讨论。

  2.2.3、设计上的差异

  注意：本节不适用于蓝牙SoC或NCP型号。有关更多信息，请参阅AN1042：在网络协处理器模式下使用SiliconLabsBluetooth® 堆栈和UG136：SiliconLabsBluetooth®C应用程序开发人员指南。

  下表按功能显示了SoC应用程序与基于NCP的主机应用程序之间的一些主要差异。

 

方法	去吧
管理堆栈参数，例如表大小和分配限制，以及端点描述符数据，例如支持群集和配置文件
SOC	主要通过编译时定义建立静态构建到应用程序二进制文件中。
NCP	由NCP管理，但在启动NCP之后和进行任何网络活动之前由主机在运行时配置; 此间隔称为“配置”阶段，允许动态配置NCP而无需重建其固件。
对事件的应用反应
SOC	应用程序可以对事件做出反应，例如安全身份验证请求，来自子进程的传入数据轮询或远程绑定修改，并且可以根据具体情况处理事件。
NCP	主机应用程序提前配置策略以预先确定结果; 通知是在事后。
轮询（适用于需要定期轮询网络的困倦终端设备） 应用程序框架负责轮询状态机，因此在使用时差异可以忽略不计。
SOC	应用程序控制每次轮询发生的时间，并选择如何对每个轮询的结果做出反应。
NCP	主机应用程序配置轮询速率和容错。NCP使用配置的速率处理轮询，仅在故障率超过配置的阈值时通知主机。如果不使用应用程序框架，这可以使主机平台上