After much testing, a nasty integration algorithm was giving the best results. It was also proving more resistant to RF interference.
It needs to set the GND pins to push/pull mode. Then it needs to raise them all to pull all the keys high instead of waiting for the pullup resistors. This takes only 1 microsecond. Then it needs to lower 1 GND to scan 1 sector. This takes only 1 microsecond. It needs to scan all the sectors about 200 times while remembering all the keys detected. Then to debouce, it only sends 1 report after a complete integration which contains the change since the last integration. 100 scans take 10ms.
To speed up the scans, it used the last 8 pins as the GND & the 1st 17 as the sense pins. This had a lot less bounces but still had a lot of dropped keys. There was no improvement from delays longer than 1us.
It seemed to drop when multiple keys were pressed simultaneously instead of registering the latest keypress. Fortunately, the scanning algorithm successfully detects simultaneous keypresses. The next step was to buffer every keypress it detected & copy the latest keypress to the report. It also needs to blacklist previous hits until they're released. It's actually very important to be able to press keys simultaneously & only show the latest key, then not show any previous keys until they're all released.
It ended up needing a complicated algorithm to determine what keypress out of multiple keypresses should go in the report. These are apparently steps all keyboards take, based on common typing behaviors. There are still memories of the 1st IBM keyboards 45 years ago & how the behavior when multiple keys were pressed was so different than the commodore. Who knew how much programming went into that algorithm.
1 of the source code examples was using a simpler algorithm & scanning at 30Hz.
Suspect the other efforts were for a desperate need or adsense rather than for daily use.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.