|
Design FeaturesFebruary 3, 1997 |
Richard A Quinnell, Technical Editor
My recent hands-on project about designing with USB generated a big response, including lots of questions, from EDN's readers. Here's a compilation of the best questions, along with my responses.
I read "USB: a neat package with a few loose ends" (EDN, October 24, 1996, pg 38) with interest, and I'd very much like a follow-up article on the finished, and hopefully expanded, project. I'm particularly interested in the software aspect of USB applications.
An expanded project is in the works. Expect an update in EDN's June 19, 1997, issue.
Your article made USB sound like a way of replacing add-in cards for data acquisition. I thought USB was a peripheral bus.
USB is a peripheral bus. It collects all those cables out the back of a PC into a single four-wire connection, and it lets you attach various peripheral devices, such as mice, joysticks, and keyboards. It also allows live insertion; the PC automatically accepts and configures new attachments. USB also is suitable for higher-performance peripherals, such as digital audio speakers, printers, and telephony equipment.
USB's performance and capabilities open the door for other uses, however, and that's what my article was exploring. More of EDN's readers design embedded systems than keyboards and mice, so I approached USB from the viewpoint of a designer looking to exploit its capabilities for a data-acquisition project. Because USB wasn't designed for such an application, this approach seemed a good way of pushing the technology to find its limits.
Why does everyone refer to USB as a slow bus? At 12 Mbps, it's faster than Ethernet, and no one thinks of Ethernet as slow.
Compared with emerging connection technologies like Firewire (1394) and Gigabit Ethernet, 12 Mbps can seem slow. But you're right; USB is more than adequate for its intended purpose of attaching peripherals to a single system.
We also talk about low-speed USB when referring to its 1.5-Mbps signaling mode. USB has two signaling modes: full speed (12 Mbps) and low speed (1.5 Mbps). The low-speed mode allows peripheral designers to lower the cost of USB devices that don't need high performance. For example, a low-speed peripheral doesn't need shielded cable for attachment. Thus, references to low-speed USB aren't criticism, but simply discussions of this particular communications mode.
Your article doesn't talk about how a USB device communicates with the host.
I must not have been clear. The host sends the device a message that asks the device to send any information it has ready. The application software must initiate that request through the host.
I read that a USB device can't initiate communication with the host. How can a data-acquisition peripheral "report" data to the host PC efficiently?
That's the responsibility of the application program. It needs to make sure that requests occur as often or more often than the sample data rate. Alternatively, the peripheral can buffer data, sending blocks instead of single samples. Then the application can take in data at a more leisurely pace. It's up to the application to prevent buffer overflow.
Can a USB host broadcast messages to a specific USB device? Can traditional serial ports coexist with a USB port on the same PC?
Yes to both. USB is an independent bus. As to getting messages to a specific device, that's what the address field is for. Each device, and each register/buffer within each device, has its own address. The first thing a host does when sending a message is to put out the address. Only one USB device will respond.
USB works on the concept of "pipes." When the host initializes a USB device, the two negotiate the establishment of pipes between host and device. Because each device has its own address and subaddresses for regions within the device, the effect of establishing all these addresses is that the host has a way of directing communications to a specific section of each device. As though there is a pipe from the host to the device's internal registers, data flows between the two completely isolated from everything else.
How do you program serial devices (with serial port addresses or port numbers)?
When you first plug in a device or boot the host, the host assigns an address to each device. The device must tell the host what subaddresses the device has and what kind of transfer pipes it needs, but the initial address is assigned by the host. If two identical devices are on the bus, the host assigns them unique addresses, but doesn't otherwise distinguish between them. You can't control what address each device receives. The application software needs its own methods for distinguishing among identical devices.
For example, if you have four identical data-acquisition devices on the USB, monitoring oil, water, vinegar, and herb flow into a salad-dressing blender, the host has no way of knowing which device connects to which data source. It assigns them unique addresses, but the application program must determine for itself which address corresponds to oil, water, and so forth. The host has no way of knowing.
What's the difference between bulk and interrupt data transfers?
Interrupt transfers occur every N frames (less than once per frame) and can retry if the data gets corrupted. The occurrence is regular and doesn't need scheduling by an application program. Bulk transfers can occur more than once per frame to the maximum bandwidth available. The application program must request the transfer whenever it's needed.
Based on Table A in your article, is 1024 kbytes/sec the worst-case achievable bandwidth for a 64-byte packet for bulk transfer?
No, it is the best you can do under worst-case conditions. There is one other variable that I couldn't take into account: the host delay. Without knowing how long it takes the host system to initiate a second transfer following the first, you can't be sure. That's what Figure B is trying to illustrate.
Another factor to consider: The table assumes that the bulk transfer is the only thing going on. If there is other bus activity, the available bandwidth must be split among all users.
What does isochronous mean? People refer to it but I can't find a definition anywhere.
The American Heritage Dictionary defines isochronous as "characterized by equal intervals of time." In the context of data communications, isochronous refers to the need for data delivery to occur at the same rate as data generation. A text-file transfer doesn't need to be isochronous; if e-mail is a few seconds late, or comes in bursts, who cares? However, if your television video ran at 10 frames/sec one minute and at 50 frames/sec the next, you'd find it intolerable. Thus, video data is isochronous.
USB includes an isochronous mode to handle data like audio and compressed video. This mode guarantees bandwidth across the bus, in place of offering delivery guarantees. If there's a data dropout, you get snow on your TV. It doesn't wait for a retransmission of the missing signal.
When should we use isochronous transfers? Which type of data transfer is best suited for reliably transferring megabytes of data?
Isochronous transfers are for data types that require timeliness, but that can tolerate lost data. Audio is a perfect example. Most audio playback schemes have ways of handling data dropouts, but cannot tolerate delays. The ear will forgive occasional noise, but not interruption of the sound.
To reliably transfer data, you need the bulk transfer. Just be aware that it won't give you a guaranteed data rate when bandwidth is limited, and you might need to do retries.
USB is like the Internet in this regard. You can stream data and accept the occasional losses, or you can guarantee data and take whatever time it needs (Reference 1). Only you can decide what your application needs.
Thanks for the coverage on USB. It would be interesting to also see an in-depth article on Firewire, another serious contender in the serial arena. A detailed comparison between USB and Firewire would help engineers tremendously in understanding these emerging standards.
EDN technical editor Maury Wright has written such an article (Reference 2). If you don't have that issue, look for a copy on our Web page: www.ednmag.com.
You can reach technical editor Richard Quinnell at (719) 530-0560, fax (719) 530-0560**, ednquinnell@mcimail.com.
| EDN Access | Feedback | Subscribe to EDN | Table of Contents |