Muirium wrote: ↑10 Aug 2022, 14:51
Got a link to your firmware? Sounds promising.
https://github.com/arkku/aakbd/releases/tag/0.9.4 <- Here you go!
I included two zip files with autogenerated builds for various "basic" F62 and F77 combinations. The main benefits will come with compiling your own, but I understand that may put the firmware out of reach of most users (for whom QMK is much better, except that I went and improved some aspects of it).
To undo the firmware, all of the builds there should support Fn + Space + R to reset the keyboard to bootloader. They also support DFU reset, so a command like `dfu-util -e` can reset the keyboard programmatically.
darkcruix wrote: ↑10 Aug 2022, 20:53
I remember that xwhatsit original firmware had issues with its manual calibration - especially, when the environment was changing. Even today, I can see that it strongly depends on environmental factors (moisture in the air?). I never had issues with QMK due to its scanning and "binning". I would love to test your variant as well.
My variant does the exact same scanning and binning as QMK does; in fact I ported pandrew's QMK code directly… However, I improved certain aspects of it:
When there are empty bins, the DAC will not be set to that threshold at all, since we know there are no keys to scan in those bins. This alone accounts for 99% of the speed increase (the 1% is some other micro-optimisations that I did): for me, in the current weather and phase of the moon, all three of my keyboards calibrate such that all keys are in one bin. (I implemented a macro that makes the keyboard type its calibration and scanning stats, i.e., go to a text editor and press Fn + Space + 2 and it will show how the bins are distributed, etc.)
Calibration itself will be done on startup normally, except that the matrix is first scanned once with the previously-saved calibration, and if that indicates that keys are down, the calibration is then skipped (it would be wrong anyway if keys are held down on start, since those keys won't work after calibration). But if the saved calibration is not so wrong that it would indicate held keys on start, the startup calibration will still be done just as with QMK.
Admittedly there is a risk here that if the old calibration is wrong enough, the keyboard might theoretically register keys as being pressed when they aren't and then you would be unable to re-calibrate. Personally, I don't see this as an issue, because a) if the old calibration works enough that I can access the Fn + Space + U key combo, I can unsave the calibration, and b) I can always flash a firmware that erases the saved calibration. My firmware supports software reset via DFU, so even if the keys are not working, I can still reset it with `dfu-util`.
The calibration is saved on the first calibration of the keyboard, but only if scanning with the hardcoded threshold doesn't show any keys as being held down, and only if the calibration didn't result in some bin having only 1-4 keys (which might indicate that those keys were held down or the layout is misconfigured to include the always-pressed pads). The calibration can still be saved manually with a macro (the ability to write custom macros in simple C code is one of the main reasons my firmware exists in the first place, but the included template has this mapped to Fn + Space + C).
