This kit provides a
way to evaluate the ZMDI ZWIR4512 low-power wireless IPv6 modules that simplify
the creation of products that can exchange secure User Datagram Protocol (UDP)
messages in the 886 and 915 MHz bands available in the U.S. and Europe. Modules
take advantage of the "IPv6
over Low power Wireless Personal Area Networks," or 6LoPAN, stack that
operates with IEEE 802.15.4 radios. This explanation might sound complicated,
but rest easy; the modules simplify communications to the level of standard
UART-based communications and API-based C code.
The kit includes three boards, each with a ZWIR4512A module
soldered in place and a screw-on antenna (supplied). Modules can communicate
with a PC via a USB port. Traces on each board route signals from the 30-pin
SMT transceiver module to headers that give you easy access to analog and
digital I/O pins. The three modules arrived with a pre-programmed demonstration,
but before I made any connections I printed the "Getting Started
Guide" (GSG) on the included CD-ROM. I found minimal instructions about
how to run the demo at the end of the guide. They should appear earlier on.
These instructions recommend using HyperTerminal or another terminal emulator
to communicate between computers. It took only a few minutes to establish
wireless communications between two computers via HyperTerminal.
Programming the ZWIR4512 modules requires the Rowley Assoc.
CrossWorks integrated development environment, and the GSG explains how to
download and install the software and obtain a free 30-day license for the
STMicroelectronics ARM Cortex-M3 processor within each module. Rowley responded
quickly to my e-mail request for a license. The ZMDI instructions about how to
set up the CrossWorks software took extra time to understand because of
statements such as, "the ZWIR4512 library can be installed like the board
support package by double clicking." I figured out how to find the drivers
and install them. The people at ZMDI assured me they will include more setup
information in the next GSG.
After describing how to set up the Rowley tools, the GSG instructions
explained how to rebuild the demo code and download it to the boards. That
process went smoothly. Every five seconds the demo displays the 16-byte address
of a transmitting module (a "blink" message) on a PC connected to
each module. You also can type information, press ENTER, and see your
"message" appear on the other computers, too. I decided to modify the
code to remove the blink message and use only back-and-forth typed messages.
The demo code was easy to understand and well-documented, so it didn't take
long to eliminate the blink-message sections and exchange only typed messages.
ZMDI uses an application programming interface (API) that
eliminates the need to program control bits or registers in each module and
thus simplifies programming. The CD-ROM includes a well-organized 67-page
Programming Guide that clearly explains how the modules operate, API naming
conventions, and how to use the API library of 139 functions. Each API entry
includes a good description.
The radio modules use a built-in basic operating system that
handles events in a preset priority, so you use the API to create sections of
code for events or commands rather than use polling and low-level hardware
coding. The OS handles only one thread at a time, so you must write what ZMDI
calls "cooperative code." After creating a program written with the
API, you build it with the Rowley CrossWorks IDE, and download it to each
The IPv6 standard includes the IP Security (IPSec) protocol for
communication security that authenticates and encrypts each IP packet. IPSec
also lets devices authenticate each other and negotiate distribution of
cryptographic keys. The ZMDI API library includes security functions that let
you implement the IPSec operations and an IKEv2 library for management of
cryptography keys. I did not investigate these capabilities.
Sometime soon designers can control modules via Command Interface
firmware, but ZMDI hadn't completed work on this technique at review time. I
plan to explore that type of operation as soon as the company makes it
available and provides a manual.
ZMDI supplies the demo program and an Ethernet-gateway program,
but so far you have no other code to learn from or study. Additional examples
would improve the kit, as would several flow charts that show how to initialize
and set up a module for a variety of applications. The company has such
information for another module so perhaps it will provide more details for the
ZWIR4512 modules soon.
Although the ZWIR4512 modules provide analog and digital I/O
pins, ZMDI has not yet documented high-level functions that let designers use
them. One of my contacts at the company provided examples that show how to
control a digital I/O pin via the "STM32 Standard Peripheral
Library," the "Cortex Microcontroller Software Interface Standard
" (CMSIS), or the "ZWIR45x1x-GPIO" library. The latter will
control only digital I/O signals, but ZMDI has not yet released it. I
used the CMSIS method, set the PA5 pin as an output, and toggled it. You can find
explanations of the commands in the stm32f10x.h file included with the Rowley
software. Thanks go to Torsten Limberg at ZMDI for the sample code and guidance
about how to control the I/O pins.
Here is the CMSIS code to control output PA5:
// include STM32 CMSIS
header - this defines types and
structures for accessing the STM32 peripherals
// configure GPIO port A
after module-hardware reset
// set all bits of GPIO PA5 configuration to
GPIOA -> CRL &= ~ (0xf << 20);
// configure GPIO PA5 pin as an output
GPIOA -> CRL |= 1 << 20;
// toggle PA5 output with
a 1-sec period
// toggle GPIO5
GPIOA -> ODR ^= 1 << 5;
My scope showed a change on the PA5
pin every second.
If you plan to use the I/O pins via the functions given in the
stm32f10x.h file, you also should download the STMicroelectronics document,
"RM0008 Reference Manual" for the STM32F101xx, STM32F102xx,
STM32F103xx, STM32F105xx and STM32F107xx advanced ARM-based 32-bit MCUs.
Search the ST site
for part number STM32F103RC, click on "design
support," and look under the heading, "reference manuals."
The STM32F103RC MCU in the wireless modules provides I/O ports
that include digital inputs and outputs, analog inputs, SPI, USB, CAN and I2C
interfaces, as well as two UARTs, so in many designs you might not need an
external chip to control or monitor remote sensors. You could create a program
that would run in the ZMDI OS framework and wake up after a preset period or
respond to commands sent from a network controller. The forthcoming Command
Interface might provide additional I/O capabilities at remote sensor modules.
As of late May 2011, ZMDI has two U.S. distributors. One did not
have the kit in stock or in its product database. I left a message for the
second distributor but hadn't received a call as I completed this description.
U.S. readers can call William Merz in the ZMDI office (Melville,
NY) at: 631-549-2666 or send an e-mail to: firstname.lastname@example.org to connect with a kit
seller. Or for general inquiries, send e-mail to: email@example.com.