wickedly designed debouncing in Circuit Python libraries

[SeattleDavid]

I am trying to debounce a switch connected to a GPIO pin. It is remarkably wickedly difficult the way the Adafruit libraries are designed. (I use the term "designed" very loosely).

The Debouncer module is the logical place to go, and the library looks reasonable. But because the GPIO apparently isn't processed using interrupts, button presses will be entirely missed if polling isn't pronto fast. As some tasks (like a screen update) are longer than a fast button press this means missed button clicks.

Another approach is to use countio. This uses hardware interrupts and catches those quick button presses when the system is busy doing other things. But it is very bouncy and will continue to count (bounce) after an event is triggered.

A *good* answer would be to combine Debouncer and countio so that bouncing switches were debounced AND quick buttons are caught.

Does anybody have any good solutions so that button clicks aren't missed *AND* the button is debounced?

[danhalbert]

You can try the `keypad` module. This does debouncing and delivers button-up/-down events. The polling is done at a timer-tick level and wouldn't normally miss anything. See https://learn.adafruit.com/key-pad-matr ... cuitpython.

`keypad` is not available on SAMD21 for space reasons.

[SeattleDavid]

Thank you for this suggestion!

I’ll take a look at it. It does seem to be what I need from your explanation. I didn’t consider it because I assumed it was primarily (only) for matrix configurations and in my case I have direct button-to-pin connections.

I’m using a Pico (RP2040).

[danhalbert]

It can do pin-per-button (e.g. Adafruit MacroPad), matrix, and shift-register. It is designed to be a general solution.

[SeattleDavid]

Wonderful module. I just looked at it. Does exactly what I need and more. Nicely architected. Even notes the time stamp of key presses and releases.

I really missed it…and appreciate it being pointed out to me.

The Debouncer module should be retired…or a note should be added along the lines of: “If you are considering using this module then you should really be looking for the keypad module. It’s what you probably want.”

[SeattleDavid]

Wonderful^2

Works perfectly, smoothly, glitch free. Easy to use, logical, and is a delight.

Thank you for the suggestion and kudos to whomever designed and built it!

[danhalbert]

Thanks for the kudos :)

a note should be added along the lines of: “If you are considering using this module then you should really be looking for the keypad module. It’s what you probably want.”

There is a blue box note on this page mentioning the `keypad` module: https://learn.adafruit.com/debouncer-li ... debouncing. But if you did not see that, where else do you think a cross-reference could go?

[SeattleDavid]

The blue box is fine, but it is not very enticing. When a person is learning they are overwhelmed by choices and options when they just want to have some small, trivial amount of success. Learning is a struggle of excessive input overload along with a lack of experience if which options are the good and useful and important ones.

When hiking on trails you can usually look at a brach for the wide well-trod trail and take that one over the other choice that has brambles crossing the path.

So the attractive blue box is fine, but there are no signs of brambles on the use of the enticingly named debouncing module. The reality is that the debouncing module is filled with brambles (issues relating to having success using it and perhaps it should even be retired or be depreciated.)

A newbie sucked into the debouncing module (by its enticing name) is more likely to really want the keypad module which is stupendous functionality and accomplishes what the newbie probably is after.

So I would suggest something--either in the blue box or in the description of debouncing--to discourage proceeding down this path.

May I suggest:

"Debouncer is depreciated. Most users will find the "keypad" module to be a better, more reliable, easier, simpler way of reading a debounced button."

or...

"Debouncer requires very frequent polling to avoid missing brief button presses. For this reason, use of the 'keypad' module is recommended. The 'keypad' module does not depend upon frequent polling and will more reliably capture button presses while also performing debouncing."

but mostly...

I would recommend depreciating and eventually retiring the unnecessary and problem-prone 'debunker' module.

[danhalbert]

Thanks for your suggestions. keypad is available on most, but not all builds, so the Debouncer library still has plenty of uses. For instance, keypad is not available on Circuit Playground Express, which is a very popular board. I have revised the material in the Debouncer guide to make clear that keypad is preferred if available.

[SeattleDavid]

Very nice.

[slight]

just a quick link to the keypad tutorial:
https://learn.adafruit.com/key-pad-matr ... cuitpython