P
Paul
DevilsPGD said:In message <[email protected]> Barry Watzman
Doesn't the USB interface require hotswapping at an electrical level?
Sure, you'll find cases where the device or driver needs notice to avoid
data loss, or but you're electrically safe to disconnect if needed.
Page 113 of USB20 spec
"The connectors are designed to be hot plugged."
If you pick up a USB flash drive, or even a USB cable,
you can see the outside (+5V and GND) contacts are longer
than the two center data contacts. That is a sign the
connector was designed for hot swap.
The ingredients of hot swap are
1) Ensure power and ground are established, such that
I/O signals are not damaged by phantom voltages coming
from the supply. (Particularly important if the hardware
is powered by -48V and the I/O is a much lower voltage.)
Making the contacts longer on some of the pins is how
you do that. This is just to illustrate what that might
look like. SATA has some pins longer than others, to sequence
what makes contact first, and ensure the sensitive pins
aren't exposed to out of bounds voltages. USB has this too,
if you look at a USB flash stick or USB cable contacts.
http://connector.almita.com.tw/rimages/304/SAAT-connector-02-B.jpg
2) Use "Failsafe" I/O pads, such that if one part of the
hardware loses power, the I/O pads don't provide a
sneak path. The sneak path can be things like diode
protection on I/O pads. The idea is the pads don't
inadvertently draw current when they're not supposed to.
3) Use a hot swap controller for power, to reduce the
transient when hardware is plugged in. USB doesn't
use this, and uses some design rules instead. The
host connector, has 100uF across +5V and ground, to
reduce the amplitude of bus voltage disturbance when
a device is plugged in. The guest device should have only
a small bypass cap used, since that cap needs to be charged
instantly. This kind of issue is detailed in an Intel document.
Failure to guard against the bus transient, can cause the
second USB on a stack to misbehave or have a data glitch.
USB devices are limited to 100mA before negotiation begins,
but that pales in comparison to a 5 amp transient caused
by charging a small capacitor inside the peripheral.
On hardware with major power consumption, and hot swap capability,
they gradually bring up the power on the module. That is
shown in the following document. But USB doesn't do this,
for reasons of economy.
(Hot swap design in a non-computer application. Mentions some issues.)
http://www.analog.com/library/analogDialogue/archives/42-05/hot_swap.html
The kind of I/O you're connecting to, makes a difference as well.
For hub architectures...
Host
/ | \
/ | \
X Y Z
the I/O may be independent of one another. USB works like that. When
something plugs into X, it doesn't disturb Y or Z. PCI Express
is like this too.
For bus based systems, it is much worse.
Host ---+---+---+
| | |
X Y Z
Plugging into "X" with the power on here, could glitch an ongoing
transaction on Y or Z to the host. Pre-charging the data pins to
half-rail before contact, is one solution. In general, this is
a much harder case to solve. Many sleepless nights if you do
something like this. PCI has a bus architecture like this, as
does the VMEBUS. PCI Express, on the other hand, is a hub, and
so doing a hot swap there, wouldn't upset a neighbor.
Designing for hot plug can either be extremely hard (bus based
system) or relatively easy. Getting the connectors right
is part of the battle. As far as I know, PS/2 has all
equal length pins, so there isn't any visible design intent
there for hot swap.
Having the OS recognize a hardware change, is a separate but
important issue. As an example, there are early SATA interfaces
that are quite capable of indicating a new drive is connected,
but because the driver didn't include any code (or maybe a
framework wasn't available to hook to), the hardware can't tell
anybody anything. For an event like that, either you can use an
interrupt, to indicate something has happened on a particular
interface. Or, the OS can poll the hardware at regular intervals,
to check for the presence of new hardware. An interrupt scheme
is preferable if available and if it is reliable.
Paul