Re: Why do not CRT/LCD monitors come with USB?



phil-news-nospam@xxxxxxxx writes:

On Thu, 24 Jul 2008 11:36:44 -0600 Joe Pfeiffer <pfeiffer@xxxxxxxxxxx> wrote:

| phil-news-nospam@xxxxxxxx writes:
|>
|> We need a new kind of interface. Existing ones like USB, Firewire, and SATA,
|> were designed for specific purposes original and were, or will be,
|> repurposed
|
| Ummm, USB? USB most definitely designed from the ground up to be used
| for a wide variety of devices.

It started as an interface to attach phones. Then it was added on to do
a few computer input devices. It wasn't until USB 2.0 that speed finally
became practical for things like disk storage.

Huh? That's the first time I've ever seen anything even resembling
that claim. It was intended for exactly what it's good at: replacing
interfaces for things like keyboards, mice, and printers. Do you have
a cite?

USB had to completely change the way the OS drivers worked to go to 2.0.
It wasn't simply a case of being faster within the same protocol. It had
to change the protocol, too. The next speed higher will require a new
protocol.

But it is just a case of being faster within the same protocol.
It's true that there's an extra negotiation required to go to
hi-speed, but once you're there it's the same protocol. I'd have to
spend more time than I want to to see whether the driver stack was
re-written at the same the EHCI driver was added.

A better design would be an interface between driver and hardware that just
goes faster when the hardware can deliver faster. The driver gives the
command to send a message and in the newer faster model, the interrupt for
completion of command comes back sooner. The meta registers that tell the
driver what speed would have a HUGE range capacity (like a 64-bit number)
beyond anyone's imagination.

So long as the hardware can reliabily report what that speed is...

USB also slows down substantially through hubs. It can't keep data moving
along and switch it in the hub at the same time.

I'm not aware of anything in the protocol that makes wormhole routing
impossible...

USB device addressing is flaky in design. Plug in a disk, unplug it, then
plug the same disk back in to the same port, and it has a different address.

Whether that's flaky is a matter of opinion -- the intent is that a
non-savvy user can unplug a disk, plug it into a different port, and
have the OS recognize it's the same disk. To do that, you have to
decouple the device addressing from the port it's plugged into; once
you've done that, there's no reason to treat same-port as a special
case.

USB is not very graceful in hotplugging. It can't figure out what is going
on instantly. Firewire beats USB big time, and even Firewire is poor.

Most of that time is just allowing the device to settle.


|> for other things. That's really not very good design. Something that is
|> designed to allow _any_ kind of devide from the outset, with _standard_
|> protocols included for a large variety of device uses (only ONE driver is
|> needed for any one class of device, regardless of manufacturer or
|> model),
|
| A compliant USB device of a particular class can be used with a
| generic driver. The device may implement additional functionality
| which requires a special driver, but core functionality can be
| accessed without it (yes, I know Windows tends to not realize this.
| That's not a weakness in USB).

So why does the old OHCI driver not "just work" at faster speeds when a faster
USB port is used with a faster device? Why are there different drivers.

Because the old OHCI (and UHCI) devices didn't talk hi-speed. You'd
have to ask Intel why they developed EHCI instead of a faster OHCI,
but that's completely unrelated to your claim. A new driver was
needed for a new interface chip.

When 3200 bps USB comes out, will the same existing driver work even at the
new speed?

I don't know -- was the EHCI device designed with the needed headroom?

Yes, there are standards for many devices on USB. But there still appear to
be a number of issues. Maybe manufacturers (like Seagate) just don't do USB
right? Why even give such leeway? Apparently there is a lack of specification
on disk drive spin down in USB.

I don't know enough details on that -- it may indeed be a function not
covered in the spec.
.



Relevant Pages