Any Internet of Things (IoT)-based business model depends on reliable and secure wireless communications from the army of edge nodes through to cloud-based analytics and control applications. Faced with designing microcontroller-based sensors and actuators, the developer is well equipped with a host of MCU development platforms and tool chains. Provisioning the wireless communication has in the past not been as easy to achieve. Faced with regional regulatory wireless approvals, the need to use or build your own validated wireless protocol stacks and the complexities of everything RF, the design engineer often adopts a pre-approved wireless module rather than face the challenges of building a discrete design.
Meeting both the wireless connectivity and the relatively low compute needs of IoT edge nodes and sensors is a new breed of wireless MCUs and modules for which no additional MCU host is required. These host-less, or standalone, devices and modules are both speeding and simplifying the whole design process. However, it is not just the availability of a suitable module that will satisfy the developer’s needs. In today’s product development environment, the embedded engineer does not have the time to learn the full capabilities of the module from scratch. Increasingly, the availability of software drivers, code snippets and evaluation platforms are as important as the capabilities of the device. The quicker a developer can get the device communicating to the cloud, the more likely it will get into the market and be a commercial success.
An example of a wireless MCU that ticks all the boxes is the CC3200 SimpleLink™ series of devices from Texas Instruments. Complementing the SimpleLink devices is a complete ecosystem of evaluation boards, code examples and a comprehensive SDK. Available in a variety of package sizes, the CC3200 integrates an ARM® Cortex®-M4 application microcontroller running at 80 MHz with an 802.11 b/g/n Wi-Fi network processor subsystem. This second subsystem has its own dedicated ARM MCU core that serves to offload all Wi-Fi communication stacks from the application MCU.
Figure 1: CC3200 hardware overview block diagram.
Optimized for battery-based IoT designs, the CC3200 has a host of other features such as battery management functions and a comprehensive set of peripheral interfaces including GPIO, UART, SPI, PWM and a 4-channel 12-bit ADC. The main feature set is illustrated in Figure 1. With 256 kB RAM, the CC3200 also has a hardware 256-bit crypto engine for fast AES, DES and 3DES encryption together with SHA2 and MD5 authentication capabilities. With its own power management subsystem with integrated DC-DC converters it is not only able to accommodate a wide range of supply voltages, but also control the low power consumption modes; the lowest taking the device into a hibernate mode with the RTC still running. In this mode it consumes less than 4 μA.
Figure 2: CC3200 embedded software overview.
Another perspective of the CC3200 is shown in Figure 2, that of the devices embedded software capabilities. The Wi-Fi subsystem supports Station, Access Point and Wi-Fi Direct modes along with WPA2 Personal and Enterprise security and WPS 2.0. TCP/IP, TLS/SSL and HTTP server stacks embedded on-chip.
The full extent of the CC3200’s capabilities can be seen in Figure 3, highlighting the GPIO and peripheral interfaces, power management, and the relatively small number of additional passive components necessary.
Figure 3: CC3200 functional block diagram.
The thought that has gone into the design of the CC3200 can be understood when you investigate the pin multiplexing capabilities of the device. A popular way to accommodate a large number of peripheral interface functions within the smallest package size possible, pin multiplexing allows mapping of the peripheral set to specific pins. Pin multiplexing is achieved through a combination of hardware configuration and register control. Full details of this process and the mapping options available are documented in the TI CC3200 datasheet. To aid the design process, TI has created a table of recommended pin multiplexing configurations for a number of different use cases (Figure 4). This approach helps shape the design at an early stage across a broad range of applications, making full use of the peripheral set and the available pinout.
|CC3200 Recommended Pinout Grouping Use - Examples(1)|
|Home Security High-End Toys||Wi-Fi Audio ++ Industrial||Sensor-Tag||Home Security Toys||Wi-Fi Audio ++ Industrial||Wi-Fi Remote w/ 7x7 keypad and audio||Sensor Door-Lock Fire-Alarm Toys w/o Cam||Industrial Home Appliances||Industrial Home Appliances Smart-Plug||Industrial Home Appliances"||GPIOs|
|External 32 kHz(2)||External 32 kHz(2)||External TCXO 40 MHz (-40 to 85°C|
|Cam + I2S (Tx or Rx) + I2C + SPI + SWD + UART-Tx + (App Logger) 2 GPIO + 1 PWM + *4 overlaid wakeup from Hib||I2S (Tx or Rx) + 1 Ch ADC + 1x 4wire UART + 1x 2wire UART + 1bit SD Card + SPI + I2C + SWD + 3 GPIO + 1 PWM + 1 GPIO with Wake-From-Hib||I2S (Tx or Rx) + 2 Ch ADC + 2wire UART + SPI + I2C + SWD + 2 PMW + 6 GPIO + 3 GPIO with Wake-From-Hib||Cam + I2S (Tx or RX) + I2C + SWD + UART-Tx + (App Logger) 4 GPIO + 1PWM + *4 overlain wakeup from Hib||I2S (Tx & Rx) + 1 Ch ADC + 2x 2wire UART + 1bit SD Card + SPI + I2C + SWD + 4 GPIO + 1 PWM + 1 GPIO with Wake-From-Hib||I2S (Tx & Rx) + 1 Ch ADC + UART (Tx Only) I2C + SWD + 15 GPIO + 1 PWM + 1 GPIO with Wake-From-Hib||I2S (Tx & Rx) + 2 Ch ADC + 2 wire UART + SPI + I2C + 3 PMW + 3 GPIO with Wake-From-Hib + 5 GPIO SWD +||4 Ch ADC + 1x 4wire UART + 1x 2wire UART + SPI + I2C + SWD + 1 PWM + 6 GPIO + 1 GPIO with Wake-From-Hib Enable for Ext 40 MHz TCXO||3 Ch ADC + 2wire UART + SPI + I2C + SWD + 3 PWM + 9 GPIO + 2 GPIO with Wake-From-Hib||2 Ch ADC + 2wire UART + I2C + SWD + 3 PWM + 11 GPIO + 5 GPIO with Wake-From-Hib|
|Pin Number||Pinout #11||Pinout #10||Pinout #9||Pinout #8||Pinout #7||Pinout #6||Pinout #5||Pinout #4||Pinout #3||Pinout #2||Pinout #1|
Figure 4: CC3200 recommended pin multiplexing configurations.
If you wish to incorporate the CC3200 device into your application, there are a number of development options available to you. Apart from designing your own PCB for the application, you could opt to use the CC3200 module that includes a screened CC3200, supporting passive components, crystals, and chip antenna in a compact module measuring just 20.5 x 17.5 x 1.5 mm.
Assisting in prototyping the CC3200 module is the CC3200 LaunchPad XL evaluation board (Figure 5). Capable of being connected directly to a PC via USB, together with JTAG emulation for Flash programming, the board hosts a selection of user LEDs, push buttons, an accelerometer, and a temperature sensor.
Figure 5: CC3200 LaunchPad XL evaluation board.
TI has a number of resources dedicated to the SimpleLink family, including product pages, software development Wiki, and pages dedicated to cloud ecosystem partners. The SimpleLink SDK is downloadable from the Wiki and provides a host of example applications, application source code and technical information. TI recommends a number of industry-respected IDEs for use with the SDK; these being their own Code Composer Studio and IAR Workbench. Include and header files are provided too, along with GCC make scripts and other library functions. Code examples are well documented with a written description of the application, key configurable parameters and how it operates. For each, the complete set of source code and header files is included in C. One example showcases the CC3200 communicating with the site ‘openweathermap.org’ to request the weather details for a specific city and then displays it on a connected Hyperterminal. See the output of this in Figure 6.
Figure 6: Output from CC3200 Get Weather Application.
Other code samples cover the implementation of MQTT Client/Server application, an email demo and a sensor-based design that makes full use of the hibernate mode.
While the application examples provided within the CC3200 SDK focus on the use of C/C++, there are plenty of other options available. One such alternative is MicroPython. Based around the Python 3 interpretive programming language, MicroPython is the result of a successfully funded Kickstarter campaign that is optimized for use on microcontrollers. A network ready version of MicroPython fully supports the CC3200 device and can be downloaded from that site.
The CC3200 SimpleLink approach to provisioning Wi-Fi communication and an application processor has gained wide support across the IoT marketplace. One such example by IBM highlights connecting a CC3200 LaunchPad to IBM’s Watson IoT Foundation Platform through the use of MQTT. Other cloud platform ecosystem partners include Temboo and Xively.
Another family of pre-certified standalone Wi-Fi modules is the Bluegiga WF121 series from Silicon Labs (Figure 7). Like the CC3200 it has two main component parts, an application microcontroller which uses a Microchip PIC32-series 32-bit microcontroller running at 80 MHz and a 2.4 GHz 802.11 b/g/n-compliant radio. Full details on this series together with reference guides and application examples can be found here.
Figure 7: Silicon Labs Bluegiga WF121.
Communication between the host and wireless transceiver is via UART, USB or SPI, as indicated in Figure 8. This also illustrates the software architecture. While is it possible to use the BGLib ANSI C host library to program applications for the microcontroller, it is also possible to use Bluegiga’s scripting language BGScript. Based around a BASIC-style programming structure, the language provides a simple and easy to learn way of creating fairly complex and powerful applications. The language provides commands and functions for setting up and managing wireless links, security, data transfer and interacting with the available peripherals, GPIO, SPI, I2C etc.
Figure 8: Bluegiga software environment.
BGScript can also be used across the whole standalone Bluegiga family of modules, including those providing Bluetooth connectivity. Figure 9 illustrates a short BGScript code example of reading the module’s ADC.
Figure 9: BGScript example to read ADC.
The Bluegiga DKWF121 is an evaluation board for prototyping Wi-Fi standalone designs using the WF121 module. The board hosts all the available pinouts of the module making it easy to connect to trial designs. All the GPIO pins are presented on pads around a large prototyping area. A useful online catalog page providing all getting started information about the DKWF121 can be found on the Digi-Key site.
As mentioned earlier, the Bluegiga family also comprises standalone Bluetooth modules such as the BLE113. Targeted at small, battery-powered applications and accessories, application development using BGScript provides an extremely convenient and easy-to-use way of establishing a link and transferring data. The Bluegiga product line-up is well supported by the broader IoT developer and pro-maker community, which has led to libraries being available to support other development languages such as bglib for Node.js and bgapi_py for Python. Figure 10 shows the simplicity of using the Node.js library to parse incoming Bluetooth data into its separate variables.
Figure 10: Parsing Bluetooth incoming data using Node.js BGLib library on Bluegiga BLE113 module.
Using a pre-certified wireless module greatly speeds the design of an IoT application, but using a standalone wireless module further simplifies the whole design process as well as reducing the overall BOM. When investigating this approach embedded engineers are recommended to not only review the hardware capabilities but the amount of software tools, flexibility of programming language, and application examples available. With this approach standalone IoT devices can quickly be brought to market, saving valuable design resources and budget.