I made quite a few keyboards recently, in my quest for the perfect low-profile keeb. It started with a minimal Dorsch-40k, through a thin Planck, Flatreus, and a 65% ergonomic one inspired by Alice. From all that, the Planck turned out to be the best for me, except for the need to keep my hands together and no easy access to numbers (which turn out to be needed when programming). So this time I’m applying what I have learned, and making something to replace the Planck without being too revolutionary.
As with my previous keyboards, I’m using a SAMD21 microcontroller running CircuitPython and my own simple keyboard code. No fancy joysticks or LEDs this time (I have my CapsLock mapped as Compose anyways).
After trying the caps, I realized they are a bit too small and too high for my taste:
So I decided to use the PBT caps, with some extra transparent caps, because I didn’t have enough at hand. I will probably switch to the Kailh’s double-shot caps eventually, and put the PBT ones in the Planck.
I’m surprised there isn’t a joystick/thumbpad/trackpad gimmick this time
So interestingly I’ve noticed you don’t typically use the same microcontrollers many others do (at least as far as I can tell), is there any reason why like availability, or are these simply what you’re used to working with?
There are several reasons for my choice of microcontroller and programming language. First of all, the AVR architecture is nearly 25 years old and extremely slow and limited compared to modern alternatives. Sure, it’s also very simple, but I’m not writing assembly here, so that’s not an advantage for me. Second, the ATmega 32u4 that is way overpriced, possibly due to its popularity among hobbyists, and requires quite a number of additional components to function correctly, which translates to even more cost and larger area of PCB needed. Finally, while there are many choices of open source keyboard firmware available, none does the hold/tap trick the way I wanted it to work, and I wasn’t sure how much effort it would take to modify them to do that. My first keyboard in the series only had 40 keys, so it really needed that mechanism — in fact you could say the whole excuse for building it was to test that mechanism.
So now about the SAMD21. It comes in a really small 32-pin QFN package, and only requires three extra components: two caps and a voltage regulator. It costs about $2. It runs CircuitPython, which means that I don’t have to compile anything every time I want to change something — both the code for handling everything, and the key map, are just text files visible on the USB drive that appears when the keyboard is connected, and you can simply edit them right there — it even automatically restarts when you change anything. (In the final version I disabled the disk, so that the keyboard only appears as a keyboard and a media device.) And instead of hundreds of lines in C, I had my first keyboard working with just 50 lines of Python code, and still plenty of room to add RGB LED animations. The documentation for the USB libraries for CIrcuitPython is also much simpler than for the 32u4.
Of course CircuitPython also has some downsides, like comparably slow speed and memory requirements, so I am considering porting QMK to SAMD21 at some point (it seems to already have support for some other MCU from the SAMD family), to have something more “professional” than the code I cobbled together, but for now it’s perfectly sufficient.
Swapped the caps with the thin Planck, now both keyboards have the same type, and perhaps people trying to use my computer stand a bit more of a chance…
Even an atmega32u4 is overkill to manage keyboard inputs, so I’m not even sure that using Python makes your keyboard too slow with a 48MHz 32 MCU
Really like the approach you made here, even if QMK looks to be the ‘professional’ way of doing firmware programing nowadays (and VIA makes it a much more compelling solution TBH).
I’m still super-happy with this keyboard, having almost perfect balance between the number of keys and size, good distance between hands and being orholinear. However, I do miss the =+, ;: and \| keys in their proper places, and I want to be able to experiment a little bit with adding different stuff in the middle, so I made one more version of the PCB:
It has one more column of keys on the right side, and all the free GPIO pins broken out, together with power, on a pair of headers in the middle. This way I can make replaceable modules for it without having to make a new large PCB every time. The PCB is on order, should be here in a week or two, I will them move all the switches and the microcontroller to the new one.
Neat! I’ve always liked the SAMD21 chips, they always felt like the true successor to the ATMEGA328P/ATMEGA32U4 to me. Also, it’s cool to see you here, I’ve seen your stuff on Hackaday for years.
I haven’t seen anyone try to port QMK to the SAMD21. I know there is limited support for the SAMD51 because of some of the Drop keyboards, but as far as I’m aware a fork that can compile to the SAMD21 doesn’t exist?
I don’t think it requires a fork. As long as they use the HAL, it should just work, you just need to set the correct model name in the makefile and the right pins…
I’ve long since abandoned ortho low pro ergo boards in favor of RSI and an empty wallet, but following your build logs does make me yearn for the old days of soldering gergo trackball units together. what modules do you plan for those broken out pins?
For a starter a PSP joystick and buttons for mouse emulation, and another one with an encoder and knob for scrolling. I can even put a display or a speaker in there (the SAMD21 has a DAC), or a gesture sensor so that I can scroll by waving my hands over it…
