The Arduino Fio is not quite as simple as the standard Arduino modules, because programming over the XBee wireless link has some complications. If you're aware of those complications, though, it's a simple board to use. Here are some tips that will make using it easier.
The Atmega328P bootloader communicates at 57600bps. This is why you have to configure your XBee radios to 57600bps in the examples above. If your sketches are going to communicate using the XBee radio serial link at a different baudrate, you will need to reconfigure the radios to that rate after programming. So if you're programming wirelessly, and you can choose the baudrate for your application, use the bootloader rate of 57600bps. It'll save you the time of reconfiguring the radios.
If you have to use a different baudrate for your application, consider programming the Fio using a wired link instead. While programming over a wired link, remove the XBee radio to avoid conflict.
The XBee radios have two modes, data mode, in which data is sent across them transparently, and command mode, in which they are configured serially. To switch from data mode to command mode, you send the string +++@.
Sending sensor values as binary values can accidentally cause the XBees to switch from command to data mode. For example, imagine you're sending an analog reading like so:
int sensorReading = analogRead(0) /4; Serial.print(sensorReading, BYTE);
If the sensor's reading happens to have the value 43 (which corresponds to ASCII '+') three times in a row, it will set the Fio's radio into command mode. To avoid this, use ASCII-based communication with the Fio whenever possible.
Like other Arduinos, the Arduino Fio does not require a physical press of the reset button before an upload. It can be reset by software running on a connected computer. When the Fio is connected to either a computer running Mac OS X or Linux, it resets each time a serial connection is made to it from software (via USB). To avoid problems, you should make sure that the Fio sends the initial communication to any program that's talking to it serially.
The sketch below sends a byte on startup. The receiving program should look for that message, and not send to the Arduino before it receives this byte.
void setup() {
Serial.begin(57600);
Serial.print(255);
}
void loop() {
int sensorReading = analogRead(0);
Serial.println(sensorReading, DEC);
}
If you use this sketch as your default when designing serial applications for the Fio, you should have fewer problems.
Here's why it matters:
One of the pins on the FTDI programming header is connected to the reset line of the ATmega328P via a 100 nanofarad capacitor. This pin connects to one of the hardware flow control lines of any FTDI USB-to-serial converter connected to the header: RTS when using an FTDI cable, DTR when using the Sparkfun breakout board. When this line is taken low, the reset line drops long enough to reset the chip. The Arduino software uses this capability to allow you to upload code by simply pressing the upload button in the Arduino environment. This means that the bootloader can have a shorter timeout, as the lowering of the reset line can be coordinated with the start of the upload.
For the following half-second or so, the bootloader is running on the Fio. While it is programmed to ignore bad data (i.e. anything besides an upload of new code), it will intercept the first few bytes of data sent to the board after a connection is opened. If a sketch running on the board receives one-time configuration or other data when it first starts, make sure that the software with which it communicates waits a second after opening the connection and before sending this data.