I have been researching USB OTG for a little while and was not able to find an answer to my question. I'm seeking for the conditions, if it's even possible, under which I can have one USB OTG port work in slave mode and at least one USB-A port act as host simultaneously. It is definitely not possible when the two ports are connected to the same USB Hub (e.g. like it is the case with a RPi Zero + Zero4U), but how about when the two ports are entirely separate? Here you can find a 'USB Map' of the Orange PI Plus2:
Could I use the USB OTG port, which originates from USB0, as slave port while, at the same time, using one of the Hub ports connected to USB1 in host mode?
Thank you in advance for your time and for sharing your experiences!
Best Answer
If they are distinct USB peripherals at least one of which supports mode switch functionality then yes. This is in fact fairly common on dual USB microcontrollers and tablet-type SoC's. Your diagram seems to show such a situation, with one OTG capable dual-role port directly accessible, and a second port setup for host use with a built in hub.
A USB hub tends to be entirely incompatible with usage of any of its ports as a USB device, as operating the USB engine in device mode would be incompatible with operating it in host mode to talk to the hub.
Probably the closest you could come to that would be using a USB data interchange cable plugged into one port of an onboard hub. A data interchange cable is a sort of dual-ended USB device - but one that is generally limited to a particular scheme of data transfer. Of course once you have that pipe supported at both ends, you can push fairy arbitrary data down it.
Theoretically it might be possible to design a hub chip with a single "passthrough" port that could be (while disabling all other ports) reversed to operate as a device and forward data to the SoC's USB interface operating in device mode, but this seems unlikely as a product, as most of the devices where operation as a device is supported don't have space for the connectors from an internal hub anyway. Ultimately in most embedded/dev board settings, the dual USB peripheral on chip approach is preferable to a single port permanently connected to an on-board hub.
Of course in the end USB is not just about hardware, but also about driver stacks and system services, user-mode APIs, etc. There has definitely been hardware that shipped with capabilities not reflect in the software, and it is theoretically possible that a software stack could enforce some kind of limit where both ports would have to be in the same mode. But that doesn't seem too common. An inability to switch modes at all though often is - the mode determination is usually ultimately made by software, which may or may not consider or honor a hardware mode detect input pin.