6 ms·

This is a pretty novel use of the low-profile Choc switches. I like it. QMK supports ARM very strangely, but the more I think about it, the more I like it. T

This is a pretty novel use of the low-profile Choc switches. I like it. QMK supports ARM very strangely, but the more I think about it, the more I like it. They use ChibiOS as an RTOS to basically schedule USB code alongside QMK, and then they get ChibiOS's USB support for free. (Note that on many of these ARM chips, the USB is actually handled in hardware; you just need to get the right bytes into the right memory addresses at the right time. You don't have to be awake at the exact instant to toggle a USB pin at exactly the instant the protocol demands. So it works quite well; ChibiOS is not preempting your matrix scan at random times or anything.) Having said that, I think it's reasonable to write your own firmware. QMK feels very very legacy right now. It is hard to use modern dev tools to work on the code (like clangd), and the newer chips are supported in a very janky manner because of assumptions made for the original AVRs that it ran on. I always thought it was weird that the boards that OLKB use are among the most jankily-supported, even though they fund the development of QMK. They also don't really maintain all of the in-tree examples, so you'll copy someone else's outdated keyboard code and be starting with code that barely works. (I made an STM32F103-based keyboard recently, and the example code actually has their own debouncing algorithm, rather than calling QMK's newish built-in debouncing algorithm. So you get latency by default, although it hasn't bothered me at all so I haven't fixed it.) The model of flashing firmware to change the key layout also seems crazy to me, in an era where you can easily enumerate as a flash drive and just drag a JSON-encoded keymap onto it to adjust the layout. (Or just edit it live, a la CircuitPython.) I watch new users of QMK-based keyboards struggle and give up on a somewhat regular basis. Seems strange to me.

blattimwind 7y ago
QMK worked well for me, using supported controllers but entirely custom odd-ball hardware designs. It handles the somewhat annoying bits (USB protocols etc.) while allowing you to completely rip out most of the built-in logic (matrix code, scanning, layers, ...) without touching the tree. It also has a lot of kitchen sink functionality, although some really weird omissions as well (the only way built into QMK to receive free-form communication from the host is through virtual serial port). Overall it's kinda neat for that specific niche. But as a "framework for [basic] customizable keyboards" it is imho a poor choice because of those omissions and what you mention.
ihuman 7y ago
> The model of flashing firmware to change the key layout also seems crazy to me, in an era where you can easily enumerate as a flash drive and just drag a JSON-encoded keymap onto it to adjust the layout. (Or just edit it live, a la CircuitPython.) Are there any keyboards that have that functionality? I know Logitech allows you to save macro key info to the hardware. However, last I saw that was only for specific macro keys, not all keys like QMK.
- jrockway 7y ago
  There aren't but someday I plan to write one. QMK does already save some things into "EEPROM" (more realistically, flash on the MCU), like whether you've enabled NKRO, which LED pattern is selected, etc. Because it's opaque, it ends up just being another trap for the inexperienced. "I pressed a key and now my keyboard doesn't work." Yup, that can happen thanks to the magic of persistent storage.) I think the reason QMK doesn't use flash for keymaps is because it was simply designed before that was within the capabilities of the hardware it ran on. My Ergodox firmware just barely fits in the 32k of available flash on the 32u4, for example. But a STM32F103 has twice or 4x that much flash, so there is much more room to breathe and add creature comforts. (You can also use USB mass storage to flash devices, see UF2: https://github.com/microsoft/uf2 https://github.com/microsoft/uf2. It's so much better than DFU or all the hacks Arduino uses.)
- boomskats 7y ago
  I think TEX are innovating bigtime here. Have a look at the TEX Kodachi web configurator for example - their keyboards use exactly this mechanism for layout adjustment.
nerdponx 7y ago
The flashing issue is hopefully going to be solved by VIA: https://caniusevia.com https://caniusevia.com

blattimwind 7y ago

QMK worked well for me, using supported controllers but entirely custom odd-ball hardware designs. It handles the somewhat annoying bits (USB protocols etc.) while allowing you to completely rip out most of the built-in logic (matrix code, scanning, layers, ...) without touching the tree. It also has a lot of kitchen sink functionality, although some really weird omissions as well (the only way built into QMK to receive free-form communication from the host is through virtual serial port). Overall it's kinda neat for that specific niche. But as a "framework for [basic] customizable keyboards" it is imho a poor choice because of those omissions and what you mention.

ihuman 7y ago

> The model of flashing firmware to change the key layout also seems crazy to me, in an era where you can easily enumerate as a flash drive and just drag a JSON-encoded keymap onto it to adjust the layout. (Or just edit it live, a la CircuitPython.) Are there any keyboards that have that functionality? I know Logitech allows you to save macro key info to the hardware. However, last I saw that was only for specific macro keys, not all keys like QMK.

jrockway 7y ago
There aren't but someday I plan to write one. QMK does already save some things into "EEPROM" (more realistically, flash on the MCU), like whether you've enabled NKRO, which LED pattern is selected, etc. Because it's opaque, it ends up just being another trap for the inexperienced. "I pressed a key and now my keyboard doesn't work." Yup, that can happen thanks to the magic of persistent storage.) I think the reason QMK doesn't use flash for keymaps is because it was simply designed before that was within the capabilities of the hardware it ran on. My Ergodox firmware just barely fits in the 32k of available flash on the 32u4, for example. But a STM32F103 has twice or 4x that much flash, so there is much more room to breathe and add creature comforts. (You can also use USB mass storage to flash devices, see UF2: https://github.com/microsoft/uf2 https://github.com/microsoft/uf2. It's so much better than DFU or all the hacks Arduino uses.)
boomskats 7y ago
I think TEX are innovating bigtime here. Have a look at the TEX Kodachi web configurator for example - their keyboards use exactly this mechanism for layout adjustment.

nerdponx 7y ago

The flashing issue is hopefully going to be solved by VIA: https://caniusevia.com https://caniusevia.com