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.