MicroPython Forum (Archive)

Alas I have no experience of using _thread under MicroPython so I can't comment on performance. I avoid pre-emptive scheduling if I possibly can. I think my approach would be to try to include the C modules in the build in an attempt to get uasyncio working. I don't know how easy that would be, mind you, but it's surely worth a try.

Failing that there is my old scheduler which is written entirely in Python. I should stress that I regard this as obsolete: I wrote it as my first MicroPython project before I had any knowledge of optimisation techniques. However it does work. My touch GUI's used it until I ported them to uasyncio so it has performance adequate to support a UI in a typical application. If you adopt that approach and the team at Pycom subsequently wake up and smell the coffee that is uasyncio, porting your application to it should be straightforward.

I made the attempt to port the module utimeq into the Pycom MP variant (instructions here: https://github.com/pycom/pycom-micropyt ... issues/112) and also made a PR to fix their utime module (https://github.com/pycom/pycom-micropyt ... x/pull/115). That allows using asyncio on Pycom MP, after catering for sligtly different API calls, like reversed arguments of utime.ticks_diff(), and the missing poll.ipoll() method. I tried some of the uasyncio examples. They seem to work.
The port of utimeq seems to have many places to change, but most of that is simple management and settings. I di dnot make a PR for that yet, but could do so.

@Roberthh Well done!

Pycom must be using ancient code: the ticks_diff() argument order was changed well over a year ago. That will cause a lot of applications developed for normal MicroPython targets to fail on their products

@Roberthh Wow, that is truly impressive!

I only hope Pycom understands and appreciates what you have achieved.

Note that the latest uasyncio packages on PyPI require the latest MicroPython, built from source. I no longer a comaintainer of the (official) MicroPython, and don't influence when upstream releases are made.

I also test uasyncio with my fork, https://github.com/pfalcon/micropython , and in the future may imagine that it may work only with my fork.

In my fork, I continue development and optimization of uasyncio and other MicroPython-related components, which I no longer can perform in the upstream.

uasyncio.cancel(coro) has been implemented in uasyncio.core 1.7.1. It corresponds to asyncio's Task.cancel() method (as there's no "Task" wrapper in uasyncio, it instead goes as a top-level function which accepts native coroutine object).

I've found this on PyPI but not in micropython-lib - will future changes appear there?

See viewtopic.php?f=15&t=70&start=10#p24434

uasyncio 2.0 is coming up. It switches scheduling to 2-level algorithm, which requires asymptotically less memory, and allows to repurpose existing memory overheads to resolve other pending issues in asyncio. It will depend on the functionality in https://github.com/pfalcon/micropython .

Ok, uasyncio.core 2.0/uasyncio 2.0 were released, with scheduling optimizations which should enable even more optimizations in the future. uasyncio.core now depends on ucollections.deque class implemented in https://github.com/pfalcon/micropython .