Allow parallel instantiation of FS and HS OTG

[mgottschlag]

I currently have a use case where I would want the MCU to present itself as two devices to two different USB hosts. Currently, this driver does not allow this scenario. However, it should not be too difficult to implement, probably without any negative sideeffects.

I quickly modified the code using some ugly macros to find out whether such parallel operation is actually supported, and managed to make my discovery board to appear like two individual serial ports:
https://github.com/mgottschlag/synopsys-usb-otg/tree/parallel-fs-hs
It is obvious, though, that this approach is not viable, as such macros introduce major headaches.

[Disasm]

I think that one of the ways to support both FS and HS is to define a superset of registers and use it. Maybe HS register set is already a superset of the FS register set, I don't know.
Additionally, we have a problem with incompatibility between register sets of different IP versions, so probably a better solution is to create our own register definition that will include registers and fields of all IP versions.
Copy-pasting and macro-generation of different versions is also possible, but doesn't look like a good solution. Libraries with macro-generated code are also difficult to debug and inspect with most modern IDEs.

[mgottschlag]

I think that one of the ways to support both FS and HS is to define a superset of registers and use it. Maybe HS register set is already a superset of the FS register set, I don't know.

I have to admit that I did not look at it in any detail, I just wanted to qucikly check whether it works at all. If the register sets are mostly compatible, then runtime checks of which operations to use (i.e., a HS/FS flag somewhere in one of the structs) would probably be the cleanest solution (code-wise).

Copy-pasting and macro-generation of different versions is also possible, but doesn't look like a good solution. Libraries with macro-generated code are also difficult to debug and inspect with most modern IDEs.

Of course - in my example, the macros immediately broke rustfmt. Maybe a small encapsulation of the operations differing between different peripheral types/versions might be viable, so that that wrapper could be passed to the other types as a generic parameter. That might generate slightly better executable code for situations in which only either FS or HS would be used (and would cause lots of duplicated code for situations in which both would be used).

[paulyoung]

I currently have a use case where I would want the MCU to present itself as two devices to two different USB hosts

I’m interested in doing the opposite; appear as host to two different USB devices.

Has any thinking evolved around this? In embassy-rs/embassy#602 they appear to be using the HS driver with FS peripheral.