Engineers who choose to design wireless IoT applications from the ground up learn quickly that this task is difficult. For starters, building an IoT networked system from scratch requires knowledge of many different technologies including wireless protocols, embedded code development, and device driver development. While many experienced engineers may already be familiar with these technologies, additional abilities such as writing mobile device applications and cloud code development, as well as ensuring adequate levels of security, are relatively new skills.
Aggravating the situation is the fact that IoT newcomers may not have a lot of background in hardware development on MCU-based platforms. The learning curve of APIs, programming, hardware, and software compatibility as well as regulatory licensing and other hurdles can translate into weeks or months of engineering work just to create a functional prototype.
As a result, near the top of most IoT developer’s wish list is finding a simple, quick way to specify hardware and produce the necessary code so they can get their ideas to market as fast as possible, which is particularly important in the rapidly-changing IoT arena.
Fortunately, modules are available for just about every wireless protocol including ZigBee, Z-Wave, Bluetooth, and Wi-Fi. These modules can be used to reduce both time-to-market and the qualification/certification time needed for wireless systems. What is more, today’s modules have evolved to incorporate powerful processors that can be programmed via commonly used languages such as Linux, C, C++, Python and Java, to manage the entire application. They further help simplify the code development effort since developers can rely on the packaged RF stacks provided by the supplier.
Evaluation kits are a popular development option here since they provide pre-made elements and fully-functional examples of how an application will run. Dev kits also already have the module’s chips properly connected for power, ground and input and output signal transfers. Some of the more integrated kit choices also include cloud connectivity, security protection and FCC approval right out of the box in an attempt to make the inclusion of wireless IoT connectivity a plug-in type of exercise.
In this article we will examine in detail two popular IoT development kits and show how a common and typical feature —the watchdog app—is easily handled in each case. All technologies, parts and development systems referenced in this article can be found on the Digi-Key website.
Connecting ZigBee to the Internet
Wireless connectivity is key to IoT applications, typically blending local gateways such as Bluetooth and ZigBee with traditional Wi-Fi networks. Offering a maximum over-the-air 250-kbps data rate and a range of up to 100 meters, ZigBee has become a popular solution for industrial systems and sensor networks. However, ZigBee lacks a crucial requirement for many applications: native IP connectivity needed for attachment to the Internet. In response, suppliers such as Digi International offer the Xbee ZigBee Gateway, a wireless way for dozens of ZigBee devices to connect transparently to the Internet.
Design engineers can jumpstart their development efforts to bring wireless Internet connectivity to ZigBee networks by using Digi International’s Xbee ZigBee Cloud Kit (Figure 1). Designated part number XKA2C-Z7T-U, the Xbee ZigBee Cloud Kit was created to help engineers build rapid prototypes using cloud-based data sets. The kit includes: the Xbee Gateway for ZigBee to Ethernet/Wi-Fi; the Xbee-PRO ZigBee 2.4-GHz module; a development board with breadboard; cables and power supplies; sample Web applications; configurable widgets and Integration with the Digi Device Cloud—the company’s public platform for connecting any device and communicating in two directions from anywhere.
The kit also enables remote control of devices and data through a customizable open-source dashboard application. Basic prototyping components include: LED gauges; 10 KΩ resistors; a temperature sensor; potentiometer; vibration motor; and an audio buzzer.
Figure 1: Digi’s Xbee ZigBee Cloud Kit has everything needed to create a cloud-connected wireless prototype. The kit includes prototyping components such as wires, LEDs, relay resistors and a temperature sensor. (Image courtesy of Digi International)
Built around Digi’s Xbee ZigBee Gateway Application, the kit allows custom embedded logic via the Python scripting language. The XBee Gateway has a standard Python 2.7 distribution, allowing applications that are not dependent on Digi-proprietary interface modules to be developed and tested independently of the device. To meet the needs of customers with varying levels of Python expertise and application complexity, a number of development strategies are supported, which can be mixed and matched as a developer sees fit. The Xbee Gateway also features a Linux shell interface. While Digi ESP for Python is intended as the main programming interface, this interface may be used for some programming and device management tasks.
Let’s now take a look at an example application from the Xbee ZigBee Cloud Kit. The watchdog feature, provided through the Xbee watchdog module, exists as a safeguard. If there are critical operations that “must” happen periodically, or else the system will be irretrievably broken, an application can request that a “watchdog” be established. If the application threads do not service their watchdog within the promised interval, the entire system reboots. These software watchdogs can have their intervals changed, if necessary, and can be deleted. Clearly, use of such a software watchdog exists as a measure of last resort.
The following sample program demonstrates the watchdog feature: (Source: Digi International)
import watchdog (1)
import time
w=watchdog.Watchdog(‘test’,20) (2)
for x in xrange(1,6): (3)
print “Step “, x (4)
time.sleep(10.0) (5)
w.heartbeat() (6)
print “Step just before the end…” (7)
time.sleep(60.0) (8)
print “Step after the end.” (9)
Program notes (1-9):
- The watchdog module includes the Watchdog class needed by the program.
- Create a watchdog object named “test” that will expire in 20 seconds.
- Loop five times (1-5).
- Indicate our iteration…
- … sleeping less than the timeout on each iteration, but more time than the timeout in total.
- Reset the watchdog timer to 20 seconds each iteration, allowing all of the loops to complete.
- Indicate that small loops are complete.
- Sleep for an interval much longer than the timeout.
- This print statement should never be executed, as the system should have rebooted due to the watchdog timeout expiration.
The CC3200MCU LaunchPad™
Texas Instruments’ SimpleLink™ Wi-Fi CC3200MCU LaunchPad (part CC3200-LAUNCHXL , Figure 2) is an evaluation kit for the supplier’s CC3200 wireless microcontroller. It includes a temperature sensor and an accelerometer and through add-on BoosterPack plug-in boards it enables integration of additional sensors to help developers prototype their IoT applications. The LaunchPad has driver support and a software development kit (SDK) with more than forty applications for Wi-Fi protocols, Internet applications and MCU peripheral examples.
Figure 2: The CC3200 LaunchPad is a low-cost evaluation platform for ARM® Cortex® M4F-based microcontrollers. It features programmable user buttons, RGB LED for custom applications, and onboard emulation for debugging. (Image Courtesy of Texas Instruments)
This board can be directly connected to a PC for use with development tools such as the Code Composer Studio (CCS) cloud integrated development environment (IDE) and IAR’s (v.7.20) Embedded Workbench. All sample applications in the SDK are supported on the integrated Cortex-M4 processor with CCS IDE and no RTOS. In addition, a few of the applications support Free RTOS, and TI RTOS.
The royalty-free CC3200 Embedded Wi-Fi Foundation SDK includes two main building blocks:
- SimpleLink Library – hosting APIs that serve the connectivity features.
- Peripheral Driver Library – hosting APIs to access MCU peripherals.
Figure 3 illustrates the various software components and their form in the CC3200 Foundation SDK.
Figure 3: The CC3200 Foundation SDK provides an easy-to-use framework hosted in the on-chip microcontroller to use WLAN networking services, along with a comprehensive listing of drivers for peripherals interfaced with the microcontroller. (Image Courtesy of Texas Instruments)
Application examples in the 3200 LaunchPad dev kit include:
- Email: Sends email through SMTP either at the push of a button, or via a user-configured email through the CLI.
- UART Demo Application: Showcases the usage of UART DriverLib APIs. The application demonstrates a simple echo of anything the user types on the terminal.
- I2C Demo: Showcases the usage of I²C DriverLib APIs. Provides a user interface to read-from or write-to the I2C devices on the LaunchPad.
- MCU Sleep: Exercises the sleep functionality of the MCU.
- PWM Demo Application: Demonstrates the general 16-bit pulse-width modulation (PWM) mode feature supported by general purpose timers (GPTs).
- Camera Application: Demonstrates the camera feature on the CC3200 (this application requires the camera BoosterPack).
- Antenna Selection: Gives the option to select an antenna with more signal capability.
- Power Measurement: Allows the user to measure the current consumption for various low-power modes.
Watchdog system demo application
Let’s take a look at how the TI dev kit handles the Watchdog Demo Application, which explores the usage of watchdog timer (WDT) DriverLib APIs. As expected the WDT demo app generates an interrupt or a reset when a time-out value is reached. As with the Digi International kit we discussed earlier, the watchdog timer is used to regain control when a system has failed due to a software error or due to the failure of an external device to respond in the expected way.
This Watchdog system demo application showcases the WDT in a complete system with an MCU and a networking subsystem. Again, the objective is to recover the full system, including the network subsystem whenever the system fails. On exit from watchdog reset, the system immediately requests hibernate for a short duration and resumes its full functionality only after returning from hibernate. This ensures recovery from any complex stuck-at scenario that involves the networking subsystem.
Application source files explained
main - Main file that showcases the watchdog functionality with LED blinking 10 times and then remains in ON state.pinmux - Pinmux configurations as required by the application.uart_if - Common UART interface APIsudma_if - Common uDMA interface APIswdt_if - Common watchdog interface APIs
Usage
In use you first set up a serial communication application (HyperTerminal/TeraTerm, see Figure 4 below) and on the host PC open a hyperterminal, with the following settings:
Port: Enumerated COM portBaud rate: 115200Data: 8 bitParity: NoneStop: 1 bitFlow control: None
Next, run the reference application (Flash the bin) and observe the UART terminal to understand the sequence of operations performed by the application. You’ll see the following display (Figure 4):
Figure 4: CC3200 Watchdog System Demo (Image Courtesy of Texas instruments)
In summary
Building an IoT networked system from scratch requires knowledge of many different technologies. To help engineers get their projects going, readily available evaluation kits provide a great way to experiment with various configurations and test applications through building basic systems. By also providing step-by-step guidance, suppliers of wireless modules allow engineers to quickly become familiar with all the value that wireless connectivity can bring to their IoT solutions, as well as how these complete packages of hardware components and integration tools can let designers sidestep the time and headaches of lengthy development cycles.
