1
0
Fork 0

Adaptive debounce logic

The debounce filtering reports a key/switch change directly, without any extra delay. After that the debounce logic will filter all further changes, until the key/switch reports the same state for the given count of scans.
So a perfect switch will get a short debounce period and a bad key will get a much longer debounce period. The result is an adaptive debouncing period for each switch.

This value defines how often the same key/switch state has to be detected in successive reads until the next key state can be reported.
In other words this value defines the minimum debouncing period for a switch.
This commit is contained in:
Michael Graf 2018-11-20 15:55:35 +01:00
parent 385de70e4d
commit ad91454574
2 changed files with 38 additions and 28 deletions

View file

@ -85,17 +85,20 @@ along with this program. If not, see <http://www.gnu.org/licenses/>.
#define RGBW 1
/* "debounce" is measured in keyboard scans. Some users reported
* needing values as high as 15, which was at the time around 50ms.
/*
* The debounce filtering reports a key/switch change directly,
* without any extra delay. After that the debounce logic will filter
* all further changes, until the key/switch reports the same state for
* the given count of scans.
* So a perfect switch will get a short debounce period and
* a bad key will get a much longer debounce period.
* The result is an adaptive debouncing period for each switch.
*
* If you don't define it here, the matrix code will default to
* 5, which is now closer to 10ms, but still plenty according to
* manufacturer specs.
*
* Default is quite high, because of reports with some production
* runs seeming to need it. This may change when configuration for
* this is more directly exposed.
*/
#define DEBOUNCE 15
#define DEBOUNCE 10
#define USB_MAX_POWER_CONSUMPTION 500