Could you explain what you did to achieve "diodeless" design and how do you prevent masking?
I was not precise with the "diodeless" definition - the keys are directly connected to the processor pins without using a matrix. (Therefore there are no side effects of the matrix design - ghosting, masking, key rollover. The key presses are more precise and for me they seem more responsive - less latency, but unfortunately I have no data to prove this statement.) Thanks for the question, I will fix the definition!
Also eliminating the diodes reduces the cost and the time it takes to build the keyboard, which is always nice IMO!
(Of course if you’ve got the pins, you should use ‘em!)
1. https://github.com/isoxliis/firmware-micropython/blob/72687e...
I built a macropad that has some regular keys and a SNES controller on the "same matrix", total scan time is 335us, which is dead slow as far as scanning goes, but nothing you'd be able to notice.
Other points are fair though, fewer parts in the BOM. Though routing is a bit trickier with diodeless, especially if you also want to adressable RGB.
To mitigate the debounce algorithm delay, you can put "DEBOUNCE_TYPE = asym_eager_defer_pk" in your rules.mk file.
What this does:
asym: use different debounce algorithm for key-down and key-up events.
eager: the key-down is registered instantly at the first signal, instead of waiting 5ms for debounce
defer: registering key-up will wait for the debounce delay, this will make sure you won't get multiple key-downs registered before a proper key-up
pk: per key debounce timer, uses the most resource but you have plenty on your rp2040. although I don't completely understand how this works, this is supposed to be the fastest.
To increase the polling rate, this can be defined in config.h:
#define USB_POLLING_INTERVAL_MS 2
It's in ms, so 2 is 500hz, 1 is 1000hz, IMO the latter is overkill.
Together, you save a minimum of 6ms, maximum of 14ms of delay, which is orders of magnitude more than you save by not scanning the matrix.