Bug #790
XBee/Wireless Initialization
0%
Description
XBee and Wireless Init functions seem to conflict. dragonfly_init() appears to call xbee_init() [found in serial.c in libdragonfly], while wl_init() appears to call xbee_lib_init() [found in xbee.c in libwireless]. The two functions appear to be arguing over what to assign a few registers.
We found that to get the XBees to work, xbee_init() needs to be called again after drangonfly_init(), but before wl_basic_init_default() [which basically just calls wl_init()].
We also are not confident that calls to wl_set_channel() are working correctly, or if the channel is getting re-initialized by calls to xbee_init()/xbee_lib_init().
Related issues
History
#1 Updated by David Schultz over 13 years ago
xbee_init() turns on the transmitter and receiver on the xbee and resets the baud rate.
xbee_lib_init() cycles the xbee to API mode to communicate with the wireless library and enables the interrupt that gets data from the xbee. They are not arguing as far as I am aware of, since there's only one register overlap and they are just turning on different bits in the register. I don't think the order of these two calls matters, but they both need to be called before doing higher level wireless functions in wl_init or wl_basic_init_default(). I'm not sure what the problem is with dragonfly_init, but maybe reordering the call to the end of dragonfly_init would work.
The channel is not set by any of the init functions, but left at the default value of 0x0C. The set_channel() call looks right, though I haven't tested it.
#2 Updated by David Schultz over 13 years ago
- Category set to Wireless
#3 Updated by Alex Zirbel over 12 years ago
- Priority changed from High to Normal