soundcyst - great question. I'd love to know the answer to that too.
When I read the USB specs, e.g.
http://www.usb.org/developers/docs/
I don't see what would prevent it. Though it does seem to add complexity.
A Hub has to present itself to the USB host 'properly', including having its own USB Device class and control endpoint. So, I assume being a hub would 'consume' the STM32F's control end point, but I don't see why that might be a problem.
The USB spec. (usb_20.pdf) includes chapters on a Hub, which is more than 1/4th the main document (123 of 420 pages). So there is some complexity in there.
There is a chunk of that USB hub documentation around *not* doing certain USB transactions during periods when a real USB device is doing a transaction, but that shouldn't happen when the device is just faking being a hub.
I have assumed their is more to it, but mainly because of the amount of documentation in the USB spec.
According to the USB spec:
"4.8.2.2 Functions
A function is a USB device that is able to transmit or receive data or control information over the bus. A function is typically implemented as a separate peripheral device with a cable that plugs into a port on a hub. However, a physical package may implement multiple functions and an embedded hub with a single USB cable. This is known as a compound device. A compound device appears to the host as a hub with one or more non-removable USB devices. " (My emphasis)
I assume the 'non-removable USB devices' is the unique part of 'compound device', but I haven't been able to pin that down.
I would have imagined that 'compound device' could become 'invisible' to the host if it were a hub + several USB devices, and the software enumerated them as if they were being plugged in.
I assume condensing the devices into a hub+spoofed devices would require each device to be enumerated, and get polled. Enumeration would take longer at bootup, and polling would take longer. If it were only a few USB devices, I wouldn't have thought this would be a big performance impact.
It is extra software complexity though. For it to have some benefit, it'd need to implement a USB Hub and at least two USB Devices.
From the perspective of a minimal bootloader and debug infrastructure, being a single USB device would be simpler. Candidate devices which are widely supported, and relatively understandable include CDC virtual serial. There are others, including HID, but I don't know how I would 'open' a HID device from the host PC, and make any use of the device. Using a USB CDC virtual serial is pretty well understood.
But having a framework which would support 'plugging in' combination's of USB Devices looks like a good idea for general development.
{whine: I would *much* prefer this sort of functionality in preference to LeafLabs creating and supporting Yet Another IDE}
