I've put up a preliminary version of some code to automatically reset
a Fio Arduino hooked to an XBee without soldering the jumper between
RTS and D3 on the source XBee at GitHub - rossbiro/Arduino: open-source electronics prototyping platform.
The code is not ready for production use and is still full of debug
code.
This code lets you configure both XBee's, select which XBee you want
to communicate with while programming and even select which data line
on the remote XBee to use to reset the remote Arduino (D3 for the Fio
boards).
Warning. There is currently no way to turn off this code without
manually editing the preferences file. So if you already have a
working system and you experiment with this code, please be ware that
you will either have to roll back the changes, or edit the preferences
file to turn it off.
To use the code, select the serial port the local XBee is connected to
and make sure all the parameters (bps, stop bits, etc.) are set
correctly. Usually a new XBee is set for 9600 8N1. Power up all
XBees you wish to communicate with. Then select tools/serial
port/Xbee.
You should get a dialog box showing the configuration of the local
XBee on the right and any remote XBees available on the left. It may
take a few moments for all the XBees to appear in the drop down.
Select the XBee you want to program from the drop down. Remote XBees
will not appear if they cannot communicate with the local XBee. For
example, if they have a different network id. The default network ID
is usually 0x3332, so be sure to change the local network id to 0x3332
if you are trying to locate a new out of the box XBee. You will
probably have to exit the XBee dialog and reopen it after changing the
network id to cause a network rescan.
Set all the parameters the way you want them, double check, and then
click connect and then ok. The write button will write the current
parameters stored in the XBee (NOT the parameters displayed) to NV Ram
and it has NOT been tested. If you wish to use the write button be
sure to click apply before you click write.
Now, when you click upload, it will upload to the remote XBee that is
connected, and it will automatically reset it using remote commands
and not the local RTS/DTR.
Notice that you can name your XBees to make it easier to keep track of
them. If it matters to anyone, the code puts both the 64 bit address
and the 16 bit address in all of the packets. I believe this means
that it actually uses the 16 bit addresses for everything.
Internally, the code tracks the XBees using their 64 bit addresses.
Whether or not an XBee is connected to a given serial port is stored
in your preferences. If you later upload something using the same
serial port and there is an XBee connected, the code will attempt to
reset the remote Arduino using remote commands instead of RTS/DTR.
Which data line to use is also stored in the preferences and is
attached to the serial number (64 bit address) of the remote XBee.
The list of remote XBees is only updated when the XBee dialog is open.
So if an XBee is not found, it may be necessary to close and reopen
the dialog box.
At this point, the code is usable and mostly in it's final form. I
could use quite a bit of help with testing and UI support. I'd like
to add
- a checkbox to enable/disable an XBee on a local serial port so that
you can deactivate the reset code without editing your preferences. - a way of executing arbitrary commands on either the local or the remote XBee.
- automatically disable/enable the write button when the XBee and the
dialog are in sync. - rescan the network automatically, periodically or if the network id changes.
I'd also like others to help with
- general comments on the code. I'm sure I violated some of the
coding standards for this project. It would help me greatly if
someone pointed them out. - testing the write button. The documentation says that the number
of times you can write to an XBee is limited, so I don't intend to
test it until I'm pretty sure everything is working 100%. - testing this in an environment with more than two XBees and more
than just XBee Pros. I did notice conflicts in the documents between
different variations of XBees. Some of them may be relevant for the
code. In particular, I believe that the code will not be able to
correctly see the name of some remote XBees.
I've put in a request to pull the code, mostly to get people to look
at it. Please comment.