Looking at the pins of USB 3.0 receptacles, I can see that there are separate transmission and reception pairs, however for USB 2.0 there is only one "data" pin pair. How does USB 2.0 ensure that the devices aren't communicating simultaneously?
\$\begingroup\$
\$\endgroup\$
2
-
2\$\begingroup\$ You might also be interested in looking at things like CSMA/CD, which is how it is solved in other contexts \$\endgroup\$– PlasmaHHCommented Feb 17, 2018 at 21:44
-
1\$\begingroup\$ Separate transmission/reception pairs don't solve all conflicts. Imagine you have a pendrive and a modem, they both want to send some data to the host, so they both start transmitting. Where? On the same pair: host receive. Conflict is still there. This is not how USB works, but this is exactly how 10/100 Ethernet works: every direction has it's own pair but "collision" light on the hub keeps blinking. \$\endgroup\$– Agent_LCommented Feb 19, 2018 at 14:08
Add a comment
|
2 Answers
\$\begingroup\$
\$\endgroup\$
9
USB is strictly master-slave. The device does not transmit unless the host tells it to transmit.
Even so called "interrupt" mode is really polling: for example, every 8 milliseconds (or less if you got a gamer mouse), the PC asks the mouse "what is your position" and the mouse replies.
Same if you have a USB-serial interface for example. When the interface receives data on the serial line, it will not transmit it to the PC. Instead it will wait for the PC to initiate the transaction and ask for the data.
This webpage has a good explanation about the packets that are exchanged. Basically, keep in mind that USB was implemented to allow the dumbest and cheapest possible peripheral to function, which means most of the intelligence is in the host, host usb controller, OS, and drivers. This is very apparent when reading the spec.
Firewire (for example) has a completely different philosophy, it is much more powerful, it's multi-master so devices can talk to each other without help from a host/master. It is actually much closer in its philosophy to something like token ring with isochronous transfers slapped on top, than to USB. However "multi master" means it requires a powerful microcontroller in the devices, running a complex software stack. It is therefore more expensive, and thus limited to expensive products like camcorders and fast hard drive enclosures. A firewire mouse makes no sense, it would be too expensive. That's one of the reasons why FireWire failed.
-
3\$\begingroup\$ Excellent explanation, and very fitting comparison with FireWire (and yeah, let's build a token-based arbiting network for ... realistically, at most 5 devices on a bus). \$\endgroup\$ Commented Feb 17, 2018 at 14:01
-
3\$\begingroup\$ This is a good answer, but I think it would be more complete if you mentioned enumeration. Discovering what devices are connected to a dynamic network with no arbitration capability (such as a multi-master network would have) is a non-trivial problem, and in many ways defines why USB cannot use a true bus topology. \$\endgroup\$– JonCommented Feb 17, 2018 at 14:13
-
\$\begingroup\$ Thanks;) I dont know the gory details about enumeration from the host side though. But IMO the real reason USB is like this is that it was designed in the mid-1990s and at that time microcontrollers were more expensive that today, and the way to cheap devices was to make them as dumb as possible with as little RAM and code as possible. Besides, it works very well, it kinda hit a sweet spot. \$\endgroup\$– bobfluxCommented Feb 17, 2018 at 14:20
-
6\$\begingroup\$ Incorrect, USB is a bus. It just has a different topology (star) as opposite to the more familiar "linear" bus. All USB 2.0 (HS) host transactions are broadcasted across all segments of the star, so it is not much different from the "linear" bus. Similar to the linear bus, all devices see the bus activity nearly at once. The only difference is that device responses are not visible to some other devices that are sitting on different branches. \$\endgroup\$ Commented Feb 17, 2018 at 17:15
-
2\$\begingroup\$ @rahuldottech it's decently cool if it works, but FireWire was much less reliable than USB, in particular WRT plug&play. And with USB, you can quite easily hook up many drives to a single port by using an extra hub. There's a performance tradeoff, but reliability and easiness trumps. \$\endgroup\$ Commented Feb 19, 2018 at 18:11
\$\begingroup\$
\$\endgroup\$
6
In USB framework devices can't communicate simultaneously, because they only "talk" when USB host "allows" them to talk. And USB host allows another device to "talk" only when the sequential transaction protocol with the first device is completed. And USB devices don't have any means to "talk" on their own, there is no active interrupt mechanism in the USB. In brief, the mechanism of implementing this discipline is as follows.
After USB 2.0 devices are connected, host enumerates them by assigning unique addresses to each device.
Every transaction on the bus is initiated by USB host.
Headers of every USB transaction carry specific device address. Even when the transactions are broadcasted over the entire USB tree (on the particular host controller instance), only the device with matched address would respond to the transaction, and either take the data, or respond with data.
The link "partners" then will send an acknowledge in the direction from who receives the data successfully. The entire transaction follows established protocol with defined sequence of tokens, time-outs, and error correction codes, to ensure integrity of the transaction.
All other devices are just listening and ignoring the traffic which is not directed to them.
That's about it, it is "half-duplex" interface.
answered Feb 17, 2018 at 13:52
-
1\$\begingroup\$ Not familiar with the USB protocol, so how does the host know the correct device responded? \$\endgroup\$ Commented Feb 17, 2018 at 17:41
-
\$\begingroup\$ @Derek朕會功夫, host knows this because this is the only device that is supposed to respond, no one else will respond. USB 2.0 transactions are "atomic", there is no deferred responses, everything relies on time-out. No timely response (uncompleted transaction) will result in re-try of it. \$\endgroup\$ Commented Feb 17, 2018 at 17:48
-
\$\begingroup\$ To follow up, my question is that since every device is connected to the same bus, what’s stopping me from pretending to be another device that’s also connected? \$\endgroup\$ Commented Feb 17, 2018 at 18:12
-
7\$\begingroup\$ @Derek朕會功夫: Nothing. That's why you don't plug in random USB keys you get from off-street markets. You can't trust them. \$\endgroup\$ Commented Feb 17, 2018 at 19:42
-
7\$\begingroup\$ @Derek朕會功夫, malicious intent aside, a USB device has to accept an address during enumeration, and another device will have a different address, all controlled by host. This is no different than when several memory modules are connected to a parallel bus, but each module responds only to address decoder/ chip select. And if two USB devices would accidentally respond (say, host screwed up with address assignment), there will be a mess of collisions on the bus, and no packet will pass CRC (which is attached to every USB token), and corresponding port will be disabled due to massive errors. \$\endgroup\$ Commented Feb 17, 2018 at 21:06