Open pcdangio opened 3 years ago
As long as you don't call xbee_dev_tick()
for the same device from two separate threads, or try to send to the same device from two threads, I think you might be OK. I designed the API to support multiple devices, even though 99.99% of users only use a single device. I did write a firmware update utility that connected to 20+ devices simultaneously, and that worked OK.
The frame dispatch table passes the device pointer to underlying frame handlers, and would generally be fixed for all devices.
But I do see that _xbee_atcmd_query_regs_head
is a global shared across all instances. You would need to update the library to move the xbee_command_list_context_t
into the xbee_dev_t
, and initialize it in xbee_dev_init()
.
It's been a long time since I've touched that code, so I'm hazy on the details of how it works without taking a closer look at it, something I don't have time for at the moment (moving out of state).
It might be useful to explicitly call out in the documentation what modules are / aren't thread safe, or if the library as a whole isn't thread safe.
I'm currently trying to communicate with multiple XBees simultaneously, each with their own thread. Initial troubleshooting seems to indicate that at least the functions in the Device and AT modules are not thread safe (since there are globally defined tables for things like cmd requests and frame dispatching)