Following my post on Topology meets Keyboard Design, I spent a few days exploring small less symmetric graphs, trying to find something in the region of 30~42 edges, 20~29 vertices, and as good a girth as possible (especially to have better rollover for the modifier & layer keys) for use in an ergonomic keyboard design. Then I realised as a starting point we can just use part of the 30 vertex Tutte-Coxeter graph, and get 6-key rollover automatically.
 |
 |
 |
| All 30 vertices in Tutte-Coxeter graph | 28 of 30 vertices in Tutte-Coxeter graph | 26 of 30 vertices in Tutte-Coxeter graph |
Why use graph theory to wire a keyboard? As per the previous blog post it avoids the need for diodes. I am not confident at soldering, so if I were to design my own keyboard at the PCB level, I'd rule out diodes, a separate USB port, BlueTooth (due to the extra complexity and circuitry for batteries), and split designs (due to the wired interconnects). I'm leaning to a small wired mono-block keyboard with a single USB-C socket on the controller daughter board for simplicity. Perhaps physically the same as an existing open choc-spacing design with a nice case design that could be reused.
So, what looks possible with a partial Tutte-Coxeter graph? As per the set of graphs above, removing one vertex (dropping to 29 GPIOs) loses 3 keys, but after that the next few removals need only drop 2 keys. I suspect slightly more optimal graphs exist, but these are good enough:
| GPIO | Controller(s) | Keys | Suitable keyboard layouts |
|---|---|---|---|
| 30 | Olimex RP2040-PICO30 | 45 | Keyboardio Arteus (44), Choctopus44 |
| 29 | Waveshare RP2040-Zero, 0xCB Gemini (both 20 pins + 9 pads) | 42 | Original Arteus, Zerosprey42, Reviung41 |
| 28 | RP2040 Pro Micro, YD-RP2040, WeAct RP2040 | 40 | Pica40, Stront (40) |
| 27 | ? | 38 | Totem, Stront (38) |
| 26 | Raspberry Pi pico series (old USB micro port), CPico RP2040 | 36 | Egret, The Endgame, Gamma Omega |
| 25 | elite-pi, 0xCB-Helios | 34 | Forager, Sweep |
| 24 | Elite-C Low Profile (rev4) | 32 | Onishi's Fish |
| 23 | Liatris Microcontroller | 30 | Hummingbird, Tern |
Many of those controllers are based on the RP2040 which has excellent support on the software side, but it is rare to have all 30 GPIOs exposed. Sadly I will avoid the Waveshare RP2040-Zero form factor with 21 GPIOs because 9 of those are awkward solder pads, not pins round the edge. Note often exposed pins like GP25 are tied to an LED, rather than being free for general use. There is also the iMX RT1011 Nano Kit (33 GPIOs) and nRF52840 Connect Kit (32 GPIOs) to consider. The newer RP2350B chip has 48 GPIOs, meaning you could in principle use the simplest circuitry of one GPIO per key for the size of keyboard I have in mind.
The 38 to 42 layouts I am looking at fit within a 3x6+3 pattern per hand (three rows of six columns, plus three thumb keys), or treating the thumbs as columns that's like a total of 14 columns of three (2x7x3 = 14x3 = 42). That makes it easy to layout the scanning matrix column wiring on one side of the PCB. Here my sketches show a Qwerty layout for familiarity, and assume something like the RP2040 Pro Micro form factor with 28 GPIOs, with the scanning and physical columns in red:
There is a lot of flexibility in which pins to use (note the seemingly random white scan row pin labelling), and the column wiring as shown leaves plenty of space to put some of the scanning-row wiring on this side too. However, I could get all of that on the other side of the board, albeit with 9 traces under the controller footprint squeezing between pins - shown here with blue trace wiring to the white row scan pins. These are nothing like the physical rows:
Dropping down to 36 or 34 keys, the scanning-row wiring is a little easier, but follows the same idea. Between 34 & 36 keys, most people would add/drop thumb keys. Given the scan columns work out as ten sets of three (C1 to C10), and two or three pairs (C11, C12, and optionally C13), I put the two keys "columns" as the thumb keys. This time the 26 GPIO pins are modelled on the Raspberry Pi Pico layout.
The partial Tutte-Coxeter graph ought to work as some silk screen art for the PCB.
Thanks a lot for those posts, I just learned about topology and the existence of diode-less keyboards!
ReplyDeleteI am planning to build a split keyboard with 44 keys on each half, and I am exploring the possibility of going diode-less. I am wondering how you routed your tracks in your design. I understand that you conveniently routed scan-columns as physical columns, but what about the scan-rows? Did you route them manually just by looking at the graph? And with that arbitrary scan-column to physical column mapping, you just happened to be lucky and didn't have any crossing tracks? Or is that a mathematical guarantee that it is possible to route your keyboard any way you want as long as you have two layers?
I used the backs of lots of envelopes to sketch these layouts manually, and avoided any crossing by choosing the pin allocation. It was a fun challenge. I found actually mapping out traces in KiCad a little harder (I had to avoid wires going round the outer edges), see the July blog post for my 36 key PCB which I have started to assemble. My design had via's on each switch (for direct wiring or hotswap), which helped. A two-layer PCB will work, with extra vias perhaps? Remember you will need extra pins for the two halves of a split-keyboard to talk to each other.
DeleteI see, I was hoping for some magical technique, but I guess I'll do it manually too then.
DeleteThanks for the reminder, but I'm planning on using a SMD module based on the nRF52840, which has 48 GPIOs, I should have plenty.
Yes, the wiring on mine was all done manually - and it is tricky as the row scanning is at first glance random. Having the expected wiring net defined in Ergogen means a mistake in KiCad is less likely at least, but it is still complicated to review.
DeleteWith that many GPIOs available from the surface mounted chip, I would aim for direct wiring of the 44 key switches, leaving 4 pins spare for communication, LEDs, etc.
This is more about your next post, but I'll ask here I guess. I understand that you went from the ergogen config directly to the PCB design on kicad, without schematics, right? I think I'll follow the other approach, with the schematics first, since I already have a schematic to start with.
ReplyDeleteThis is actually my third iteration of this keyboard, and I keep adding features, for the challenge I guess. For this iteration, I want to include RGB LEDs, a screen, a speaker and the communication channel with the other half. Also, I want my design to be reversible so that the same PCB can be used for both the left and right side (so that don't need to order 5 boards of each half). This last constraint makes me think that I may not be able to route all of the available GPIOs of my controller because of space constraints. This is why I need some leeway with the extra pins available, and why I'm interested in a Tutte Coxeter wiring.
As far as I know, Ergogen does not output a schematic, and I didn't write one.
DeleteIf this is the third iteration of your keyboard I'll assume you know what to expect. Have a look at my PCB wiring, and the QMK firmware on GitHub, that might clarify a few things.