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.