Bug #790
XBee/Wireless Initialization
| Status: | Assigned | Start: | 10/19/2009 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assigned to: | Brad Neuman | % Done: | 0% |
|
| Category: | Wireless | |||
| Target version: | - | |||
| Votes: | 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().
History
Updated by David Schultz 9 months 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.
Updated by David Schultz 9 months ago
- Category set to Wireless