Suggestion: Reverse version with swapped USB ports

[braxlan]

I know there is the Dual Pico Version with enhanced compatibility on the host side by using the pico's native USB port as USB host. But what I did not understand is why it uses a second pico on the device side. Wouldn't it be easier to use Pico-PIO-USB on the device side instead? This way only one pico would be needed, while the soldering complexity is even smaller. Debugging will of course not be as easy because CDC cannot be used this way, but the same applies to the Dual Pico Version too in a way. And non-developers (probably most users) will not use debugging anyhow.

The standard approach for single-MCU solutions seems to be to use Pico-PIO-USB to add a USB host to a MCU which has a USB device port (e. g. Adafruit Feather RP2040 with USB A host). In my eyes this wastes the potential of the native USB port which will be used as the "easier" device part while adding a "problematic" PIO based implementation on the more complex host side. This makes programming easier but leaves a lot of problems in the long run. Just my personal opinion.

I am looking forward to your thoughts on this. Maybe I am simply missing important details because I am not an expert in this field.

[jfedor2]

I attempted this at various points in time but never got it to work in any reasonable form.

As of right now I don't think TinyUSB examples even compile when trying to use the Pico-PIO-USB interface in device role.

[braxlan]

Thank you for clarifying this, and it completely explains why there is the Dual Pico Version in existence.

I wanted to try the Pico-PIO-USB device examples too but also stumbled about the fact that they don't compile. Looks like support for device mode is broken since version 0.6.0.

It is funny that it is impossible to find an MCU which has two native USB ports, with one working in device mode and one working in host mode, both with stable TinyUSB support. If you know one by any chance, please tell me, I could not find any.

Should we leave this open for future reference? Otherwise I will close it as irrelevant.

[gkbd]

There are a few RISC-V MCUs with native dual USB interfaces, such as CH32V203 and CH32V305.

One can try mass produced boards like nanoCH32V203, nanoCH32V305 and Suzuno32rv.

Last time I tried TinyUSB, support for these boards was incomplete and I ended up using BSP code instead, but now I see there is PR from @verylowfreq that should add missing bits once merged.

[braxlan]

Thank you for your suggestion. I already tried the nanoCH32V203, but I could not get any TinyUSB example compiled which uses host functionality, the device examples seem to compile fine. I haven't done any further testing because I need the dual role functionality.

Ha, I just wanted to mention the Kite project but then found out you're the original programmer! btw, where did you get WCH's USB library from? It could be an option to play around with a recent version of it until TinyUSB becomes stable on the CH32.

This device would indeed be very interesting if fully supported by TinyUSB, maybe another option for the hid-remapper in the future. I'm thrilled to see the PR merged into TinyUSB in the near future!

[gkbd]

WCH USB examples are available at

• https://github.com/openwch/ch32v20x/tree/main/EVT/EXAM/USB

But if in the end you plan to use TinyUSB, then maybe PR branch is better starting point:

• https://github.com/verylowfreq/tinyusb/tree/pr-ch32v-usbfs-host

[jfedor2]

There's also the chip that's in Teensy 4.x (i.MX RT1060) that's supposedly supported by TinyUSB. Some STM32 variants, Renesas RA6M5, Bridgetek FT900L, CH583.

To be honest the dual RP2040 setup works well and is cheap and easy to make so I haven't spent a lot of effort exploring other possibilities. Though of course I wouldn't mind an RP2040/RP2350 successor with two native interfaces.

[braxlan]

WCH USB examples are available at

* https://github.com/openwch/ch32v20x/tree/main/EVT/EXAM/USB

Thank you for pointing me to the USB lib! I was absolutely unable to find it myself.

But if in the end you plan to use TinyUSB, then maybe PR branch is better starting point:

* https://github.com/verylowfreq/tinyusb/tree/pr-ch32v-usbfs-host

Yeah, maybe the PR branch could work, or even simply applying the PR myself on a recent local clone instead of waiting until it goes upstream.

[braxlan]

There's also the chip that's in Teensy 4.x (i.MX RT1060) that's supposedly supported by TinyUSB. Some STM32 variants, Renesas RA6M5, Bridgetek FT900L, CH583.

A big thank you for all the suggestions! I will check them out.

I tried compiling some TinyUSB examples for the Teensy 4.1 which compiled without errors, but the result made lsusb hanging until I pulled the Teensy again. I guess it would take more effort to get this running, and I am lacking experience to do so. Also endpoint 1 is reserved internally which could be a show stopper in for my project because of compatibility with simple KVM switch USB stacks. For other things, the Teensy is a quite impressive device.

To be honest the dual RP2040 setup works well and is cheap and easy to make so I haven't spent a lot of effort exploring other possibilities. Though of course I wouldn't mind an RP2040/RP2350 successor with two native interfaces.

I'd possibly go for the dual pico option too because it is known to be supported and working. Especially the PCBs you've designed with dual pico compatibility are very interesting. But if the CH32V203 is working with the mentioned PR in TinyUSB, this could be a game changer, because it is roughly the same price as a pico, but with native dual USB support.

[braxlan]

There are a few RISC-V MCUs with native dual USB interfaces, such as CH32V203 and CH32V305.

One can try mass produced boards like nanoCH32V203, nanoCH32V305 and Suzuno32rv.

Last time I tried TinyUSB, support for these boards was incomplete and I ended up using BSP code instead, but now I see there is PR from @verylowfreq that should add missing bits once merged.

I just tried the PR with a few examples with host functionality. They now all compile without errors, but when I connect a device to the nanoCH32V203, the blinking stops in the current state (on or off) and the board freezes until I reset it When I connect a hub or a device to a connected hub, the blinking stops for a moment before it continues, showing no further effect elsewhere. In case you tried it yourself, did you have more luck? I connected the devices to the USB2HD port. Interestingly, using the PORT=x parameter did not issue a recompile when I changed the value.

[gkbd]

I just tried dual/host_hid_to_device_cdc example on nanoCH32V203 and it works with mixed success for me, low speed devices like mice mostly work fine, but most of keyboards don't, I found couple of keyboards that worked though. So I guess it's not ready for prime time yet, but might be worth investigating why so many keyboards fail.

[verylowfreq]

Thanks for finding my fork! :)
The PR is still incomplete. And as you mentioned, some LowSpeed USB keyboard via external HUB cause the problem. (In my test, plugging the USB keyboard to the USB port directly works fine.)
I'm working with this PR continuously, and any reports and suggestions are welcome.

[braxlan]

I just tried dual/host_hid_to_device_cdc example on nanoCH32V203 and it works with mixed success for me, low speed devices like mice mostly work fine, but most of keyboards don't, I found couple of keyboards that worked though. So I guess it's not ready for prime time yet, but might be worth investigating why so many keyboards fail.

Looks like I need to do further tests. I didn't have luck with neither a mouse nor a keyboard, both connected directly, but that was before the latest update of the PR.

Thanks for finding my fork! :) The PR is still incomplete. And as you mentioned, some LowSpeed USB keyboard via external HUB cause the problem. (In my test, plugging the USB keyboard to the USB port directly works fine.) I'm working with this PR continuously, and any reports and suggestions are welcome.

I'm looking forward to your PR going upstream! I'm glad you're working on this, because the CH32 series looks promising to me!

Maybe we should move further discussion regarding this to @verylowfreq's PR because this is really becoming off-topic for the hid-remapper project.

[braxlan]

Closing this because this might happen sometime in the future if Pico-PIO-USB allows it.