USB: Add support for external ULPI PHYs

[mattico]

Tested with an STM32H743BIT6 and a USB3300-EZK on a custom board.

[richardeoin]

This looks great. I also tested your example (https://github.com/mattico/test-ulpi-usb) on a STM32H747I-DISCO board and it works fine, only the DIR and NXT pins are different.

Thanks for adding the clippy directive, this must have been upgraded to an error recently.

Potentially the USB API could be reworked slightly, so instead of filling in a structure, the user would call a constructor method like USB1_ULPI::new(...). I think that would be more idiomatic and match the rest of the HAL. But it should be added for all USB peripherals, so better tackled in a different PR.

Feel free to add your name to Cargo.toml/authors if you like!

[richardeoin]

Do you need the #[cfg(not(feature = "rm0455"))] on the USB1_ULPI declarations? The USB1_ULPI implementation should be valid for RM0455 parts also, so you can remove it

[mattico]

This looks great. I also tested your example (https://github.com/mattico/test-ulpi-usb) on a STM32H747I-DISCO board and it works fine, only the DIR and NXT pins are different.

Good to hear! Had a lot of trouble getting this to work, then the result was fairly simple. Always a bit worried I missed something.

Thanks for adding the clippy directive, this must have been upgraded to an error recently.

You know, it was probably upgraded to an error due to LLVM removing infinite loops with no bodies. (rust-lang/rust#28728) Maybe we should use asm::nop() in the loops instead.

Potentially the USB API could be reworked slightly, so instead of filling in a structure, the user would call a constructor method like USB1_ULPI::new(...). I think that would be more idiomatic and match the rest of the HAL. But it should be added for all USB peripherals, so better tackled in a different PR.

Yeah, like the Pins traits. I don't have the energy for that right now, but I'll keep it in mind.

Do you need the #[cfg(not(feature = "rm0455"))] on the USB1_ULPI declarations? The USB1_ULPI implementation should be valid for RM0455 parts also, so you can remove it

Good catch.

[richardeoin]

You know, it was probably upgraded to an error due to LLVM removing infinite loops with no bodies. (rust-lang/rust#28728) Maybe we should use asm::nop() in the loops instead.

This is a better fix, thanks!

bors r+

[bors]

Build succeeded:

• ci (1.43.0, stm32h743)
• ci (1.43.0, stm32h743v)
• ci (1.43.0, stm32h747cm7)
• ci (1.43.0, stm32h753)
• ci (1.43.0, stm32h753v)
• ci (1.43.0, stm32h7b0)
• ci (1.43.0, stm32h7b3)
• ci (stable, stm32h743)
• ci (stable, stm32h743v)
• ci (stable, stm32h747cm7)
• ci (stable, stm32h753)
• ci (stable, stm32h753v)
• ci (stable, stm32h7b0)
• ci (stable, stm32h7b3)
• Rustfmt

[richardeoin]

Yeah, like the Pins traits.

I don't think it needs any new traits, the existing implementations are fine. I've tried this in #187, do you have any comments @mattico ?