Is there any USB 3.0 hub or device that multiple USB 2.0 devices can be connected to and still retain the maximum USB 2.0 bandwidth for each device by utilizing the higher bandwidth of USB 3.0?
These devices exist for USB2.0/1.1 interfacing (they are called Multi-TT USB hubs).
Are there any such devices that exist for USB3.0/2.0? What I'm trying to do is connect 3 high-bandwidth USB 2.0 cameras to one USB 3.0 port.
I've been personally trying to find details about this as well. I'm trying to get multiple USB based audio cards to MUX over USB 3.0.
So far the following two URLs are giving me my details:
http://www.via-labs.com/en/products/vl810/index.jsp
http://electronicdesign.com/embedded/what-s-difference-between-usb-20-and-30-hubs
-- 1 --
This is interesting because it shows a block diagram of the VIA VL810 controller chip. Unfortunately, it sure looks like the USB2.0 functions are completely seperate from the USB 3.0 sections. This leads me to believe that, at least this chip, and HUBs that use it, can not multiplex USB2.0 transfers over USB3.0.
-- 2 --
This site spends a lot of time talking about how the HUBs are suppose to work. It takes the time to explain that the USB3.0 bus is separate from the USB2.0 bus:
Within the hub, only the port power control logic is shared between the USB 3.0 path and the USB 2.0 path, since there is only one 5-V power path in either USB 2.0 or USB 3.0.
This leads me to assume that most if not all current USB 3.0 HUBs can't multiplex.
You comment about Multi-TT Hubs being available for USB 2.0/1.1 gives me hope that some time in the (near?) future we'll have the same ability with USB3.0/2.0.
Related
I need to attach 8 devices of the same kind (RFID readers) to the 8 positions of the USB hub. I need to recognize which reader is not plugged-in. I also need to know which exact device sends the data (based on the physical location)
I am aware of "a path" related to an USB plug. However, I am still a newbie in the topic. Are the positions at the USB hub numbered always the same way, or are the numbers in the path assigned based on when the USB device is plugged in? In other words, can I tell whether a specific position at the USB hub is connected or not? Can I reliably determine which device sends the data based on the communication path?
I am working on a hardware-embedded software project involving USB protocol. My plan is to use a USB3.0 Hub that clusters many USB2.0 isochronous devices, each requiring around 33 Mbps BW.
Now, I know that USB3 is able to enumerate up to 127 devices [1], what I'd like to know is whether this is true if I connect USB2 devices to the USB3 Hub. Can I, in theory, use the hub with 97 USB2 devices?
Also, could I utilize the entire BW (yes, only around 70% is feasible) of a USB3 port this way? The above figures add up to 5 Gbps*70% = 3.2 Gbps = 97*33Mbps.
Any help is much appreciated.
I believe there is some confusion with your understanding.
USB 3.0 hub contains 2 logical hub partitions.
1 - USB 3.0 hub
2 - USB 2.0 hub
USB 2.0 devices communicate through the USB 2.0 hub data path which has nothing to do with USB 3.0 data path. So the assumption of the bandwidth is incorrect as they are for USB 3.0 devices connected via USB 3.0 data path.
Also USB 2.0 devices will get connected via USB 2.0 lines and NOT USB 3.0 lines.
Another misconception in your question.
The speed which you mentioned i.e. 5 Gbps, that is USB 3.0 link speed.
What that means is that 2 devices over USB 3.0 link can send or receive data at 5 Gbps. Since every hub downstream port is physically a separate link, the link speed will be same for all i.e. 5 Gbps. So its speed between 2 link partners and not end to end speed.
Now when you say End to End data transfer rate, that will depend on your host controller driver architecture, your OS performance, your Hub, etc.
For Isochronous endpoints, the hub will start data transfer on service intervals for each endpoints on each port as per USB spec but you cannot be sure that End to End data transfer rate will be equally divided.
PS - You will get a lot less end to end bandwidth by the way as the link speed for USB 2.0 is 480 Mbps. :)
I need a software or application with API support to capture USB packet and data buffer. I would like to analyse the captured data using LabVIEW.
Suggest applications for usb packet and data capture with API support, so that I can access them using LabVIEW.
Or
Alternate methods to capture and analyse usb data using LabVIEW
I had tried a approach using logman.exe . But that doesn't log all the USB packets. Has anyone tried logman to capture the usb packets?
you can consider using VISA functions.
A few examples are shipped with Labview (open example finder and look for USB).
Here is a starting point giving instructions about how to give VISA access to the device.
You need find out some windows dll's and use it in labview. the examples provided for NI USB devices.
When reading about hardware/device independence this statement from wikipedia (http://en.wikipedia.org/wiki/Device_independence#Desktop_computing) states that:
The application software does not need to know anything about the hardware on which it was to be used. Instead it discovers the capabilities of the hardware through the standardized abstraction layer, and then use abstracted commands to control the hardware.
I wanted to know about the lower level interaction between the BIOS routine/device driver/HAL/OS and the device controller about discovering the hardware capabilities.
Kindly help me out to understand the communication between these entities that takes place which helps in hardware independence.
Hardware devices, normally, connect to the main controller through a standard bus of some kind.
For example - PCI, PEX, USB.
Each connected device on the bus will be allocated with a device #, bus #, function #, etc, by the bus controller.
Modern bus contollers either provide the main controller with the ability to perform a scan, or send an event when a device is hot plugged into the bus.
Per each discovered device, it is possible, using the bus controller standard commands (such as read/write registers of a device, by device ID, bus number, etc), to interrogate the device for details such as:
Manufacturer ID
Device ID
Class (controller / networking device / Human interface / imaging device / and so on)
Per bus type, all these details must be available in the same way for every connected HW device, thus enabling the OS to use an abstraction layer.
Once a device has been discovered and identified, the OS will call all the specific bus registered device drivers' probe function, which use the details mentioned above to decide if can handle it.
When a device driver probe succeeds, an instance of the driver is allocated and can be used directly by the application that needs to access the HW.
For example:
USB PC CAM connects to USB port. An event is sent to the main CPU by the USB bus controller. The CPU will use the standard USB bus controller functions to learn the manufacturer & device ID/s, device class, functions, etc, and will call all the USB registered device drivers probe functions.
If an appropriate device driver is installed (registered), it will successfully create an instance of the device and a video application (such as skype) can use it directly, through DLLs supplied by the driver SW.
Hope this helps.
I'm developing an embedded USB device which needs to be available to two different hosts.
The first is a normal PC, where it will be used as a MSC (mass storage) device, and the second is a specific hardware which the USB device needs to comunicate with a CDC profile.
during the enumeration, the USB device send descriptor table where it declares its capabilities.
Is there a way in the enumeration process to know to which host the device was connected to ?
The simplest solution perhaps would be to implement a "USB Composite Device", where the single device presented both the MSC and CDC class interfaces simultaneously. The host PC would see both interfaces, but you could simply leave one unused. The "specific hardware" would probably simply ignore the MSC class if it had no support for it.