Atmel AVR2052 User manual

Atmel AVR2052: Atmel BitCloud Quick Start
Guide
Features
•Introduces Atmel® BitCloud®Software Development Kit (SDK)
•Introduces WSNDemo application
1 Introduction
This document is intended for engineers and software developers evaluating the
Atmel BitCloud ZigBee®PRO stack.
The BitCloud SDK and the supported kits serve as the perfect vehicle to evaluate
the performance and features of Atmel microcontrollers and radio transceivers as
devices in a low-power, Atmel ZigBee-compliant wireless sensor network. The SDK
provides a complete software and documentation toolkit for prototyping,
developing, and debugging custom applications on top of the BitCloud application
programming interface (API), as well as easily demonstrating ZigBee technology in
action.
This document describes how to start quickly with the BitCloud SDK by installing
development environment and programming devices with sample applications. It
also provides a short introduction to the BitCloud API. To find more detailed
information concerning application development, refer to [2].
8-bit Atmel
Microcontrollers
Application Note
Rev. 8200M-AVR-11/11

2
Atmel AVR2052
8200M-AVR-11/11
2 Overview
Atmel BitCloud is a full-featured, professional-grade, embedded software ZigBee
stack from Atmel. The stack provides a software development platform for reliable,
scalable, secure wireless applications running on Atmel microcontrollers and radio
transceivers. BitCloud is designed to support a broad ecosystem of user-designed
applications addressing diverse requirements while enabling a full spectrum of
software customization.
The BitCloud stack is fully compliant with the Atmel ZigBee PRO and ZigBee
standards for wireless sensing and control. It provides an augmented set of APIs,
which, while maintaining full compliance with the standard, offer extended
functionality designed with developers’ convenience and ease-of-use in mind.
2.1 Supported platforms
The following hardware platforms are supported by the BitCloud SDK.
Table 2-1. Supported hardware platforms.
Name in this
document
Platform
(MCU + RF)
Supported
modules
Supported
external flash
for OTAU Supported evaluation kit SDK package
ZigBit®ATmega1281
+ AT86RF230
ATZB-24-B0
ATZB-24-A2
ATZB-A24-UFL
ATZB-900-B0
AT25F2048,
AT45DB041
N/A BitCloud for ZigBit
megaRF ATmega128RFA1 N/A AT45DB041
(only 264-byte
pages)
RCB128RFA1 and
ATAVR128RFA1-EK1 with
ATSTK600 boards
BitCloud for
megaRF
XMEGA®ATxmega256A3 /
ATxmega256D3
+ AT86RF231
or
ATxmega256A3 /
ATxmega256D3
+ AT86RF212
or
ATxmega256A3 /
ATxmega256D3
+ AT86RF230
N/A AT45DB041
(only 264-byte
pages)
ATxmega card hosted on
STK®600 and RZ600 radio
boards
ATREB212ED-EK
ATREB231ED-EK
ATREB232ED-EK
BitCloud for AVR®
XMEGA
UC3 AT32UC3A0512
+ AT86RF231
N/A N/A EVK1105 BitCloud for AVR
UC3 32-bit MCUs
SAM3S ATSAM3S4C
+ AT86RF231
or
ATSAM3S4C
+ AT86RF230
or
ATSAM3S4C
+ AT86RF212
N/A N/A SAM3S-EK and RZ600 radio
boards
Atmel RF212USB-RD
Atmel RF231USB-RD
BitCloud for
SAM3S-EK

Atmel AVR2052
3
8200M-AVR-11/11
Name in this
document
Platform
(MCU + RF)
Supported
modules
Supported
external flash
for OTAU Supported evaluation kit SDK package
SAM7X AT91SAM7X256
+ AT86RF231
or
AT91SAM7X256
+ AT86RF230
or
AT91SAM7X256
+ AT86RF212
N/A N/A AT91SAM7X-EK and RZ600
radio boards
BitCloud for
SAM7X-EK
Please note that this document describes the use of the Atmel BitCloud SDK with the
specific modules and evaluation kits listed in Table 2-1. Operation of BitCloud on
supported MCU/RF combinations realized in a custom hardware application is outside
the scope of this document.

4
Atmel AVR2052
8200M-AVR-11/11
3 Getting started
This document describes how to quickly get Atmel BitCloud running. A typical starting
scenario consists of the following:
•Setting up the development environment. Note that platform-specific details are
moved to the corresponding appendix chapters, as described in Table 3-1
•Programming several devices with demonstration firmware. This topic is also
described in the corresponding appendix chapter
•Monitoring activity of a network formed by the devices, with a sample wireless
sensor network (WSN) monitor PC application provided with the SDK. This topic is
described in detail in Chapter 4
•Starting the development of new or modifying existing applications based on the
BitCloud C API, as shown in Chapter 5
The BitCloud SDK is available for several platforms, as described in Section 2.1, and
so before proceeding, select the SDK version that matches your target platform.
The majority of instructions for setting up the BitCloud stack and applications depend
on the specific platform and evaluation kit. To get started, proceed to the platform-
specific sections listed below.
Table 3-1. Hardware-specific getting started sections.
For platform Refer to Section
ZigBit 8.1
megaRF 9.1
UC3 10.1
XMEGA 11.1
SAM7X 12.1
SAM3S 13.1
After completing the installation, try running the WSNDemo application by
programming the devices with ready-to-use images, as described in Section 4.2.

Atmel AVR2052
5
8200M-AVR-11/11
4 WSNDemo application
4.1 Overview
The network and radio frequency performance of the hardware components is
demonstrated with the WSNDemo application, which is based on the Atmel BitCloud
API. This application consists of the embedded firmware, which supports functions for
coordinator, router, and end device, and the GUI visualization application,
WSNMonitor, which is run on a PC. In WSNDemo, the nodes communicate based on
a proprietary messaging protocol.
The SDK includes the WSNMonitor PC application in binary format, and the
WSNDemo embedded application is available in binary format and source code.
The source code for the WSNDemo application can be modified and extended,
making it possible to develop WSN applications for a variety of application scenarios.
WSNMonitor is described in Section 4.5. Some more details on WSNMonitor and
WSNDemo are given in [1].
With WSNDemo installed, the devices are organized into a set of nodes forming a
ZigBee PRO network.
With Atmel ZigBit development boards, end devices, routers, and the coordinator
read the sensor data from onboard light and temperature sensors, and forward
collected data to the WSNMonitor application for visualization. On Atmel XMEGA,
Atmel SAM7X, Atmel SAM3S, Atmel megaRF, and Atmel UC3 platforms, zero values
are sent to the network coordinator to emulate sensor data and demonstrate data
transmission.
End devices follow a duty cycle (that is, the microcontroller and radio transceiver are
put to sleep periodically) and wake up to transmit data to the coordinator. Using the
serial connection, the coordinator transmits the received packets, along with its own
sensor data (or emulated sensor data), to the WSNMonitor application. Those
transmitted values are displayed on WSNMonitor panes as temperature, light, and
battery level measurements.
WSNMonitor also visualizes network topology by drawing a tree of nodes that have
joined the network. For each of the nodes, parameters like node address, node
sensor information, and link quality data are displayed.
RSSI indicates a link’s current condition and is measured in dBm. The RSSI
resolution is 3dBm. LQI,a numeric parameter defined within the 0 to 255 range, is
used to measure the link quality. Larger values mean a better link, while values close
to zero indicate a poor connection.
In WSNDemo, the number of routers and end devices is limited only by the network
parameter settings.
In reference to the WSNDemo application, Section 4.3 describes how to set up and
use the boards. The user interface is described in Section 4.5.
The application is delivered with source code that demonstrates how to develop a
wireless network application using the Atmel BitCloud API, and provides a number of
useful programming templates for common application tasks. Development of custom
applications is described in Section 4.5.

6
Atmel AVR2052
8200M-AVR-11/11
4.2 Programming the boards
As a first step, WSNDemo images should be loaded onto the boards. The locations of
the WSNDemo image files are platform specific, and are provided in the “Installing the
SDK” subsection of the sections specified in Table 3-1.
The programming instructions and the sets of pre-built application images provided
with the SDK also depend on the target platform. Table 4-1 provides references to the
sections that describe how to program each target platform and evaluation kit.
Table 4-1. Platform-specific programming sections.
For platform Refer to Section
ZigBit / ZigBit Amp / ZigBit 900 8.2
megaRF 9.2
UC3 10.2
XMEGA 11.2
SAM7X 12.2
SAM3S 13.2
Running any ZigBee or ZigBee PRO application, WSNDemo included, requires that
every device in the network have a unique, 64-bit MAC address. See the appropriate
sections in Table 4-1 for how MAC addresses are assigned for each type of
supported board. In order to make initial setup easier, there are a number of pre-
compiled images provided with the SDK that can be used right away without any
modification.
Atmel ZigBit platform does not require manual assignment of MAC addresses, as the
evaluation boards are equipped with a dedicated unique ID chip or EEPROM, which
the BitCloud stack uses automatically on startup. Also, note that the default images
are configured to use a particular extended PAN ID and channel mask. To change
these parameters, the user must modify the configuration.h file included in the
project and rebuild the application. Special care must be taken by the user when
configuring an application so that each compiled image contains a unique MAC
address and all images share the same extended PAN ID and channel mask.
4.3 Running WSNDemo
Each target platform requires its own set of instruction for getting the WSNDemo
application to run. Table 4-2 provides references to the sections with platform-specific
instructions.
Table 4-2. Platform-specific WSNDemo sections.
For platform Refer to Section
ZigBit 8.4
megaRF 9.4
UC3 10.4
XMEGA 11.4
SAM7X 12.4
SAM3S 13.4

Atmel AVR2052
7
8200M-AVR-11/11
4.4 Network startup
The coordinator organizes the wireless network automatically. Upon starting, every
node informs the network of its role.
When the coordinator is powered on, it switches to an active state even though no
child node is present. This is normal, and it indicates that the coordinator is ready and
that child nodes can join the network with the coordinator’s extended PAN ID. By
default, the coordinator uses extended PAN ID 0xAAAAAAAAAAAAAAAA, which is
recognized by all routers. A short PAN ID is chosen at random. The extended PAN ID
can be modified by the user through the application’s configuration.h file.
NOTE If the coordinator is absent or has not been turned on, the routers and end devices
will remain in the network search mode. In this mode, routers scan the channels
specified in the channel mask in search of a network with the specified extended PAN
ID.
By default, the channel mask for all application images provided with the SDK
contains a single channel. In rare cases, if the frequency corresponding to the radio
channel is busy, the coordinator node may stay in the network search mode. If this
happens, it may become necessary to change the application’s channel mask to
select another channel by changing the application’s configuration.h file and
recompiling the application.
Network health can be monitored by looking at the individual node’s LED state (LED
states are platform specific, and are described in platform-specific sections noted in
Table 4-2) or through the WSNMonitor application described in the next section.
4.5 WSNMonitor
WSNMonitor is a PC counterpart to the WSNDemo embedded application, and can
be used to display ZigBee network topology and other information about a wireless
sensor network. A typical WSNMonitor screen is shown in Figure 4-1. It contains
topology, sensor data, and node data panes and application toolbars.

8
Atmel AVR2052
8200M-AVR-11/11
Figure 4-1. WSNMonitor GUI.
The topology pane displays the network topology in real time, which helps the user
monitor the formation of and dynamic changes in the network while nodes join, send
data across, or leave the network. The network topology is constructed on the basis
of next-hop information for each of the nodes, and each link is also tipped with RSSI
and LQI values. Each of the nodes displayed is depicted by an icon, with the node’s
address or name below and sensor readings to the right of the icon, if required by
settings.
The sensor data pane displays data coming from onboard sensors of the selected
node (see Section 4.5.2). It is presented in graph and table form. Other parameters
can be observed for each node in table form. The node data pane includes a sensor
selection combo-box, which is used to switch between sensor types.
By default in the topology pane, nodes are labeled with their short addresses.
However, another title can be assigned to any desired node by a double click. If
“Cancel” is pressed in the opened window, the node’s title is set back to the short
address.
4.5.1 Node timeouts
The Window/Preferences menu of WSNMonitor contains a number of parameters
used to control application behavior. Timeouts are used to tune visualization of
coordinator, routers, and end devices as the nodes disappear from the network each
time a connection is lost, power is down, or a reset has occurred. A node timeout
corresponds to the time the WSNMonitor application waits for a packet from a

Atmel AVR2052
9
8200M-AVR-11/11
particular node before assuming that the node is no longer part of the network. Note
that this value does not correspond to the frequency with which data are transmitted
by each type of device. To get smooth topology visualization, setting timeouts to 20
seconds is recommended for coordinator and router, and 30 seconds is
recommended for an end device. Assuming a default application configuration, these
timeouts cover three periods between sending a packet, and so at least three packets
would need to be lost before a node is removed from the WSNMonitor topology pane.
Figure 4-2. WSNMonitor preferences menu.
4.5.2 Sensor data visualization
Each board sends temperature/light/battery sensor readings (or emulated values) to
the coordinator, which in turn sends it to the PC. WSNMonitor displays the readings
from onboard sensors next to a node icon inside the topology pane. A corresponding
option can be selected in the node/link parameters from the quick settings toolbar.
The user can select any node in the topology pane to monitor the node’s activity and
see the node data in one of three different forms:
•Text table
•Chart
•The onboard sensor’s data displayed next to each node in the topology pane.
These values are also tipped with arrows indicating whether the value increased
or decreased in relation to the previous sample
NOTE A given node is selected when it is clicked on and a dashed frame is visible around it.
The same values are shown on the sensor data pane, enabling the user to observe
how the values change over a period of time.
The sensor data pane includes a sensor selection combo-box. Use the button on the
sensor control toolbar to display the desired types of sensor data.
4.5.3 Over-the-air upgrade
Over-the-air upgrade (OTAU) can be executed on supported hardware platforms by
loading a special version of the WSNDemo application with OTA support. This
demonstration also requires an additional in-network device to perform the role of the

10
Atmel AVR2052
8200M-AVR-11/11
upgrade server, which is the device that sends new firmware images to other devices
on the network. For this purpose, a device programmed with the Runner application is
used. Such device is able to receive and process commands from a PC over the
serial link. To control the Runner device, the Bootloader PC tool included into the
Atmel Serial Bootloader package is used (see Chapter 6). Pre-built images of the
Runner application for various configurations are provided with the SDK and are
located in the \Evaluation tools\Runner directory.
The details of compiling and running WSNDemo with OTAU support differ for each
platform. Please refer to the appropriate section listed in the table below for platform-
specific instructions.
Table 4-3. Platform-specific settings for WSNDemo with OTAU support.
For platform Refer to Section
ZigBit 8.4.3
megaRF 9.4.3
XMEGA 11.4.3
After WSNDemo device(s) with OTAU support are configured, programmed and
joined to the network, follow the step-by-step instructions below to execute an over-
the-air upgrade:
1. Connect the Runner device to the PC.
2. Start the Bootloader PC tool (from the Microsoft®Windows®Start Menu, select
Atmel > Bootloader > Bootloader):
a. On the OTAU tab, select the network parameters, as shown in Figure 4-3.
b. Specify Connection settings to match the port where the Runner device
is connected.
c. Click the Init button to force the program to collect information about the
node’s configuration; for example, security settings or network
parameters.
d. Click the Set keys button to manually set keys; for example network key,
TC link key, public and private keys.
e. The utility will automatically populate the list of devices that support OTA
functionality (that is, applications that include OTA cluster). By default,
only devices programmed with WSNDemo with OTA support should be
shown in the list, as seen in Figure 4-4.
3. Start the Image Converter PC utility (from Windows Start Menu, select Atmel >
Bootloader > Converter):
a. Select the *.srec image(s) you wish to upload to a remote, OTA-capable
device over the air.
b. Fill in image metadata information in the fields below and click Convert.
4. Return to the Bootloader PC tool:
a. Click on the Update button next to the device information.
b. In the Open File dialog, select the *.zigbee file that was converted in
step 3.
c. Click OK, and the upload process will begin. It usually takes 5-10 minutes
to upload a single image to a router device; sleeping end device upgrade
may last considerably longer.
d. Once the image is uploaded, the progress bar indicating the upload
progress will be replaced with the button. The device will not reset and
switch to the new image, until the command for this is sent by pressing
this button.