💡[FEATURE] Dedicated Controller API about pico-pio-usb HOT 12 CLOSED

Thank you for your suggestion.
It would be great if we can use pio-usb with TinyUSB stack.

Current device driver(enumeration, class ...etc.) implementation is tentative and is for my study of the USB specification. So I think this can be obsoleted if pio-usb works with tinyUSB stack.

Anyway, separating controller from protocol stack is good idea, and I welcome pull requests.

from pico-pio-usb.

That is great to hear you are interested in the idea. I will make an PR as soon as I could.

from pico-pio-usb.

I have been working on this for last couple of weeks, the pio-host works pretty well, though the pio-device is a bit mixed. It works when attaching to pio-host though struggle with an actual PC. Maybe I got mess up with the device part, out of curiosity, did you get pio-usb device running well with your PC ?

from pico-pio-usb.

How can I test current your branch?

1. Check out my tinyusb branch here https://github.com/hathach/tinyusb/tree/pio-host
2. check out submodule at lib/Pico-PIO-USB, whic include an fork to your https://github.com/hathach/Pico-PIO-USB/tree/tinyusb-test
3. The following examples in the tinyusb are changed to use pio-usb

• host example examples/host/cdc_msc_hid
• device example examples/device/hid_boot_interface
• cd to either example above and run make BOARD=raspberry_pi_pico all flash

4. Note I did change the default pio-usb configure of DP pin to 26 (since pin0 is for uart debug)

Note: my branch is still wip, and is rather mess up, code is still moving around. I have made quite a lots of changes to your pio-usb that I start to worry that you wouldn't accept my PR 😅 . Though I will make it anyway, I am putting pieces together and make sure it will work with both tinyusb stack and your minimal integrated stack as well (configurable).

from pico-pio-usb.

One thing I noticed that I'm not sure if it's specific to the pio-usb backend, but it currently seems to ignore the polling interval declared by the device in the endpoint descriptor. It runs at 1000 Hz regardless of what the device requests. Does that sound possible?

That is my TODO, original pio-usb host does respect the interrupt interval, I just haven't got time to do it yet and want to wrap up other works first.

from pico-pio-usb.

Yes, I tested example/usb_device on Windows PC, Linux PC, and android phones.
In my experience, timing requirement is more severe for device than for host.
How can I test current your branch?

from pico-pio-usb.

@sekigon-gonnoc thank you for confirming, indeed the timing is very strict with device since pc host has a strict timing policy. While in host mode, we could dictate the pace of package. I have made more progress and done more testing with another windows laptop, and it seems to have a better result than my Linux work pc. I think the timing does depends on both pc driver and usb controller on the mobo (one port of my linux pc work better than other). Here is my test result

• with old windows 10 laptop: stock example/usb_device work well (great work !!!), my wip fork also does as well with (yeah !!). Though even everything is working, there is still quite some token without response from our device, noted as turn around error in the analyzer capture. Note: My pio-usb + tinyusb combo seems to also cause more of this orphan token than your, possibly due to the overhead causing by event queue and mutex etc, will try to improve it later.

As seen in the analyzer, some IN token has no data response from our pico. Though it is fine since host re-issue new token as retry

• with my linux 5.15.0, ubuntu 22.04: on cpu-integrated usb controller (amd 3900x), our example work rather well. However on an port with external Microchip controller (which I tested first) both your and my examples does not work at all, they got constant timing issue with IN transaction from host.

As seen in the capture, issue is different than above, since we did responded with DATA to the IN token, however, it is probably too late (turnaround/timeout error) and host controller abort transfer already and discard our message (didn't even send ACK handshake). The cpu probably does not run fast enough from device_receive_token to usb transfer. I will try to see if I could tweak it up somehow

Anyway, we shouldn't expect pio-device work with all controller, since it is still bit-banging an USB. Thank you for your great work, I think I have better working base now

from pico-pio-usb.

I need to do more testing, but it seems that one device that didn't work with bare pio-usb (enumeration failed, #18), does work with this branch. I will be watching this with great interest.

from pico-pio-usb.

@hathach On your branch, is it currently possible to use RP2040's built-in USB for device and pio-usb for host, at the same time?

from pico-pio-usb.

@hathach On your branch, is it currently possible to use RP2040's built-in USB for device and pio-usb for host, at the same time?

yes, it is the main purpose for me to do this work. device on hw controller, host on pio. You can try out https://github.com/hathach/tinyusb/tree/pio-host/examples/host/hid_to_cdc , though I haven't looked at the example for awhile(eventually it will).

from pico-pio-usb.

yes, it is the main purpose for me to do this work. device on hw controller, host on pio.

It does work indeed! You're both doing awesome work, guys!

One thing I noticed that I'm not sure if it's specific to the pio-usb backend, but it currently seems to ignore the polling interval declared by the device in the endpoint descriptor. It runs at 1000 Hz regardless of what the device requests. Does that sound possible?

from pico-pio-usb.

implemented by #22

from pico-pio-usb.