Start • USB Medicine Show • Good USB Medicine • Popping USB Pills • Relief • How Do You Feel? • Sources and PDF

USB MEDICINE SHOW

Dr. Bob’s first piece of USB medical advice had nothing to do with code or USB hardware. He said part of my pain was the direct result of incorrect thinking. Basically, I had become accustomed to the ways of RS-232. In my mind’s eye, I had been attempting to equate RS-232 programming and RS-232 hardware to USB programming and USB hardware. But there’s little that an RS-232 and USB design have in common. They’re both intended to deliver data across a bidirectional link, but that’s about it.

So, Dr. Bob began by pointing out that RS-232 hardware is more complex than USB hardware. In the USB world, there are no DTE and DCE devices to contend with, he explained. Four wires and a standard set of well-defined USB physical connectors replace the multiple combinations of male and female nine- and 25-pin shell connectors used by RS-232.

To relieve the obvious USB stress I was experiencing, Dr. Bob reminded me that by using USB instead of RS-232, I could power my hardware via the USB connector. As a result, I could talk to multiple USB peripheral devices from a single PC with relative ease. But before I could offer up a retort, Dr. Bob cut in. He asked how much current I could really pull from an RS-232 port. He also asked how much hardware would be required to make any sort of RS-232-based power supply happen. I had nothing to say, so I kept my mouth shut.

Dr. Bob went on to say that there are few if any application restrictions associated with replacing RS-232 applications with USB equivalents. That’s because almost any RS-232 application can be converted into an identical USB application. To drive his point home, he asked me to describe a simple RS-232 application from a programmer’s point of view. 

In my reply, I stated that the first order of business is to declare the interface type that will be associated with the RS-232 peripheral. I normally designate the RS-232 peripheral as the DCE device, I explained. Thus, I can avoid using a crossover cable to communicate with the host PC, which is normally configured as DTE. If the RS-232 peripheral’s application demands the peripheral hardware to stand alone, I wire the peripheral’s RS-232 interface for DTE. The DTE interface enables the RS-232 peripheral to directly connect to DCE devices such as modems or other DCE-wired peripherals. 

Dr. Bob smiled wryly and nodded his head in agreement as I moved on to the logical side of my RS-232 design philosophy. I told him that I always account for the unreliable nature of RS-232 communications. I tend to write code that verifies the send-and-receive process at both the peripheral and PC ends of the link. In the process, I continued, I also include mechanisms to catch unexpected transmissions from either side of the RS-232 link. 

 Dr. Bob then interrupted: “So, you write what for all intents and purposes is a specialized protocol for every RS-232 design you implement?”

I had never quite thought about it that way. The only answer I could come up with was “Yes.”

Dr. Bob seemed curious as to why I hadn’t experienced any pain having written RS-232 code for so long. He insinuated that I was a RS-232 junky forced to design and build more complex communications hardware. I was writing complete protocol stacks for every new RS-232 application.

“That just doesn’t make any sense,” he said, just before reiterating that USB is built around a stable standard protocol. It doesn’t require the hardware effort of a typical RS-232 design. 

In my defense, I tried to point out that adding some extra traces and an IC to my unique RS-232 designs was far easier than writing USB descriptor table entries and USB device drivers for Bill Gates’s Windows. But Dr. Bob just laughed as he wrote me a prescription for Trace Systems’s HIDmaker FS.