Dual device (to separate hosts) capability?

[DragRedSim]

Hi there,
One thing I don’t seem to have been able to figure out with this library is whether the following setup actually is possible; to have both the hardware USB port and the PIO USB port both acting as devices (in the USB sense, communicating with two separate hosts) at the same time. The use case in question would be to have one port provide a communication path (eg. over UART) to input commands from a PC, for the Pico to process those serial messages in an appropriate manner to the use case, and then to communicate with the other host based upon those messages received, by emulating a keyboard/mouse on that USB device. The current implementation I’m using of a similar device uses a serial-converter chip to provide the first interface, however I’d like to be able to avoid using such a thing if possible; if it could be as simple as hooking up an extra USB connector to three pins (avoiding crossing the VCC streams) and handling the rest in software, it would be preferable to do so to minimise the number of boards involved. Certain variations I’ve seen have used an entire second Pico as a USB-UART converter, that then transmits to another Pico over UART and that does the conversion… but why use two devices if we could use one?

[adirobu84]

As far as I know there is nothing in this library that wold prevent you from doing so. In fact, I have this exact setup you're describing working, but I have heavily modified the library. For the most part it was just removing the host capabilities to simplify things a bit. There are also a few things that I think are bugs, but to be fair I might have misunderstood the author's intention. Unfortunately the examples are not very explicit and I'm not getting a lot of feedback from the author either, so I decided to just go ahead and modify it.

The RP2040 native USB port and the TinyUSB stack should not interfere with the USB PIO operation at all, just make sure that you set your interrupt priorities appropriately. This is an issue I ran into (I had some other stuff running on interrupts that interfered). The PIO USB library does all of the low-level packet handling in the ISR. This means that you need to give it a high (or highest) interrupt priority so that any packet received by the PIO RX engine is processed right away. If the ISR enters too late you might lose the packet. The host will usually resend the packet if it doesn't get a response, but if the ISR cannot respond to the received packet right away this could be an issue. Also be careful with disabling global interrupt in the application (Note: I'm saying be careful, not don't do it. Just be aware what you're doing).
In contrast, the native USB port doesn't need such a high ISR priority, because the packet handling is all done in the HW (USB peripheral) and the low-level packet ACK/NACK is done by the hardware as well.

I'd also like to point out that the timing requirements for USB HS are very tight for a microcontroller that can run only a bit over 100MHz. Running it at LS might be just fine, but if you're using the RP2040 as a device the chances are really high that your host is HS. Since the RP2040 has a second core you could partition things in a way where the second core is entirely dedicated to USB PIO, but although this is not super complicated, I think most people just don't want to deal with it and just use a second PICO and resort to using example code. That's totally fine, but again, as far as I am aware, there's nothing that would prevent you from doing all of it on one device. You might just have to spend a bit more time integrating and modifying things.

[okyeron]

Do you have any sharable sample code showing the setup for this? Can't find anything similar in the repo examples.
Thx!

[benmcevoy]

hey @okyeron refer: hathach/tinyusb#1673
might be possible using two PIO ports?