Monitor GPIO Input with uselect?

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
AndyFug
Posts: 5
Joined: Mon Jun 22, 2020 6:26 pm

Monitor GPIO Input with uselect?

Post by AndyFug » Tue Jun 23, 2020 6:21 am

Hi,
Had a quick scout around and couldn't find much on the subject. Apologies if I just missed it.

I was wondering if it was possible to monitor a GPIO pin (in my case, on an ESP8266) with uselect? I'm using uasyncio for other network io and misc tasks and was just trying to work out the best way to capture and then act quickly upon GPIO activity. It seemed to me that uasyncio polling the GPIO pin via uselect would be a better approach than uasyncio polling the GPIO ports on its event loop. Correct me if I'm wrong.

Novice to this world so apologies if this seems like a daft question. I guess if the above isn't possible, I can see two other options:
1. Poll the GPIO Input as an additional async task
2. Use interrupts/callback to create an async task. (Would this work?) Issue I foresee with this is if uasyncio at that point happens to be waiting on a uselect poll for network activity, how can you interrupt it to run the new task?

Which would be the best solution? Are there any other options?

Many thanks,

Andy

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

Re: Monitor GPIO Input with uselect?

Post by pythoncoder » Thu Jun 25, 2020 4:52 pm

This is something which is under consideration by the maintainers: enhancing select.poll to handle a wider variety of asynchronous events. Currently there is no support for this.

One option is to have a coroutine method which polls the pin and sets an event on a state change.

Code: Select all

async def check_pin(self):
   pin_state = self.pin()
   while True:
       if self.pin() == pin_state:
           await asyncio.sleep_ms(0)
       else:
           self.pin_event.set()
           pin_state = self.pin()
This is crude but in many applications works fine. On each complete iteration of the scheduler after every other coroutine has been scheduled, check_pin will cost perhaps 200μs of execution time (depending on platform). In a typical application this might equate to a 1% performance hit.

You could use an interrupt, but currently triggering an event from an ISR is unsupported (another work in progress). This doesn't provide any gain in terms of uasyncio scheduling latency but can be vital if a rapid response to a pin change is required.

Latency is the worst-case time between the state change occurring and a coroutine responding to it. Currently there is no way to make this happen in less than one complete iteration of the scheduler - round-robin scheduling can't be pre-empted. Again this is under discussion. The intention is to provide a means whereby selected events can be polled every time a coroutine yields to the scheduler, rather than once per complete iteration.

In conclusion, with current uasyncio V3, polling is as good as it gets.
Peter Hinch

AndyFug
Posts: 5
Joined: Mon Jun 22, 2020 6:26 pm

Re: Monitor GPIO Input with uselect?

Post by AndyFug » Fri Jun 26, 2020 6:15 am

Hi,

Many thanks for your response. That's much appreciated. I was hoping you'd say that it would be trivial to wrap the GPIO pin as a stream object or something along those lines, so it can be monitored like sockets, but given the fact it's under discussion and not been implemented by anyone, I'm guessing that's not the case. :)

I guess I'll have to consider other hardware options for projects where this may cause a problem.

Cheers,
Andy

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

Re: Monitor GPIO Input with uselect?

Post by pythoncoder » Fri Jun 26, 2020 10:12 am

It is possible to wrap a GPIO as a stream object, and my tutorial shows how to do this. Alas uasyncio V3 does not yet have a means of prioritising I/O, so wrapping a GPIO in this way confers no advantage.

It is planned for uasyncio V3 to have a facility to prioritise I/O, so there is a high likelihood that this approach will eventually pay dividends. However, as I explained above, enhancements to select.poll are also under consideration. More elegant and efficient ways to prioritise GPIO will probably emerge.

That's life at the bleeding edge, I'm afraid ;)

My fast_io version of uasyncio has a way to prioritise I/O. This is is just a modified V2. I don't recommend it for general use: in every respect aside from I/O scheduling uasyncio V3 is streets ahead of V2.
Peter Hinch

AndyFug
Posts: 5
Joined: Mon Jun 22, 2020 6:26 pm

Re: Monitor GPIO Input with uselect?

Post by AndyFug » Wed Jul 01, 2020 9:40 am

Hi,
Sorry for the slow response to your last post. I think I need to look into my email notification settings.

Thanks for the detail and the pointer towards your tutorial - that looks great. I'm using pycopy & picoweb for my current project, which isn't heavily reliant on GPIO but I was thinking of adding a couple of minor features. I'll need to look into if/how I can make any of that work together.

I suspect I may need to have a ground-up re-think if I want to implement GPIO 'properly' with an async web server/framework on a future project with the esp8266. :)

Many thanks again,

Andy

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

Re: Monitor GPIO Input with uselect?

Post by pythoncoder » Fri Jul 03, 2020 5:10 am

Bear in mind that pycopy is developed by the author of uasyncio V2, and its uasyncio is an updated version of that design. Hopefully some of the bugs have been fixed.

Official MicroPython uses uasyncio V3 which is a complete rewrite. A key aim of the V3 design is improved CPython compatibility. Implementations will continue to diverge when the improvements to uselect and prioritisation are implemented. It's your choice which to run. My view is that V3 is already excellent and can be expected to become considerably better in applications requiring high performance.
Peter Hinch

Post Reply