Exploring the Intricacies of Mechanical Keyboards

[Eric12368]

As an enthusiast of mechanical keyboards, I've always been fascinated by the myriad of designs, switches, and customization options available. Recently, I delved into understanding the underlying technology that powers our beloved keyboards, particularly focusing on the role of microcontrollers.

Microcontrollers are essentially the brain of modern electronics, and they play a pivotal role in the functionality of our keyboards. They manage everything from key matrix scanning to executing complex macros. If you're interested in learning more about microcontrollers and their impact on various electronic devices, I found a great resource that provides an in-depth look at their functions and applications: Microcontrollers: The Brain of Modern Electronics.

In your experience, how have different microcontrollers influenced the performance or capabilities of your mechanical keyboards? Are there specific models or brands you prefer when it comes to the microcontroller component?

[kbdfr]

If you are such an "enthusiast of mechanical keyboards" and not just spamming with an advertising link, how about providing more details about you and your equipment?

[Findecanor]

In your experience, how have different microcontrollers influenced the performance or capabilities of your mechanical keyboards?

Some history:

The origin of "the hobby" (whatever that is...) is largely with collectors and users of older mechanical keyboards, like most of us on this forum in particular. A big part of that was to adapt them into working with modern computers, and that either required an protocol converter ("active adaptor") or some DIY with a microcontroller dev board to replace (parts of) the old electronics.
Then people started constructing their own custom keyboards, and the first ones often used the same microcontroller boards.

For a long time the DIY scene gravitated around one microcontroller in particular, the AVR ATMega32U4. Reasons:
1. Firmware existed for it.
2. It had a decent number of GPIO pins, and a tiny dev board with lots of pins existed: The Teensy 2.0. It was small enough to fit inside an older keyboard.
3. The AVR is 5V-capable, being able to interface with older electronics that use 5V logic. It is also electrically robust, not being dependent on

The company behind Teensy had published simple USB firmware that got adapted into larger open source firmware frameworks such as TMK and later its successor: QMK — which is the dominating firmware today and which other open source firmwares are measured against.
The Teensy 2.0 is now discontinued, but the community had already largely migrated to the cheaper Pro Micro, which had fewer GPIO pins but was much cheaper ($5 vs $16, if I remember correctly) because is made without license by multiple vendors.

These days, TMK, QMK, ZMK, KMK and others support multiple microcontrollers, and there is often no reason to choose ATMega32U4 or any other AVR.

However, in some circles, such as DIY ergonomic mechanical keyboards, the use of µC boards with the Pro Micro's footprint are still common, although the Raspberry Pi Pico is now also popular.

As to capabilities: those are mostly in software. Modern firmware uses VIA or VIAL so the layout and features can be controlled with a web browser instead of having to edit source code, recompile and flash.
Some support for LED controllers do exist, but many DIY keyboards with backlight have used quite crude monochrome backlighting by sending PWM to a single MOSFET blinking all LEDs in parallel.
Split ergonomic keyboards most often use I²C between a µC in each half. Small OLED screens also tend to speak I²C.

[Hak Foo]

My personal choice of controller directly influenced the capabilities of the board. When the Teensy++ went out of production, I switched to the WCH CH32V305, since it was offered as a comparatively cheap through-hole breakout with a similar GPIO count, and offered the (then) novelty of being RISC-V. But with no "popular" firmware available, I had to roll my own starting with the trivial examples in the WCH demo package.

This resulted in some rather unique behaviour choices-- the ability to dynamically adjust sense parameters for debounce and key-release hysteresis because my early test boards and configuration were sort of flaky, and a unique macro model (storing either raw strings or series of modifier holds and key presses). If I had just found an endless supply of Teensy++ units and kept on QMK, the current form of this board would probably not have either of those features.