diff options
author | Seebs <seebs@seebs.net> | 2017-11-18 16:11:26 -0600 |
---|---|---|
committer | Jack Humbert <jack.humb@gmail.com> | 2017-11-26 02:07:06 -0500 |
commit | 7fbe6c35944a140cc3b089884350844dddf301e6 (patch) | |
tree | 83d006ab2e198e6e141f2ac5d9b5d1fdbfec5cbd /keyboards/ergodox_ez/util/readme.md | |
parent | 55f3cd37af7b83c12fd8a83f0a1000fea1d89d41 (diff) | |
download | firmware-7fbe6c35944a140cc3b089884350844dddf301e6.tar.gz firmware-7fbe6c35944a140cc3b089884350844dddf301e6.tar.bz2 firmware-7fbe6c35944a140cc3b089884350844dddf301e6.zip |
improve ergodox ez performance
With these changes, the ergodox ez goes from 315 scans per second
when no keys are pressed (~3.17ms/scan) to 447 (~2.24ms/scan).
The changes to the pin read are just condensing the logic, and
replacing a lot of conditional operations with a single bitwise
inversion.
The change to row scanning is more significant, and merits
explanation. In general, you can only scan one row of a keyboard
at a time, because if you scan two rows, you no longer know
which row is pulling a given column down. But in the Ergodox
design, this isn't the case; the left hand is controlled by an
I2C-based GPIO expander, and the columns and rows are *completely
separate* electrically from the columns and rows on the right-hand
side.
So simply reading rows in parallel offers two significant
improvements. One is that we no longer need the 30us delay after
each right-hand row, because we're spending more than 30us
communicating with the left hand over i2c. Another is that we're
no longer wastefully sending i2c messages to the left hand
to unselect rows when no rows had actually been selected in the
first place. These delays were, between them, coming out to
nearly 30% of the time spent in each scan.
Signed-off-by: seebs <seebs@seebs.net>
Diffstat (limited to 'keyboards/ergodox_ez/util/readme.md')
0 files changed, 0 insertions, 0 deletions