-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement EPx-only RP2040 USB Host #2814
base: master
Are you sure you want to change the base?
Conversation
This commit fixes issue hathach#2776 hathach#2776. The HCD now routes all USB transfers through the EPx endpoint. It no longer uses the "interrupt" endpoint hardware to handle INTERRUPT and BULK endpoints. The fix avoids the data sequence error handling bug in the RP2040 USB IP's "interrupt" endpoint hardware and allows the host to correctly drop the IN packet with the error without locking up. That fixes rppicomidi/usb_midi_host#14 This fix requires the CPU to handle the SOF interrupt (every ms). That might be an issue for some systems. A benefit of this fix is that BULK transfers are more than 2x faster. There is an opportunity to speed them up further by forcing BULK transfer to begin immediately instead of waiting for the next SOF interrupt. This code has been tested with MSC flash drives, HID devices, and USB Hubs. It works with full speed and low speed HID devices connected at the same time through a hub. With the usb_midi_host application host driver, 4 MIDI devices plugged to a hub can send messages to each other (see the midi2usbhub project).
@hathach The hardware test seems to fail because the flash download failed. Is that a problem with the build system? Flash download worked fine on my system. |
that is my bad, I was migrating HIL machine from pi5 to an VM. Merged with latest should fix this. Please give me a bit of time, I will review and test this as soon as I could |
Anything helpful in this young repo? => https://github.com/shreeve/picousb |
@shreeve Helpful to this code, or to picousb? My testing shows that this code works better than the TinyUSB host controller driver code for the RP2040 that is currently in TinyUSB. It works around a RP2040 hardware issue and it makes bulk transfers faster than what you get with the current HCD. Do you see an area for improvement in this pull request? |
@rppicomidi - It's hard for me to grok the code since it is very compact and there is a lot going on. I've started the other project to try to create a simpler and dynamic version of USB Host. Ha Thach has done an AMAZING job with TinyUSB though and has had a huge impact. My small little library is primarily nowhere near close to a fraction of what he has done, but it is a small effort to understand how the rp2040 USB Host mode works and hopefully it will inspire someone else. Thank you for your work on this patch! |
This commit fixes issue #2776
#2776.
The HCD now routes all USB transfers through the EPx endpoint. It no longer uses the "interrupt" endpoint hardware to handle INTERRUPT and BULK endpoints. The fix avoids the data sequence error handling bug in the RP2040 USB IP's "interrupt" endpoint hardware
and allows the host to correctly drop the IN packet with the error without locking up. That fixes
rppicomidi/usb_midi_host#14
This fix requires the CPU to handle the SOF interrupt (every ms). That might be an issue for some systems.
A benefit of this fix is that BULK transfers are
more than 2x faster. There is an opportunity to speed them up further by forcing BULK transfer to begin
immediately instead of waiting for the next SOF interrupt.
This code has been tested with MSC flash drives, HID devices, and USB Hubs. It works with full speed and low speed HID devices connected at the same time through a hub. With the usb_midi_host application host driver, 4 MIDI devices plugged to a hub can send messages to each other (see the [midi2usbhub](https://github.com/rppicomidi/midi2usbhub project).
Describe the PR
See description, above
Additional context
rppicomidi/usb_midi_host#14
raspberrypi/pico-feedback#394