[Ballas]

Interesting, I have found the standard key spacing too far apart, I cannot fathom it being too close for some. I guess hand size variance is bigger than I think.

Could you explain what you did to achieve "diodeless" design and how do you prevent masking?

[jogme]

> 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!

[jbarberu]

Having implemented a custom matrix in qmk, I can say the timescale involved is not something you'd notice a difference between diodes vs diodeless. On ARM boards there's a setup delay to let the gpio propagate before reading the columns, which by default is set to 0.25us, which means reading 4 rows would take about 1us.

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.

[flacebo]

The default debounce algorithm in QMK also introduces a minimum of 5ms delay, and the default usb polling rate another 10ms.

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.

[jogme]

Thanks, I will try this! Do you use this setup?

[flacebo]

Yes, on all my keyboards. No double presses so far. On the keyboard I use for gaming, I actually use 1000Hz polling just to get that sweet placebo effect.

[gadgetoid]

I could believe you feel less latency, but suspect that’s more a symptom of matrix scanning working for the general case rather than being optimised for your layout. Scan with an RP2040’s PIO [1] and after debouncing I’d challenge you to measure the difference, much less notice it.

(Of course if you’ve got the pins, you should use ‘em!)

1. https://github.com/isoxliis/firmware-micropython/blob/72687e...

[jogme]

iiuc you are comparing matrix implementation with or without diodes. What would be the results between matrix against pin/key implementation? I am using QMK and I haven't looked under the hood what the "direct pin" actually does.

[daliusd]

34 keys are usually diodeless as many microcontrollers (promicro, elite-c and etc.) have enough connections to connect everything directly on one side of split keyboard and when you need one connection to communicate between sides. RP2040 can accommodate even more keys (even RP2040-zero). You need two microcontrollers of course.