You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've given the interrupts a test, and while they work, I get pretty bad bouncing on a simple switch (no hardware debouncing), which triggers the interrupt on almost every 'release' as well as each 'press'.
I've configured the software with interrupt: rising which should (and does) trigger when I press the button, however it also triggers quite often when I release the button. You can see why in the waveform above. The Pi's GPIO lib doesn't seem to be adequately protective of this, given that it should really discard the rising edge if it occurs within bouncetime of a falling edge.
I wonder if there's a neat way we can protect against this, which will work regardless of debounce implementations offered by the GPIO libs we use?
I wonder if it's because you have interrupt: both, which will probably take into account the debouncing of both rising and falling edges. In which case, we'd need a way to establish whether the trigger was a rising or falling one in order to be useful.
That's the problem, I guess: the library doesn't support, what interrupt occured... Then we would have to register to both interrupts (although only rising is configured) and try to recognize the interrupt level (with sleeps?!) and only transmit rising interrupts ...
I've given the interrupts a test, and while they work, I get pretty bad bouncing on a simple switch (no hardware debouncing), which triggers the interrupt on almost every 'release' as well as each 'press'.
I've configured the software with
interrupt: rising
which should (and does) trigger when I press the button, however it also triggers quite often when I release the button. You can see why in the waveform above. The Pi's GPIO lib doesn't seem to be adequately protective of this, given that it should really discard the rising edge if it occurs withinbouncetime
of a falling edge.I wonder if there's a neat way we can protect against this, which will work regardless of debounce implementations offered by the GPIO libs we use?
@BenjiU
The text was updated successfully, but these errors were encountered: