Anybody know of an example of how to handle Pi GPIO IRQs in a C module?

I am working on an Econet hat for a pi based on Andrew Gordons RasPi Pico Econet work, and while I have a fair way to go before I have a drop in replacement for the Econet module, its functional to the point of packet exchange with my BBC.

At the moment the RISC OS side polls the Pico side over the GPIO but the PRM says I should generate Econet RX and TX events and for that it looks like I need the Pico side to interrupt the RISC OS side.

If anybody knows where I might find an example pi gpio irq handling, preferably for a C module that would be very helpful.

I am thinking my plan B is to sit on tickerv and just poll the pico irg gpio pin at 100hz.

Alan

Hello Alan,
You can take a look at: https://gist.github.com/keriszafir/37d598d6501214da58e0
Where you will find sample code….

Using wiring library, you could do:
#include
#include
#include
#include

#define BUTTON_PIN 17

void handleInterrupt(void) {
// Your code to handle the interrupt goes here
printf(“Button pressed!\n”);
}

int main(void) {
if (wiringPiSetupGpio() == -1) {
fprintf(stderr, “Error initializing WiringPi\n”);
return 1;
}

}

but of course, it’s using WiringPi library…

oops, apparently includes are lost in the copy of code: , , and

#include (wiringPi.h)
#include (stdio.h)
#include (stdlib.h)
#include (signal.h)

…. replace parenthesis by minus and greater signs…

You can use HTML character entities to stop Textile converting them.

#include <stdio.h>

becomes

#include <stdio.h>

Or wrap the code in a <pre> block to make it readable?
Then the angle brackets get converted automatically.

Reading material: https://textile-lang.com/

Using a timer to poll the GPIO pin (your plan B) could work, but interrupt-driven GPIO handling is a more efficient and responsive approach.

I recently wanted to implement a timer in RISC OS, triggered to start and stop by two different GPIO pins. I discovered that the GPIO module allows setting of the pins to generate interrupts, but doesn’t allow a handler to be added.

I ended up polling in tickerV, and for speed stored a counter that was incremented in TickerV every call. As I needed accurate time-of-day I also stored the 5-byte system clock when I started the counter. TickerV also set a pollword to non-zero, and the poll response code read the stored counter, and cleared it (done with interrupts disabled), and added the system clock value. Having run it for 24 hours, the results were about a second different from the stopwatch. As I only need 1/10 second accuracy, over a maximum of 10 minutes, it’s fine. (I have 5 stopwatches, and the difference between them is greater than that.)

Jay:
> but interrupt-driven GPIO handling is a more efficient and responsive approach.
Yes I absolutely agree, hence my post…

Alan:
> I discovered that the GPIO module allows setting of the pins to generate interrupts
Interesting I must have missed that, where exactly?

It seems there are two versions of the GPIO module the current one which converts all its SWI calls to HAL calls and the old one that did all the work in the module and supported beagle boards, DEVKIT8000,and early pies.

What I find at the moment is neither the GPIO module or the PI HAL have any code to enable/disable GPIO interrupts.
So given that I either

(A) write support for interrupts into the HAL and GPIO module or
(B) write support into my module to enable irqs on however many different PI IO schemes I feel like supporting, well I guess at least we know there won’t be any more for RISC OS.
© poll from the ‘Call Every’ I already have setup to timeout my code if the PICO crashes for any reason.

Since I don’t even know of a single use case for Econet events I will be implementing option C for now.

I guess its valuable to know that GPIO IRQS are presently unsupported by the OS.

I doubt its hard to DIY, I just haven’t bothered finding the data book on the GPIO registers and their addresses in RISC OS yet.
If that turned out to be the same for pies 2,3,& 4 it might be no trouble, my hat’s got a 40 pin connector so I am ignoring Pi1.