Slashdot Mirror
USB To Go Wireless
Troy Samuel writes "The WiMedia Alliance is planning to make the technology known as 'ultrawideband,' or UWB, work among a wide variety of consumer electronics devices. Various organizations, including the Bluetooth SIG, have chosen the WiMedia Alliance's version of UWB technology as the foundation for a next-generation short-range networking technology." From the article: "UWB technology can deliver data rates at up to 480 megabits per second at around 3 meters, with speeds dropping off as the range grows to a limit of about 10 meters. Real-world speeds will probably be a little slower, but this is as fast as the wired version of USB 2.0 and much faster than current Wi-Fi networks are capable of transmitting data. 'This stuff is plumbing,' Roger Kay, an analyst with Endpoint Technologies Associates, said of the newer-generation wireless technology. 'It's important that it be there, it's going to be handy for getting rid of cables hanging around your desk.'"
For that matter, one of the benefits of USB is that power is delivered along with the data--how often do you change the batteries on your thumb-drive, or plug in your 2.5" external hard drive? So, directly compared to USB I still need the same number of cables, unless they're delivering power wirelessly too? Hmm...
----- Connection reset by beer
No, wait! It's back up with an annoying alert that it's connected again!
Wait, no, it dropped again.
I love this game.
symmetric peer-to-peer interfaces like that provided by Firewire.
Firewire actually has rather strong master/slave relationships; there's a tree, and a tree root, and a master node. But there's a negotiation process during hot-plugging which establishes the master/slave relationships.
One big problem with Firewire is that it doesn't have a notion of device ownership. You can plug two computers together with FireWire, and that will work if both machines support IP or Ethernet over FireWire. But plug a peripheral into the same bus, and there's no mechanism to allocate it to a unique host computer. You'll get a control clash.
Underneath, FireWire isn't really a "bus". It's actually a local area network, and its controllers work more like Ethernet controllers, with packets and buffer chains, than bus adapters.
The "bus" aspect is that there are defined packet formats for loading and storing 32-bit data items in a 64 bit address space. In practice, though, what usually happens is that at the host end, some code formats such a packet, saying "set bit 22 of register 0x2490 at node 3", and when that packet gets to node 3, some little CPU in the peripheral decodes the packet, acknowledges receipt of the packet, a switch statement decodes the "register" address, and code notes that bit 22 means "turn camera on". No status for this event comes back; the host has to send a packet to "read" some other device register to find out what happened.
Giving FireWire a "device register" model turned out, in the end, to be kind of silly. Something more like SCSI, with function codes and statuses, would have made more sense. (And, in fact, there's SCSI over FireWire.) You'd get back better status info, and devices which don't implement some functions would have a simple way to report that. This makes it easier to implement generic drivers, reducing the temptation to have to have a special driver for every manufacturer's device. And we all know where that leads.
So if you're designing something like this, don't go with a device register model. Anything smart enough to talk it will have a CPU, so use it.