Pico-PIO-USB VS InputShareUSB

I know that I can have multiple ports using https://github.com/sekigon-gonnoc/Pico-PIO-USB, but I wanted to know if I could make one port a device and the other a host at the same time using the given PIOs and state machines.

I think a PIO based USB driver is a better approach, but someone needs to do the work of porting that to Ada.

That would be Pico-PIO-USB library or some people combine two Pico boards (or one board with two RP2040 MCUs).

If you need both device and host interfaces at the same time, then you can either use Pico-PIO-USB library or combine two Pico boards (or one board with two RP2040 MCUs).

However, not so many microcontrollers can easily do USB keyboard input (host) and output (device) at the same time, if that's what you need. You could look at the Teensy 4 or Teensy 4.1 for example. There might be other Arduino-compatible boards that can do it, I'm not sure which. Apparently it's also possible on the Pi Pico with this project: sekigon-gonnoc/Pico-PIO-USB: USB host/device implementation using PIO of raspberry pi pico (RP2040). But that's a bit of an advanced hack, and I can't tell you how well it works.

Maybe you could use something like this: https://github.com/sekigon-gonnoc/Pico-PIO-USB

you should check out https://github.com/sekigon-gonnoc/Pico-PIO-USB for someone that has implemented USB chaining with rp2040. unfortunately it uses up both PIOs.

The pico just seems to be a flexible cheap option for USB applications. An example https://github.com/sekigon-gonnoc/Pico-PIO-USB

Highly experimental for advanced users. Adds a second USB port to Pi Pico using the PIO controller so the pico can connect to a PC and keyboard at the same time. https://github.com/sekigon-gonnoc/Pico-PIO-USB

watch the video to see this non-qmk firmware for the Rasberry pi Pico used to daisy chain devices with fixed device and host ports https://github.com/sekigon-gonnoc/Pico-PIO-USB

Have you tried using a different cable? A few months ago I wrote a similar program and someone experienced the same issue and it turned out to be the cable.

I wrote something similar (windows --network--> raspi zero w --usb--> target device). My first attempt used a simple tcp stream without nagle's algorithm and it was completely useable because I was sending way to many packets this way. After turning nagle's algorithm back on it generally usable but it also introduced something like a 0.5s delay (it's easily noticable, trust me). However the whole thing was pretty unstable, because even a small hick-up in network quality would result in a death spiral that took around 2-3s to resolve itself and make the program usable again. I'm sure I could've optimized my naive tcp protocol further to make it more stable but I chose to fix the problem on the source and wrote my own simple, reliable, ordered network protocol on top of UDP. While it currently has some limitations (no encryption, no congestion control, connection loss is somewhat ungraceful) it runs amazingly stable even under bad network conditions and with unnoticeable latency.

Both the Windows and Raspberry Pi parts of this project are written in Rust and can be found here.

Yes. When you use the Linux gadget driver it creates a device like /dev/hid0 for you in that you can write your usb-hid packets. This means that you can write a simple script that listens to a TCP connection and simply forwards everything it receives into /dev/hid0. On the PC side of things you then simply connect to this TCP server and you're good to go. Here is an example of what I'm talking about.