diff options
author | Seebs <seebs@seebs.net> | 2017-12-05 17:55:05 +0100 |
---|---|---|
committer | Jack Humbert <jack.humb@gmail.com> | 2017-12-10 06:40:41 +0100 |
commit | d1feb8744aeb14f4ff024507b25d224e77de60a0 (patch) | |
tree | 6160b4a9b4fea7a277eebc97872574bbac10b941 /build_keyboard.mk | |
parent | 6d1b45fb84d4f57193fd1db5bd9307842f03f7e9 (diff) | |
download | qmk_firmware-d1feb8744aeb14f4ff024507b25d224e77de60a0.tar.gz qmk_firmware-d1feb8744aeb14f4ff024507b25d224e77de60a0.tar.xz |
Don't "unselect" left-hand rows
"unselecting" left-hand rows is a wasted i2c transaction.
On the left-hand side, the ergodox uses a GPIO expander. It
does *not* change "direction" (input/output) of pins, it just
sets pins high or low.
But all the pins are written at once. There's no way to
change just one pin's value; you send a full byte of all eight
row pins. (Not all of them are in use, but that doesn't matter.)
So every pin is either +V or ground. This is in contrast
with the right-hand side, which is using input mode to make pins
be neutral.
So there's no need to "deselect" the rows on the left side
at all. To select row 0, you set the GPIO register for the
rows to 0xFE. The previous code would then set it back to
0xFF, then set it to 0xFD on the next cycle. But we can just
omit the intervening step, and set it to 0xFD next cycle,
and get the same results.
And yes, I tested that the keyboard still works.
On my system, scan rate as reported by DEBUG_SCAN_RATE goes
from 445 or so to 579 or so, thus, from ~2.24ms to ~1.73ms.
Signed-off-by: seebs <seebs@seebs.net>
Diffstat (limited to 'build_keyboard.mk')
0 files changed, 0 insertions, 0 deletions