ESP32-S3 USB OTG - USB Hub support?

[maaamc]

Is there any news ?

[ulflar2]

Hi everyone,

Seeking any news regarding support for USB hub.
We are developing a product where it is required. The limitations mentioned in earlier posts are not a showstopper for us.
But we would like to see the beta branch for public testing mentioned by tore-espressif. It would certainly help and be interesting to explore.
Any news on that one?

[s0urceror]

Looking forward for a beta release.

I have experience developing a USB stack for MSX computers via a CH376 in low-level mode. Will contribute my findings and use it in a new ESP32 S3 project.

Btw. in my previous project I had a 8 port hub connected with various devices. But the user could choose which ones it wanted to communicate with to go around the I/O limits of the CH376.

[s0urceror]

Okay, little update, I managed to connect to a USB HUB, retrieve the Hub descriptor, power-on and check which ports have devices attached, and reset each and every device.

From that moment on I'm a bit stuck because messages send/from a reset hub port attached device are not being returned. Per specification after RESET you can continue to communicate to EP0 on address 1 where the hub will forward the communication to EP0 of the connected device. Instead I still wrongly get (cached?) answers from the Hub.

One of those messages would be the SET_ADDRESS command to tell the device (and hub) that from that moment on it is at for example address 2.

After this you can communicate to address 1 for hub related messages and address 2 to N for the other devices messages.

[maaamc]

any news ?

[g3gg0.de]

2. Small Receive FIFO - 512 bytes: 512 bytes is borderline enough for one streaming (high-bandwidth) FullSpeed device. It will not be possible to stream from 2 USB camera at the same time on S2/3 (at reasonable definition of the video).

I am trying to read data from a isochronous device, the InfiRay TS2+ thermal camera.
It uses a MPS of 524 instead of 512, which is 12 bytes too short.
that seems to be [UVC header] + [256 pixels per line * 2 byte]

My question:
Its this limit of 512 a physical limitation, where there is no way to work around?
Or might it be possible with a hack to throw away 12 bytes of every transfer.
I would be even happy with receiving 512 byte, throwing away the last 6 pixels (12 byte).

Best regards