To keep existing functionality for existing users of wiringPi and introduce this new functionality you can add some new defines next to existing INT_EDGE_XXX and let the user by bit-or'ing mode
parameter of wiringPiISR
choose between two behaviors: old one where interrupt condition should occur when user function is not active and new one when wiringPi also reacts to interrupt condition at the time of user function execution.
firstname.lastname@example.org wrote:The seek I was using is not needed (serves me right for copying someone elses example!)
As I understand what RasperryPi/Linux developers say there are five interrupt conditions: raising edge, falling edges, both edges, low and high. With seek
you could read last two conditions (without seek read
always returns 0 bytes) but for now I can not imagine what it exactly means interrupt on low
or interrupt on high
- does it means that poll without waiting will always return POLLPRI event while GPIO pin stays low or high?
Arguably, if a 2nd interrupt comes in while still processing the first one, then you've lost - interrupts are coming in too fast for you to handle.
Or the hardware/software setup has a flaw: with RFM70 to clear interrupt state I need to send some SPI data and RFM70 clears interrupt by returning INT line to high level, but after moment it pulls it down again and my user handler function at this time is still active (I tried to put call to wiringPiSPIDataRW
as last instruction in user handler and there still was moments when new interrupt signal was discarded by read
This will allow a 2nd interrupt to be latched and dispatched then next time was waitForInterrupt(), but only a 2nd - any more will be ignored and lost.
With one additional thread per pin and semaphores it is possible to implement interrupt counting and call user function as many times as the interrupt condition occurs. But I can not imagine real world situation that would need it.
I've also noticed there is often a spurious interrupt when the system is setup
I saw the same behavior and think that it needs to be cleared in wiringPiISR
(you can use the same function waitForInterrupt
with 0 timeout).
If you want to try the new code, drop me an email - but I'll be doing a new more tests before I push a new released of wiringPi out.
I will send you PM. And it would be nice to hear some more opinions from forum readers - maybe someone have some practical experience with interrupt handling in userland programs (for me it is very first project - with RPi, interrupts, wiringPi, SPI and a lot more things - feels like I'm learning very well).