Components#

The GSDK v3.x platform introduced a mechanism – called the component library – that empowers developers to leverage existing, proven implementations of desired functionality. The GSDK v3.x and Simplicity Studio 5 (SSv5) were architected from the ground up to support this modular component-based approach to rapid and robust application development.

In Flex SDK v3.x, Silicon Labs Connect (both the stack and application framework) has been reformulated to integrate seamlessly with this component architecture – the Connect-specific elements are accessible to applications in the same way as other components (like the Power Manager for sleep mode transitions, board support for Silicon Labs development kit hardware, and so on) through the SOFTWARE COMPONENTS tab in the Project Configurator.

Provided as either a standalone pre-compiled library or a set of source code, each component adds a specific feature set to the project. Use the Project Configurator to install desired (or uninstall unwanted) components to add (or remove) the associated code and libraries to/from the build. Many components have configurable options, which can be adjusted directly in the underlying header files or conveniently managed using the Component Editor. Reference information on component descriptions and behaviors – including component dependencies and dependents – is also easily accessible from the Project Configurator.

More information on using the component library is available in the Simplicity Studio 5 User's Guide, available through SSv5 and online at https://docs.silabs.com.

Connect Features in the Component Library#

This section describes some of the Connect components currently available. For a complete and current list (including inter-component dependencies), see the SOFTWARE COMPONENTS tab of a Connect project using the latest Flex SDK. These components can be found beneath the top-level "Connect" group, as shown in the following figure.

v3x Connect groupv3x Connect group

MAC and Network Layer Components#

The component library includes the following Media Access Control (MAC) and Network layer Connect components:

  • AES Security

  • Frequency Hopping

  • MAC Queue

  • Parent Support

  • Stack Common

AES Security: Enables nodes to exchange secured messages with IEEE 802.15.4 mode-5-like or mode-5 MAC encryption/authentication using Mbed TLS. This takes advantage of hardware-accelerated AES support on EFR32 devices. Install this component only if the application will use/supports AES security.

Frequency Hopping: Allows nodes to communicate while rapidly switching channels in a pseudo-random fashion, thereby reducing channel interference which aids in regulatory compliance. For more information, see U435.03: Architecture of the Silicon Labs Connect Stack v3.x.

MAC queue: Some applications need to submit multiple messages to the Connect stack. This component provides dynamic memory allocation functionality and permits messages to be queued and sent out as soon as possible according to the submission order and/or priority. Without this component installed, the Connect stack can only process one message transmit request at a time.

Parent Support: Provides parent features such as indirect communication (communication with sleepy devices), child table, and routing table support. It should be installed for any coordinator or range extender node intended to support multiple end-device and/or sleepy end-device nodes. To save flash/RAM, star end devices, direct devices, or MAC devices should not install this component. The Parent Support component is also discussed in Energy Saving with Silicon Labs Connect v3.x.

Indirect queue support buffers packets destined for sleepy child devices.

The child table allows a star coordinator or a star range extender to support multiple child devices. Child devices are aged and eventually removed. The child information table is stored in non-volatile memory (NVM) and requires (n*11) Bytes token space, where n is the configured child table size. For more information, see Connect Application Dependency on Non-Connect Components. The child table size of a coordinator is limited to 64, while the range extender child table sizes are limited to 32.

A routing table is needed for star coordinator applications in extended star networks (that is, the network includes star range extenders). It stores the information collected from star range extenders.

Stack Common: Provides Connect Stack common functionalities such as 15.4-like MAC layer, events system, dynamic memory allocation, and other required infrastructure functions. It also provides the stack configuration file, which allocates all the sizable RAM data structures. Should be installed in any Connect application.

Application Framework Components#

The optional Connect Application Framework components are used to manage application layer functionality as follows:

  • Mailbox

    • Mailbox client

    • Mailbox server

  • Application Framework Common

  • Debug Print

  • Frequency Hopping (CLI)

  • CMSIS Stack IPC

  • Poll

  • Stack Counters

Mailbox: A server/client service that allows client nodes to submit messages to, and retrieve messages from, a server node. An application-layer protocol (as opposed to the indirect queue, which is provided by the MAC layer), the Mailbox component supports much longer timeouts (default 1 hour, can be set to days) than the indirect queue (between 8 and 30 seconds). The Mailbox component is not supported in MAC mode. The Mailbox feature is also discussed in Energy Saving with Silicon Labs Connect v3.x.

Application Framework Common: Declares all the required application framework globals, initializes the Connect stack and dispatches stack callback calls as needed to the application components.

Debug Print: Provides APIs for adding serial debugging capability (printf-style printing from the application).

Frequency Hopping (CLI): Provides frequency hopping CLI commands.

CMSIS Stack IPC: Provides an IPC (Inter-process communication) for the Connect stack APIs. If this component is installed, the stack will be running within an RTOS (Real time operating system) as an RTOS task and the application framework will run as a separate task. APIs are invoked at the application framework using an IPC. Similarly, stack callbacks are communicated to the application framework task using an IPC. For more information, see Using Real Time Operating Systems with Silicon Labs Connect v3.x.

Poll: Manages periodic polling for end devices. Regular end devices need to exchange some sort of traffic with the parent as a keep-alive mechanism, also referred to as a long poll interval. Star sleepy end devices need to poll the parent for incoming packets, also referred to as a short poll interval. Star end devices are in long poll mode by default. The application can switch to short poll mode when appropriate using the component API. For instance, a star sleepy end device sends out a packet that expects a response. The application then switches to short poll mode until the expected response is received. The Polling component is also discussed in Energy Saving with Silicon Labs Connect v3.x.

Stack Counters: Provides stack packet counters functionality. If this component is installed, the Connect stack keeps track of successful and failed transmissions as well as successful received packets and dropped incoming packets.

Bootloader-Related Components#

Connect provides the following components that either directly implement or support the Connect Over-the-Air (OTA) bootloader functionality. For more in-depth coverage of this feature set, see U435.06: Bootloading and OTA with Silicon Labs Connect v3.x.

Note: OTA Bootloader components are not supported in MAC mode.

  • OTA

    • OTA Broadcast Bootloader Client

    • OTA Broadcast Bootloader Server

    • OTA Unicast Bootloader Client

    • OTA Unicast Bootloader Server

  • Test

    • OTA Bootloader Test Common

    • OTA Broadcast Bootloader Test

    • OTA Unicast Bootloader Test

  • OTA Bootloader Interface

Bootloader Interface : Provides a set of APIs for interacting with the Gecko Bootloader.

OTA Bootloader Server components implement the server side of the OTA bootloader protocol. They include all the functionality to distribute an image to one or multiple target devices (clients) and to instruct one or more clients to perform an image bootload operation at a certain time in the future.

OTA Broadcast Bootloader Server: The broadcast server version, meant for multiple clients.

OTA Unicast Bootloader Server: The unicast server version, meant for a single client.

OTA Bootloader Client components implement the client side of the OTA bootloader protocol. They include all the functionality to download an image from an OTA bootloader server and to be instructed to perform an image bootload at a certain time in the future.

OTA Broadcast Bootloader Client: The broadcast client version that assumes there are multiple clients receiving the same image simultaneously.

OTA Unicast Bootloader Client: The unicast client version that assumes only one client is receiving the image from the server.

OTA Bootloader Test components provide test code to demonstrate how to perform flash read/write/erase operation locally and how to use the OTA Bootloader Server/Client components to perform an OTA bootloading operation. These components also support a set of CLI commands.

OTA Bootloader Test Common: The common part of the bootloader tests which contains the CLI commands for the external Flash part operations, as well as functions that work the same way for broadcast and unicast (for example, setting the image tag on the client side).

OTA Broadcast Bootloader Test: The broadcast-specific bootloader test functions, such as CLI commands for setting up the target devices, starting the distribution, and requesting a bootload from the targets.

OTA Unicast Bootloader Test: The unicast-specific bootloader test functions. The same as above but different CLI commands with some differences to those in the broadcast commands.

Connect Application Dependency on Non-Connect Components#

With the advent of GSDK v3.x and its unified approach to platform modularization and configuration, prior support for some Connect-specific implementations of common features has been replaced by universal stack-agnostic solutions elsewhere in the component library. This includes the (former) Idle/Sleep and NVM "plugins". Note: Developers who have worked previously with Connect in SDKs prior to v3 should consult AN1254: Transitioning from the v2.x to the v3.x Proprietary Flex SDK.

Device energy mode transitions are now overseen by the Power Manager component. For more information, see Energy Saving with Silicon Labs Connect v3.x.

Connect applications require emulated nonvolatile memory support. Silicon Labs provides a number of such solutions, located in the Services component group (NVM3 is strongly recommended). These libraries simulate an EEPROM within the internal flash of the chip to maximize the lifetime of flash pages and reduce write cycles by wear leveling writes across the flash. This NVM is used for persistent storage of tokens for the network (automatically managed by the stack) and application layers (the application can add its own tokens).

These tokens incur the following hardware requirements:

  • SimEEv1: 8 kB flash is used to provide 2 kB token space

  • SimEEv2: 36 kB flash is used to provide 8 kB token space

  • NVM3 (strongly recommended): Configurable storage with at least three flash pages

  • All versions: 47 bytes of token space are consumed by the Connect stack. For end devices this represents the complete token storage footprint. Coordinators and range extenders can require up to an additional 704 bytes due to the Parent Support component (n * 11 bytes, to support up to n children, where n is between 0 and 64).

For more information, see AN703: Using Simulated EEPROM Version 1 and Version 2 for the EFR32 SoC Platform; AN1135: Using Third Generation Non-Volatile Memory (NVM3) Data Storage; and AN1154: Using Tokens for Non-Volatile Data Storage.