pygmy_giant wrote:sorry to 'interrupt' but when I think of 'GPIO' + 'interrupt' in the same sentace I think of pages 25 -30 and 79 most of all 109 onwards in the Boardcom BCM2835 ARM Peripherals datasheet - is that what was intended by the OP?
I'm more interested by the way that interrupts work on a hardware level than in pieces of software elbowing each other out of the way.
Am I missing the point? how can software exploit these hardware interrupts?
I'm sorry I have no understanding of my own to contribute - I intend on scrutinising these parts of the datasheet at a later date....
Myself and others have posted demonstrations of how software can work with these hardware level interrupts.
The issues (as I see it) is making them work in a Linux-friendly manner.
So while you can get down to the bare metal and have some code executed the instant the interrupt happens, once you put Linux on-top it all changes and there are 2 mechanisms that I'm aware of.
One is the way it's done at present - the GPIO driver is capable of detecting interrupts and working with the standard Linux file event mechanism, so that when a program listens for an interrupt, that program is stalled, the CPU is free to do other things and when the interrupt comes in, the program is resumed. If that program is a thread in a bigger program, then the bigger program keeps on running, the thread is stalled, and wakes up when the interrupt happens. There is no busy-loop polling, and other than the overhead of creating the thread and waiting on the file event, it works in the same way you'd expect a program to take an interrupt.
Fetch my wiringPi library and look in the examples directory for a file wfi.c - that program creates a thread and the thread then waits for an interrupt. It's not a busy wait, it's consuming zero cpu resources while it's waiting, but as soon as the interrupt happens, the process is resumed from where it stopped and can handle the interrupt.
The other way is to have a signal delivered asynchronously to your program. This is being worked on as a kernel module right now - to do it this way, you need to write a signal handler in your program (which is a function), register that function with the Linux signal mechanism, then get on with what you need to ge on with doing. When the interrupt happens, your program will be signalled and the signalg handler code will be executed. This is closer to a more traditional approach to handling interrupts but it's not mainline yet.
Both ways handle interrupts from the hardware directly to the user program. The first way involves creating a thread that runs in parallel with the main program, the 2nd is a more traditional approach.
Both ways are utilising real interrupts - there is no busy-loop polling for an event.
If you want to start to program the interrupt registers your self and have the ARM vector directly into your code, then you need to write it as a kernel extension/module and run it as part of the kernel.