Presto IRQ

Hello,
Does anyone know if you can use the IRQ handler on the Presto Button with Micro Python?

Perhaps I’m comparing the use of a physical push button with a logical on screen button activated with a touch and getting the wrong end of the stick so ignore the comment if its not appropriate.

Interrupt handling functions should run as quickly as possible, maybe just setting a flag on a physical button press for a routine that polls the flag to start a beefier function. When the Presto touch indicates a button is pressed then I suggest the same function (that the interrupt handling routine would call) is called directly. No need to generate an IRQ just for the interrupt service routine to call the function.

Thanks for your help, but
I use this part in my program:

while True:
cl, addr = s.accept()
receive = str(cl.recv(1024))
cl.close()

This waits for an incoming HTTP call.
As long as nothing comes in, it’s idle here, about a minute.
So I do need an IRQ handler to get something done in between.
Otherwise, I have to hold down the key for a minute.

No, you do not have to use an IRQ to do concurrent programming. The usual way is to use the asynio module. Best if you have a read about using asyncio produced by Peter Hinch.

I probably should have given a link direct to the async tutorial docs - here it is:

Thank you, I am studying it.

In this case, I would still use an interrupt (add a handler to the user_sw), set a flag and query that flag in your while True loop. With touch, things might be different. And it also depends if you need the interrupt to leave your loop or if you need it to trigger some other action.

Nevertheless, asyncio programming is extremely useful and I use it for all kinds of stuff. Mainly because I use CircuitPython which does not support interrupts. So reading the asyncio link that @SirFico provided will pay off sooner or later.

Thanks for your answer.
But what is a user_sw on a Pico-W?
Besides reset and boot, there are no switches on the Pasmorini Presto.

from presto import Presto <<<<<<
from touch import Button <<<<<<

And this button doesn’t support IRQs.

The boot button is a dual use button. Pressing it while you power the device on will take you into bootloader mode (i.e. you can update the MicroPython firmware). Once the firmware is running, you can use the boot button as a regular button. The schematic calls this “user_sw” and it is tied to GP46. You would create a normal digitalio for this as you would do for every other mechanical button.

Great, thanks!
I didn’t know this, but it’s helpful.

Thanks again.

@Eef if you are mulling over using interrupts or async style for the physical push button (you can have more physical button on the Presto if you use an i2c gpio extender) then, if you got a bit genned up on the async stuff, then a peruse of the doc linked below by the same author may be of interest. (or it may be just some more unwanted homework :)

As I was just playing with some touch buttons on the Presto to get them to briefly flash red to indicate a touch, I thought about that little old boot button and had a feel as to how easy it would be to find. Its rather close to the reset button, and rather too easy to press both or even the wrong button and reset the program at least for my stubby mitts. Compared to an easy prod of the screen button the boot button would be a bit of a pain. Anyway enough of this musing, and I hope you get to a suitable solution for your program.

Thank you for your information.

The problem is that I’m waiting for multiple incoming HTTP messages.
Every minute or so, a message arrives.
The problem is that the while True: loop has to wait for this.
And that’s why using the touch buttons doesn’t work.
(Yes, if you hold it down for 1 minute).

Thats the sort of scenario that async can handle very well. Perhaps a fuller explanation of your scenario will enable me to give a better response rather than giving you a bunch of homework to read. My normal messaging with micropython is via mqtt and I don’t have a ready snippet example of using asyncio with HTTP to hand in mp. I think I have a python one somewhere.
But anyway a better understanding of your program would be required for good advice. Is your program short enough to post here perhaps.

I don’t think so. If you set a timeout on the server-socket you don’t have to wait that long: the accept will fail without a message, you can process other stuff, then iterate next.

I would suggest that you search the net for a more robust server implementation. There are many, including tutorials and sample code. There are even MicroPython webservers based on asyncio available.

True, it is more than the few lines you have here, but it really saves you work.

Absolutely true, I have the same problem on other devices. These are the small details you don’t pay attention to when you design hardware. But even with two buttons that have a different tactile feel: you will still ask yourself which is which, especially if you don’t use them often.

while True:
cl, addr = s.accept()
ontvangen = str(cl.recv(1024)) <<<<< STOP
cl.close()
print(“Receive”) # This print comes only after the http call.

'''
splitsing()	#<<<<These are normally the next steps, and that works fine after the http call.
plaatsing(x) # this is dutch.
'''

This is a part of the program

#The problem is that by STOP, the program waits for any incoming HTTP message (one minute)

#But under the while True command, I want to use touch buttons.

That is why recommended to set a timeout on the socket. It seems it has a timeout of 60 seconds. I would set it to nonblocking (i.e. timeout=0). You only have to make sure you catch the relevant exception, because cl.recv(1024) will fail.

Here are the docs: socket – socket module — MicroPython latest documentation

Well yes, and if 1024 bytes are not received, unless you put in a timeout as @bablokb suggests then your program will block. This is not anything to do with the use of physical or on screen touch buttons though. Whatever process it is that kicks off this while true loop, this could block whilst it awaits data. Asynchronous sockets to the rescue ? But maybe start with creating a timeout in your socket code.

Well I just found this on a quick google that may be helpful to you:

When you do recv(1024), there are 6 possibilities

  1. There is no receive data. recv will wait until there is receive data. You can change that by setting a timeout.

  2. There is partial receive data. You’ll get that part right away. The rest is either buffered or hasn’t been sent yet and you just do another recv to get more (and the same rules apply).

  3. There is more than 1024 bytes available. You’ll get 1024 of that data and the rest is buffered in the kernel waiting for another receive.

  4. The other side has shut down the socket. You’ll get 0 bytes of data. 0 means you will never get more data on that socket. But if you keep asking for data, you’ll keep getting 0 bytes.

  5. The other side has reset the socket. You’ll get an exception.

  6. Some other strange thing has gone on and you’ll get an exception for that.