doetoe wrote:
Finally, there is no mention of specifying ISRs. Is that because in linux there is a standard interrupt API which should be used?
I would be very grateful if anybody could help me out, even if it is just some keywords to look for on google. Thanks.
Linux (and unix) in-general never really expected user-land code to handle hardware interrupts (that's the kernels job!), and that's the issue at-hand - there really is no API for handling interrupts in user-land code.
So in the traditional sense, there isn't "ISR" - Interrupt Service Routine.
So what can you do - many things. One, write your own operating system. A bit drastic that one! Use another OS - well the only other viable choice right now is RiscOS... You could write your own kernel module - this is the closest you'll get to a real ISR. You write the module, poke the hardware to tell it to deliver an edge triggered interrupt and tell Linux to register your driver with the interrupt handler and off you go. It actually is a real ISR - within the Linux kernel interrupt handler - this is the same mechanism Linux usesto access all interrupt driven hardware, disk controllers, serial ports, and so on. All your code is running at the kernel level with all the implications that has - security, robustness, crashability, etc.
Great if you're a Linux kernel module writer, not so good for the other 99.9999% of us... (Although from what I've seen the learning curve isn't that steep for an accomplished C programmer, however, much though I wish I have dived in, I've never found time).
So we're left with Plan B.
Firstly, it is good to know that is is possible to get an edge detected interrupt on a GPIO pin delivered into a user-land program. It's not technically the same as a true ISR, but it does have the same effect and with care you can handle about 10K interrupts/second although realistically at that speed the overhead is so high, there's little cpu left for anything else.
The way to do it is to create a thread in your program - that's a function that you write, and which you then ask Linux to schedule concurrently with the main program. That thread then asks the kernel to make it sleep, and wake it up when the interrupt happens.
Meanwhile, your main part of the program carries on executing, doing its thing, whatever that might be.
When the interrupt happens, the main program is suspended and the sleeping thread is woken up, it can do "stuff" to handle the interrupt, possibly use global vairables to communicate with the main program, then go back to sleep, waiting for the next interrupt.
Note that it's not the same as polling as the thread is stopped and consumes zero cpu, (which polling wouldn't) however the mechanism inside the Linux kernel to suspend the main task and wake up the sleeping thread when the interrupt fires does have more overhead than something you might be used to on an embedded controller with no operating system as such.
Anyway, that's the way that's currently implemented - I know of someone working on a Plan C, however I don't think i's quite ready yet.
If you want examples, demos, then see:
https://projects.drogon.net/raspberry-p ... functions/
scroll down to interrupts, then get the wiringPi code and have a look at the wfi.c code in the examples directory
-Gordon