| Multiplexers are only better for N-key rollover. The settling time of the switch is the same, regardless of the scanning technique used. But with a multiplexer, the output of one switch has no impact on the output of another – you can independently actuate each key. They are all essentially isolated switches with individual pull-up resistors. The multiplexing can be done in a number of different ways, none of which need to be particularly clever. The simplest scheme is simply to connect each key directly to a GPIO on a large-pinout microcontroller, like a TQFP-144. The fewer the keys, the less GPIO you need. This is the best way to build a keyboard, since input can be done at the clock speed of the MCU, and debouncing can happen on all pins in parallel simultaneously. Slightly more complex would be to use a smaller MCU with a multiplexer on each input, like a 4051 or 4067. The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards. If you really wanted to get crazy, you could read each switch with a high speed ADC and use an ML model to debounce the keys. But at that point, you're better off just using optical switches which don't really need debouncing. |
> The switching time is like 20-50ns on these parts, so while it's not quite as fast as a GPIO register read, it's still pretty quick, more than fast enough for keyboards.
I guess my point was that if you change which input you're reading from the mux and then immediately sample with the MCU, you'll get unstable data. 50ns is 20MHz, I can easily see an MCU used in a keyboard being fast enough to hit this.
It's obviously easy to work around, but so is ghosting.