Design suggestions for split keyboard

[eigenvektor]

Hi,
I'm designing a split keyboard (each hand has it's own half keyboard) and was wondering how to approach this.
I want each half to have 2 usb c ports, one at the top to connect to the computer and one on the side to connect the other keyboard half. The goal would be that each half can be used independent,
or slaved to a half connected to the computer.

My original plan was using a pic18f24k50 8bit microcontroller supporting 1 USB connection. The top usb c port would get the usb connection, while the side-usb port would be connected to UART on the mc. (UART would be stepped down from 5v to 3v3 using a logic level converter to conform to USB specifications).

With the recent hype for the wch RISC V mcus I've thought about using a CH32V203 instead. It's cheaper, supports 2 USB connections (1 device and 1 host/device), is 32 bit, much faster and more memory. However the packaging options aren't great: a QSOP28 package is too large, QFN48 would fit but it seems ridiculous to use such a package for half a keyboard.

Are there any other low cost MCU's I should consider or should I approach this in a different way? This is my first microcontroller project and figuring out what should happen when 2 keyboard halves are connected over USB sounds a bit complicated. I've attached a schematic to hopefully make this easier to understand.
Thanks!

[ejeffrey]

My original plan was using a pic18f24k50 8bit microcontroller supporting 1 USB connection. The top usb c port would get the usb connection, while the side-usb port would be connected to UART on the mc. (UART would be stepped down from 5v to 3v3 using a logic level converter to conform to USB specifications).

Do you mean you would run the UART over a USB-C connection, or that you would use a USB->UART adapter chip like the FT232 family?

If the former, please don't.  USB type C is confusing enough as is, don't put a non-USB USB port on devices.

If the latter, that won't work.  USB does not support "peer to peer" connectivity.  All communication is from 1 host to 1 device.  The FT232 USB chips are devices, not hosts.

With the recent hype for the wch RISC V mcus I've thought about using a CH32V203 instead. It's cheaper, supports 2 USB connections (1 device and 1 host/device), is 32 bit, much faster and more memory. However the packaging options aren't great: a QSOP28 package is too large, QFN48 would fit but it seems ridiculous to use such a package for half a keyboard.

Are there any other low cost MCU's I should consider or should I approach this in a different way? This is my first microcontroller project and figuring out what should happen when 2 keyboard halves are connected over USB sounds a bit complicated. I've attached a schematic to hopefully make this easier to understand.
Thanks!

I would avoid implementing a USB host if possible.  The easiest solution is to use a UART for side-to-side communicaiton, just over a different connector than USB-C.  This could be anything: M8, RJ11, RJ45 all have common pinouts for serial connections.  Alternately, you could use a USB hub chip and add a downstream hub port to each half.  This would provide extra utility since you could use the extra port for anything (like a USB flash drive or security key), but would mean that the correct way to chain them is to connect the top port of one to the side port of the other, not side-to-side.

Finally, keep in mind that (at least traditionally) BIOS had quite limited device compatibility for boot time input devices like mice and keyboards.  I think modern EFI systems have greater compatibility, but you may have trouble using your non-conventional keyboard for BIOS/EFI.

[thm_w]

You are making this far too complicated. Just have the one main USB port on either the left or right side.
Also, using any micro thats not supported by QMK will make your life about 10x harder: https://github.com/qmk/qmk_firmware/blob/master/docs/compatible_microcontrollers.md
Assuming you are interested in that featureset.

If you are dead set on using a USBC connector for serial connection between the two sides, just go for it. Don't really care if its non-compliant, its not like you are selling it as a product.

[ejeffrey]

One more thing:

QFN48 would fit but it seems ridiculous to use such a package for half a keyboard.

I wouldn't worry about the package at all.  That chip may or may not be a good fit, but don't worry about the package, as long as you are able to assemble it.

[eigenvektor]

Sorry for the late reply, didn't have WiFi on my bus.

Classically, these types of keyboards are connected with UART over TRRS aux cable. This isn't hot swappable however, as pulling it out causes a short. I wanted to go with usb c as it just seems elegant having everything connected with usb c to usb c cables.
So yes I meant running the UART over USB-C and telling the user to pretty please not plug it into anything else. Hence stepping down the voltage, never trust em :P

The easiest solution is to use a UART for side-to-side communicaiton, just over a different connector than USB-C.

I need a slim connector, the attached render of an older version shows what it's gonna look like. There's not much space for anything other than usb micro / c.

Depending on how it turns out selling it is an option.

As for assembly: board will be entirely single sided smd components, though I have soldered larger pitch QFN packages with an iron already.

[thm_w]

This isn't hot swappable however, as pulling it out causes a short.

TRS can be hot-swappable, if you handle the short in hardware.

[eigenvektor]

True, but is it really better to have UART out of an aux port than UART through USB? Call it a matter of taste but I'd prefer to have USB.

[NorthGuy]

I don't understand why you need two USBs on the chip.

PIC32MM0064GPM048-I/M4 is QFN and is cheaper than your PIC18. It is 32-bit, and has more memory (although you don't need any of these). More importantly, it doesn't require a crystal which will save you some space and money.

Make sure it is safe connect USB cables from the host, phone, or charger to your USB-C connector because many people will do this.

[ejeffrey]

True, but is it really better to have UART out of an aux port than UART through USB? Call it a matter of taste but I'd prefer to have USB.

Yes in my opinion it is absolutely better to use TRRS than USB connectors for a non standard UART.

[fchk]

Most environments support multi-mouse and multi-keyboard operation. There is no need for a connection between the two parts - just plug them both into the PC.

Note: HID Keyboard and HID Mouse can have a simplified "boot protocol" for BIOS support. Windows and Linux don't use this, so it's optional. I don't know, however, if BIOS environments support multi-keyboard operation. For these rare events you would need a standard keyboard.

fchk

[mariush]

If you want to keep it simple, a 4 wire cable and a couple RJ11 connectors would be enough... power, ground, data, clock ... SPI or I2C between the two parts.
Whichever parts gets to be connected to usb becomes master and receives keys from the other and forwards them to the computer.

I was thinking of using barrel jack connectors with a thread lock, and modulate the data over the voltage wire (ex 2.5v constant, 3.3v or higher are 1s and send bits at a constant frequency like addressable rgb leds works, with some prefix pattern so that the other can sync on the frequency)  but that becomes complicated fast.. unnecessarily complicated.

Another option could be to just have a battery in each one and use a bluetooth module to pass keys between the segments but then only the part connected to usb would charge over time.  You could add some solar cells on top of the keyboard somewhere to slowly charge the batteries, or maybe a QI charger on the bottom of the keyboard so that user could charge the keyboard by placing it over night over a charger disc.

[exe]

As an idea.

I used https://nicekeyboards.com/nice-nano/ and ZMK firmware for "true wireless keyboard". It is convenient, but a bit expensive and range is not great, but I also have installed facedown, where antenna is relatively close to the pcb, may be that shields the signal. There might be other (cheaper) boards supported by ZMK.

[Nominal Animal]

My own first microcontroller project was a honking big gamepad (on a 50×20cm or 20"×8" birch plank) with an arcade joystic and buttons using Teensy 2.0++ (AT90USB1286) with native USB interface.  It had a small absolute hexadecimal encoder on it, for me to select which keypresses the joystick and buttons generate, so I could play Flash games (platform puzzles) more comfortably.

I would suggest you use any microcontroller with native USB interface, and use the USB HID protocol, so no OS drivers are needed.  As thm_w mentioned, Quantum Mechanical Keyboard Firmware is a pretty good option here.  Personally, I'd use a Teensy LC, and program it in the Arduino environment using the keyboard support library that comes built-in with Teensyduino, though.

However, I would also put an USB hub in each, and wire the microcontroller in each keyboard half directly to one downstream port, exposing the other downstream port(s).

This way, the user can plug in the (hub upstream port in each keyboard half) to a host, or to the other keyboard half as long as that half is connected to a host or to a hub that is connected to a host.  If you limit to keyboard/mouse/human interface use, USB 2.0 full/high-speed hubs will suffice, and are very easy to use.  Mouser, for example, has Microchip/Atmel USB2412 with two downstream ports in stock, for 2.45€ apiece, that only requires a 24 MHz crystal and some bypass capacitors; just use the schematic and suggestions from the related application note or hardware design checklist.

One of my pet peeves is the limited rollover and/or ghosting in custom keyboards.  I personally always use Schottky diode pairs in SOT-23 or SOT-323/SC-70 in the matrix, just to get rid of that ghosting (letting me detect each key independently of any other key state in the matrix).  Sure, it's an additional 50 or so components on a 100-key keyboard, but BAT54C costs ~ 7€ per 100, and I find it easily worth it; others do not.

[eigenvektor]

Thanks for suggesting the PIC32MM0064GPM048-I/M4, I'll have a look :)
The PIC18 does have an internal oscillator as well.
Classically yes one would connect the 2 halves with I2C, SPI or UART. Like I mentioned, RJ11 won't fit unfortunately, the goal is to have the board be as low profile as possible. That means stacking PCBs like the nice-nano is not an option either, I'd much rather implement that on the main board myself if at all. Going bluetooth would be an option, but would mean having to allocate extra space for a battery and designing a battery management system. I currently have neopixel LEDs on the board, would have to see how much runtime I would get with those, but going cable-free would be very elegant.

Here's an idea: If I declare alternate mode through the CC pin, wouldn't that allow me to send data in whatever form on most other pins? With UART or I2C I could even limit myself to only the SBU pins (I'd have to use logic for detecting cable orientation though).

If a neat solution can't be found going for just one USB port per half and connecting them both to the computer might indeed be the way to go, just seemed nice to offer the option of using only a single USB port on the host, and maybe being able to use each keyboard half as a hub to connect extra stuff if the mcu supports 2 USB connections.

@Nominal Animal: 2.45EUR seems a lot for hub if the mcu costs less than 1EUR. As for ghosting: I'm using a full matrix with diodes on every key, so n-key rollover with no ghosting.

[mariush]

The way JLCPCB is pushing down prices, you could probably afford to make a 4 layer or even a 6 layer pcb and route all the traces to some port expanders or parallel to serial register chips and have 100+ independent keys.
I see 400mm x 150mm 4 layer boards (5 pieces cost around 65$ and 6 layer boards are around $110

If you manage to make both sides have identical pcb you could do one order with boards half the width for even less price, and use 2 of the 5 pcb to build your keyboard.

[eigenvektor]

I don't need 100 keys and it all fits on 2 layers (no need for impedance matching at these low speeds).

[Nominal Animal]

@Nominal Animal: 2.45EUR seems a lot for hub if the mcu costs less than 1EUR. As for ghosting: I'm using a full matrix with diodes on every key, so n-key rollover with no ghosting.

Have you looked at what good-quality keyboard switches cost?  The cost of the MCU and the hub chip is a tiny fraction of the overall cost, because good-quality keyboard switches will be the major cost of the project (assuming you 3D-print the enclosure, otherwise making that will be the major cost here).

It is a bad idea to be cheap with the MCU here.  Pick one that your preferred toolchain has good support for, instead.

[eigenvektor]

about 20 cents pp in single keyboard order quantity, cheaper with higher order quantity ofc. Adding 5EUR / keyboard would be quite substantial, but it's an option I'll consider, I'm sure there are cheaper hub controllers.

As for the MCU: considering future projects I think gaining experience with 32bit RISC V MCUs would make much more sense than 8bit PIC 18 cores.

[Nominal Animal]

I'm sure there are cheaper hub controllers.

Me too.  I'm just a hobbyist on the electronics side, and looked at Mouser (because that, or LCSC/JLCPBC, is what I'd use); a few euros per unit would be irrelevant for me for a small batch.

Edited: That said, LCSC does have WCH CH334S and CH334U chips in stock for about 0.60€ apiece right now.  If only there was an application note in English...

Just like I did with my arcade-joystick-as-keyboard project, I'm sure you'll learn a lot about exactly what you want the design to achieve –– you did say this is your first microcontroller project ––, and will probably want to do a respin/redesign afterwards, after you know more.  (I myself found I prefer to have the joystick on the right and the buttons on the left, opposite to what is typical on most controllers, for example; and that starting with an even more massive chunk of birch would have been nice, because of the extra weight, allowing me to carve/shape the upper and lower surfaces, with better designed "pockets" for the electronics and arcade switches.)

For a truly low-cost solution, WCH does have cheap USB-capable microcontrollers (with 8051 cores) that would be suitable for this.  I designed a simple USB Gamepad using CH551G, intended to be used with standard 12x12mm tactile buttons, and programmed using sdcc and loaded using librech551 or ch552tool.  I couldn't get the chips from LCSC/JLCPCB, but CH554G is now available, so I could respin it and see how well it works.. but Olimex has OSHW ESP32-C3 (WiFi & BT, RISC-V, USB) with LiPo connector and ~ 15 GPIO pins, at an affordable price with a couple of choices of LiPo batteries too, so I could just get a couple of those and make a wireless-capable one instead.

As for the MCU: considering future projects I think gaining experience with 32bit RISC V MCUs would make much more sense than 8bit PIC 18 cores.

32-bit ARM cores (Cortex-M0+, Cortex-M4, and Cortex-M7), and RISC-V, are supported by both GCC and Clang, so you can use up-to-date FOSS toolchains for development.  I like that, because I don't want to be stuck with a single vendor (although I do believe there are multiple C compilers for PIC18).
(I do do both proprietary and FOSS development, under various licenses.  Tux (my avatar) is just my mascot, not my idol.)

[NorthGuy]

The PIC18 does have an internal oscillator as well.

It is not accurate enough for USB, so you would need an external clock source.

[eigenvektor]

@Nominal Animal yes I'm just always thinking about how to make this as easy to mass produce as possible (2 layers, all smd components on one side and so on) hence the slight obsession with cost.
It does sound like you have a lot of experience with such projects, thanks for sharing the knowledge! :)
Technically this would be the third complete overhaul of the project already. I've already had boards produced for my latest version, didn't like the key placement so changed it up again and had boards produced for v2.1, I'm really liking the form factor and key placement. Haven't gotten to programming it, but I'm having doubts about how I'm approaching this (UART over USB-C, microchips proprietary compiler, wanting to use ARM/RISC-V in the future).

Since the CH32V203 has native support for 2 USB ports, one of the supporting both host and device it just seemed like a perfect solution (except for the horrible packaging) if I can negotiate who's host and who's device when connecting two keyboards together.

@NorthGuy no idea how I missed that, just checked the datasheet and you're right. Although curiously https://hackaday.io/project/63204-usb-c-usb-pic-bootloader does provide a "no xtal" hexfile for the pic which you're supposed to use with USB...

[Nominal Animal]

@Nominal Animal yes I'm just always thinking about how to make this as easy to mass produce as possible (2 layers, all smd components on one side and so on) hence the slight obsession with cost.

Makes sense.

It does sound like you have a lot of experience with such projects, thanks for sharing the knowledge!

Only as a hobbyist, though!
I do like to play with human interface devices, and am quite familiar with the Linux input subsystem.

I have seen the problems others working on hobby-custom HID devices with serial-to-USB bridges (not capable of USB HID) have had; and consider myself extremely lucky having started with AVRs with native USB interfaces, as they're quite easy to program even with open-source toolchains, but are simple/straightforward compared to current 32-bitters with their numerous peripherals and details.

I definitely recommend using an MCU with native USB so you can have a couple of HID endpoints + USB Serial for run-time configuration, per MCU.  While Linux is very flexible with HID devices, some other OSes are pickier and don't like nonstandard report mixes of HID devices, so modeling ones own so that it is roughly similar to what is already widely used in the market gives maximum OS compatibility.

So, whatever MCU you pick, make sure you can find an USB HID example implemented on it, unless you intend to use an existing open-source firmware like QMK mentioned earlier.  It is much, much easier to start with an existing USB HID example, and then modify it to suit ones own needs, than start from scratch.

I already mentioned I personally would probably just embed a Teensy LC for my own one-off or prototype keyboard PCB, with a separate cable-type USB hub, because of the low cost ($12 when in stock) and the USB HID Keyboard support Teensyduino provides (take a look at the examples on that page for an example). Note that Teensies aren't well suited for mass-produced products, however, because the bootloader is proprietary.

Because I know the keyboard PCBs would need a few design iterations to find out the best layout et cetera, I'd use an IC socket for the Teensy LC, so that I only would need to solder a socket to the (bottom at the back of the) PCB, the key switches, and the diodes.  I'm pretty sure the switches can be desoldered without damage, but I'd prefer to avoid having to rework the rest.  So, I could trivially just lift the Teensy LC from one board to another.
I believe the only way to know would be to test it in practice for a few days; try to write some code, documentation, or something else actually meaningful/important, and see how it works.  Heck, even measure the statistics while using, to compare the different boards quantitatively.

After I'd found a working layout and matrix/schematics, I'd know exactly what features I want.  For example, I like those small I²C-controlled OLED displays (128x32 and 128x64) to occasionally show information like the current mapping; even my gamepads have those for that exact reason!)
Only then would I look at existing microcontrollers and possibly USB hub chips, to see how best to implement it as a product.  Plus, you already have a working prototype at that point.  Except, of course, I only do hobby stuff, not products, and usually drop the designs into public domain (via CC0-1.0).

Other members here know a lot more about how to go about commercializing a product, from small batches on Tindie, to large-scale product development with batches in the thousands.

[NorthGuy]

Since the CH32V203 has native support for 2 USB ports, one of the supporting both host and device it just seemed like a perfect solution (except for the horrible packaging) if I can negotiate who's host and who's device when connecting two keyboards together.

USB C provides a mechanism with resistors. If the keyboard is connected to the PC via USB, make it a host (DFP in new terminology), if not, make it a device (UFP). The host will provide power to the device. If both are plugged into PC, they both will be hosts (DFP), will not power each other or talk to each other.

[fchk]

Here's an idea: If I declare alternate mode through the CC pin, wouldn't that allow me to send data in whatever form on most other pins? With UART or I2C I could even limit myself to only the SBU pins (I'd have to use logic for detecting cable orientation though).

Absolutely not!

Read the official USB Specs! For example, the "USB Type-C Cable and Connector Specification" Revision 1.1 specifies these electrical requirements for SBU1/2, SSTX, SSRX and B6/B7 pins:
Common Mode Voltage: 0 to 1.5V
Impedance to GND: < 4MOhm (SBU, SSTX, B6/B7), 25k-4M (SSRX).
AC coupling in SSTX and SSRX.

This is to protect real full-featured USB ports from damage. PCIe adheres to these limits and is a common choice. DisplayPort uses PCIe drivers and is also a common option.

fchk

[ejeffrey]

Building in a hub is a pretty nice feature *anyway* and definitely a feature I look for when buying keyboards.  It's not like I refuse to buy a keyboard without it, or would buy an otherwise bad keyboard for the hub, but it definitely adds value.  That's something to consider when you are looking at the cost of the chip.