The move to Serial

[BCinSC]

I have some interesting USB connectivity issues. My Minolta/QMS 2300W really HATES being moved to another port. All the drivers reload themselves and then Windows XP gets all confused as to which is which and print jobs often go into limbo - really annoying. If I somehow mix up which of the 6 ports in back I once plugged it into, I purge all iterations and let it rediscover the one true instance. In addition, if I plug my MMC card reader in front port, I lose connectivity to same printer. Maybe bad drivers from Minolta, maybe crapping WinXP programming, maybe cheap-a$$ Dell computer. I dunno, but it sux.

Overall, I guess I'm bored with the multitude of interfaces, serial and parallel.
AGP, PCI, PATA, SATA, USCSI, Floppy, PS/2, Serial, Parallel, USB, FW,

I once had a system that was SCSI only. Hard Drive, Floppy, Scanner, Printer, and anything (SCSI) you wanted to attach. Keyboard was regular DIN-5 and Mouse was Serial, so not completely universal, but I still miss it.

Of course, original Apple Macintosh had that one universal port that KB, Mouse, Printer, Appletalk network, and everything else plugged into.

 

[Pariah]

The solution, is to not supply power through the connector, beyond the bare minimum, and make the device supply its own power as it does now. You will never be able to supply enough power for a laser printer through a peripheral cable. Most manuals recommend you have a dedicated wall socket for a laser printer. You standard 7200RPM ATA drive will draw 30+ watts at spinup, which is why SCSI controllers have options for delayed spin ups so you don't kill the power supply trying to spin up half a dozen drives at once. The reason external interfaces don't supply more than about 12W's now is because in order to power any useful peripherals that can't be now would take a significant increase in power. With 20W's, you're not going to power anything new except a dozen keyboards.

 

[Matthias99]

The reason to use two is to keep power supply as simple as possible. There are many devices that use power and are 100% USB powered (mice, some scanners, some rare printers, etc). Plug too many in and you get serious problems (there have been threads of this around here).

Lets make up numbers here. Suppose this new universal connection had devices that use up to 20W each. Lets say we have 8 connections (about typical with USB now). Thus that connector needs to be able to provide 160W of power. That isn't going to happen. What do they do now? Provide less power (say 50W for a nice number) and hope the user doesn't plug in too much. What if the user overloads? Who knows it probably leads to a bunch of problems. Scanner uses too much power, and mouse stops working for example.

Splitting it into two categories would help. Instead of providing 8x20W, provide 6x5W and 2x20W. Or mix the numbers however you want. Then when the scanner and printer take up too much power, the user still has control over the mouse and keyboard to shut things down in the software.

One might also argue that you should budget your power better -- if you provide 8 ports with 20W max draw, you SHOULD be able to plug 20W devices into all of them, as long as the power supply can handle it. Or, if you say "we provide 8 ports with 20W max draw each, and an overall draw of 50W", and the user plugs in 100W worth of stuff and it doesn't work -- well, they should RTFM. Or, even better, each device should *know* how much power it can draw, and the system should prevent you from turning on too many high-drain devices.

Repeat with bandwidth. If one device or combination of devices was hogging too much bandwidth, it'll be nice if the mice/keyboard still function so you can pause one program until the bandwidth logjam is fixed.

Actually, serial connections are almost always point-to-point, with some sort of central controller that manages the connections. You can use quality-of-service techniques at a hardware level to ensure things like this don't happen (as is done with networking technologies like Ethernet, at least with decent routers and switches).

 

[BCinSC]

Time to bring this back to foreground...