Experience Designing a Keyboard PCB
Tags:
I designed a keyboard PCB, which I’m calling “CH552-48”. (It uses the CH552 MCU, and it has 48 keys).
This was
I have designed other keyboard PCBs,
but I’m particularly pleased with this one.
The keyboard PCBs I’ve designed fall into two kinds: those that use a development board (and are relatively easy to solder by hand), and those that are intended to be manufactured with “PCBA”.
However, the devboard-based designs were pretty easy to design; and while I found the PyKey40 tricky to design (I found it quite tricky to fit the MCU between the keyboard switches; an ortholinear keyboard doesn’t allow for much space!), I was more/less modifying an existing PCB design.
To be honest.. the keyboard PCB designs I’ve done aren’t really aiming for “great keyboard” so much as they’re aiming for “interesting PCB to design”.
e.g. designing a split keyboard where each half is smaller than 10x10cm may not make for a ‘great’ keyboard, but the design constraint made it really fun to design.
The “X-2 Lumberjack Arm” is a pretty good keyboard. I think it’s visually very striking. At the time I designed it, there weren’t many Arm-powered (ortholinear) keyboards that could be bought off-the-shelf.
And PyKey40 is also a good keyboard.. but, I had thought it’d be an interesting challenge to try and cram the fully-featured PyKey60 into the smaller 4x12 grid.
– I do like that idea “first time you do something, it’s as a scientist; the second time, as an engineer, but by the third time it’s as a technician”.
I wanted to design the CH552-48 after I came across the fak firmware. Fak firmware was written for the CH552, which has the advantage of being much cheaper than the RP2040 (even if it’s not as powerful).
Something that made this an interesting or constrained PCB to design was that the CH552T MCU only has 14 GPIO pins.
A keyboard uses the GPIO pins for scanning which keys have been pressed. Typically, 1 pin is used for each row and each column of the keyboard matrix. e.g. a 60-key keyboard arranged in 5 rows of 12 columns would typically use 17 pins.
I have seen other projects use the CH552 for keyboards, but these tend to be keyboards with a very low number of keys, such as using it for a numpad, or using a CH552 for one half of a small split keyboard.
I figured that 14 pins allows for 7 rows of 7 columns, or about 49 keys.
Obviously, a square keyboard wouldn’t make for a useful desktop computer keyboard.. but instead, the 7x7 matrix could be the ‘logical’ matrix, and I could arrange the 48 keys in 4 rows of 12 columns. I thought this was pretty neat.
I designed the CH552-44 first, which more/less takes the same shape as the Pico42 keyboard which I had designed earlier as a workaround to make use of keyboard cases I borked the design for. (The Pico42 in turn does itself bear close resemblance to the X-2 “Lumberjack Arm” keyboard I’d designed earlier..).
It made sense to start with CH552-44 as a proof-of-concept since it would be solderable with only through-hole components, which are very easy to solder.
In designing the CH552-44, I had to come up with some scheme to actually route this logical 7x7 matrix laid out on a physical 4x12 grid.
When the logical matrix is the same size as the physical matrix, it’s straightforward to connect each of the column pins together.
But with a mismatch between the logical matrix and the physical matrix, some complexity was inevitable.
Keyboard designs, especially ortholinear keyboard designs, involve a lot of patterns and repetition. My experience is that early on when routing the traces for the PCB, it might not be clear what the patterns for the traces should be; but once it does become clear, then routing the traces does become straightforward.
This part of PCB design can be very fun. – In a way, it tickles the same part of the brain that some parts of Factorio do: in Factorio, you need to connect certain outputs to certain inputs, and the challenge is in how to physically arrange the systems as part of a larger factory; ideally in an organised manner, without too much spaghetti. Hobbyist PCB design is exactly the same.
Compare the traces for the Pico42:
with those of the CH552-44:
It’s not an extreme difference, but the CH552-44 does feel like it’s got busier streets and city blocks.
Anyway. Once I’d received these CH552-44 PCBs, and checked that they worked with the CH552 devboard I was using, the next step I wanted to try was to make a PCBA version of the design.
This itself wasn’t too hard, either.
I looked at the devboard’s schematic, saw what parts of that I was using, and replaced the devboard in my schematic with those parts.
Overall, not too much needed to be changed for the PCBA design:
I haven’t done much with PCBA.
I found JLCPCB’s most accessible; since you can search what components they have, and they provide some documentation for the files you need to give them so they can assemble the keyboard for you.
(Whereas, for other places, you have to send them the components?).
But, since this PCBA project was similar enough to the PCBA project I had done before, it wasn’t too much effort to figure out how to set this part up.
The main effort was figuring out how to reduce the PCBA costs. Some of the components that JLCPCB uses are “basic parts”, some are “extended parts”, and it costs a few dollars extra for each “extended part” you use. – So, the goal is to find and use the “basic parts” when you can.
I wasn’t 100% sure that the PCBA design would work. So, it was a relief to find that it worked without issue.
And with the CH552 being a low-budget MCU, the cost to get it manufactured was relatively low.
Overall, it might be that no particular step of this was far beyond my experience. But, it was a satisfying use of the PCB designing I’d been doing before, with a PCB design that had some interesting constraints.