Asyncio short sleep?

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
mkarliner
Posts: 8
Joined: Fri Sep 09, 2016 10:59 am

Asyncio short sleep?

Post by mkarliner » Fri Sep 09, 2016 11:01 am

Is there any time frame for asyncio sleeps shorter than 1s?
What are the issues about shorter sleeps?

thanks

Mike

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Asyncio short sleep?

Post by pythoncoder » Sat Sep 10, 2016 5:41 am

As I understand it asyncio is scheduled for further development as part of the ESP8266 work. Hopefully it will acquire better timing granularity. Faster approaches to concurrency include the _thread module, which I believe is supported on the WiPy. Lastly there is an unofficial module which supports cooperative scheduling using coroutines https://github.com/peterhinch/Micropython-scheduler.git.
Peter Hinch
Index to my micropython libraries.

mkarliner
Posts: 8
Joined: Fri Sep 09, 2016 10:59 am

Re: Asyncio short sleep?

Post by mkarliner » Sat Sep 10, 2016 9:41 am

Thanks Peter,

So, the question is, will we be getting _thread on the ESP8266?

Meanwhile, I've had a quick look at your scheduler, and I'm trying to
work out if I can use it with the mqtt module.

Also, I'm having a serious think about trying to write an asyncio
version of mqtt, assuming that we get milli/micro second sleeps
in asyncio. Would you be at all interested in joining me in this
adventure?

cheers
Mike

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Asyncio short sleep?

Post by pythoncoder » Sat Sep 10, 2016 11:00 am

My scheduler works on the ESP8266 and I have been using it with MQTT, using simple.py. The aim was to bring MQTT to the Pyboard via an ESP8266. This involves a significant amount of code and frozen bytecode is necessary to run it on the ESP8266.

I subclassed MQTTClient to avoid blocking behaviour when awaiting qos 1 acknowledgements and use a thread to reconnect the WiFi link after outages. Threads are used for other purposes including communication with the Pyboard. However all in the garden is not rosy...

I'm experiencing some odd behaviour with qos 1 when the quality of the WiFi link degrades, and I haven't yet got to the bottom of the cause. The code may have a bug or there may be something more subtle going on. It works, but communication is less robust than under the synchronous code: sometimes acknowledgement packets aren't received. The code re-transmits but I'm unhappy that I haven't yet figured out the reason why the asynchronous version behaves in this way.

As I understand it the developers are improving asyncio and I think there was talk of an official asynchronous MQTT implementation: I think we need to know the official direction on this. I'm sure contributions will be welcome, but there's no point in duplicating effort. My attempt started out as a supposedly simple test to verify that my scheduler was practical on the ESP8266. It is, but I think there's something about ESP8266 sockets which I don't yet understand.
Peter Hinch
Index to my micropython libraries.

Post Reply