Closed BrianHoldsworth closed 1 year ago
maccasoft
commented
2 years ago The USB HUB support is definitely on the TODO list. Dedicating COGs to the devices is not feasible, it would require an almost complete rewrite of the driver to allow message passing between COGs, and anyway USB devices don't run in parallel.
BrianHoldsworth
commented
2 years ago Thank you for the response. Seems I have a misunderstanding about the cog usage, and clearly it's better if several devices could be managed by a single cog.
maccasoft
commented
1 year ago HUB support added sometime ago, forgot the update the issue.
Note: This is more "feature request" than issue, but would make the PASM USB code far more practical for hardware designs with a single USB device port.
I think the USB code is designed to dedicate a cog to each USB device. I also think this is an Ok use of cog resources, but would like it to support multiple devices using a single USB port wired to the P2 - in other words, support a USB hub device, and dynamically spawn (and kill) additional cog drivers for the downstream devices connected via the USB hub.
Likely, the separate cog used to monitor the USB hub could co-exist with other functionality, and just poll the hub periodically for device updates. So, an application's "main cog" would need to poll the USB hub periodically by calling the hub driver code, and the hub driver code would allocate spare cogs to deal with any new USB device found. Ideally, there would be both a SPIN2 and PASM interface to call the USB hub poller from within the "main cog's" code. Even more ideal would be to design this as a "generic USB device poller" that can work whether the first downstream device is a USB hub, or not. That would fulfill the goal of a single USB port wired to the P2 and able to detect both direct USB device connections or via a USB hub. Then, a cog gets started to deal with any connected device.