Usbh prerequisites (part 2)

[i404788]

This is a follow-up to #3253 now that I've finished a reference implementation based on usbh.
It should now have all registers required make Host HS/FS/LS FIFO/Buffer-DMA/Scatter-gather-DMA driver on an ESP32* and similar devices that have a Synopsys USBOTG core.

The only registers missing are GHWCFG{1..=4}, I've added them as u32, but some may be needed to do feature detection of e.g. HS phy, scatter-gather dma support, number of EPs.

If desired I can either make a later follow-up for the GHWCFG or include it in this one (may take a few days).

I also found a source for register documentation so I've added it to the module description.

The reference implementation still needs to be cleaned up and is planned to be added in a pull-request to esp-rs, since it's not async. In the future I may port it to embassy if embassy adopts a standard host trait (I know there is a proposal in #3307)

[Dirbaio]

hey!

did you write this manually? that file is autogenerated from https://github.com/embassy-rs/stm32-data/blob/main/data/registers/otg_v1.yaml . Could you add the missing registers there and then sync the generated code?

[i404788]

It was written by hand since there wasn't any note about it I had assumed it was only auto-generated to get a starting point. There are also a few things that I don't think are possible with the yaml like:

• embassy/embassy-usb-synopsys-otg/src/otg_v1.rs

  Line 4251 in 2f46ed5

  debug_assert!(val & 0xFFFFFE00 == val, "QTD list needs to be 512 byte aligned");

• embassy/embassy-usb-synopsys-otg/src/otg_v1.rs

  Line 4640 in 2f46ed5

  pub const fn as_value(self) -> u8 {

Even without the assert I'm also not sure how to define qtdaddr since it's not a shifted value but does have a mask. So some help would be appreciated.

[Dirbaio]

For qtaddr you can just make it a u32, and ensure in the driver the value you write is aligned. For .as_value() that match can be done in the driver as well.

That file is a "mini PAC", it defines the registers of the peripheral. It shouldn't do any special validation, that's better left to a higher layer (the driver/HAL).

You're right there should've been a warning, sorry about that.

[i404788]

@Dirbaio I've completed adding the registers in embassy-rs/stm32-data#529 it's a bit hard to review if nothing else has changed before my previous pull-request since the output of chiptool was different than the existing file.

[i404788]

It seems like there were previously some manual changes related to sd1pid_soddfrm and sd0pid_sevnfrm as well as the fact that chiptool does not output a functional file (has crate::common which should just be common).

[i404788]

@Dirbaio seems like the new gen also affects other packages now, do we want to make a breaking change to update generation or should I revert to the original PR?

[i404788]

@Dirbaio is it possible to make a decision on this? I'm working on the host driver based on the #3307 discussion, so it would be useful to know which convention I should base it on.