The xbee.transmit() function appears to only be blocking. Is there a way to transmit a message asynchronously from MicroPython? In other words, issue the transmit() then check another function for the result later. Surprisingly, the receive() function is non-blocking.
This seems like a major omission as it means that the MicroPython script can’t transmit a message if it has any time sensitive activity it handles (e.g. flashing an LED).
/Ross
Yes you just need to put it in a different loop if I recall.
I’m not sure I understand your response. Does MicroPython have intrinsic multi-threading or concurrency? If not, what do you mean by ‘different loop’? I already employ cooperative multitasking but even that falls down if just one task is blocking (such as transmit).
I didn’t mention that I’m working with XBee3 (ZigBee firmware).
Cheers, Ross
You are correct, the transmit() method currently blocks so it can generate errors if the module is unable to transmit for some reason.
If you were requesting asynchronous transmit as a feature, what sort of API would you expect? How would you check whether the transmission was still pending, had completed, or had erred out?
Hi Tom,
The usual way this situation is dealt with is to have the transmit function return a ‘future’ (object) immediately, rather than blocking and returning the final result. The future object can have functions which return the final result in a blocking manner (like currently) or non-blocking manner which can be polled by the application.
Importantly, the reason I have raised this issue is simply that blocking on an unsuccessful transmit (esp. to a sleeping end device, which could take quite some time), is really not great when any kind of user interface is also being managed. For example, simply flashing an LED should be simple but can’t be done properly if a message must be transmitted from time to time.
There are other consequences to the transmit call blocking… WDT for example continues running during transmit and can trip if its timeout isn’t made longer than the transmit timeout (which could be very long for a sleeping end device).
Cheers, Ross