General Design Choices#

Before beginning a wireless design with Silicon Labs’ wireless microcontrollers, you should first consider which of the available networking technologies would be most appropriate for your project. Once you’ve decided on the networking protocol you want to use for your design, consider whether your product will fit best into a System-on-Chip (SOC) paradigm or a Network Coprocessor (NCP) paradigm and, for the NCP, what kind of serial communication to use for controlling the coprocessor.

Which Wireless Protocol Should You Use#

Silicon Labs offers the following stacks for development on the Wireless Gecko family:

  • Silicon Labs Flex SDK, including the IEEE 802.15.4-based "Connect" stack (described in Silicon Labs Connect Fundamentals) for multi-hop "star" network topologies, and the Radio Abstraction Interface Library (RAIL) for truly proprietary designs with custom RF configurations (described in RAIL Fundamentals).

  • EmberZNet, a Zigbee PRO-based mesh networking stack, described in detail in Zigbee Fundamentals.

  • Silicon Labs Bluetooth® SDK, a Bluetooth networking stack, described in detail in Bluetooth LE Fundamentals.

  • Silicon Labs Bluetooth® mesh SDK, a companion to the Bluetooth SDK supporting Bluetooth mesh networks.

To assist with application development, for each protocol or platform Silicon Labs supplies example application code and other support, such as application frameworks or preconfigured GATT structures. EmberZNet and the Connect component of the Flex SDK all contain one or more application frameworks. Application frameworks contain a body of Silicon Labs-supplied code stored in libraries and components. Silicon Labs also provides Simplicity Studio, which includes configuration tools such as Project Configurator or Application Builder (AppBuilder) that allow you to configure the libraries and components contained in the application framework to implement devices.

After familiarizing yourself with the details of these protocols, your choice among them will likely depending on your needs for standards compliance, networking topology, interoperability, frequency range, and message throughput.

SoC, NCP, or RCP?#

The choice of the design paradigm─either the SoC (system-on-chip) model, the NCP (serial network coprocessor) model, or the RCP (radio coprocessor) model─is a crucial one. It dictates the requirements and constraints of both the software and the hardware. This choice governs where the application resides relative to the core stack functionality. In the SoC model the entire system (stack and application) resides on a single chip, whereas in the NCP model the stack processing is done in a separate "coprocessor" that interacts with the application’s own microcontroller through an external serial interface. In the RCP model, the radio processing is done in a separate "coprocessor" and the application and network layer are handled on a separate microcontroller with communication through a serial interface.

The following figure illustrates the various components of the stack and application and how they are organized relative to the SoC, NCP, or RCP architecture model.

Stack and Application Component Organization in SoC, NCP, and RCP ArchitecturesStack and Application Component Organization in SoC, NCP, and RCP Architectures

While the choice between architectures is not to be made lightly, the application framework masks the differences to some degree, simplifying a change from one architecture to another when necessary, or supporting a mix of architectures for different products.

Note that Dynamic Multiprotocol applications must be built using the SoC or RCP model.

System-on-Chip Approach#

In the SoC approach, a single chip, such as one of the ICs in the Wireless Gecko (EFR32™) portfolio, provides all stack functionality (including integrated flash, RAM, and RF transceiver) as well as the application-layer components (application profiles, clusters, attribute management, and stack interactions). Stack functionality is implemented as pre-compiled library files. You link with those library files along with your own application-related code during the final build process to produce a single, monolithic binary image comprising everything needed for a completely functional wireless application. An application framework, although supplied by Silicon Labs, is considered part of the Application Layer.

Note: While a bootloader is typically used in deployed wireless networking devices, that bootloader firmware is not part of this monolithic binary image. However, Silicon Labs does provide post-build tools that can be used to further combine both the application firmware and the stack firmware into a single HEX record file for ease of distribution and manufacturing. For more information about these software utilities for EmberZNet PRO applications, consult document UG107: ISA3 Utilities Guide, Simplicity Commander Reference Guide, and document Bootloader Fundamentals.

In the SoC approach to development, the application, including the application framework, is co-resident with the stack. The application calls APIs (application programming interface functions) provided by the stack libraries, and the stack triggers handler functions implemented by the application code. The application framework handles calling these APIs and implementing the necessary handler functions, then wraps these in higher level APIs and application callbacks to simplify the design process and help ensure protocol compliance.

Because the SoC model requires only a single chip, compared to the NCP model and legacy design architectures that require multiple ICs, the SoC model has lower power consumption, lower BOM (bill of materials) cost, and smaller possible layouts. Also, tighter integration with the stack software and radio hardware can be achieved when everything resides on a single chip, allowing for more precise and timely control over application behaviors correlated to stack activity.

However, once you have committed to an SoC model, you are bound by the constraints of the available offerings in that SoC family. These include the following:

  • Flash and RAM memory constraints

  • Toolchain constraints, such as the requirement to use IAR Embedded Workbench for Zigbee/Bluetooth dynamic multiprotocol applications

  • HAL constraints, such as limited amount of peripherals of a certain type, or lack of a specialized peripheral that may be integral to your hardware design

  • Timing constraints based on having to share a CPU with the stack, which has its own set of requirements in order to maintain IEEE 802.15.4 and protocol compliance

If any of these constraints are too much of a deterrent, the NCP model may be a more attractive alternative.

NCP Approach with a Serial Protocol#

Note: This section does not pertain to the Bluetooth SoC or NCP models. For more information, see Using the Silicon Labs Bluetooth Stack v3.x and Higher in Network Co-Processor Mode and Silicon Labs Bluetooth C Application Developer's Guide.

In the NCP approach, a Silicon Labs chip with integrated flash, RAM, and RF transceiver runs most stack functions on its own through pre-loaded coprocessor firmware with runtime configurability, then uses a serial interface such as Serial Peripheral Interface (SPI) or Universal Asynchronous Receiver/Transmitter (UART) to communicate with a second device, known as the "host" processor, on which the application layer functionality is "hosted" separately from the core stack components. The NCP may be a special integrated circuit designed with limited I/O and reduced functionality for the express purpose of acting as a coprocessor or it may be a fully-featured microcontroller that happens to have the coprocessor firmware loaded onto it to make it behave as an NCP.

To facilitate communication between the application’s host and the stack’s NCP, Silicon Labs provides two serial command sets. The first, known as EZSP (EmberZNet Serial Protocol), is used when developing Zigbee solutions (see document UG100: EZSP Reference Guide, for more information about EZSP.) The second, known as the Connect Serial Protocol (CSP) is used when developing Connect solutions

EZSP, which operates either synchronously over SPI or asynchronously over UART (with or without flow control), mimics the EmberZNet PRO API with EZSP-specific command frames (which may sometimes differ slightly from their SoC-based counterparts in EmberZNet) and the EmberZNet-related handler functions with callback response frames. Silicon Labs provides EZSP driver source code that abstracts these serial commands and responses into a set of APIs and handler functions similar to those used in the SoC model. The application framework takes care of calling the necessary API functions and implementing the required handler functions, allowing the designer to focus on higher level application processing with client APIs and framework callbacks.

The Connect Serial Protocol (CSP) is used by a Host application processor to interact with the Connect stack running on an NCP. CSP messages are sent between the Host and the NCP over a UART interface. CSP is a binary protocol encapsulated within the ASHv3 protocol. For details on the ASHv3 protocol, see UG115: ASHv3 Protocol Reference.

The main advantage to the NCP platform is its flexibility. The host processor can be as simple as an 8-bit microcontroller, or it can be something as sophisticated as a 64-bit computer with gigabytes of memory and a Windows or Linux operating system. This means that the NCP design is well-suited to scenarios where a device is being added on or retrofitted to an existing system, such that an OEM’s expertise and intellectual property on the software and hardware side can be leveraged to speed up the design cycle and expedite time to market. Another advantage to the NCP approach is that the host can provide significantly more resources (flash and RAM) and a different peripheral set for the application than the available SoC options. This allows for development of more complex applications with new features, and protects the application from exceeding the limitations of the SoC when significant new features are added to the application.

Decoupling the stack processing from the application allows installing fixes and new features on the stack side with simple firmware updates to the NCP, without necessarily requiring any changes to the application firmware on the host. This decoupling also removes the CPU time constraints of sharing a processor with the stack. Because the NCP firmware manages the sleep state of the NCP to minimize its activity and its current consumption, only the host processor needs to be active when the application has tasks that don’t directly involve the stack. If the host processor’s active current consumption is lower than that of the SoC when the CPU is active without the radio, the total current consumed by the host and the NCP when running non-networking application tasks may actually be lower than the SoC in a comparable scenario.

The primary disadvantage to the NCP approach is the addition of a second, host, processor, which adds extra cost and PCB real estate, and may impact the device’s overall power consumption. Another tradeoff is that decoupling stack and application processing means that certain time-sensitive interactions between the stack and the application can no longer occur in "real time" and must instead occur as notifications about decisions made by the stack after the fact. Thus, the host application has fewer opportunities to decide the outcome of certain decisions as they arise. Instead, "policies" are configured on the NCP to guide stack behavior in those situations. Also, because the NCP firmware is pre-built firmware supplied by Silicon Labs, the application designer does forfeit some amount of control over how the stack behaves and how its internal resources are allocated.

Once you commit to using the NCP approach, you must then decide which host platform to use for the design. This platform may be different for the prototyping and final design stages, depending on the availability of materials and the flexibility required during the initial stages of debugging. When choosing a host platform, consider your existing expertise and available tools and resources on that platform, the cost and power consumption requirements of that platform, and the amount of memory available for application development, including any headroom needed for future enhancements. When developing a Zigbee solution, you should also consider whether to use UART or SPI for EZSP communication. EZSP-UART requires a more complex driver, generally intended for use in a POSIX-compliant operating system, with more sophisticated logic and a larger memory footprint than the EZSP-SPI driver, and its supported maximum throughput is not as high. However, the EZSP-SPI implementation requires a few more interface pins than the EZSP-UART design. (A Portable Operating System Interface (POSIX)-compliant SPI driver for EZSP is also available but is often less portable across embedded Linux operating systems than the POSIX-compliant UART driver.) Because not all microcontrollers or operating systems support SPI, architectural constraints at the host may dictate this design choice.

RCP Approach with a Serial Protocol#

On the RCP setup, the RCP implements less functionality than the NCP does, so this functionality is bridged by two components, the Zigbeed Daemon and the Co-Processor Communication Daemon (CPCD). Zigbeed runs the Zigbee networking stack on the host. It is built with a Spinel adaptation layer that translates between 802.15.4 MAC primitives and Spinel messages. Spinel messages from the Zigbeed are sent to CPCd, where they are encapsulated and forwarded to the RCP. Zigbeed also opens a virtual serial port for communicating with the host application using the EZSP/ASH protocol. The socat command line utility is used to create two virtual serial ports (PTY) and link them to each other. This allows a Zigbee host application that was built for a Zigbee NCP co-processor to interface with Zigbeed unchanged.

For more detailed information on the RCP approach, see Running Zigbee, OpenThread, and Bluetooth Concurrently on a Linux Host with a Multiprotocol RCP.

Differences in Design#

Note: This section does not pertain to the Bluetooth SoC or NCP models. For more information, see Using the Silicon Labs Bluetooth Stack v3.x and Higher in Network Co-Processor Mode and Silicon Labs Bluetooth C Application Developer's Guide.

The following table shows some of the primary differences between an SoC application and an NCP-based host application, by function.

Method Difference
Managing stack parameters, such as table sizes and allocation limits, and endpoint descriptor data, such as support clusters and profiles
SoC Mainly set up through compile-time definitions built statically into the application binary.
NCP Managed by the NCP but configured by host at runtime after bootup of NCP and before engaging in any network activity; this interval is referred to as the "Configuration" phase and allows dynamic configuration of the NCP without rebuilding its firmware.
Application reaction to events
SoC The application can react to events, such as security authentication request, an incoming data poll from a child, or a remote binding modification, in the moment and can handle events on a case-by-case basis.
NCP The host application configures policies ahead of time to pre-determine the outcome; notifications are after the fact.

Polling (for sleepy end devices that need to poll the network periodically)

The application framework takes care of the polling state machine, so the difference is negligible.
SoC The application controls when each poll occurs and chooses how to react to the result of each poll.
NCP The host application configures poll rate and failure tolerance. NCP handles polling with the configured rate, and only notifies the host when the failure rate surpasses the configured threshold.

Managing message buffers

The application framework handles SoC buffer management, so the difference is negligible.
SoC The application shares memory for packet data with the stack. Shared message buffers must be allocated by the application for outgoing message data, and by the stack for incoming or relayed message data. Buffer management process, including buffer allo- cation/deallocation and construction, can be tricky and is often the source of errors in SoC application design.
NCP NCP handles the buffer management itself and accepts / delivers message payload data as a simple array and a length argument.
Adding and Removing Core Networking and Radio Functionality
SoC When changing the core (stack) functionality in an SoC application, you need only add or remove libraries or source code from a single application. This is easily done using the application framework by changing the components to be included.
NCP If you want to change the core (stack) functionality in your host plus NCP application, you must make changes to both the host processor application and the NCP firmware. This can be slight hindrance to the application development process, but the Network Coprocessor Application Framework provides an interface to build NCP applications that include only selected pieces of core networking and radio functionality.

Security#

A number of different security aspects must be considered when implementing an IoT solution. IoT Endpoint Security Fundamentals uses the ioXt Alliance’s eight security principles as a structure for a review of those aspects. The document clearly delineates the solutions Silicon Labs provides to support endpoint security and what manufacturers and developers must do outside of the Silicon Labs framework. The decisions range from implementing product update infrastructure to the level of security offered by the application. For example, most protocols offer different security levels, with tradeoffs between security level and other features such as ease of network formation. Silicon Labs tools are designed to support the various levels of security provided by the protocol in question. Designers need to review and decide on the level required by their specific application and use cases. IoT Endpoint Security Fundamentals offers pointers to more detailed documentation to help make those decisions.