USB Support about rp-hal

[Szpadel]

I wanted to implement USB driver, but it looks like there are some registers missing in PAC, because of incomplete svd, I already created issue in C sdk repo
raspberrypi/pico-sdk#351

[Lichtso]

I joined the effort.
You can find my work on this branch here: https://github.com/Lichtso/rp-hal/tree/feature/usb

Already done:

• USB device prototype with a capitalizing echo interface for testing
• Integrated into the HAL crate
• Supports interrupts / has an ISR
• Localization and UTF-16 LE for string descriptors
• Configurable descriptors & endpoints
• Programmable endpoint handlers with stall signaling
• Fixes the PID (DATA0 / DATA1) issues the C / TinyUSB version had
• Get-descriptor-request always limited by wLength
• Tries to use as little additional RAM as possible, e.g. storing the endpoint configuration and state only in the dpram
• Tested to work on Linux and macOS (which is a lot stricter with the protocol)

Left todo:

• USB host
• USB class drivers
• Data packet fragmentation (transfer longer than one buffer size)
• Double buffering
• Feature enable / disable, alternative interfaces, multiple configurations
• Error handling
• Connection & VBUS state

[Szpadel]

@camrbuss I do not have much spare time now, therefore I wasn't able to do any significant progress here, but I tried to create similar implementation to https://github.com/stm32-rs/stm32-usbd, and in my initial research it looked like rp2040 uses very similar api for usb, so it looks like good example to base on.

[9names]

If you do take this up, be sure to check https://github.com/Tiwalun/pico-usb as well

[9names]

I don't understand what you mean by ...
Do you mean as having the driver's implementation in a separate crate?

No, I do want the USB support driver in rp2040-hal - I just want to ensure we could use idiomatic Rust to interact with the driver and make use of the existing usb-device infrastructure - which it looks like you've accomplished, so you can ignore what I've said here.

It will also require a preceding PR on the pac in order to simplify the programmer's model.

A quick comment on the PR about this and why it's needed would be great.
Is it the one you've already made that arrayifies the endpoints? That's a good change.

I created the #98. Let me know if you have any issues with it.

I gave it a quick skim and it looks good, I'll try to review it tomorrow

[9names]

#98 is merged. Support for USB is now in main, closing this issue.

[camrbuss]

@Szpadel SVD 1.2 has the DPRAM registers and the rp2040-pac now has what we need 😃

Does anyone have a fork started on this effort?

[9names]

I've updated pico-usb to work with the new PAC.
https://github.com/9names/pico-usb
I've also got it working with the HAL doing all the reset and init, and converted the debug print statements to work with defmt-rtt.
https://github.com/9names/rp2040-project-template/tree/pico-usb

It doesn't always initialise correctly. I recommend using a powered hub so you can disconnect USB upstream while keeping the Pico powered.

[9names]

I tried out your impl - seems quite reliable! A couple of comments:

• Don't put an interrupt in your driver, provide a poll() function that a user can place in an interrupt handler in their own code. That will allow them to process USB in a task in RTIC, or do any other processing they want in the interrupt before/after the poll if they're just using cortex-m-rt directly, or just manually call poll if they want to avoid interrupts altogether.
  It's just generally more flexible without a great cost
• Use usb-device instead of implementing your own USB class drivers - we'll get device descriptors + drivers for several common device types for free that way.

[camrbuss]

I got Lichtso's latest commit 00ed727 working with a lot less issues than the previous "pico-usb". Now we just need to implement usb-device traits so that we can use other crates. Very exciting!

[9names]

This is much better Lichtso!
We can swap that raw pointer to USB for an Option in the example, so we have a little less unsafe to deal with.

static mut USB: Option<usb::Usb<pac::USBCTRL_REGS, pac::USBCTRL_DPRAM>> = None;

#[allow(non_snake_case)]
#[interrupt]
unsafe fn USBCTRL_IRQ() {
    if let Some(usb) = USB.as_mut() {
        usb.poll()
    }
}

[Lichtso]

I implemented some more of the todos and separated the example code into its own file.
Maybe somebody else can link the ISR of the example correctly as I am not using "rp2040-boot2" and "cortex-m-rt" but my own.

[9names]

The ISR changes are minimal, see
9names@1aaa666

[ithinuel]

For what it's worth, I need to integrate the rp2040-hal with keyberon that relies on usb-device for my next keyboard so I started to do the port.

I'll keep you updated if I managed to make it work and if I can get a green light to share what I have.

[9names]

@ithinuel: if you're porting I think it would be best to try to bring the implementation closer to https://github.com/stm32-rs/synopsys-usb-otg or https://github.com/stm32-rs/stm32-usbd, since they've already gone through the effort of designing sharable data-structures and associated functions, and there are already examples and projects using them with usb-device integration

[ithinuel]

I don't understand what you mean by:

the effort of designing sharable data-structures and associated functions

Do you mean as having the driver's implementation in a separate crate?
That seems a bit over kill for now as there is only 1 rp chip.

---

I have a working implementation of the driver. I did test it with the usbd-serial class and will soon integrate with keyberon.
I need to do some extra polish (mostly doc) and get clearance from work.
It will also require a preceding PR on the pac in order to simplify the programmer's model.

[ithinuel]

I created the #98. Let me know if you have any issues with it.