Can Pi GPIO's interrupt

I know this has been discussed before but I couldn’t find a definitive answer. I’m using a Pi4 and I need to monitor a gpio pin for edges. I couldn’t get a gpio event to cause an interrupt which may be because I’m forgetting to enable something. The documentation is not very helpful in this matter either.
So I poll the pin which works but is not ideal because the edges occur every few hundred microseconds,

The BCM2711 peripheral data sheet clearly states that gpio events can cause interrupts but how do I enable them or is it just that this has not been implemented in the OS ?

Sadly, as far as I’m aware, they can’t generate interrupts on RISC OS. The closest you can get is to set a pin to generate an event on eg. a rising edge, then if the event has happened you get told about it the next time you poll the pin to check. I don’t think the GPIO module offers a way to get an interrupt from the pin every time a rising edge (eg.) occurs.

Thanks Andrew, that confirms what I thought.
It’s a shame because I was given a case for my Pi which amongst other things has an infra-red receiver in it and I can now control Digital CD from a remote. The only down side is that once an edge is detected via polling, it blocks until the message is received (timing is important) which is a few tens of milliseconds and not so good for say adjusting the volume by holding a button down.
Never mind, it’s still quite good fun.

I had a similar problem. In the GPIO event handler I set a pollword to non-zero and added the current timestamp to a buffer. This then caused a response from the main program, saving polling for the event. In my case I only needed 0.01 sec resolution, and this is sufficient.

Unfortunately for Peter, IR signals typically run at 36kHz so needs much tighter timing when MetroGnome.

It might be worth looking at offloading the processing to something dedicated. A little Arduino device could be set up to receive and decode IR signals, and present the information as bytes to the Pi’s serial port which can deal with them as and when necessary. In that way, it won’t be sensitive to the host’s activity and/or timing.

Even were you able to generate interrupts from the GPIO, you wouldn’t be able to rely on receiving every interrupt at that sort of frequency. Latency on RISC OS was always a bit ‘variable’.

The IR “diode” does the demodulating so I don’t see the 36k carrier but the bit period might only be a few 100us depending on the protocol. I run it from a 1ms interrupt and check for an edge in a callback then sit in a loop with a timeout. Like Alan I timestamp each edge and when edges stop, message the App to decode the edge buffer. I do get about 100 – 200us of jitter but it works quite well, better than I thought it would when my original plan using gpio edge interrupts failed.

I know it’s not really relevant, but in the original GPIO module I did add the ability to read and write the IRQ enable, but only on the Beagleboard…
Obviously then an IRQ capture routine would have needed to be added to the vector, if it was enabled.

Ah, that is exactly what is missing. I knew just enabling the event could not be all that was needed to be done but couldn’t find any way to enable the interrupt. Thanks, at least I’m not going mad… yet!

It might be worth looking at offloading the processing to something dedicated.

I was going to mention this, but it’s not very RISC OS; you could do what the Pi 5 does and have a Pico handle the GPIO. You would then have all the detection code running on that in C or MicroPython, and communicate the IR code received via USB, I2C, or a GPIO UART.

Well I could, I’ve got some development boards with arm cortex round here somewhere and I could use one of those, but it sort of defeats the object of being given this Pi case on the strict understanding that it results in a tidy office (junk room). My house manager would not be impressed.

but it’s not very RISC OS

Oh? Even in the world of RISC OS, fiddly time consuming and complicated things got pushed off to dedicated hardware. The combi-chip that did all the parallel, serial, floppy, IDE jazz. The dinky chip that turned keyboard matrix scanning into serial codes. And these days we don’t even bang out IIC, there’s a controller that looks after it.

The problem is that one cannot reliability handle time sensitive tasks with an operating system running – RISC OS is not an RTOS.
The two choices are to have potentially screwy timing (especially if something stamps on the interrupts) or hijack the entire machine to dedicate time to handling the hardware.

Far better, even in the RISC OS world, to let something else deal with lining up all the chicken nuggets so the host doesn’t have to.

being given this Pi case on the strict understanding that it results in a tidy office

Little microcontrollers ought to, if not fit within the case, be able to be attached to the outside. I’d guess there’s sufficient space in a Pi case for an ESP8266, the Cortex board isn’t much bigger than that is it?

Besides, a tidy office/desk is a sign that nothing ever gets done.

When I needed a computer looked at, prior to having the nouse to fix my own problems, I had a very simple rule. Look at where the computers actually get fixed. Tidy empty bench? Walk away, it’s not a vet.
Bench covered in random crap and a tape drive two decades old sitting on top of an oscilloscope with a tangle of wires connected to it? That’s the guy I trust to sort my problem, and that theory never let me down. Unlike the clean desk clowns who told me that if I needed an extra IDE bus in my Acorn machine, just fit a SoundBlaster card…

My house manager would not be impressed.

Treat your house manager to Felix and tummy rubs. They’ll come around to your way of thinking.

They’ll come around to your way of thinking

Furry people… They will come round to your way of thinking?

Nurse! He’s stopped taking his medication again.

@Rick, Even you would not want to see my cave (garage) where too many years of “that might be useful” and “surplus to requirements (from work)” items are. To be honest I’m a bit lazy and writing a bit of code is easier than fafing about with the hardware. I spent a whole day reverse engneering the case micro pcb to get a circuit diagram as the “user guide” was well, a “user guide”.
@Steve, You’re quite right, I don’t think the cat cares 2 hoots. I was thinkng of the one that uses the hoover.

I was thinkng of the one that uses the hoover.

Er, yeah, about that…