|
In computers, a serial signal is one in which the bits of data of the digital code are arranged in a series. They travel through their medium or connection one after another as a train of pulses. Put another way, the pattern that makes up the digital code stretches across the dimension of time rather than across the width of a data bus. Instead of the bits of the digital code getting their significance from their physical position in the lines of the data bus, the get their meaning from their position in time. Instead of traveling through eight distinct connections, a byte of data, for example, makes up a sequence of eight pulses in a serial communications system. Plot signal to time, and the serial connections turns things sideways from the way they would be inside your PC.
Do you detect a pattern here? Time, time, time. Serial ports make data communications a matter of timing. Defining and keeping time become critical issues in serial data exchanges.
Engineers split the universe of serial communications into two distinct forms, synchronous and asynchronous. The difference between them relates to how they deal with time.
Synchronous communications require the sending and receiving system-for our purposes, the PC and printer-to synchronize their actions. They share a common time base, a serial clock. This clock signal is passed between the two systems either as a separate signal or by using the pulses of data in the data stream to define it. The serial transmitter and receiver can unambiguously identify each bit in the data stream by its relationship to the shared clock. Because each uses exactly the same clock, they can make the match based on timing alone.
In asynchronous communications the transmitter and receiver use separate clocks. Although the two clocks are supposed to be running at the same speed, they don't necessarily tell the same time. They are like your wristwatch and the clock on the town square. One or the other may be a few minutes faster even though both operate at essentially the same speed: a day has 24 hours for both.
An asynchronous communications system also relies on the timing of pulses to define the digital code. But they cannot look to their clocks for infallible guidance. A small error in timing can shift a bit a few positions, say from the least significant place to the most significant, which can drastically affect the meaning of the digital message.
If you've ever had a clock that kept bad time-for example, the CMOS clock inside your PC-you probably noticed that time errors are cumulative. They add up. If your clock is a minute off today, it will be two minutes off tomorrow. The longer time elapses, the more the difference in two clocks will be apparent. The corollary is also true: if you make a comparison over a short enough period, you won't notice a shift between two clocks even if they are running at quite different speeds.
Asynchronous communications banks on this fine slicing of time. By keeping intervals short, they can make two unsynchronized clocks act as if they were synchronized. The otherwise unsynchronized signals can identify the time relationships in the bits of a serial code.
Isochronous communications involve time critical data. Your PC uses information that is transferred isochronously in real time. That is, the data are meant for immediate display, typically in a continuous stream. The most common examples are video image data that must be displayed at the proper rate for smooth full motion video and digital audio data that produces sound. Isochronous transmissions may be made using any signaling scheme, be it synchronous or asynchronous. They usually differ from ordinary data transfers in that the system tolerates data errors. It compromises accuracy for the proper timing of information. Whereas error correction in a conventional data transfer may require the retransmission of packets containing errors, an isochronous transfer lets the errors pass through uncorrected. The underlying philosophy is that a bad pixel in an image is less objectionable than image frames that jerk because the flow of the data stream stops for the retransmission of bad packets.
|