USB Peripheral Controller with USB-Hub - is this possible?

[m1k3m]

Hello everybody!

I'm researching information for my pet-project - device that will allow connecting singular keyboard and mouse to multiple machines.
I have experience in programming but I'm complete newbe in electronics(so be gentle, please))

At high level I understand how to connect keyboard/mouse to this hypothetical device - USB-controller(MAX3421E) + USB-hub(USB5534B). Than I want to send keyboard/mouse inputs to one of connected computers. My device should present itself to this computers as device(gadget, slave, etc.) via dedicated host-controller configured in device/gadget/slave mode. This dedicated USB-host-controller mirrors all devices, interfaces and functions from "keyboard" side to connected computer and route all inputs to it.

My question is:
- Can I reuse setup from host side - USB-controller + USB-hub. Is it even possible to merry USB-hub with USB-controller configured as device/gadget/slave?
- If it is possible, what hubs allow this functionallity?
- If it's not - what should I do? One USB-controller per computer seems redundant/expensive...

Thanks in advance:)

[Nominal Animal]

I would use a dedicated CH554G per computer, and a SI8621 or ISO7221 digital isolator per CH554G, so that each USB device has their own local ground and VCC (USB 5V).
The keyboard and mouse would be connected to a more powerful microcontroller with USB host capability.  I myself would probably use a Teensy 4.0 with an external off-the-shelf USB hub (soldered directly to the USB host pads on the Teensy), because I'm familiar with it, and know it can do this – and isn't too expensive ($20); and it has five UARTs on the easily accessible pins (7 if you use the pads on the bottom as well) to connect to each CH554G.  Both Teensy and the CH554Gs can be programmed in the Arduino environment.

USB HID is limited to 64000 bytes/sec per device, so using an UART (serial connection) between Teensy and each CH554G would be perfectly okay.  You even have ample SPI and I2C buses left over, in case you wanted to add a display for extra control of the unit; I like the small OLED displays, as well as BuyDisplay (AKA EastRising) IPS TFT displays (using ILI9431, ST7735, or ST7789 controllers), as they look nice and there are existing Arduino libraries supporting these.  (Having a small flip-up 128x32-pixel 0.91" OLED display per USB port might look nice, although I don't know if it would be useful per se...)

At minimum, I would at least add a button and two leds per computer: one led showing whether it is connected, and another to show whether it is actively forwarding the keypresses/mouse events, and a button to select between the two.  A 2.8" display with capacitive touch would make it simpler (as you could show the connected devices graphically, using icons as the buttons selecting operation), but costs a bit (about USD $20 from BuyDisplay; they also sell these on eBay).

For even niftier use cases, I'd actually switch to a Teensy 4.1 and get the Ethernet kit too, so that the same device could be used as a network-controlled keyboard-mouse combo, and an SD card could be used to hold full-display icons in uncompressed form (320x240), say created in Gimp and saved in PPM form then processed through a simple program (PPM itself is uncompressed; trivial to load and save) to convert to the desired form.

Note that the digital isolators are not optional.  When you have multiple machines, you really don't have any guarantees their USB grounds are at the exact same potential.  And if they are not, and you connect them, some current will flow: you have a ground loop.  You want to avoid this, because in my experience, it does odd stuff to hardware.  (Or maybe I'm just unlucky, or extra butter-fingery, having the Magic Smoke escape from my devices when I do things like that.)  The digital isolators not only act as a barrier, but they also mean each slave CH554G module is essentially identical.  This kind of modularity makes things easier.  On the Teensy end, only the Serial object changes depending on the slave.

If you don't like the CH554G's, any microcontroller with native USB interface will do, for example ATmega32u4 (which are used in many custom keyboard projects).

[m1k3m]

Wow! Thanks for such elaborate reply, really appreciate it!

After cursory glance at CH554 datasheet it seems to me that it cannot support more than one device(single device register) and only 5 endpoints. You probably would say that it is enough to implement keyboard and mouse functionality, but... I _really_ do not want to write drivers for target OS(s) - it should use stock/installed drivers where it can. More over, what if I want to add MIDI keyboard support? CH554 just will not do. I think full-fledged USB-peripheral controller on "computer"-side is a must. 
But thanks anyway:)

My initial idea was ARM or SoC running Linux with multiple USB-host controllers(preferably no more than 2) because I somewhat comfortable writing kernel modules and Linux have high-level abstractions of USB concepts. I also do not really want to know about all nuances of USB standard and then (Oh God, no!) implement them - I want to grab something off the shelf and run with it. As far as I know all popular boards (Raspberry Pi, Orange Pi, etc.) that support OTG uses SoCs that have only one USB-host that is configured at start-up to be host or peripheral(Correct me if I wrong). Hence the idea to design my own board with more blackjack and more hookers. I guess Teensy 4.x can be starting point.

I wanted this device to have program button, so by pressing it device will remember next key-stroke as trigger to switch to/from current "computer"-port. I see now that user interaction with this device will be sufficiently more complicated, so screen displaying internal state is a great idea.

By the comment about decouplers you've highlited another issue - I have no idea how to power this thing except externally with some kind of phone-charger power supply. I suppose it won't be easy to power it from "computer"s...

[Nominal Animal]

Right.. I think SAMD11 family would be a viable alternative for the CH554Gs; SAMD11D14A in particular with 8 endpoints (8 in, 8 out, that is). 

There is an Arduino Core one should be able to adapt, and even a SAMD11D14A development board by Stefan Wagner licensed under CC-BY-SA 3.0; at Mouser, SAMD11D14A's cost < 1.25€ apiece in singles in retail, so they're definitely not a cost barrier.  Since it has an internal crystal/resonator for USB use, you only need a couple of bypass capacitors and a 3.3V regulator per SAMD11 (and the digital isolator), and a 10k pull-up resistor to ensure /RESET (PA28) stays high.  A 100mA power budget at 3.3V would be absolutely rock solid; Wagner's design uses an AP2112K-3.3 that has ample power, but costs less than 0.50€ in singles – not a bad choice.

USB D- and D+ are pins 9 and 10 on 14-pin SOICs, pins 14 and 15 on 20-pin SOICs, and pins 21 and 22 on 24-pin WQFNs, corresponding to GPIO pins PA24 and PA25. For debugging and bootloader programming (default bootloader supports firmware updates via USB), you might wish to expose five signals directly to the SAMD11: 3.3V, GND, /RESET (PA28), SWCLK (PA30), and SWDIO (PA31).  That way even a misprogrammed ("bricked") SAMD11 can be reprogrammed.

I would definitely use modular design here, so that the SAMD11s would be completely interchangeable, perhaps using a standard 90-degree 1×4 or 2×2 pin header (VIO for the isolator, GND, RX, and TX).  Maybe 3D print an enclosure, where each computer-facing USB port is a detachable module with their own display and tactile button.

For power, I would just have an additional USB power-only connector for the "main" unit.  Because the device-facing USB units are isolated, that power-only USB could be connected to a wall wart, or any of the currently powered-on computers.  The "main" unit would simply then have the same ground potential as that host.  The extra USB cable can be a bit annoying, but you'll have cable spaghetti anyway, so who cares.


Which brings me to a completely different suggestion: Use ESP32-S2 modules (as used on Saola, Kaluga, and ESP32-S2-DevKitM-1 EspressIf development kits; Ai-Thinker ESP-12K development board; and Adafruit Feather ESP32-S2 and Metro ESP32-S2 boards).  These have native USB (although only four bidirectional endpoints), but you could use WiFi to control them. That avoids ground loops and the cable spaghetti.  The TinyUSB project even has some code for enabling it as an USB Host for HID devices; but the device stack has both HID and MIDI and other types of devices supported for these modules.

[pigrew]

I don't see any easy way to implement this.

Easiest solution is to buy KVM switches from Amazon. Many of them even support programming a hotkey for switching (Looks like US$50 would get you a 4-port model...).

To design this, I would use 1 MCU per port. The host MCU could have a hub attached so that the 1 host would connect to multiple HID devices. The "host MCU" could be a SPI master, talking to the device MCUs as slaves.

Each "device" MCU could provide a single HID device to the computer (or a composite device with a mouse and a keyboard device).

Difficulties would be that the micros would need to remember state (like if the caps lock LED is on, or if the computer wants boot protocol or not) on a per-computer basis, and retransmit them to the keyboard when switching between computers.

The host would also need to combine all of the HID reports from the mouse and keyboard into a single report. AFAIK, HID reports cannot change after device enumeration, so the design would likely need to disconnect from all of the computers, and reconnect, when any mouse or keyboard is plugged in or unplugged.