ISO support would be easy to include in a new PCB.
I'm probably going to add support for MX-style switches and ISO layouts.
Support for ISO for Cherry MX and Alps in
regular PC standard key sizes would be relatively easy... That's only three alternative footprints for existing keys and one additional key.
Support for both original ISO and ANSI AEK/AEK II keycaps however would require almost twice as many footprints because for some reason, Apple decided to
shift all alphanumeric keys 0.25u to the right on ISO AEK/IIs compared to ANSI. The keys on the left are wider and the keys on the right are narrower. Only the bottom row is the same.
That would make it more complicated... and I don't think anyone expects you to support that.
But if you do decide to, I think the easiest way to realise it would be as more complex footprints.
You would not need additional holes for Cherry MX, but the footprints would need to be different for each key also on the left and right sides.
One more suggestion (just to make it more complicated
): If you are going to support the original keycaps, and Cherry MX plate then ... why not also support vintage SMK switches?
SMK Alps Mount would fit the original Apple keycaps, and in the same plate as Cherry MX. The clicky SMK "Monterey" switch variety is well liked, and feel like something in-between a Cherry MX Blue and Blue Alps.
The pads could fit on the opposite side of the centre from the pads used by Alps/MX (... as long as you don't use that space for SMD backlight or for support of PCB-mount Cherry MX without plate).
ANSI+standard ISO+AEK ISO+MX+SMK and different key sizes could become quite complicated however.
Look at Caps Lock, for instance:
• Centred/ANSI AEK (1.75): Alps, MX, SMK
• ISO AEK (2.0): Alps, SMK
• Stepped Alps (1.5+0.25): Alps, SMK (MX in this size exists but is rare)
• Stepped MX (1.25+0.5): MX (I have never seen Alps in this)
That's
eight switch footprints in one ... but wouldn't it be glorious?
Should I try to make everything smd, or should I use through hole diodes?
I think a DIY PCB should be sold either populated with everything but the switches, or with nothing at all.
If populated: SMD diodes and SMD controller. I think through-hole soldering at factory is expensive.
If blank: through-hole diodes and DIP socket for a generally available separate controller board. Never expect customers to solder SMD.
BTW, there are keyboards with diode-footprints that support both: the through-hole diode goes over the SMD pads.
Were there any other features that anybody wanted? There should be plenty of space on the pcb for any features. ... I'm thinking about using an usb-c daughterboard, and adding an option to replace the top-right button with a rotary encoder.
I think (support for) a USB hub would be a nice touch, so that you could connect a USB mouse to it like on the original keyboards.
If not built into the board itself, how about a footprint for soldering a
NanoHub onto the board? You would need to have additional separate headers for USB in and out, but it would greatly simplify the work for someone who wants to add this board.
(The ideal would be a USB C hub and connect either side like on the original, but there are no USB C mice ...)
Agree, lots like the atmega32u4 supports a total of 26 GPIO lines. Not enough for the scanning (at 21*6, or 15*11) Grumble.
There would be a maximum of just under 110 keys. You
could optimise that down into a logical keyboard matrix of 11×10 => 21 GPIO lines, but it would make things more difficult for the circuit designer.
You would also need three GPIO pins for indicator LEDs, and those should be driven with PWM.
On the ATmega32U4 the pins preferred for this are PB5, PB6 and PB7. Now we are up to 24 lines.
Next, a rotary encoder
could perhaps be part of the matrix even, because you normal people would not be able to turn it very fast anyway... but I would choose pins PB0 and PB1 because those could be used with Pin Change Interrupt, and that would be easier to code firmware for.
But yeah, I think AT90 or STM would be preferred anyway ...
BTW, I have also had another weird idea for some time that would not work with ATmega32u4:
Have routed channels in-between key sections ... so that section could be broken off. That way, the same PCB could be used for a Alps 60%, ... or a Alps TKL... or whatever.
The matrix would have to be divided into sections, each section for a different part of the PCB, and each section as square as possible to reduce the number of lines that go onto each (breakable) bridge between sections.