In your sketches folder, create a folder called “hardware” and put the contents of the zip file in it.

In that hardware folder, under the “tiny” folder, you should see a file called “boards.txt”. Open it for editing. For each ATtiny chip you plan to program, you need to set the ISP you’ll be using. In this example, I am using the Arduino as an ISP, so this block (for ATtiny85, 1MHz clock) will look like this when finished:

# The following DO work (pick one)...
# attiny85at1.upload.protocol=avrispv2
attiny85at1.upload.using=arduino:arduinoisp
# attiny85at1.upload.using=pololu

If you haven’t figured it out, the ‘#’ sign at the beginning of a line will comment it out. Make sure only one of these lines is not commented – the one you want to use.

Open the Arduino IDE. You should now see each of the boards listed in the file you just edited.

Now open the ArduinoISP sketch (found in the file/examples menu). Make sure your Arduino board is selected in the list of boards (your Arduino board, not the ATtiny, we are not to that step yet). Upload the sketch. You can add some diagnostic LEDs (with 1k resistors) at this point (or even before you upload the sketch). Put an LED (with resistor) on the following pins to ground:

7: Programming – In communication with the slave (use green if you like)

You should now see the LED at pin 9 slowly pulse on and off.

VERY IMPORTANT: To finish turning your Arduino into an ISP, you must connect a 120 ohm (500 ohm seems to work as well for me anyway) resistor from the reset pin to +5v. What this does is prevents the Arduino IDE from resetting the Arduino itself. After all, we are not programming the Arduino anymore after this, but the ATtiny. Don’t forget to remove this resistor when you want to program your Arduino again.

Now wire up your Arduino to the ATtiny chip. Here are the connections you need for each ATtiny pin to your Arduino:

ATTiny45 & ATTiny85 pinout

digital 10

nc

nc

ground

digital 11

digital 12

digital 13

+5V

You are ready to program. To test it do the following:

Open up the Blink sketch, under examples/basics.

Change all instances of pin 13 to pin 0.

Under the Tools/Board menu, select the ATtiny version you are using. I am using an ATtiny85, clock speed 1MHz. No external clock is needed.

Hook up a 1k resistor & LED from ATtiny pin 5 (digital 0) to ground.

Upload the sketch. Your Arduino pin 7 pin should blink, and the error pin should stay off. When it is done, your ATtiny LED should be blinking on and off.

This works on Arduinos with a 328 or 168 only. It looks like the same trick might be possible on the Arduino Mega – experiments are ongoing, and will be reported here.

How it works

The Arduino 328 and 168 have a built in precision voltage reference of 1.1V. This is used sometimes for precision measurement, although for Arduino it usually makes more sense to measure against Vcc, the positive power rail.

The chip has an internal switch that selects which pin the analogue to digital converter reads. That switch has a few leftover connections, so the chip designers wired them up to useful signals. One of those signals is that 1.1V reference.

So if you measure how large the known 1.1V reference is in comparison to Vcc, you can back-calculate what Vcc is with a little algebra. That is how this works.

What’s cooler than a robot? A robot with a wireless network adapter! The XBEE wireless radio modules from Maxstream are a quick, inexpensive, and easy way to implement a wireless serial interface between two devices. They are practically a drop in replacement for a TTL-level serial cable. They have a low (~ 50mA) current consumption, and long range (rated at 300ft line of sight, but I have at least full speed coverage throughout a two-story house).

An important note: Series 1 XBEE devices cannot talk to Series 2 (or series 2.5 devices)

Wiring OptionsConnecting to the XBEE devices is quite easy, however, just remember that they are 3.3V devices. The regular ol’ XBEE will draw about 50mA (the PRO modules may draw upwards of 300mA). We can easily power our regular XBEE from an LP2950 3.3V 100mA regulator.

There are a variety of easy to use modules for setting up your XBEE:

An XBEE USB Explorer can be used to connect an XBEE directly to your PC. It is a compact circuit board that already hhas a 3.3V regulator, plus a USB connection to commiunicate with your computer. It draws power directly from the serial port. Simply plug it into a USB port and you’re ready to go. I always keep an Explorer handy to do setup on my XBEE devices. (The XBEE Explorer is the red circuit board shown in the picture below).

You can also connect an XBEE directly to an FTDI breakout board.XBEEs unfortunately use 2mm headers, rather 0.1″ that we are all so accustomed to, however a breakout board that converts the 2mm layout to a breadboard-accessable 0.1″ one is available for only a few dollars. The breadboard below shows an FTDI breakout board, connected to and powering an XBEE breakout board.

An XBEE can be directly coupled to the TX/RX lines of a 3.3V or 5V microcontroller. In either case, it will still require a 3.3V power source. It is recommended that you use several resistors for a voltage divider if using the XBEE with a 5V microcontroller, however, I don’t. The following schematic shows both a circuit with voltage divider resistors and without, regardless, the XBEE always requires a 3.3V power supply:

Most users will find they already have the FTDI drivers, but you may find that you need to install drivers for the XBEE Explorer or FTDI breakout. They can be found at http://ftdichip.com/Drivers/VCP.htm

Pairing and Other Parameters
If you want to have your XBEEs communicate at high speed, with the automatic resending of lost packets, you’ll want to pair them. And trust me — you want the automatic resending capability! This is very easy, we just need to set a few registers in the device. XBEE devices have several settings that we will use, and many more that we won’t be using right now. XBEE modules use standard AT commands. This is a protocol left over from the days of serial modems, but it still works for us now. These commands allow you to edit the registers found inside the XBEE. Each register has a name, prefixed by AT, such as ATBD, which is the Baud Rate register.

First off, XBEE radios only operate at a given baud rate, this is the number of bits per second that the XBEE can send. A brand new xbee will default to 9600bps, which is pretty slow. We can change the baud rate, by changing the ATBD register. Both of our XBEEs have to be the same baud rate to talk to one another. The available baud rates (and corresponding ATBD value) are:

1 = 2400bps

2 = 4800bps

3 = 9600bps

4 = 19200bps

5 = 38400bps

6 = 57600 bps

7 = 115200 bps

The next parameter of interest is the Personal Area Network ID. This is a number shared amongst each XBEE in a network. For now, we are only using 2 XBEEs, but we could have many, many more in a single network. XBEEs on different networks do not “see” each other. The default PAN is 3332, so you should avoid that number. The PAN ID is stored in ATID

Once both of our XBEEs are on the same network, we can give each one an address number, denoted by ATMY. We can also set the destination address, which is what address number to talk to, denoted ATDL (for destination low, we really don’t need to use the high bytes if we keep our address numbers < 16 bits in length). A sample setup of two XBEEs that will talk directly to one another, at 38.4kbps:
XBEE1:ATID = 1111
ATMY = 10
ATDL = 11
ATBD = 5

XBEE2:ATID = 1111
ATMY = 11
ATDL = 10
ATBD = 5

Additionally, XBEE devices are 2.4Ghz radios. The 2.4Ghz band is currently used by many, many devices. None of them operate at exactly 2.4Ghz, there are several different channels which are in the 2.4Ghz band. We can change which channel the XBEE devices are on, ATCH, but again, devices on different channels cannot talk to one another.

Using the MaxStream Software

MaxStream distributes a piece of software called X-CTU which allows you to set all of the parameters we describe above, using a Graphical User Interface. Unfortunately, the software is a Windows application, but luckily for those of you using Linux (like myself), X-CTU can be run under Wine, here’s how.

When we start X-CTU, we need to select the baud rate and port that our XBEE is connected to:

It’s a good idea to click Test/Query to check that your baud/port are correct. If so, you’ll see a box that says:

Once we know we have a good connection, we’ll switch over to the Modem Configuration tab, and click Read. The items of interest are obviously the Channel (CH), PAN ID, Destination Low (DL), and Source Address (MY). We have to scroll down a ways to see the Baud Rate (BD) setting:

Once we make any changes, click Write to send them out to the XBEE. The write phase could take a little time.

Using the XBEE-API Terminal to Send AT Commands DirectlyThe XBEE-API Terminal is a simple to use python program that allows you to interact with an XBEE directly, sending AT commands. Why can’t we just use any old terminal? First, we want to send carriage returns rather than newlines, but also, we don’t want to send a carriage return on some transmissions.

To setup the XBEE-API Terminal, you will need Python 2.5, and the PySerial package installed. You’ll then want to pull down xbee-serial-terminal.py and xbee.py and put them on your path (I’d also recommend renaming xbee-serial-terminal.py to something easier like xbeeterm.py):

This same API can be used to programmatically interact with XBEEs quite easily. Setting this up to run, is just like any other python script.

Before we can send AT commands, we need to get the XBEE into AT command mode, by sending “+++” and nothing else, for at least 3 seconds. We should have a short pause and then see “OK”. The XBEE will automatically exit AT command mode after 10 seconds of inactivity. We can then send data to our XBEE, or read back. With our example XBEE still in the XBEE Explorer, we would see:

That last command is quite interesting. ATND tells the XBEE to do a Node Detection, which lets us find what devices are on around us. In this case our Arduino XBEE was on, we can now see what the key registers are set to, and how strong our connection is.

We can also easily set parameters. An important thing to note though, is that changes we make are stored in temporary memory, if we power the XBEE device off, they are lost. We need to send ATWR to write the changes to non-volatile memory. If we decide to change our settings:

Code:

> +++
OK
> ATID2222
OK
> ATMY12
OK
> ATID
2222
> ATWR
OK

Our PAN is now 2222, and our ID is 12 rather than 10. Our XBEEs will no longer talk to each other, or even see one another. You should change it back before continuing!

Testing our setup with an Arduino
To test our setup, we can use an Arduino to loopback our data. In this example, the Arduino will recieve data from the XBEE, and then send it back out, after incrementing by one. Thus if we send “Hello”, we should see “Ifmmp”. Hook up one of our XBEEs as shown above with our Breadboarded Arduino Connection, and plug our other into the XBEE Explorer. NOTE: You will have to remove the XBEE from the breadboard when downloading code onto the Arduino.

Notes About ProtocolsBeing a wireless network, there will eventually be lost information — even though the XBEE has automatic resend of lost packets. For mission critical stuff, I recommend adding your own data integrity or checksum/resend protocols on top of the hardware resend built into the XBEE.