uasyncio

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
pythoncoder
Posts: 1381
Joined: Fri Jul 18, 2014 8:01 am

uasyncio

Postby pythoncoder » Sun Jan 01, 2017 5:02 pm

In recent weeks this has been radically improved. In particular it now offers millisecond level scheduling making it usable for asynchronous (non-blocking) device drivers. I've spent some time coding with it and documenting its use.

This is the outcome https://github.com/peterhinch/micropython-async.git.

It provides the following:
  • A brief description of the subset of asyncio currently available.
  • Debounced device drivers for switches and pushbuttons. The latter supports long-press and double-click events.
  • Several demo programs.
  • A set of simple synchronisation primitives: Lock, Event, Barrier and Semaphore classes.
  • A tutorial on using the uasyncio subset to interface hardware.
The tutorial is a work-in-progress, not least because uasyncio is itself under development.

Any comments, especially corrections of factual errors, welcome ;)
Peter Hinch

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

Re: uasyncio

Postby mkarliner » Tue Jan 10, 2017 6:23 pm

Very good late Christmas present!

Thanks Peter.

User avatar
pythoncoder
Posts: 1381
Joined: Fri Jul 18, 2014 8:01 am

Re: uasyncio

Postby pythoncoder » Wed Jan 11, 2017 7:39 am

I'm impressed by the updated uasyncio :D I'm porting my applications to it in place of my old scheduler and have found the process remarkably painless. For example my touchscreen GUI https://github.com/peterhinch/micropython-tft-gui now runs under uasyncio with subjectively quick responsiveness. This makes fairly extensive use of asynchronous code so it's been a good practical test.

As I see it uasyncio still needs further development of IORead to better support devices such as UARTs and user-written drivers. But kudos to Paul for producing an effective asyncio subset with speed capable of handling hardware interfaces.
Peter Hinch

brett
Posts: 11
Joined: Sun Jan 15, 2017 3:17 am

Re: uasyncio

Postby brett » Fri Jan 20, 2017 2:24 pm

I read your information and I'm still trying to wrap my head around it. Would uasyncio help in this situation?

I'm a psychologist in a school system and we have several students with behavior issues that flip out (technical term) and get aggressive when their teacher calls the office for assistance. I've been trying to use a ESP8266 to create a box with a remote that she could discretely press to send a push notification to the office, myself, administration, etc. I want it to send a help request message with one press and a urgent help request with 3 presses in a certain time.

Thanks to help from you guys on here I got the button presses working but when I put the urequests post in there it locks the program up so it doesn't respond to additional presses and when it does they are so backed up that it crashes the program. I've been looking for a way to have the program send the request but not have to wait for it to complete before returning to the main loop. Is that possible with uasyncio on the ESP8266? I may have to utilize two different buttons on the remote, but I would rather the teacher not have to look at the remote to send the request. Thanks for your help.

--Brett

User avatar
pythoncoder
Posts: 1381
Joined: Fri Jul 18, 2014 8:01 am

Re: uasyncio

Postby pythoncoder » Sat Jan 21, 2017 7:18 am

Unfortunately I'm not knowledgeable about the network programming side of things; I did some work with umqtt and found that it was difficult to integrate with asynchronous programming because it can block. In other words it can monopolise the CPU until a response is received. If urequests works in a similar way then you need to decide whether to send a request or an urgent request before you initiate the urequest. By that time the fact that it might block won't matter: the asynchronous timing stuff is complete.

In principle it should be easy. By definition a non-urgent request can be postponed until you're sure an urgent request is not intended.

The following comments relate to my aswitch.py module.

Create a Pushbutton instance and a Delay_ms timer. Your press_func callback triggers the timer if it's not already running, and sets a press_counter to 1; if the timer is running, it increments the counter. At the end of the time period you check the counter, clear it down and send a request or urgent request. If the sending process blocks for a period it then doesn't matter.

Rather than require three button presses have you considered a long press for an urgent request? It might be easier for users in a stressful situation and also possibly faster. How long should you wait to count three presses?

The Pushbutton class supports this. If the button is held down, after a configurable period a long_func callback is run. Start your Delay_ms timer in the button's press_func callback. Have the button's long_func callback set an emergency flag. When the Delay_ms timer times out, send the non-urgent message if emergency is False, otherwise clear it down and send the emergency message.
Peter Hinch

brett
Posts: 11
Joined: Sun Jan 15, 2017 3:17 am

Re: uasyncio

Postby brett » Mon Jan 23, 2017 2:21 am

Someday I will have to figure out how to install uasyncio and your aswitch modules. I think you are probably right about the long press, but I was struggling on how to get those modules working. So I figured out how to postpone the helpRequest function like you suggested. The program is working for the moment...well...if I can get the urequests post working correctly. Thanks for the help.


Return to “General Discussion and Questions”

Who is online

Users browsing this forum: No registered users and 4 guests