Technical info alert, so you might want to skip over.......
A white connector is in theory the ancient USB 1, while black is USB 2. The red port is probably indicating that the 5V power supply from that USB port stays active, while the host (PC,laptop) is suspended or asleep.
There is backwards compatibility between USB2 and USB3 and it really should work, but there are a number of issues with USB.
First, in some respects the "compatibility" possibly could be considered a bit of a con.
Up to and including USB2.x there were 4 "wires" involved. 2 power (5V and ground) and a single, bi-directional, differential signalling, communication pair (uses 2 wires). Bi-directional means that only one end of the link can talk at any given instant (i.e. only the PC or the peripheral can transmit (talk) at any one time). Being bi-directional is one of the factors that limits its speed.
USB3 added 5 more signals. 2 more differential communication pairs (2x2 wires) and an additional ground. This time the differential pairs are uni-directional. i.e. the PC sends and the peripheral listens on one pair and the peripheral sends and the PC listens on the other pair. This is one (there are others) factor that helps to increase the speed. It's a completely different standard to USB2. (e.g. the USB3 signalling scheme results in lower power consumption for a start)
You have effectively two different systems running side by side. I suppose the semi-smart bit is the fact that, for type A connectors at least, they managed to squeeze the extra five signals into the same connector form factor.
The way all this is handled by the hardware is that USB3 controller chips (and hub ICs and peripheral ICs) integrate a separate old USB2 controller along side a controller that can handle USB3. Two different systems running side by side, that to the user, sort of looks like one.
It not usually my area, but in the last few months, I've had to design a PCB with a USB3 hub on it. A microcontroller on the same PCB is connected up to the hub, but this microcontroller only has USB2 capability. So, it's just connected up to the USB2 signals on one downstream port of the USB3 hub. The USB3 signals for that port just remain unused.
When you plug a USB peripheral (device) into the PC (host), there's an initial process called "enumeration", used to get the device working. Various bits of information are exchanged. Involved with this are two items stored in the peripheral - VID (Vendor ID) and PID (Product identification). You can assume the VID is unique to each manufacturer (although there are some cases whether this may not be true) and the PID is unique to the product model (again, mostly true). There is also an optional serial number, which is unique to each individual device.
The serial number doesn't always get included in the peripheral. It's probably slightly easier to push stuff down a production line and not program in a serial number at the end.
This is kind of where some of the problems arise.
On windoze, When you plug the same peripheral into a different port on the PC, it will nearly always spend time loading, or trying to load, the driver again. This is probably because the serial number is not present and so it treats it as a completely new device. The reason it does this is, if you only have one of a device, everything would be fine, but should you happen to have 2 identical devices plugged in (i.e same VID and PID), well, without some means to distinguish which is which (i.e. a serial number), some buggy things would start to happen. I hate to admit it, but Windoze is trying at least, to make a good job out of a slightly bad situation.
Problems are also confounded by the way Windoze looks for and tries to load drivers, when it sees a "new" device.
All this is why plugging a device back into it's old USB socket will make it work again and why sometimes putting it into a new socket, can cause problems. Making the serial number mandatory may have reduced all this nonsense.
You can also have "fun" with the way COM port numbers get assigned to serial to USB adapters, but that's another story and fixable.
is this true?
A white connector is in theory the ancient USB 1, while black is USB 2. The red port is probably indicating that the 5V power supply from that USB port stays active, while the host (PC,laptop) is suspended or asleep.
There is backwards compatibility between USB2 and USB3 and it really should work, but there are a number of issues with USB.
First, in some respects the "compatibility" possibly could be considered a bit of a con.
Up to and including USB2.x there were 4 "wires" involved. 2 power (5V and ground) and a single, bi-directional, differential signalling, communication pair (uses 2 wires). Bi-directional means that only one end of the link can talk at any given instant (i.e. only the PC or the peripheral can transmit (talk) at any one time). Being bi-directional is one of the factors that limits its speed.
USB3 added 5 more signals. 2 more differential communication pairs (2x2 wires) and an additional ground. This time the differential pairs are uni-directional. i.e. the PC sends and the peripheral listens on one pair and the peripheral sends and the PC listens on the other pair. This is one (there are others) factor that helps to increase the speed. It's a completely different standard to USB2. (e.g. the USB3 signalling scheme results in lower power consumption for a start)
You have effectively two different systems running side by side. I suppose the semi-smart bit is the fact that, for type A connectors at least, they managed to squeeze the extra five signals into the same connector form factor.
The way all this is handled by the hardware is that USB3 controller chips (and hub ICs and peripheral ICs) integrate a separate old USB2 controller along side a controller that can handle USB3. Two different systems running side by side, that to the user, sort of looks like one.
It not usually my area, but in the last few months, I've had to design a PCB with a USB3 hub on it. A microcontroller on the same PCB is connected up to the hub, but this microcontroller only has USB2 capability. So, it's just connected up to the USB2 signals on one downstream port of the USB3 hub. The USB3 signals for that port just remain unused.
When you plug a USB peripheral (device) into the PC (host), there's an initial process called "enumeration", used to get the device working. Various bits of information are exchanged. Involved with this are two items stored in the peripheral - VID (Vendor ID) and PID (Product identification). You can assume the VID is unique to each manufacturer (although there are some cases whether this may not be true) and the PID is unique to the product model (again, mostly true). There is also an optional serial number, which is unique to each individual device.
The serial number doesn't always get included in the peripheral. It's probably slightly easier to push stuff down a production line and not program in a serial number at the end.
This is kind of where some of the problems arise.
On windoze, When you plug the same peripheral into a different port on the PC, it will nearly always spend time loading, or trying to load, the driver again. This is probably because the serial number is not present and so it treats it as a completely new device. The reason it does this is, if you only have one of a device, everything would be fine, but should you happen to have 2 identical devices plugged in (i.e same VID and PID), well, without some means to distinguish which is which (i.e. a serial number), some buggy things would start to happen. I hate to admit it, but Windoze is trying at least, to make a good job out of a slightly bad situation.
Problems are also confounded by the way Windoze looks for and tries to load drivers, when it sees a "new" device.
All this is why plugging a device back into it's old USB socket will make it work again and why sometimes putting it into a new socket, can cause problems. Making the serial number mandatory may have reduced all this nonsense.
You can also have "fun" with the way COM port numbers get assigned to serial to USB adapters, but that's another story and fixable.
is this true?
Last edited by a moderator:
