How to do software de-bounce?

[HakanL]

What's a good way to do a software de-bounce when using interrupts on the PiFace? I've tried with just a sleep in the interrupt routine, hoping it would just pause that thread/process and then do another evaluation after the sleep. It didn't work that well though, sometimes it misses interrupts because of this (like if the return to 0 is within my 100ms sleep then I won't get another interrupt to indicate that the pin is now 0, even if the previous interrupt was 1.

[HakanL]

On that note, if I have noise on my input (I touched the input with my finger) I get a lot of interrupts and they all had the same direction. I find that odd, I'd assume the interrupt would only trigger when there is a change compared to the previous interrupt. Also I'm not convinced the pull-up is working, is there a good way to verify that?

[tompreston]

Interrupts are difficult to handle when sitting so high up the software stack. When an interrupt occurs, subsequent 'interrupts' in the MCP23S17 are ignored until we clear the interrupt flag. This can only be done after the first interrupt reaches our Python process, which is at the mercy Linux's scheduling. Very fast interrupt handling simply isn't possible unless we're programming on the hardware.

While we may not be able to get all of the interrupts, we can still often pick up more than we bargained for. In the latest version of pifacecommon we can pass the register method of the PortEventListener (InputEventListener) a settle_time. The settle_time is the window in which subsequent events for that pin/direction will be ignored. Setting it to 0 will cause the event listener to grab events as fast as possible (as fast as Linux/Python will let us reset the interrupt flag).

See: http://piface.github.io/pifacecommon/reference.html#pifacecommon.interrupts.PortEventListener.register

import pifacedigitalio
pfd = pifacedigitalio.PiFaceDigital()
listener = InputEventListener(chip=pfd)
listener.register(0, pifacedigitalio.IODIR_FALLING_EDGE, callback, settle_time=0.1)
listener.activate()

Does that solve your issue?

[HakanL]

My problem occurs if the final "off" trigger happens during the settle time. See if this helps explain it:

1. Input goes high
2. Interrupt is triggered
3. Input goes low
4. Waiting for settle time
5. Nothing

Preferable I'd want a check in the interrupt routine (PiFace code) after settle time to see if the input is different than what it triggered on and issue another python-interrupt with that new value. In my application I'm dependent on both the high and low state (plus de-bounce) so my application gets stuck in high state.

[acatoire]

I have a similar issue using a relay.

I miss some interrupt even if they are slow, it may be a debounce issue, I don't know.
I have a ON/OFF command on a relay connected to an input of the piface.
The On to Off or off appear usually with more than a second between, sometimes the system don't detect the last rising or falling.
It is strange because finally if I read the level of the input I have 0 even if the falling event never happen. I was thinking to add a periodic check of the level (pulling), but it feel wrong next to an event handler :-)

I will try the new setting and let you know.