dcsimg
Skip to end of metadata
Go to start of metadata

Background

Atmel provides a variety of wireless MCU solutions in the 802.15.4 platform.  They provide multiple RF transceiver solutions in the 2.4GHz band and the 700/800/900MHz band.  These radios can be very easily interfaced with any of Atmel's AVR or SAM microcontrollers through the digital SPI port.  Atmel also provides single chip RF solutions which combine the microcontroller and RF transceiver into a single chip. 

ZigBit modules combine these wireless MCU solutions with an approved antenna interface in an easy to implement platform.  Using ZigBit modules can save the developer time and money by not having to pursue quite as much FCC testing.  Atmel also provides wireless stacks and example code in Atmel Studio for these ZigBit modules.  The purpose of this page is to familiarize the user with these modules and the differences between them.

Quick Comparison

Easiest to Use
ATmega256RFR2 ZigBit
Highest Performance / Most Flexible
ATxmega256A3U / AT86RF233 ZigBit
Highest Transmit Power / Link Budget
AT86RF233 Amplified ZigBit


  • 8-bit MCU with Integrated 802.15.4 RF Transceiver
  • Up to 100.6 dB link budget
  • Up to +3.6 dB TX power
  • -97 RX sensitivity
  • Up to 2 Mb/s data rate
  • Integrated Chip Antenna
  • MS-147 RF Test Port
  • Up to 256KB Flash, 8KB EEPROM, 32KB SRAM

  • On-board High Performance 8-bit MCU
  • On-board 802.15.4 RF Transceiver
  • Up to 99.6 dB link budget
  • Up to +3.6 dB TX power
  • -96 RX sensitivity
  • Up to 2 Mb/s data rate
  • Integrated Chip Antenna
  • MS-147 RF Test Port
  • Up to 256KB Flash, 4KB EEPROM, 16KB SRAM
  • Flexible Clock options and sleep modes

 


  • 802.15.4 RF Transceiver
  • Integrated Power Amplifier
  • Low-noise Amplifier
  • Up to 124 dB link budget
  • Up to +20 dB TX power
  • -104 RX sensitivity
  • Up to 2 Mb/s data rate
  • Integrated Chip Antenna
  • MS-147 RF Test Port
  • Interface with any host microcontroller with SPI

Part Number

Part Number

Part Number

Development Tool

Development Tool

Development Tool

Software Links/Downloads

Software
  • Atmel Studio 6.x  -  Free code development suite.  Fully supports Atmel devices and programmers/debuggers.
  • Atmel BitCloud  -  Free ZigBee PRO compliant (mesh network) wireless stack for Atmel AVR devices.
  • RF4Control -  Free ZigBee RF4CE wireless stack for Atmel AVR devices.
  • Atmel Lightweight Mesh  -  Free Atmel proprietary mesh network wireless stack for AVR devices.
  • IEEE 802.15.4 MAC  -  Free MAC wireless stack for Atmel AVR devices.
  • AVR2054: Serial Bootloader  -  Free UART/SPI/TWI Bootloader with PC upload application (need to scroll about halfway down the page)
  • Tera Term  -  Free Serial Terminal Emulator (open source) for Windows.  Useful for sending AT commands.
Software Documentation

Jump to Top

Programming Options

Every ZigBit module is supposed to ship with the Serial Bootloader image installed.  Refer to the following tables for available Bootloader interfaces.  USART1 is the default interface for ATmega256RFR2.  USARTD0 is the default interface for ATxmega256A3.  If you wish to use a non-default interface, the configuration.h file (in the Embedded_Bootloader_src folder) needs to be modified to define which port(s) you wish to use for the Bootloader.  Any or all of the interfaces can be enabled at the same time, except for the TWI.  If using TWI, it is the only interface that can be selected to ensure proper functionality.  If multiple ports are enabled, the Bootloader will scan the various ports until one responds.  Using JTAG, ISP, or PDI will overwrite the installed bootloader.  However, the Bootloader can be reinstalled using one of the other programming protocols.  At the time of this writing, Serial Bootloader v2.2.0 was used.

The following tables present a breakdown of the various ways to program the ZigBit modules.  The tables show which and how many pins are required for each programming interface as well as any Atmel Tools that can be used for that specific protocol.  The reader is encouraged to fully read through the referenced documentation.

ATmega256RFR2 ZigBit
Programming ProtocolZigBit PinsInternal MCU PinsProgramming ToolsUseful DocumentationAdditional Notes
JTAG30-33, 5, 3, 1PF[7:4], Reset, Vcc, Gnd

JTAGICE3
JTAG mkII
AVR ONE!
AVR Dragon

ATmega256RFR2 Datasheet Section 31.10
Programmer/debugger user guide
JTAGEN Fuse must be programmed (programmed by default).

Serial (ISP)7-9, 5, 3, 1PB[3:1], Reset, Vcc, GndJTAGICE3
JTAG mkII
AVR ONE!
AVRISP mkII
AVR Dragon
ATmega256RFR2 Datasheet Section 31.9
Programmer/debugger user guide
N/A
Serial Bootloader (USART0)22-23, 1PE[1:0], GndBootloader PC Tool
USB/UART Bridge Cable
AVR2054 - Serial Bootloader User Guide
FTDI Bridge Cable User Guide
Need external USB/UART bridge device.
Baud/Frame: 38400, none, 1, none
Serial Bootloader (USART1)13-14, 1PD[3:2], GndBootloader PC Tool
USB/UART Bridge Cable
AVR2054 - Serial Bootloader User Guide
FTDI Bridge Cable User Guide

Need external USB/UART bridge device.
Baud/Frame: 38400, none, 1, none

Serial Bootloader (TWID)36-37, 1PD[1:0], GndBootloader PC ToolAVR2054 - Serial Bootloader User Guide

Need external USB/TWI bridge device
Slave address 0x55

Parallel ProgrammingN/AN/AN/AN/ACurrently unsupported: PB5 not mapped to module pins.

ATxmega256A3U ZigBit
Programming ProtocolZigBit PinsInternal MCU PinsProgramming ToolsUseful DocumentationAdditional Notes
JTAG30-33, 3, 1PB[7:4], Reset, Vcc, Gnd

JTAGICE3
JTAG mkII
AVR ONE!
AVR Dragon

Programmer/debugger user guideJTAGEN Fuse must be programmed (programmed by default).
Serial (PDI)16, 5, 3, 1PDI_DATA, PDI_CLK, Vcc, Gnd

JTAGICE3
JTAG mkII
AVR ONE!
AVRISP mkII
AVR Dragon

Programmer/debugger user guideN/A
Serial Bootloader (USARTF0)22-23, 1PF[3:2], GndBootloader PC Tool
USB/UART Bridge Cable
AVR2054 - Serial Bootloader User Guide
FTDI Bridge Cable User Guide
configuration.h must be modified to use this port for Serial Bootloader.
Serial Bootloader (USARTD0)13-14, 1PD[3:2], GndBootloader PC Tool
USB/UART Bridge Cable
AVR2054 - Serial Bootloader User Guide
FTDI Bridge Cable User Guide
This is the default port for the Serial Bootloader.
Serial Bootloader (SPIE)N/AN/AN/A

N/A

Currently unsupported due to pin overlap with 32kHz crystal.
Serial Bootloader (TWIC)16-17, 1PC[1:0], GndBootloader PC ToolAVR2054 - Serial Bootloader User GuideTWI and USART cannot be enabled simultaneously.
configuration.h must be modified to use this port for Serial Bootloader.
Serial Bootloader (TWIE)N/AN/AN/AN/ACurrently unsupported due to pin overlap with Radio SPI port.

Jump to Top

Clock Options

This section attempts to cover all of the available clock options for the ZigBit modules.  Peripheral clock trees are not extensively covered.

ATmega256RFR2 ZigBit

The device core clock source is set by fuse bits with an external programmer/debugger and cannot be changed at run-time.  The device core can be clocked by the following on-board sources:

    • Internal 16MHz RC Oscillator
    • External 16MHz Crystal Oscillator
    • External 0-16MHz clock signal
    • 128kHz Internal RC Oscillator

The modules ship with the Internal 16MHz RC Oscillator selected as the clock source with the CLKDIV8 fuse programmed, making the default clock frequency 1MHz.  Fuse-bits are non-volatile, so if the user changes the clock source, it will persist as the selected clock source until it is manually changed by the user.

The external 16MHz crystal is used by the integrated RF transceiver.  However, it does not need to be selected as the core clock source.

If clocking the device with an external 0-16MHz clock signal (pin 38), the module should be held in reset until the clock signal is stable.  Changes >2% on the clock signal could lead to unstable operation (unpredictable behavior).

The 128kHz internal RC oscillator serves as the only clock source for the Watchdog Timer.  However it can also be used as the core clock.

The maximum allowable core frequency is 16MHz regardless of Vcc level.  A system clock prescaler (CLKPS) register allows the user to divide the source clock to lower frequencies, which can decrease power consumption.  The CLKPS register can safely be written at run-time without causing unstable operation.  The value written to CLKPS will have different effects depending on the selected clock source.  See ATmega256RFR2 datasheet, sec 11.11.2 for details.

The module also has an on-board 32.768kHz crystal that can be used as the source for Timer2 (not as the core clock source).  This allows Timer2 to run asynchronously to the core.  This oscillator can be kept running in all sleep modes except Standby and Power-Down.  If enabled in sleep mode, Timer2 can be used as a wake-up source.

 

ATxmega256A3U ZigBit

Core Clock

Unlike the ATmega256RFR2 ZigBit, the ATxmega256A3U Zigbit core clock source can be safely changed at run-time.  The device core can be clocked by the following on-board sources:

    • Internal 32MHz RC Oscillator
    • Internal 2MHz RC Oscillator
    • Internal 32.768kHz Oscillator
    • External 32.768kHz crystal oscillator
    • CLKM output from Radio (1, 2, 4, 8, or 16MHz)
    • Internal PLL with 1-31 multiplier

Additionally, the following clock sources can be used as inputs to the PLL:

    • Internal 32MHz RC Oscillator divided by 4
    • Internal 2MHz RC Oscillator
    • External 32.768kHz crystal oscillator
    • CLKM output from Radio (1, 2, 4, 8, or 16MHz)

On power-up or after power-on-reset, the internal 2MHz oscillator is always selected as the system clock source.  The clock source and prescalers can be changed at any time by software. 

See the figure below for maximum core clock frequency vs. Vcc.

Real Time Counter

The ATxmega256A3U includes an asynchronous timer that can be used for RTC applications.  The ZigBit module contains a 32.768kHz crystal that can be used to source the RTC.  Alternatively, the internal 32.768kHz oscillator or the 32kHz internal Ultra Low Power (ULP) oscillator can be used to source the RTC.  The ULP oscillator is a very low power source with low accuracy.  It wouldn't be recommended for RTC applications, but could be selected for general purpose asynchronous timer applications.  The ULP oscillator is the only clock source available for the Watchdog timer.

USB

The ATxmega256A3U supports USB device functionality.  The USB clock can be sourced from the internal 32MHz oscillator or from the output of the PLL (available clock inputs to PLL are listed above).  Therefore, the USB clock can be run asynchronously to the core clock.  By default the USB clock is disabled.

Jump to Top

Power Reduction and Sleep Modes

ATmega256RFR2 ZigBit

The ATmega256RFR2 ZigBit has a total of 6 available sleep modes to choose from.  Which sleep modes you implement will depend on which peripherals you need to remain on (if any), what you've selected as the core clock source, and what type of wake-up source you are using.  Each sleep mode presents different power consumption vs. wake-up time characteristics as well as available peripherals.  The device supports the following sleep modes:

    • Idle Mode - shuts down CPU and Flash clocks.  All peripherals continue running in this mode.  Idle mode is useful if you are waiting for a serial packet from an external device.
    • ADC Noise Reduction Mode - improves noise level for ADC readings.  This isn't used as much for power reduction (although that is a nice side effect) as it is for noise reduction.  The CPU, flash clock, and all digital peripherals are shut down in this mode which allows for cleaner ADC readings.
    • Extended Standby Mode - only used when 16MHz crystal is selected as core clock source. 16MHz crystal is kept running in this mode.  This allows for very fast wakeup time.  It's typically used when waiting for an RF packet to come in.
    • Standby Mode - only used when 16MHz crystal is selected as core clock source.  16MHz crystal is kept running and the 32kHz oscillator is disabled in this mode.  Like Extended Standby, this mode allows very fast wakeup time, but doesn't waste unnecessary power on the 32kHz oscillator if it's not being used anyway.
    • Power Save Mode - All peripherals are disabled except asynchronous Timer2.  Power Save and Power Down have the longest wakeup times, but save the most power.  Timer2 can be used to wake the device from Power Save mode.
    • Power Down Mode - All peripherals are disabled including the asynchronous Timer2, therefore it saves a little more power than Power Save mode.  If you don't need Timer2 running while in sleep mode, you should use Power Down mode.

See section 12 of the ATmega256RFR2 datasheet for details on sleep modes and wake-up sources.

The device also includes power reduction registers for turning off unused peripherals in active and idle modes.

ATxmega256A3U ZigBit

The ATxmega256A3U has a total of 5 available sleep modes to choose from.  Which sleep modes you implement will depend on which peripherals you need to remain on (if any), what you've selected as the core clock source, and what type of wake-up source you are using.  Each sleep mode presents different power consumption vs. wake-up time characteristics as well as available peripherals.  The device supports the following sleep modes:

    • Idle Mode - shuts down system clock and Non-Volatile Memory clocks.  All enabled peripherals continue running in this mode.
    • Extended Standby Mode - system clock and RTC are kept running in this mode.  This allows for very fast wakeup time.
    • Standby Mode - system clock is kept running in this mode but the RTC is disabled.  Like Extended Standby, this mode allows very fast wakeup time, but doesn't waste unnecessary power on the RTC if it's not being used anyway.
    • Power Save Mode - System clock and all peripherals are disabled except RTC.  Power Save and Power Down have the longest wakeup times, but save the most power.  RTC can be used to wake the device from Power Save mode.
    • Power Down Mode - All peripherals are disabled including the RTC, therefore it saves a little more power than Power Save mode.  If you don't need RTC running while in sleep mode, you should use Power Down mode.

See section 8 of the XMEGA-AU manual for details on sleep modes and wake-up sources.

The device also includes power reduction registers for turning off unused peripherals in active and idle modes.

Jump to Top

Tutorials

The following tutorials are meant to help you get started developing code for the ZigBit modules.  They are separated by module type and are presented in order of complexity.  Each of the tutorials builds on previous examples.  If you have no prior experience with Atmel AVR devices, it is recommended that you start with the first tutorial and work your way through each of them in order.  If you have significant experience with Atmel AVR, feel free to jump ahead to any of the wireless examples to get your wireless communication working quickly.  Each of the tutorials was written using Atmel Studio 6.1.

ATmega256RFR2 ZigBit

The RFR2 ZigBit Xplained PRO attachment (ATZB-256RFR2-XPRO) was used as the platform for each of these examples.  The board was powered through the 20-pin connector using a 3.0V bench supply.  All of the following examples use the JTAGICE3 as the programmer.  However, you can use any of the Atmel Programmers/Debuggers listed in the Programming Options section above.  For these tutorials, the module was programmed using JTAG through the J2 header.

 

 Blinky LED

This is a simple "Getting Started" tutorial for the ATmega256RFR2 ZigBit module.  It demonstrates basic GPIO functionality, and introduces a 16-bit timer with interrupt.  It also shows how to configure the 8-bit asynchronous timer (Timer2) which runs off the 32kHz crystal.

Objectives

  • Introduce user to a simple "getting started" tutorial
  • Setup a basic 16-bit synchronous timer with interrupt
  • Setup the 8-bit asynchronous timer with interrupt
  • Toggle LEDs based on timer interrupt execution

Requirements

  • One ATZB-256RFR2-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 installed
  • Optional: 2 jumper wires for power connection (jumper wire kits)

Procedure

  1. Download the following Blinky_LED project for Atmel Studio 6.1.
  2. Extract the contents of the downloaded folder (7-zip or Filzip are 2 free options).
  3. Open the Blinky_LED project in Atmel Studio 6.1.
  4. Connect your debugger/programmer to the Xplained PRO board.
  5. Connect the Xplained PRO board to a 1.8-3.3V power supply.  Use the 20-pin right-angle Xplained PRO connector, pin 2 for GND and pin 20 for Vcc.
  6. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  7. This project bases its timing on a 1MHz system clock.  The RFR2 ZigBit ships with the internal RC oscillator selected as the clock source and the CKDIV8 fuse programmed.  This creates a system clock of 1MHz.  The user should verify these settings:
    • In Atmel Studio, in the menu bar, navigate to:  Tools  ->  Device Programming
    • In the "Tool" dropdown, select your debugger/programmer (I'm using "JTAGICE3"). 
    • Select "ATmega256RFR2" in the "Device" dropdown.  Select your debug interface (I'm using "JTAG")
    • Click "Apply".
    • On the left side of the Device Programming dialog box, select "Fuses". 
    • Ensure that the CKDIV8 box is checked and the CKSEL_SUT option is "INTRCOS_6CK_65MS" (may have to scroll to view all fuses).  
    • Click "Program" and close the Device Programming dialog box.  The system should now be running off the internal RC oscillator at 1MHz if it wasn't already. 
  8. Save and build Blinky_LED in Atmel Studio 6.1.
  9. Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.
  10. Verify the yellow on-board LED is toggling every half second.
  11. Verify the green on-board LED is toggling every second.

 Using the 16MHz Crystal

The ATmega256RFR2 differs from previous mega microcontrollers in the fact that it has a 16MHz internal RC oscillator instead of an 8MHz internal RC oscillator.  Switching between the internal 16MHz RC oscillator to an external 16MHz crystal requires some specific configuration. 

The value in the Clock Prescaler register will have different effects depending on the System Clock Source.  By default, the CLKPR register contains 0x00, regardless of clock source.  A value of 0x00 will give a division factor of /2 when using the internal RC oscillator, while 0x00 will give a division facter of /1 for all other clock sources.  

If the user wants to switch from the internal 16MHz RC oscillator to the external 16MHz crystal, the CLKPS3:0 bits must be changed accordingly within the CLKPR register from application code to ensure proper timing.  Note that the value written to the CLKPR register will override the CKDIV8 fuse.  See section 11.11.2 of the ATmega256RFR2 datasheet for full explanation and a table of division factors.

Objectives

  • Change the system clock source from the default 16MHz internal RC oscillator to the external 16MHz crystal that's loaded within the RFR2 ZigBit module.
  • The same Blinky_LED project from above will be used and the blink rate of the LED will be used to indicate changes in System Clock.

Requirements

  • One ATZB-256RFR2-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 installed
  • Optional: 2 jumper wires for power connection (jumper wire kits)

Procedure

  1. Download the following Blinky_LED project for Atmel Studio 6.1.
  2. Extract the contents of the downloaded folder (7-zip or Filzip are 2 free options).
  3. Open the Blinky_LED project in Atmel Studio 6.1.
  4. Connect your debugger/programmer to the Xplained PRO board.
  5. Connect the Xplained PRO board to a 1.8-3.3V power supply.  Use the 20-pin right-angle Xplained PRO connector
    • Connect pin 20 to Vcc
    • Connect Pin 2 to GND
  6. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  7. Verify that the device is running off the 16MHz internal RC oscillator at 1MHz:
    • In Atmel Studio, in the menu bar, navigate to:  Tools  ->  Device Programming
    • In the "Tool" dropdown, select your debugger/programmer (I'm using "JTAGICE3").
    • Select "ATmega256RFR2" in the "Device" dropdown.  Select your debug interface (I'm using "JTAG")
    • Click "Apply".
    • On the left side of the Device Programming dialog box, select "Fuses".
    • Ensure that the CKDIV8 box is checked and the CKSEL_SUT option is "INTRCOS_6CK_65MS" (may have to scroll to view all fuses). 
    • Click "Program" and close the Device Programming dialog box.  The system should now be running off the internal RC oscillator at 1MHz if it wasn't already.
  8. Save and build Blinky_LED in Atmel Studio 6.1.
  9. Program the RFR2 ZigBit and verify the yellow on-board LED is toggling every half second.
  10. Verify the green on-board LED is toggling every second.
  11. Now change the System Clock Source from the 16MHz internal RC oscillator to the 16MHz crystal that's loaded within the RFR2 ZigBit:
    • In Atmel Studio, navigate to:  Tools  ->  Device Programming
    • Again, select your debugger as the Tool (I'm using JTAGICE3), "ATmega256RFR2" as the Device, and select your interface (I'm using JTAG). 
    • Click "Apply".
    • Select "Fuses" on the left.
    • In the CKSEL_SUT dropdown, select "TOSC_16KCK_65MS", and click "Program".
    • Close the Device Programming dialog box.
  12. Notice that the yellow LED is blinking twice as fast as before.  This is because the value of 0x00 in the CLKPR register gave a /2 division factor when the internal RC oscillator was selected as the source.  With a different clock source now being used, the 0x00 value in the CLKPR register gives a division factor of /1.  This means the System Clock is now running at 2MHz instead of 1MHz (Note: the CKDIV8 fuse is still programmed). The green LED should not be affected because Timer2 is running asynchronously from the 32kHz crystal.
  13. Adjust the System Clock back to 1MHz while still running off the external 16MHz crystal:
    • Add the following lines of code to the start of the main function in Blinky_LED.c:
    • int main(void)
      {
         CLKPR = 0x80; // Enable CLKPR change
         CLKPR = 0x04; // Change division factor to /16

      Note:  Writing directly to the CLKPR register overrides the CLKDIV8 fuse setting.

  14. Save and compile Blinky_LED.

  15. Program the RFR2 ZigBit and verify the LED toggles every half second as before.

The reader is encouraged to experiment with different clock sources and prescaler division factors to become familiar with the timing system


 USART - Asynchronous Mode (UART)

UART Background

UART communication is a very simple and inexpensive method of serial communication in embedded designs.  UART communication in full-duplex mode uses one pin for Transmit (TX) and one pin for Receive (RX).  Half-duplex uses a shared pin for TX and RX (commonly referred to as single-wire UART or 1-wire Comm).  Both versions require a common ground to operate properly.

Since there is no shared clock line, the data rate needs to be setup on both ends of the communication link ahead of time.  The receiver on each end uses oversampling to read each bit of incoming data.  The oversampling rate is dependent on the desired baud rate being used.  Asynchronous communication commonly fails due to sloppy reference clocks.  It's normally recommended to use some sort of high accuracy clock like a crystal oscillator, or a calibrated RC oscillator as the reference clock.  Generally, reference clock accuracy becomes more and more important at higher baud rates.

The following image was taken from the ATmega256RFR2 datasheet (Sec 23.4).  It shows the frame format for UART communication.

UARTs can be used in device-device communication or human-device communication.  An example of the latter would be transmitting and receiving ASCII (human readable) characters between a PC terminal program and a microcontroller.  This type of user interface is useful in applications requiring command prompts or for dumping diagnostic information on screen.  UARTs are also commonly used in bootloader applications.

Project Overview

The ATmega256RFR2 has 2 USART's that can be run in full duplex, asynchronous (UART) or synchronous master mode, with the frame options shown in the figure above.  For this example, USART1 was setup in asynchronous mode with the following serial communications settings:

  • Baud (bits per second):  38400
  • Data bits: 8
  • Parity: none
  • Stop bits: 1
  • Flow control was not implemented

USART1 was connected to a PC terminal program (Tera Term was used for this example) using the TTL-232R-3V3 UART/USB bridge cable from FTDI.  Tera Term was used to send/receive ASCII characters to/from the ZigBit.

The 16MHz crystal oscillator was used as the high accuracy clock source for the system.  The system clock was setup to run at 8MHz in order to achieve a 38400 baud with minimal error.

This project also implemented a software FIFO buffer for data transfer.  See this Software FIFO Buffer for UART Communication page for details on its functionality.

Objectives

  • Introduce a basic UART example to the user
  • Present a use-case for the Software FIFO Buffer
  • Display test string in terminal program
  • Echo characters typed in terminal program

Requirements

  • One ATZB-256RFR2-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 and terminal program installed (Tera Term was used in this example - Download_Link)
  • UART/USB bridge cable (TTL-232R-3V3)
  • 5 jumper wires (jumper wire kits)

Procedure

  1. Download the following ATZB-256RFR2_UART_Example project for Atmel Studio 6.1
  2. Extract the contents of the downloaded folder and open the project in Atmel Studio 6.1.
  3. Connect your debugger/programmer to the Xplained PRO board.
  4. Connect the Xplained PRO board to external 1.8-3.3V supply using the 20-pin Xplained PRO connector.
    • Connect Pin 20 to Vcc
    • Connect Pin 2 to GND
  5. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  6. Verify that the device is running off the 16MHz crystal oscillator:
    • In Atmel Studio, in the menu bar, navigate to:  Tools  ->  Device Programming
    • In the "Tool" dropdown, select your debugger/programmer (I'm using "JTAGICE3").
    • Select "ATmega256RFR2" in the "Device" dropdown.  Select your debug interface (I'm using "JTAG")
    • Click "Apply".
    • On the left side of the Device Programming dialog box, select "Fuses".
    • Ensure the CKSEL_SUT option is "TOSC_16KCK_65MS" (may have to scroll to view all fuses). 
    • Click "Program" and close the Device Programming dialog box.  The system should now be running off the external crystal oscillator if it wasn't already.
  7. Connect the FTDI cable to an open USB port on the PC.
  8. Make the following connections between the FTDI cable and the Xplained PRO board using jumper wires:
    • TX pin of FTDI cable connected to pin 14 of the 20-pin Xplained PRO connector (PD2 of ZigBit)
    • RX pin of FTDI cable connected to pin 13 of the 20-pin Xplained PRO connector (PD3 of ZigBit)
    • GND pin of FTDI cable connected to pin 2 or 19 of the 20-pin Xplained PRO connector
  9. Open a terminal window (I'm using Tera Term).
  10. Setup the following serial settings (in Tera Term navigate to Setup -> Serial Port):
    • Select the COM port associated with the FTDI cable (cable must be plugged in and driver fully installed)
    • Baud (bits per second):  38400
    • Data bits: 8
    • Parity: none
    • Stop bits: 1
    • Flow control was not implemented
    • Transmit delays were not implemented
  11. In Atmel Studio, save and build the project.
  12. Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.
  13. In the terminal window, you should see a test string printed.  You should also be able to type characters and have them echoed in the terminal.

Below is a screenshot of the Tera Term window while running this application.


 

 10-bit Analog to Digital Converter (ADC)

ADC Background

Analog to Digital Converters (ADC) are one of the most commonly used peripherals in embedded design.  The ADC converts a continuous analog signal (such as the output from a sensor) into a digital representation that can be understood by the microcontroller.  The resolution of the ADC depends on the number of bits within the ADC and the reference voltage range.  The ATmega256RFR2 contains a 10-bit successive approximation ADC that can sample analog voltage as fast as 330,000 samples per second.  The ATmega256RFR2 contains an internal temperature sensor which can be connected to the input of the ADC.  In this way, the microcontroller can monitor its own temperature which can be used to compensate for temperature effects on external devices, or it can be used for general diagnostic purposes for the user.

Project Overview

For this project, the internal temp sensor was used as the analog source for the ADC.  The ADC was setup to use 10-bit resolution using the internal 1.6V voltage as the ADC reference.  The ADC was setup in single ended mode to take a single reading from the internal temp sensor.  The ADC clock frequency was set to 500kHz with a start-up time of 24us. 

The 16MHz external crystal was used as the system clock source and the clock prescaler register was used to set the system clock rate to 8MHz.  See the "Using the 16MHz Crystal" example above for a basic crystal oscillator example.

The ADC result was converted in to human-readable ASCII characters and USART1 was used to display the temperature in a terminal window.  See the "USART - Asynchronous Mode (UART)" example above for introduction to UART functionality.  The UART was setup with the following communication settings:

  • Baud (bits per second):  38400
  • Data bits: 8
  • Parity: none
  • Stop bits: 1
  • Flow control was not implemented

The same Software FIFO Buffer for UART Communication was used for handling character transmission.

Tera Term was used as the terminal software for displaying characters.  The TTL-232R-3V3 UART/USB bridge cable from FTDI was used to connect the device to the PC.

Objectives

  • Introduce a basic ADC example to the user
  • Introduce the user to the internal temperature sensor
  • Convert ADC result to Celcius degrees
  • Display characters in terminal window over UART

Requirements

  • One ATZB-256RFR2-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 and terminal program installed (Tera Term was used in this example - Download_Link)
  • UART/USB bridge cable (TTL-232R-3V3)
  • 5 jumper wires (jumper wire kits)

Procedure

  1. Download the following ATZB-256RFR2_Temp_Meas_Example project for Atmel Studio 6.1
  2. Extract the contents of the downloaded folder and open the project in Atmel Studio 6.1.
  3. Connect your debugger/programmer to the Xplained PRO board.
  4. Connect the Xplained PRO board to external 1.8-3.3V supply using the 20-pin Xplained PRO connector.
    • Connect Pin 20 to Vcc
    • Connect Pin 2 to GND
  5. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  6. Verify that the device is running off the 16MHz crystal oscillator:
    • In Atmel Studio, in the menu bar, navigate to:  Tools  ->  Device Programming
    • In the "Tool" dropdown, select your debugger/programmer (I'm using "JTAGICE3").
    • Select "ATmega256RFR2" in the "Device" dropdown.  Select your debug interface (I'm using "JTAG")
    • Click "Apply".
    • On the left side of the Device Programming dialog box, select "Fuses".
    • Ensure the CKSEL_SUT option is "TOSC_16KCK_65MS" (may have to scroll to view all fuses). 
    • Click "Program" and close the Device Programming dialog box.  The system should now be running off the external crystal oscillator if it wasn't already.
  7. Connect the FTDI cable to an open USB port on the PC.
  8. Make the following connections between the FTDI cable and the Xplained PRO board using jumper wires:
    • TX pin of FTDI cable connected to pin 14 of the 20-pin Xplained PRO connector (PD2 of ZigBit)
    • RX pin of FTDI cable connected to pin 13 of the 20-pin Xplained PRO connector (PD3 of ZigBit)
    • GND pin of FTDI cable connected to pin 2 or 19 of the 20-pin Xplained PRO connector
  9. Open a terminal window (I'm using Tera Term).
  10. Setup the following serial settings (in Tera Term navigate to Setup -> Serial Port):
    • Select the COM port associated with the FTDI cable (cable must be plugged in and driver fully installed)
    • Baud (bits per second):  38400
    • Data bits: 8
    • Parity: none
    • Stop bits: 1
    • Flow control was not implemented
    • Transmit delays were not implemented
  11. In Atmel Studio, save and build the project.
  12. Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.
  13. In the terminal window, you should see a test string printed.  You should also result of the internal temperature measurement in Celcius.

Below is a screenshot of the Tera Term window while running this application.


 Peer2Peer Wireless Communication with Atmel's Lightweight Mesh (ALM)

ALM Background

Atmel's Lightweight Mesh (ALM) is a low power mesh networking wireless software stack that can be downloaded and used for free.  It is a proprietary network protocol, meaning it does not comply with the ZigBee standard.  However, it can be used in low power, mesh networking applications that don't require ZigBee compliance. 

Project Overview

This project shows how to apply the ALM to the ATmega256RFR2 ZigBit module and achieve direct point to point wireless communication.  For this example, a wireless UART was implemented between two ATmega256RFR2 ZigBit modules.  In this example each board was connected to a separate USB port of the PC and two terminal windows were opened.  As characters were typed in one terminal, they were wirelessly transmitted to the other wireless device and the characters appear in the second terminal.  ALM version 1.2.1 was used for this demo.

Objectives

  • Present a basic wireless communication example
  • Demonstrate how to use basic GPIO macros that the ALM provides
  • Demonstrate how to use the built in software timers that the ALM provides

Requirements

  • Two ATZB-256RFR2-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 and terminal program installed (Tera Term was used in this example - Download_Link)
  • Two UART/USB bridge cables (TTL-232R-3V3)
  • Jumper wires (jumper wire kits) for connecting power/gnd/uart

Procedure

  1. Download Atmel Lightweight Mesh (ALM) v1.2.1
    • Tip:  Once the ALM folder is downloaded, make another copy for editing and keep the original unchanged.  If you ever need to start from scratch, you won't need to re-download the entire ALM.  Just make a new copy of the saved original.
  2. Within the ALM download folder, navigate to:  LwMesh_1_2_1  ->  apps  ->  Peer2Peer  ->  astudio
  3. Open the XplainedPRO_ATmega256rfr2 project in Atmel Studio 6.1.
  4. Connect your debugger/programmer to the Xplained PRO board.
  5. Connect the Xplained PRO board to external 1.8-3.3V supply using the 20-pin Xplained PRO connector.
    • Connect Pin 20 to Vcc
    • Connect Pin 2 to GND
  6. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  7. Change the system clock to 8MHz:
    • In Atmel Studio, in the menu bar, navigate to:  Tools  ->  Device Programming
    • In the "Tool" dropdown, select your debugger/programmer (I'm using "JTAGICE3").
    • Select "ATmega256RFR2" in the "Device" dropdown.  Select your debug interface (I'm using "JTAG")
    • Click "Apply".
    • On the left side of the Device Programming dialog box, select "Fuses".
    • Ensure that the CKDIV8 box is unchecked and the CKSEL_SUT option is "INTRCOS_6CK_65MS". 
    • Click "Program" and close the Device Programming dialog box. 

      The system should now be running off the internal RC oscillator at 8MHz.

  8. Create a software controlled LED pin within the ALM stack.
    • In the XplainedPRO_ATmega256rfr2 project, in the Solution Explorer Window, navigate to:  stack  ->  hal  ->  atmega256rfr2  ->  inc  ->  hal.h
    • In hal.h, add the following block of code:
    • #include "halGpio.h"
      #if defined(PLATFORM_XPLAINED_PRO_ATMEGA256RFR2)
          HAL_GPIO_PIN(LED, E, 2); //This creates a name for PE2 as HAL_GPIO_LED which is software accessible
      #endif
    • In the Solution Explorer Window, navigate to:  stack  ->  hal  ->  atmega256rfr2  ->  src  ->  hal.c
    • In hal.c, add the following block of code to the HAL_Init() function:
    • HAL_GPIO_LED_out(); //Configure PE2 as a digital output pin
      HAL_GPIO_LED_set(); //Set PE2 to '1' (LED off)
  9. Create a miscellaneous timer
    • In the Solution Explorer Window, open Peer2Peer.c.

    • Add the following software timer declaration to the file:

    • static SYS_Timer_t hrtbtTimer;
    • Within Peer2Peer.c, add the following block of code at the end of the appInit() function to configure a 1 second timer:
    • hrtbtTimer.interval = 1000; //ms
      hrtbtTimer.mode = SYS_TIMER_PERIODIC_MODE;
      hrtbtTimer.handler = hrtbtTimerHandler;
      SYS_TimerStart(&hrtbtTimer);
    • Within Peer2Peer.c, add the following function above the appInit() function to execute the heartbeat timer.
    • static void hrtbtTimerHandler(SYS_Timer_t *timer)
      {
          HAL_GPIO_LED_toggle();  //Toggle LED
      }
  10. Echo typed characters in host terminal:
    • Within Peer2Peer.c, add the following line of code to the HAL_UartBytesReceived() function, after the HAL_UartReadByte() function call:
    • HAL_UartWriteByte(byte);
  11. Enable acknowledge signals between the two boards:
    • Within Peer2Peer.c, in the appSendData() function, modify the options line to the following:
    • appDataReq.options = NWK_OPT_ENABLE_SECURITY | NWK_IND_OPT_ACK_REQUESTED;
  12. Verify Device Configuration
    • Within the Solution Explorer Window, open config.h.
    • Verify the following constant values are defined:
    • #define APP_ADDR 0
      #define APP_CHANNEL 0x0f
      #define APP_PANID 0x4567
      #define APP_ENDPOINT 1
      #define APP_SECURITY_KEY "TestSecurityKey0"
      #define APP_FLUSH_TIMER_INTERVAL 20

      Note: The default values are kept for the first device.

  13. Save and Build the project.
  14. Program the first board. 
  15. Verify that the yellow LED toggles every second.
  16. Setup terminal window.
    • Open Tera Term window
    • In menu bar, navigate to:  Setup  ->  Serial Port
    • In the "Port" dropdown, select the enumerated port corresponding to the plugged in board.
    • Select 38400 as the Baudrate
    • Select "8 bit" for data size
    • Select "none" for Parity
    • Select "1 bit" for Stop
    • Select "none" for Flow Control
    • Transmit delays should be zero
    • Click OK to save these settings
  17. Begin typing characters on the keyboard.  They should appear in the Tera Term window as they are typed.
  18. Configure 2nd board.
    • In Atmel Studio 6.1, in the same XplainedPRO_ATmega256rfr2 project, open config.h if it's not already opened.
    • Change the APP_ADDR constant to '1' as shown below:
    • #define APP_ADDR 1
    • All other values should be left alone for this demo.
  19. Save and build the project.
  20. Connect the second board to the PC/Debugger.
  21. Ensure the system clock is set to 8MHz as shown in Step 7.
  22. Program 2nd board.  Verify the yellow LED toggles every second.
  23. Configure 2nd terminal window.
    • Open a second Tera Term window.
    • Configure the serial port as shown in Step 16.
  24. Begin typing characters in the 2nd Tera Term window.  If both boards are powered up and within range of each other, characters should appear in both Tera Term windows.  If not, try resetting the boards.

Below is a screenshot of the two terminal windows connected to the wireless devices:

You can also very easily setup your ZigBit module to communicate with an ATmega256RFR2 Xplained PRO Board since it uses the same chip.  This might be useful for serving as a central coordinating device connected to a PC since it has a built in USB interface on the board.  You can use multiple ATZB-256RFR2-XPRO boards as remote, battery-powered, sensor nodes relaying information to the central Xplained PRO board connected to a PC.  See this page for example usage with the ATmega256RFR2 Xplained PRO board.


 Multi-Node Network and Custom AT Commands

A common way to communicate with wireless devices is through the use of AT commands.  AT commands are predefined commands, unique to the platform being used, that are sent to the device over UART from an external device.  The external device could be another microcontroller, or it could be a PC terminal program.  If a wireless software package supports AT commands, it will include a command reference document which lists the available commands and their function.

Currently, Atmel doesn't have a software package that supports AT commands.  However, Atmel's Lightweight Mesh can very easily be modified to implement custom AT commands from the user.  Take a look at the  Multi-Node Wireless Communication using ALM example written for the ATmega256RFR2.  It was written for the Xplained PRO platform, but the same chip is used in the RFR2 ZigBit module.  Therefore, you can use the same code on your ZigBit modules.  You will just need to change the pin used for LED control.


ATxmega256A3U ZigBit

The XMEGA ZigBit Xplained PRO attachment (ATZB-X-233-XPRO) was used as the platform for each of these examples.  The board was powered through the 20-pin connector using a 3.0V bench supply.  All of the following examples use the JTAGICE3 as the programmer.  However, you can use any of the Atmel Programmers/Debuggers listed in the Programming Options section above.  For these tutorials, the module was programmed using JTAG through the J2 header.

 

 Blinky LED

This is a simple "Getting Started" tutorial for the ATxmega256A3U ZigBit module.  It demonstrates basic GPIO functionality, and introduces a 16-bit timer with interrupt.  It also shows how to configure the asynchronous timer (RTC) which runs off the 32kHz crystal.

Objectives

  • Introduce user to a simple "getting started" tutorial
  • Setup a basic 16-bit synchronous timer with interrupt
  • Setup the 16-bit asynchronous RTC with interrupt
  • Toggle LEDs based on timer interrupt execution

Requirements

  • One ATZB-X-233-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 installed
  • Optional: 2 jumper wires for power connection (jumper wire kits)

Procedure

  1. Download the following Blinky_LED project for Atmel Studio 6.1.
  2. Extract the contents of the downloaded folder (7-zip or Filzip are 2 free options).
  3. Open the Blinky_LED project in Atmel Studio 6.1.
  4. Connect your debugger/programmer to the Xplained PRO board.
  5. Connect the Xplained PRO board to a 1.8-3.3V power supply.  Use the 20-pin right-angle Xplained PRO connector, pin 2 for GND and pin 20 for Vcc.
  6. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  7. Save and build Blinky_LED in Atmel Studio 6.1.
  8. Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.
  9. Verify the yellow on-board LED is toggling every half second.
  10. Verify the green on-board LED is toggling every second.


 USART - Asynchronous Mode (UART)

UART Background

UART communication is a very simple and inexpensive method of serial communication in embedded designs.  UART communication in full-duplex mode uses one pin for Transmit (TX) and one pin for Receive (RX).  Half-duplex uses a shared pin for TX and RX (commonly referred to as single-wire UART or 1-wire Comm).  Both versions require a common ground to operate properly.

Since there is no shared clock line, the data rate needs to be setup on both ends of the communication link ahead of time.  The receiver on each end uses oversampling to read each bit of incoming data.  The oversampling rate is dependent on the desired baud rate being used.  Asynchronous communication commonly fails due to sloppy reference clocks.  It's normally recommended to use some sort of high accuracy clock like a crystal oscillator, or a calibrated RC oscillator as the reference clock.  Generally, reference clock accuracy becomes more and more important at higher baud rates.

The following image was taken from the ATxmega256A3U datasheet (Sec 23.4).  It shows the frame format for UART communication.

UARTs can be used in device-device communication or human-device communication.  An example of the latter would be transmitting and receiving ASCII (human readable) characters between a PC terminal program and a microcontroller.  This type of user interface is useful in applications requiring command prompts or for dumping diagnostic information on screen.  UARTs are also commonly used in bootloader applications.

Project Overview

The ATxmega256A3U has 7 USART's that can be run in full duplex, asynchronous (UART) or synchronous master mode, with the frame options shown in the figure above.  For this example, USARTD0 was setup in asynchronous mode with the following serial communications settings:

  • Baud (bits per second):  38400
  • Data bits: 8
  • Parity: none
  • Stop bits: 1
  • Flow control was not implemented

USARTD0 was connected to a PC terminal program (Tera Term was used for this example) using the TTL-232R-3V3 UART/USB bridge cable from FTDI.  Tera Term was used to send/receive ASCII characters to/from the ZigBit.

The desired baud rate for this example was 38400 bps.  Using the default 2MHz internal oscillator would lead to a baud rate error of aproximately 8.5% (plus any reference clock error).  To decrease the baud error, the internal PLL was used to generate a higher frequency system clock.  Instead of using the internal 2MHz oscillator as the system clock, it was used as the input to the PLL.  The PLL was used to multiply the 2MHz clock by four which generated an 8MHz system clock.  By increasing the system clock to 8MHz, the UART baud rate error decreased to 0.16% (not including any reference clock error) with the same target baud rate of 38400 bps.

This project also implemented a software FIFO buffer for data transfer.  See this Software FIFO Buffer for UART Communication page for details on its functionality.

Objectives

  • Introduce a basic XMEGA UART example to the user
  • Provide an example for using the XMEGA internal PLL
  • Present a use-case for the Software FIFO Buffer
  • Display test string in terminal program
  • Echo characters typed in terminal program

Requirements

  • One ATZB-X-233-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 and terminal program installed (Tera Term was used in this example - Download_Link)
  • UART/USB bridge cable (TTL-232R-3V3)
  • 5 jumper wires (jumper wire kits)

Procedure

  1. Download the following ATZB-XMEGA_UART_Example project for Atmel Studio 6.1
  2. Extract the contents of the downloaded folder and open the project in Atmel Studio 6.1.
  3. Connect your debugger/programmer to the Xplained PRO board.
  4. Connect the Xplained PRO board to external 1.8-3.3V supply using the 20-pin Xplained PRO connector.
    • Connect Pin 20 to Vcc
    • Connect Pin 2 to GND
  5. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  6. Connect the FTDI cable to an open USB port on the PC.
  7. Make the following connections between the FTDI cable and the Xplained PRO board using jumper wires:
    • TX pin of FTDI cable connected to pin 14 of the 20-pin Xplained PRO connector (PD2 of ZigBit)
    • RX pin of FTDI cable connected to pin 13 of the 20-pin Xplained PRO connector (PD3 of ZigBit)
    • GND pin of FTDI cable connected to pin 2 or 19 of the 20-pin Xplained PRO connector
  8. Open a terminal window (I'm using Tera Term).
  9. Setup the following serial settings (in Tera Term navigate to Setup -> Serial Port):
    • Select the COM port associated with the FTDI cable (cable must be plugged in and driver fully installed)
    • Baud (bits per second):  38400
    • Data bits: 8
    • Parity: none
    • Stop bits: 1
    • Flow control was not implemented
    • Transmit delays were not implemented
  10. In Atmel Studio, save and build the project.
  11. Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.
  12. In the terminal window, you should see a test string printed.  You should also be able to type characters and have them echoed in the terminal.

Below is a screenshot of the Tera Term window while running this application.



 12-bit Analog to Digital Converter (ADC)

ADC Background

Analog to Digital Converters (ADC) are one of the most commonly used peripherals in embedded design.  The ADC converts a continuous analog signal (such as the output from a sensor) into a digital representation that can be understood by the microcontroller.  The resolution of the ADC depends on the number of bits within the ADC and the reference voltage range.  Any input voltage higher than the reference voltage will saturate the ADC - meaning the ADC result register will contain the maximum possible value (0xFFF for 12-bit unsigned, 0x7FF for 12-bit signed).  Likewise on the low end, any input voltage lower than the negative input will saturate the ADC - meaning the ADC result register will contain the minimum possible value (0x000 for 12-bit unsigned, 0xFFF for 12-bit signed).  Normally a microcontroller will have multiple options available for the reference voltage (Vref).  The low end of the ADC input range is typically GND for single-ended measurements and -Vref for differential measurements.

ATxmega256A3U - ADC Information

The ATxmega256A3U contains two internal ADCs (ADCA and ADCB).  Each ADC allows up to 8 single-ended inputs or 4 differential inputs.  Alternatively, the user could setup a single ADC (either ADCA or ADCB) to use all 16 pins of PORTA and PORTB.  This allows for up to 16 single-ended inputs or 8 differential inputs for a single ADC.  Each ADC has global settings as well as settings that are specialized for each individual channel.

According to the electrical specs for the ATxmega256A3U, the min and max voltage applied to any ADC input are -0.1V and AVcc+0.1V, respectively.  However, the maximum ADC Reference voltage is AVcc-0.6V.  Therefore, even with the maximum allowable reference voltage, any voltage above AVcc-0.6V will saturate the ADC.  The following figure illustrates this point:

Any ADC input voltage in the pink range will read 0xFFF for unsigned results and 0x7FF for signed results (assuming 12-bit operation).  What does this mean for us?  It means any voltage in the pink region applied to the input of the ADC is electrically acceptable.  However, it is useless because it will always return the same digital value.  The reader should note, a similar Saturation Region exists on the low end as well.  However, this region is defined by the negative input of the ADC and is configurable by the user.  Refer to section 28.3 of the XMEGA-AU manual for details on input sources.

Internal Temp Sensor

The ATxmega256A3U contains an internal temp sensor which can be used as an input to the ADC.  The temp sensor displays a linear relationship between temperature and the ADC result shown by the following equation: 

Where:

  • y is the ADC result (dependent variable)
  • x is the temperature (independent variable)
  • m is the linear multiplier (slope) that must be calculated
  • b is the initial offset that must be calculated

The values of m and b can be calculated if the user has 2 known points (x, y).  Atmel provides one of these points - a single calibration point for the temp sensor (at 85C) which resides in the production calibration portion of memory.  The problem is, you need a second calibration point under the same operating conditions as the first point to characterize the temp sensor.  Measuring the second point is a separate process that must be performed before the temp sensor is usable in future readings.  The user must take an ADC reading at a known temperature with the ADC setup in 12-bit unsigned mode with the internal 1V used as the ADC reference.  

Once the second calibration point has been established, you can use the following equation to calculate m:

Where:

  • V1 is the ADC result taken at 85C and stored in memory
  • V2 is the ADC result measured at a second point
  • T1 is the temperature of the first point in Celsius (85)
  • T2 is the temperature of the second point in Celsius

Once m has been calculated, you can use the following equation to calculate b:

Once m and b have been calculated, we can consider our temp sensor characterized.  We can then take any temp reading within the specified range and use the following equation to convert the result to degrees Celsius:

Where:

  • x is the temperature in degrees C
  • y is the ADC result
  • b is the calculated initial offset
  • m is the calculated linear coefficient

Some Things to Think About

What we are trying to accomplish here is to determine the slope m and initial offset b of this linear sensor.  Ideally, you would be able to do this with only 2 points.  The problem is, no real-life device is ideal and any measured point will include some error.  What we end up doing in reality is taking measurements at known temperatures and finding a "best fit" line that corresponds to the points we measured.  The point that Atmel provides in calibration is accurate within ±15 degrees Celsius.  Not great.  You should take measurements at as many known temperature points as you can to generate a "best fit" line with the highest possible accuracy (the more points the better).  However, using Atmel's calibration point is many times good enough for simple "alert" conditions.

Project Overview

This project consists of two separate programs.  The first program uses ADCB to establish a second calibration point for the internal temp sensor.  It takes an ADC reading of the temp sensor at the current temperature and displays the result on screen through UART.  It then calculates the value of the coefficients m and b and prints them on screen.

The second program uses both ADCs.  ADCA was setup to measure the supply voltage (Vcc) using the internal Vcc/10 signal.  ADCB was used to read the internal temp sensor.  Using the calculated coefficient values from the first program, the current temp was calculated within application code.  The Vcc and Temp results were displayed in a terminal program through UART.

For this example, USARTD0 was setup in asynchronous mode with the following serial communications settings:

  • Baud (bits per second):  38400
  • Data bits: 8
  • Parity: none
  • Stop bits: 1
  • Flow control was not implemented

USARTD0 was connected to a PC terminal program (Tera Term was used for this example) using the TTL-232R-3V3 UART/USB bridge cable from FTDI.  Tera Term was used to send/receive ASCII characters to/from the ZigBit.

The internal PLL was used as the core clock source similar to the UART tutorial above.

This project implemented the same software FIFO buffer as the previous UART tutorial.  See this Software FIFO Buffer for UART Communication page for details on its functionality.

Objectives

  • Introduce an XMEGA ADC example
  • Use the ADC to provide second calibration point for Internal Temp sensor
  • Characterize the Internal Temp sensor by calculating the coefficients m and b
  • Use the calculated coefficients to convert ADC results to degrees C
  • Measure Vcc using the internal Vcc/10 as input to the ADC

Requirements

  • One ATZB-X-233-XPRO board powered by external 1.8-3.3V supply
  • Atmel Debugger/Programmer (JTAGICE3 used in this tutorial)
  • PC with Atmel Studio 6.1 and terminal program installed (Tera Term was used in this example - Download_Link)
  • UART/USB bridge cable (TTL-232R-3V3)
  • 5 jumper wires (jumper wire kits)

Procedure

  1. Download the following ATZB-XMEGA_Cal_Temp_Sensor project for Atmel Studio 6.1
  2. Extract the contents of the downloaded folder and open the project in Atmel Studio 6.1.
  3. Connect your debugger/programmer to the Xplained PRO board.
  4. Connect the Xplained PRO board to external 1.8-3.3V supply using the 20-pin Xplained PRO connector.
    • Connect Pin 20 to Vcc
    • Connect Pin 2 to GND
  5. Make sure pins 1 and 2 of J5 are shorted, otherwise ZigBit will not power up.
  6. Connect the FTDI cable to an open USB port on the PC.
  7. Make the following connections between the FTDI cable and the Xplained PRO board using jumper wires:
    • TX pin of FTDI cable connected to pin 14 of the 20-pin Xplained PRO connector (PD2 of ZigBit)
    • RX pin of FTDI cable connected to pin 13 of the 20-pin Xplained PRO connector (PD3 of ZigBit)
    • GND pin of FTDI cable connected to pin 2 or 19 of the 20-pin Xplained PRO connector
  8. Open a terminal window (I'm using Tera Term).
  9. Setup the following serial settings (in Tera Term navigate to Setup -> Serial Port):
    • Select the COM port associated with the FTDI cable (cable must be plugged in and driver fully installed)
    • Baud (bits per second):  38400
    • Data bits: 8
    • Parity: none
    • Stop bits: 1
    • Flow control was not implemented
    • Transmit delays were not implemented
  10. In Atmel Studio, save and build the project.  Program the ZigBit.  You can either start a debug session or select Debug -> Start Without Debugging.

    The following image is a screenshot of the terminal window while running this application at room temperature (25C).


    This program takes an ADC reading at the current temp and calculates the coefficients m and b for you.  You will need to define the current temperature in application code.  Once you have the values for m and b you need to define these coefficient values in the second program.
    Why did we multiply by 100?  Multiplying by 100 saves us from integer drop off when we are dividing numbers.  This helps us maintain 2 decimal points of accuracy.  If we wanted 3 decimal points of accuracy, we'd multiply by 1000.  Just make sure your variables are large enough to store the values!  We correct the result by dividing by 100 after the calculations are done. 

  11. Now download the following ATZB-XMEGA_Temp_Meas_Example project for Atmel Studio 6.1
  12. Extract the contents of the downloaded folder and open the project in Atmel Studio 6.1.
  13. Your ATZB-XMEGA XPRO should already be connected (debugger, power, USB/UART).  If not, do so now.
  14. Ensure the same serial communication settings are applied (38400, 8, none, 1, none).
  15. Make sure you adjust the coefficient definitions to match what was calculated for your device.  The definitions are located towards the top of ATZB-XMEGA_Temp_Meas_Example.c.  The following screenshot shows the definitions corresponding to the result of the first program (shown above):
  16. Save and build the project.
  17. Program the ZigBit.
  18. In the terminal window, you should see Vcc and the current temperature displayed.

The following image is a screenshot of the terminal window while running the second program.  The device was running at 3.0V at room temperature.

Some error exists in the ADC measurements due to ADC offset and gain error.  Additionally, for internal ADC measurements, the internal GND signal is used as the negative input to the ADC.  Any difference between the internal GND signal and the external PAD GND will introduce error into the ADC conversion.  ADC offset and gain error can be corrected for in software.  However, that topic is out of the scope of this tutorial.  Refer to AVR120 for details on software ADC calibration.

Also, it should be noted that the temp sensor is taking internal temp readings, not ambient temp readings.  If the user wishes to monitor ambient temperature, an external sensor should be used.  However, the internal temp sensor can be helpful in alerting the user of extreme internal temps (or defined thresholds of any kind).


 Peer2Peer Wireless Communication with Atmel's Lightweight Mesh (ALM)

At the time of this writing there is limited ALM support available for the ATxmega256A3U ZigBit modules.


 BitCloud for ZigBits - Using AT Commands

At the time of this writing BitCloud support is not available on the ATxmega256A3U ZigBit modules.


Jump to Top

 

Documentation

As if you didn't have enough already:

Legacy ZigBit Information

For designers that are using the older ZigBit modules, here are some links to some helpful info:

Jump to Top

Contact the Author

The goal of this page was to provide some insight on the use of Atmel ZigBit modules.  I wanted to provide some code examples and design guidelines along with any reference material you might need, all in one location.  Feel free to use the example code in your own projects.  I challenge you to build on their functionality.  Try implementing power down mode in the RTC example to make a low power real-time clock.  See if you can implement a threshold compare function for ADC or setting multiple calibration points for the Xmega temp sensor.  Try implementing a multi-node wireless network of temp sensors that report data to a central node.  The purpose of this page was not to do everything for you.  The goal was to give you building blocks that allow you to create more complex applications (you know...that whole "teach a man to fish" idea).  If you notice any discrepancies, have any questions, or would like to see something added to the page, let me know at eewiki@digikey.com.  I hope you enjoy working with Atmel's ZigBit modules!

    -    Scott