Author Topic: USB Compound device in software  (Read 9899 times)

sdzienge

  • Member
  • ***
  • Posts: 1
USB Compound device in software
« on: January 09, 2018, 09:37:15 am »
Is it possible to create a compound device using a general puprose micro-controller or am I limited to a composite device without dedicated hub silicon?

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB Compound device in software
« Reply #1 on: January 09, 2018, 12:21:29 pm »
I believe you need dedicated hub silicon.

benlunt

  • Member
  • ***
  • Posts: 1
Re: USB Compound device in software
« Reply #2 on: January 09, 2018, 09:57:14 pm »
Hi everyone, Hi Jan,

Long time reader--first time poster.

Anyway, I was thinking about your question.  I have made a few simple devices using an ATTiny2313 with the USB being emulated by V-USB.  (V-USB can be found at https://www.obdev.at/products/vusb/download.html)

Since the communication is all emulated, I would bet that if your micro-controller had more memory and more space for code than the ATTiny2313, I bet that you could emulate the Hub and then the two devices.

You will never plug anything else into it, nor will you ever remove a device.  i.e.: When you plug the physical device in, all three devices will be attached.  Then when you unplug the physical device, all three devices will be unplugged.  Correct?  Also, all three devices, the emulated Hub, and the two devices, will all be the same speed, correct?

I think that you can emulate the Hub, then catch all of the device packets that a hub would normally pass through to the attached devices.

If all devices are the same speed, then there is no need for the Transaction Translator of the hub.  It would normally just be passed through using the Repeater.

Please note that I haven't actually tried this, but I thing it could be done if you are emulating all three devices as V-USB does for one device.

Anyway, Jan can correct me if I am wrong here.  The only thing I think might throw a wrench into this idea is the physical indication of the two devices being attached, though the Hub returns the status of this in packets, which is easily emulated.

Another idea is that you don't have more than one device.  You only have one device, but use an "address" type field in all communication, indicating which device (which of the two you have) uses it.  Kind of like LUN's in SCSI devices.  All Control Pipe packets have one address, the USB address assigned by the Host, but all Bulk, Interrupt, and/or ISO packets have a header describing which of your two devices this information goes to.  One of the "devices" uses the information while the other ignores the information.

Again, long time reader--first time poster, and enjoy reading these posts.  Since I have studied and written my own book on USB, I enjoy reading Jan's USB forum and her informative responses.

Thank you,
Ben

P.S.  If you are interested, and if Jan doesn't mind, I have Appendix Q of my book freely available at http://www.fysnet.net/docs/appendixq.pdf which explains the small devices mentioned above.

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB Compound device in software
« Reply #3 on: January 10, 2018, 09:22:25 pm »
The main limitation is that the hub must be able to repeat any data or status codes heading to or from device endpoints without significant delay (and thus typically is handled in hardware).

The other idea you mention, "one device," is similar to a composite device, where communications use the Setup stage (endpoint zero) or an interface number (other endpoints) to specify a function within a composite device.

Also note that HID-class devices can have multiple functions where each function is a Collection (Application) item in the HID report descriptor.

I think I've seen low-speed devices implemented in firmware but can't recall any compound firmware devices (doesn't mean it's not possible).

All, Ben's book is:

USB: The Universal Serial Bus (FYSOS: Operating System Design Book 8)