embassy
embassy copied to clipboard
embassy-rs
Usbh prerequisites (part 2)
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)
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?
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:
- https://github.com/embassy-rs/embassy/blob/2f46ed5cbeecede74c2327deda3897b5cb232335/embassy-usb-synopsys-otg/src/otg_v1.rs#L4251
- https://github.com/embassy-rs/embassy/blob/2f46ed5cbeecede74c2327deda3897b5cb232335/embassy-usb-synopsys-otg/src/otg_v1.rs#L4640
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.
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.
@Dirbaio I've completed adding the registers in https://github.com/embassy-rs/stm32-data/pull/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.
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).
@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?
@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.