|
I have used and still do use several XBee with Basic Atom Pros, including both BAP28 and ARC32. I both send and receive. Many of the programs that use it are uploaded to the Lynxmotion forums. This includes the DIY remote control, plus several different robots that are controlled by this remote.
I do not use S_OUT as S_IN and S_OUT are connected to the 9 pin connector. For most of my actual robots I connect the XBEE up using the two IO pins associated with the hardware serial port (on Bap28 this is 14 and 15). I then use the hardware serial commands (HSEROUT, HSERIN...). This gives me good reliable communications with the XBee. However as the hardware serial code generates interrupts, this can lead to issues. Like when I need to output serial data to the SSC-32 servo controller. The interrupts corrupt this data. So I use the RTS/CTS capabilities of the XBee and a little time before I am about to output to the SSC-32, I tell the XBee to not send any data. The XBee will still send up to 2 more characters, which is why I said a little before...
On other versions of some of this code (and maybe a few still in use), I connected up the XBee to standard IO pins and use serin and serout to communicate with it. You can get this to work (again issues if there are other interrupts...), but an issue with using serin is, if you are not in the serin when data is being transmitted by the XBee to the BAP, the data is lost. There are ways around this, like:
a) Write your own protocol that sends data out to tell the other side you are ready for data, and then wait for the data in a SERIN.
b) Use the flow control of the XBee, with this the XBee will only send data when you say you want it. There are a couple options on how to do this.
b1) Use the flow control in SERIN (fpin). This again requires another IO pins between the Xbee and the BAP. Note: if you are using the sparkfun adapter, it does not do any voltage conversion on this pin, so you either need to do it yourself, or on the BAP28 there are 2 IO pins that only output 3.x volts (7 and 8 if I remember correctly at this time of morning), which is what I used. Issue is that if the XBee has more data than you are reading, you will lose 2 bytes of data, as these will be sent after the BAP changes the flow control pin... (They were probably already queued up in the XBee hardware port...). Some have gotten around this, by padding additional bytes to their messages... But this causes issues with syncing your code up...
b2) To get around this, I wrote my own version of serin with flow control(and serout), that after it finished and changed the flow control pin, it would wait a bit of time (a couple of bit periods), to see if more bytes of data were coming and it would queue these up, to be used first in the next call to my serin... I wrote a couple of different versions of this. One that like serin/serout counted CPU cycles to control the bit timing. A later version used one of the processors timers for this. This worked better at times, of not having the data corrupted as often when the processor was handling interrupts, like from HSERIN/HSEROUT... But...
So yes, you can interface an Xbee with an Atom pro.
Kurt
|
Login
Register
FAQ
