I wrote an entry about device vs hub emulation on the blog
.html). I reproduced the content below, it would be great if someone could
check if my understanding of USB hub is correct.
Then I'll start researching/writing something about how I think device
emulation would work.
wrt the blog text: not sure which port you mean with MUSB port. I
would expect the device-to-be-sniffed to be connected to the regular
(EHCI) port and the OTG port to the host.
Yes. By MUSB I mean the slave (gadget, OTG) controller (the EHCI controller does not seem to be part of the MUSB IP, from what I see in the datasheet).
The OTG port will definitely be able to deal with address 0 as it can
be used to act as a slave device.
My concern is that the OTG port may only be able to deal with _one_ address at a time. It will answer to address 0 after a reset, but as soon as it is assigned an address by the host, it will answer to that address, and not any other.
Some more remarks:
- the device to be emulated can only be a HS device as other speeds
are not supported by the EHCI port.
Sure, for LS/FS, we need a hub (a real physical USB hub ,-)), I'm aware of that.
- you might want to consider the case where a physical device actually
represents multiple devices. E.g. a simple voip handset might present
itself as an audio-in, audio-out, input (kbd) and output (lcd) device.
As long as all these devices answer to the same USB address, it should not be a problem.
Ideally a sniffer should be able to sniff all traffic (so also if
there is a physical hub downstream).
That, I don't think would be feasible. If there is a hub downstream, there will be multiple addresses.
What we could do, if there is a hub, is to "pick" one device, and forward the traffic to it (that would be useful for the LS/FS case, where a hub is needed).
Having said that, I think you should probably focus at a single device
first, but keep this in mind, so you do not close doors or make
decisions that disallow that (or if you have to then at least it was a
Yes of course. That's why I prefered a hub solution in the first place (more flexibility). But if that can't be done...
And, as mentioned before, synchronous transfers may cause additional
pain (and be a reason to do most, if not all, in the kernel). Note
that synchronous does not mean delay-less (a hub will also cause some
delay), but it may well mean that the latency (if any) is constant.
Wrt the acquisition and display of the data: I would suggest
investigating if it is possible to use a wireshark plugin.
There is a wireshark plugin for USB traffic dumped from usbmon (http://wiki.wireshark.org/CaptureSetup/USB). If we keep the usbmon interface, that comes for free.
Then again, probably the initial focus should be to have the data
passing through the beagle (probably starting with a single device).
Maybe that is a good mid-term goal.
Indeed. I plan to start with simple devices, with limited number of endpoints, and slowly start to support different endpoint types (control/bulk, then interrupt, and finally isochronous).