qmk_firmware

Commit Graph

Author	SHA1	Message	Date
Andrew Pritchard	cd30a60d0e	Change to per-key eager debouncing for ErgoDox EZ. Empirically, waiting for N consecutive identical scans as a debouncing strategy doesn't work very well for the ErgoDox EZ where scans are very slow compared to most keyboards. Instead, debounce the signals by eagerly reporting a change as soon as one scan observes it, but then ignoring further changes from that key for the next N scans. This is implemented by keeping an extra matrix of uint8 countdowns, such that only keys whose countdown is currently zero are eligible to change. When we do observe a change, we bump that key's countdown to DEBOUNCE. During each scan, every nonzero countdown is decremented. With this approach to debouncing, much higher debounce constants are tolerable, because latency does not increase with the constant, and debounce countdowns on one key do not interfere with events on other keys. The only negative effect of increasing the constant is that the minimum duration of a keypress increases. Perhaps I'm just extremely unlucky w.r.t. key switch quality, but I saw occasional bounces even with DEBOUNCE=10; with 15, I've seen none so far. That's around 47ms, which seems like an absolutely insane amount of time for a key to be bouncy, but at least it works.	8 years ago
Jack Humbert	e9f7487518	mostly working	8 years ago
Fred Sundvik	9af995c59b	Initial structure for Ergodox as subprojects Only the EZ default keymaps compiles at the moment though.	9 years ago

Author

SHA1

Message

Date

Andrew Pritchard

cd30a60d0e

Change to per-key eager debouncing for ErgoDox EZ.

Empirically, waiting for N consecutive identical scans as a debouncing
strategy doesn't work very well for the ErgoDox EZ where scans are very
slow compared to most keyboards.  Instead, debounce the signals by
eagerly reporting a change as soon as one scan observes it, but then
ignoring further changes from that key for the next N scans.

This is implemented by keeping an extra matrix of uint8 countdowns, such
that only keys whose countdown is currently zero are eligible to change.
When we do observe a change, we bump that key's countdown to DEBOUNCE.
During each scan, every nonzero countdown is decremented.

With this approach to debouncing, much higher debounce constants are
tolerable, because latency does not increase with the constant, and
debounce countdowns on one key do not interfere with events on other
keys.  The only negative effect of increasing the constant is that the
minimum duration of a keypress increases.  Perhaps I'm just extremely
unlucky w.r.t. key switch quality, but I saw occasional bounces even
with DEBOUNCE=10; with 15, I've seen none so far.  That's around 47ms,
which seems like an absolutely insane amount of time for a key to be
bouncy, but at least it works.

Jack Humbert

e9f7487518

mostly working

Fred Sundvik

9af995c59b

Initial structure for Ergodox as subprojects

Only the EZ default keymaps compiles at the moment though.

3 Commits (9546b180b961868f7f87a5367b94bb3daf30b61e)