Grumpy Mike wrote:
firstname.lastname@example.org wrote:The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run
So if you have to suspend your program while the kernel handles an interrupt isn't that just defeating the whole purpose of having an interrupt in the first place. It is in my book. Why not simply pole if that is all it is going to do?
I don't know - why not? That's up to you - but it all depends on what you are trying to achieve...
e.g. you might have several programs running at once - if one of them were to actively poll via a loop in the program for an IO pin to become a certain value, then it will eat CPU cycles, depriving other programs of those cycles... So, having the program wait on a interrupt will stop that program running, allowing all those cycles to be shared between everything else that's running.
It's a bit of an oddty though - here we are on a multi-user, pre-emptively multi-tasking operating system now - not a little microcontroller like an ATmega where you have everything to yourself - of-course if you're writing just one program to run on the Pi then it's probably no different, but the Pi can do more than that... Or it can allow single program to capture an event smaller than a program mght otherwise be able to detect - the hardware can be programmed to trigger on an egde, so a tiny pulse that a program polling it might miss will be recorded and actioned as soon as possible.
(Although you can capture and poll for those edges without interrupts - the hardware is quite versatile)
So it's one more tool avalable to you.
An example I'm going to do soon is to use it to count pulses from an encoder connected to a robot I'm working on. I will run a separate thread to my main program which will wait for the interrupt and increment a global variable until it matches a pre-set value, then it will turn the motor off and signal the main program.
Meanwhile the main program will be listening for commands via a wireless interface and exchanging other telemetry with the base station..
So you can get awy from the whole "big loop" type of programming for these sorts of things by creating lots of autonomous and asynchronous tasks.
Although that in itself can sometimes be a challenging thing to comprehend - however at least you have the tools to-hand!