IoT development kits simplify application design

Jacktang

IoT development kits simplify application design [Copy link]

Engineers who choose to design a wireless IoT application from scratch will quickly realize that the task is difficult. First, building an IoT network 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, other functions such as writing mobile device applications and cloud code development, as well as ensuring adequate security, are relatively new skills. To
　　exacerbate the situation, IoT newbies may not have much background in hardware development based on MCU platforms. The learning curve for 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.
　　Therefore, at the top of the wish list of nearly most IoT developers is finding an easy, fast way to specify the hardware and generate the necessary code so that they can get their ideas to market as quickly as possible, which is particularly important in the rapidly changing IoT landscape.
　　Fortunately, modules are available for nearly all wireless protocols, including ZigBee, Z-Wave, Bluetooth, and Wi-Fi. These modules can be used to shorten the time to market and certification/certification time required for wireless systems. What's more, today's modules have evolved to include powerful processors that can be programmed in common languages such as Linux, C, C++, Python, and Java to manage the entire application. They further help to simplify the code development effort, as developers can rely on a packaged RF stack provided by the vendor.
　　Evaluation kits are a popular development option, as they provide pre-built components and fully functional example applications of how they will run. The development kit also already has the module’s chip properly wired up for power, grounding, and input and output signal transmission. Some of the more integrated kit options also include out-of-the-box cloud connectivity, security protections, and FCC approval in an attempt to make wireless IoT connectivity a plug-in type exercise.
　　In this blog post we’ll examine two popular IoT development kits in detail and show how a common, typical feature – a watchdog application – is easily handled in each case.
　　Connecting ZigBee to the Internet
　　Wireless connectivity is key to IoT applications, which are often a mix of Bluetooth and local gateways such as ZigBee with traditional Wi-Fi networks. Offering a maximum wireless 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 key requirement for many applications: native IP connectivity needed to connect to the Internet. In response, vendors such as Digi International offer the Xbee ZigBee Gateway, a wireless way to transparently connect dozens of ZigBee devices to the Internet.
　　Design engineers can jumpstart their development efforts to bring wireless Internet connectivity to ZigBee networks using Digi International’s Xbee ZigBee Cloud Kit (Figure 1). Designated part number XKA2C-Z7T-U, the Xbee ZigBee Cloud Kit is designed to help engineers build rapid prototypes using cloud-based data sets. The kit includes: Xbee Gateway for ZigBee to Ethernet/Wi-Fi; Xbee-PRO ZigBee 2.4-GHz module; development board with breadboard; cables and power supply; sample web application; configurable widgets and integration with Digi Device Cloud—the company’s public platform for connecting any device and communicating in both 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 meter; 10KΩ resistor; temperature sensor; potentiometer; vibration motor; and audio buzzer.
　　

　　Figure 1: Digi’s Xbee ZigBee Cloud Kit has everything you need to create a cloud-connected wireless prototype. The kit includes prototyping components such as wires, LEDs, relay resistors, and temperature sensors. (Image courtesy of Digi International) The kit is based on Digi’s Xbee ZigBee Gateway application, which allows for customization of embedded logic through the Python scripting language. The XBee Gateway features a standard Python 2.7 distribution, allowing for device-independent development and testing of applications that do not rely on Digi’s proprietary interface modules. To meet the needs of customers with varying levels of Python expertise and application complexity, many development strategies are supported that can be mixed and matched based on the developer’s needs. The Xbee Gateway also features a Linux shell interface. While the Digi ESP for Python is intended to be the primary programming interface, this interface can be used for certain programming and device management tasks.
　　Now let’s take a look at an example application from the Xbee ZigBee Cloud Kit. The watchdog functionality provided through the Xbee watchdog module exists as a safety measure. If there is a critical operation that “must” occur periodically or the system will be irreparably damaged, the application can request that a “watchdog” be established. If an application thread does not service its watchdog within the promised interval, the entire system will be rebooted. These software watchdogs can have their intervals changed if necessary, and can be removed. Obviously, the use of such software watchdogs is a last resort.
　　The following example program demonstrates the watchdog functionality: (: 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 "Steps before end..." (7)
　　time.sleep(60.0) (8)
　　print "Steps after end." (9)
　　Lesson Notes (1-9):
　　The watchdog module contains the watchdog classes needed for the program.
　　Create a watchdog object called 'test' that expires after 20 seconds.
　　Loop five times (1-5).
　　This means that our iterations...
　　...each iteration sleeps for less than the timeout, but the total time exceeds the timeout.
　　Each iteration resets the watchdog timer to 20 seconds, allowing all loops to complete.
　　Indicates that the small loop has completed. The
　　sleep interval is much longer than the timeout.
　　This print statement should not be executed because the system should have restarted due to the expiration of the watchdog timeout.
　　CC3200MCU LaunchPad?
　　Texas Instruments' SimpleLink? Wi-Fi CC3200MCU LaunchPad (part CC3200-LAUNCHXL, Figure 2) is an evaluation kit for the vendor's CC3200 wireless microcontroller. It includes a temperature sensor and an accelerometer, and with additional BoosterPack plug-in boards, it can integrate other sensors to help developers prototype their IoT applications. The LaunchPad has driver support and a software development kit (SDK) with more than 40 example applications for Wi-Fi protocols, Internet applications, and MCU peripherals.
　

　　Figure 2: The CC3200 LaunchPad is a low-cost evaluation platform for an ARM Cortex M4F-based microcontroller. It features programmable user buttons, an RGB LED for custom applications, and onboard emulation for debugging. (Image courtesy of Texas Instruments) The board can be connected directly to a PC for development tools such as the Code Composer Studio (CCS) cloud integrated development environment (IDE) and the IAR (v.7.20) embedded workbench. All sample applications in the SDK are supported on the integrated Cortex-M4 processor with the CCS IDE and without an RTOS. In addition, some applications support Free RTOS and TI RTOS. The
　　royalty-free CC3200 Embedded Wi-Fi Foundation SDK includes two main building blocks:
　　SimpleLink Library - hosts the APIs that provide connectivity capabilities.
　　Peripheral Driver Library - hosts the APIs to access the MCU's peripherals.
　　Figure 3 illustrates the various software components in the CC3200 Foundation SDK and their form factors.
　

　　Figure 3: The CC3200 Foundation SDK provides an easy-to-use framework hosted on the on-chip microcontroller to use WLAN network services, as well as a comprehensive list of drivers for interfacing with peripheral devices on the microcontroller. (Image courtesy of Texas Instruments) Application examples in the 3200 LaunchPad development kit include:
　　Email: Sends email via SMTP with a single button press, or via a user-configured email through the CLI.
　　UART Demo Application: Demonstrates usage of the UART DriverLib API. This application demonstrates a simple echo of anything the user types on the terminal.
　　I2C Demo: Demonstrates usage of the I?C DriverLib API. Provides a user interface for reading or writing to an I2C device 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 functionality supported by the general-purpose timer (GPT).
　　Camera Application: Demonstrates the camera capabilities on the CC3200 (This application requires the Camera BoosterPack.
　　Antenna Selection: Provides the option to select an antenna with more signal capabilities.
　　Power Measurement: Allows the user to measure current consumption in various low-power modes.
　　Watchdog System Demonstration Application
　　Let's take a look at how the TI development kit handles the watchdog demonstration application, which explores the use of the Watchdog Timer (WDT) DriverLib API. As expected, the WDT demonstration application generates an interrupt or reset when the timeout value is reached. As with the Digi International kit we discussed earlier, the watchdog timer is used to regain control when the system fails due to a software error or an external device failing to respond in the expected manner.
　　This watchdog system demonstration application demonstrates the WDT in a complete system with an MCU and a network subsystem. Again, the goal is to recover the entire system, including the network subsystem, in the event of a system failure. Upon exiting the watchdog reset, the system immediately requests to sleep for a short period of time and only resumes its full functionality after returning from sleep. This ensures recovery from any complex fix scenarios involving the network subsystem.
　　Explanation of the application source file
　　main - Master File LED showing watchdog functionality flashes 10 times and then stays ON.
　　pinmux - Pinmux configuration required by the application.
　　uart_if - Generic UART interface API
　　udma_if - Generic uDMA interface API
　　wdt_if - Generic watchdog interface API
　　Usage
　　In use, you first set up a serial communications application (HyperTerminal/TeraTerm, see Figure 4 below) and open a hyperterminal on the host PC with the following settings:
　　Port: Enumerated COM port
　　Baud rate: 115200
　　Data: 8 bits
　　Parity: None
　　Stop: 1 bit
　　Flow control: None
　　Next, run the reference application (Flash bin) and watch the UART terminal to understand the sequence of operations performed by the application. You will see the following display (Figure 4):
　

　　Figure 4: CC3200 watchdog system demonstration (Image courtesy of Texas Instruments) Summary
　　Building an IoT network system from scratch requires knowledge of many different technologies. To help engineers complete their projects, readily available evaluation kits provide a great way to experiment with various configurations and test applications by building a basic system. By providing step-by-step guidance, wireless module vendors enable engineers to quickly become familiar with all the value that wireless connectivity can bring to their IoT solutions, and how these complete hardware components and integrated kits allow designers to bypass the time and headache of a long development cycle.

人去搂空

Thanks for sharing!