“Market demand for smart, connected products presents a vast opportunity for developers who can quickly turn concepts into viable Internet of Things (IoT) applications. Power-efficient processors, a variety of optional wireless connectivity, and a wide range of hardware peripherals provide a solid foundation for a suitable, production-ready, low-power design.
Author: Stephen Evanczuk
Market demand for smart, connected products presents a vast opportunity for developers who can quickly turn concepts into viable Internet of Things (IoT) applications. Power-efficient processors, a variety of optional wireless connectivity, and a wide range of hardware peripherals provide a solid foundation for a suitable, production-ready, low-power design.
However, in the early stages of product definition, developers need a flexible development platform to rapidly build prototypes based on peer-to-peer processors, connected subsystems and peripherals. The ability to quickly build working prototypes and easily add functionality is critical to providing early proof-of-concept and supporting custom software development.
This article shows how developers can use Silicon Labs hardware and software, as well as a host of off-the-shelf expansion boards, to quickly prototype specialized energy-efficient interconnected IoT devices.
Enable rapid prototyping
When exploring the new possibilities of battery-powered wireless IoT devices, developers can find themselves bogged down in the details of building an effective development platform. With their integrated subsystems, advanced system-on-chip (SoC) devices can provide such a core platform, but developers still need to build complete systems around these devices.
To build a suitable development platform for these devices, developers not only need to meet the basic requirements of robust performance and longer battery life, but also need to achieve flexibility to meet the specific requirements of each application. Silicon Labs’ BGM220-EK4314A Explorer Kit meets this combination requirement, allowing developers to focus on rapid prototyping of new design concepts without having to deal with the various details involved in building a development platform.
Flexible Rapid Development Platform
The BGM220-EK4314A Explorer Kit is a low-cost platform for developing various applications based on Bluetooth, which integrates SiLabs’ BGM220P Wireless Gecko module (BGM220PC22HNA), 1 onboard SEGGER J-Link debugger, 1 button, 1 light Diodes (LEDs) and various expansion options (Figure 1).
Figure 1: The SiLabs BGM220-EK4314A Explorer Kit enables rapid prototyping to evaluate the processing performance, power management capabilities, and configuration flexibility required for different peripheral hardware configurations. (Image credit: Silicon Labs)
The BGM220P module can be used as a complete solution for small battery powered IoT devices. Its integrated EFR32BG22 Blue Gecko SoC features ultra-low power consumption, Bluetooth Angle of Arrival (AoA) and Angle of Departure (AoD) capabilities, and sub-1-meter positioning accuracy—all required for more and more popular Bluetooth applications, Including asset tracking tags, smart door locks, fitness and other applications.
The BGM220P module operates as a stand-alone system, combining the EFR32BG22 SoC with 512KB Flash, 32KB random access memory (RAM), high frequency (HF) and low frequency (LF) crystals (XTAL), and a 2.4 GHz matching for wireless connectivity The network and ceramic antenna are combined (Figure 2).
Figure 2: The SiLabs BGM220P module is available as a stand-alone system that integrates the EFR32BG22 Blue Gecko SoC with other components required to implement a Bluetooth device. (Image credit: Silicon Labs)
In addition to being a stand-alone host for small IoT designs, the module can also act as a Network Co-Processor (NCP) to the host processor connected via its UART interface. The module’s integrated Bluetooth stack performs wireless services for applications running on the module in stand-alone designs, or handles commands received from the host when running in NCP designs.
Energy Efficient Wireless SoC
The BGM220P module’s EFR32BG22 Bluetooth wireless SoC integrates a 32-bit ArmCortex-M33 core, a 2.4GHz radio, security, energy management subsystems, and multiple timer and interface options. Designed for ultra-low power, battery-powered devices, the EFR32BG22 SoC features a variety of energy management features that enable 10-year coin cell battery operation.
Powered by a single external voltage, the SoC uses its internal energy management unit to generate the internal supply voltage. During operation, the transition between the five energy modes (EMs) of the SoC is controlled by the energy management unit. When the SoC transitions from active mode (EM0) to sleep mode (EM1), deep-sleep mode (EM2), stop mode (EM3), or shutdown mode (EM4), each mode furthers by maintaining a decreasing number of active function blocks Reduce power consumption (Figure 3).
Figure 3: The energy management unit of the EFR32BG22 SoC controls transitions between energy modes EM0, EM1, EM2, EM3, and EM4 (color codes are below the picture). (Image credit: Silicon Labs)
In active mode (EM0) at 76.8 MHz and 3 V, using its internal DC/DC converter, the SoC consumes 27 μA/MHz. EM0 is the normal operating mode and the only mode where the Cortex M33 processor core and all peripheral modules can be used.
All peripherals are available in sleep mode (EM1), and fewer peripherals remain active when the system enters a lower power mode. In low-power mode, the reduction in the number of active clocks and functional blocks results in a significant reduction in power consumption levels:
・ In sleep mode (EM1): 17 μA/MHz
・ Deep Sleep Mode (EM2): 1.40μA, 32KB RAM reserved, Real Time Clock (RTC) running through LFXO
・ In stop mode (EM3): 1.05 μA, 8KB RAM reserved, RTC running through SoC integrated ultra-low frequency 1 kHz Resistor Capacitor (RC) Oscillator (ULFRCO)
・ 0.17 μA shutdown mode (EM4)
Some battery-powered devices require more than the ability to run the processor in low-power operating modes. Many Bluetooth-enabled applications are typically infrequently active or inactive for long periods of time, but require a low-latency response when reinstating the active state. In fact, even if an application has more relaxed latency requirements, a slow wake-up operation wastes power because the processor does not complete the wake-up process and enter active mode (or complete the process of going from a high-power mode to a low-power mode) without will do any useful work.
As the time between active states decreases, using a low-power sleep mode can even be beneficial when slowly waking up or entering a power mode that consumes more energy than maintaining a high-power mode during periods of inactivity. reaction. As a result, developers working to optimize battery life sometimes maintain processors in higher power modes to meet application processing demands.
By using a processor with faster wake-up and power-in times, developers can take advantage of the processor’s low-power modes more fully. In EM1, the EFG32BG22 wakes up in three clocks/1.24 μs with an entry time of 1.29 μs, which stretches to 8.81 ms and 9.96 μs in EM4, respectively (Table 1).
Table 1: Wake-up and power-mode entry times for the EFG32BG22 SoC. (Image credit: Silicon Labs)
The method used to wake the processor when reactivated can also significantly affect battery life. While some applications, such as industrial applications, require the system to use polling processing to ensure strict periodic timing, many applications in the consumer space use event-based processing in response to specific activities. For example, using a polling approach for event-based applications can significantly impact battery life when the processor is repeatedly woken up unnecessarily.
Many sensor-based designs use a “wake-on-interrupt” feature to avoid repeatedly waking up the processor just to check activation status. Likewise, a similar interrupt-driven approach is employed in the built-in “RF Wake-up” function of the EFG32BG22 SoC radio subsystem. This allows developers to keep the processor in a lower power energy mode until a radio frequency (RF) activation condition occurs.
In practice, developers put the EFG32BG22 wireless SoC into ultra-low-power EM2, EM3, or EM4 modes and rely on the “Wake-on-RF” feature to wake the SoC when RF energy is detected. When limited to detecting energy above a threshold, RFSENS consumes 131 nA. RFSENSE mode is more selective and consumes slightly more current at 138 nA, but in this mode RFSENSE filters the incoming RF signal, ensuring that it wakes up on the presence of a valid RF signal rather than RF noise.
In some cases, the EFG32BG22 SoC may not need to wake up the processor core at all in response to external events: SiLabs’ Peripheral Reflex System (PRS) enables peripherals to react to events and operate without waking up the processor core. There can be direct communication between peripherals, and their functions can be combined to achieve complex functions. By using the PRS function with a lower energy mode, developers can significantly reduce power consumption without affecting critical functions such as sensor data acquisition.
Built-in debugging function, easy to extend
Built into the BGM220 Explorer Kit board, the BGM220P module brings the full power management and processing capabilities of the EFR32BG22 SoC to battery powered Bluetooth designs. When rapid prototyping is required to explore new design concepts, the board’s other features help speed development.
Accessed via the on-board USB Micro-B interface, the on-board SEGGER J-Link debugger enables code download and debugging as well as a virtual COM port for host console access. The debugger also supports SiLabs’ Packet Trace Interface (PTI) feature for analyzing packets transmitted or received over a wireless network.
When used for rapid prototyping, the board supports a variety of expansion options, providing flexibility to explore new design ideas that require different combinations of sensors, actuators, connectivity options, and other peripherals. With a wide range of mikroBUS expansion boards and Qwiic Connectivity System hardware from multiple vendors, developers can quickly configure a development platform for each application.
After plugging into the board’s mikroBUS socket, the mikroBUS board can be connected to the BGM220P module via I2C, SPI or UART interface. The Qwiic connector provides the Qwiic system’s I2C interface for connecting one or more Qwiic boards over distances up to 4 feet. For longer distance connections, developers can use the SparkFun QwiicBus EndPoint Board (COM-16988), which uses differential signaling to maintain I2C signal integrity for connections up to 100 feet long.
Rapid application development
SiLabs applies the concept of rapid expansion to application software development. In addition to board support packages, drivers, libraries, and header files for custom development, the company provides several example applications bundled in the Simplicity Studio development environment, as well as others available from SiLabs’ GitHub repository project. In fact, developers can use the bundled temperature application samples as an entry point to explore the development of sensor applications. This example uses the EFR32BG22 SoC’s internal temperature sensor as the data source.
The temperature application is built around the standard Bluetooth health temperature service and demonstrates the processing flow directly through a generic Bluetooth IoT application based on the SiLabs software architecture. The application calls a series of initialization routines for system services, application services that set up interrupt handling and callback capabilities. After initialization, the app enters an endless loop waiting for an event to occur (Listing 1).
Listing 1: SiLabs’ Bluetooth sample application uses a generic execution framework, where an infinite loop allows callback functions and event handlers to handle system and application behavior after initialization. (Code source: Silicon Labs)
In this application, an associated callback routine takes the temperature measurement when the timer set during initialization counts down. Once developers have built their application and lighted up the board, they can use the SiLabs EFR Connect app—a universal Bluetooth mobile app that works with all Silicon Labs Bluetooth kits and devices. In addition to providing a framework for customizing the application, the application also assists development by providing a view of supporting properties related to Bluetooth services, such as the Bluetooth Health Thermometer service used in this example application (Figure 4).
Figure 4: The SiLabs EFR Connect application displays the characteristics of the Bluetooth services used in an application, which not only speeds up prototyping but also provides a framework for custom application development. (Image credit: Silicon Labs)
In Simplicity Studio, developers can import a number of different Bluetooth application examples showing various usage scenarios, including designs using Qwiic or mikroBUS boards alone or in combination. For example, the sample application demonstrates the use of a standard Bluetooth heart rate (HR) pulse oximeter (pO2) service with MikroElektronika’s MIKROE-4037 Heart Rate 2 Click mikroBUS board, which includes Maxim Integrated’s MAX86161 biosensor. The MAX86161 provides a complete low-power subsystem capable of providing accurate heart rate and SpO2 measurements to a host processor connected through its I2C interface. (For details on using the MAX86161, see Building a True Wireless Fitness Hearable – Part 1: Heart Rate and SpO2 Measurements).
This application demonstrates a more complex IoT device software application architecture due to the need for additional drivers and more demanding processing algorithms than the temperature application (Figure 5).
Figure 5: Sample projects such as the HR/SpO2 application help speed up prototyping and show a typical process flow for a Bluetooth low energy sensor application. (Image credit: Silicon Labs)
Like the temperature application mentioned above, this application relies on a series of initialization routines to set up system and application services. In the temperature application, the routine app_process_action is empty, this application adds a call to the routine hrm_loop in app_process_action. This will cause hrm_loop to be called each time the top-level infinite loop shown in Listing 1 is passed. In addition, HR and SpO2 data are periodically updated using a software timer.
The hrm_loop routine in turn calls maxm86161_hrm_process, which takes samples from a queue maintained by a helper function and passes them to the sample processing routine. This in turn calls a pair of routines: maxm86161_hrm_frame_process and maxm86161_hrm_spo2_frame_process, which execute algorithms to validate and generate HR and SpO2 results, respectively. Developers can use the EFR Connect app mentioned above to view results and other service characteristics.
Another software application example shows how developers can build on complex applications, such as the HR/SpO2 application here, when extending their hardware platform. Building around existing hardware and software is relatively straightforward using the BGM220-EK4314A Explorer Kit board and the SiLabs software ecosystem. SiLabs demonstrates this approach with a sample application that adds an OLED Display to the hardware/software platform of the HR/SpO2 application described above. In this example, SparkFun’s OLED Display Qwiic Expansion Board (LCD-14532) is connected to the board’s Qwiic connector, while the MikroElektronika Heart Rate 2 Click Expansion Board is from the previous HR/SpO2 sample application (Figure 6).
Figure 6: Developers can quickly add functionality to an existing design built on the BGM220-EK4314A Explorer Kit board – in this case adding an OLED display to an existing HR/SpO2 prototype. (Image credit: Silicon Labs)
The software application for this extended version of the HR/SpO2 application remains largely unchanged, except for the addition of a driver and support service for the OLED panel. The previously mentioned software timer for the HR/SpO2 application adds a call to the function hrm_update_display to display HR and SpO2 data (Listing 2).
Listing 2: Using this kit and software ecosystem, developers can make existing The HR/SpO2 application adds display functionality. (Code source: Silicon Labs)
This scalable hardware and software approach enables developers to rapidly build IoT working applications. Because both hardware and software are easy to add or remove, developers can more easily explore new design options and evaluate alternative configurations.
Battery-powered Bluetooth IoT devices are at the heart of popular applications and are a key enabler in meeting the ongoing market demand for more functionality and longer operating life. For developers to effectively meet these conflicting needs, the ability to rapidly explore new designs and evaluate alternative design concepts is essential. Using Silicon Labs’ development kits and associated software, developers can quickly build prototypes, adding and removing hardware as needed to meet specific application requirements.