Add USBHost

[dobrowolski-lukasz]

I'm opening new pr since author of previous one has become unresponsive.
Previous PR: #4032

I've rebased code form the previous pr.

This code is WIP.
Currently there are a lot of warnings due to missing doc-strings and the like.

[AlexCharlton]

Here's a commit that restores the ability to compile with the log feature: AlexCharlton@46c9d8c

This fix had been reverted because I had originally added the {:x?} format directive, which evidently dfmt doesn't recognize. I've simply used {:?} instead.

[AlexCharlton]

And another commit that fixes iter_interface: AlexCharlton@4c3afbd

It incorrectly assumed that interface descriptors would always come immediately after config descriptors. Embassy's own descriptor builder may stick an interface association descriptor before any interface descriptors, though. Since the IAD isn't actually needed to parse IDs (and since this iterator is also used to parse configurations from potentially unknown sources), I simply made it so that we skip over any non-interface descriptors, which is also what the previous interface iterator did.

[AlexCharlton]

One additional fix for this branch: AlexCharlton@3ef6a05

get_active_configuration (unlike get_configuration) was requesting a config descriptor that was always equal to the maximum available buffer size. Some devices don't like this and may not respond, so we're limiting the request to be exactly the size of the descriptor.

[dobrowolski-lukasz]

Rebased and took in AlexCharlton's fixes.
Test: Examples for rp and stm32g0 build fine.

[jakerr]

I recently attempted to port the stm32g0 example from this PR to stm32f4 (otg).
I'm guessing this may very well be one of the places where this PR is still WIP so it makes
sense that there are rough edges here.

I'm testing on the stm32f446re Nucleo board which has two USB peripherals both OTG, I'm focusing on the OTG_FS one.

I saw that this PR includes what appears to be an implementation for host mode for STM32 otg peripherals (embassy-usb-synopsys-otg/src/host.rs) in addition to the usb_v4.

The usb_v4 implementation has an example "examples/stm32g0/src/bin/usb_host_keyboard.rs"
I attempted to port that to "examples/stm32f4/src/bin/usb_host_keyboard.rs" but I couldn't quite find the right combination of feature flags and routing of the otg code into the example to make it work.

I see the feature flags in "embassy-stm32/src/usb/mod.rs" automatically select the _version mod to used based on the board capability (via mechanism in build.rs I think?) which automatically enables or disables cfg attributes usb and otg. For the usb with usb_v4 config case the usb_host mod is enabled and allows writing the example for stm32g0 but for the otg board case such as stm32f4 I don't think there's currently a clear way to import the host driver into the user's code (though I may very well be missing something!) I tried making the host module public and doing:

    let mut usbhost = UsbHostBus::new(otg);

But couldn't quite find how to create that otg parameter configured as host, that it seems to expect.

I'd love any advice or thoughts on how the usb_host driver interface should be unified, or at least made ergonomic, whether the board peripherals are usb or otg.

[Qix-]

I'm testing on the stm32f446re Nucleo board which has two USB peripherals both OTG, I'm focusing on the OTG_FS one.

I could be wrong, but if I understand the STM32's correctly, there is actually only one peripheral, with the option for it to be either FS or HS, depending on what's connected. If there's a ULPI interface, then you must use HS. FS is only usable (at least on the chips I've developed for) if you have D+ and D- connected directly to the OTG peripheral pins.

I would imagine that the Nucleo boards have an external ULPI interface, which means you must use the HS peripheral.

Nevermind, I stand corrected.

[dobrowolski-lukasz]

I've rebased onto main.

It might be better to merge main into this branch. This way I would avoid rewriting others commits and not risk attributing my errors to others if I make any during rebase. It seems to me that this would also play nicer with github.

Test: Examples for rp and stm32g0 build fine.

[jakerr]

I'm testing on the stm32f446re Nucleo board which has two USB peripherals both OTG, I'm focusing on the OTG_FS one.

I could be wrong, but if I understand the STM32's correctly, there is actually only one peripheral, with the option for it to be either FS or HS, depending on what's connected. If there's a ULPI interface, then you must use HS. FS is only usable (at least on the chips I've developed for) if you have D+ and D- connected directly to the OTG peripheral pins.

I would imagine that the Nucleo boards have an external ULPI interface, which means you must use the HS peripheral.

I'm not sure a blanket statement about STM32s can't be made regarding USB peripherals.

The reference manual and block diagram for the STM32F446 show two separate USB OTG peripherals:
• USB OTG FS → with its own on-chip full-speed PHY.
• USB OTG HS → controller present, but to get high-speed you need an external ULPI PHY; otherwise you can still run it at full-speed using the built-in transceiver.

[Qix-]

Yep, appears I was mistaken - thanks @jakerr, I wonder why I thought that. Looked at the block diagrams for a few of the chips I worked with again and it looks like they're distinct controllers; doesn't look like the pins overlap either.