Serial Interface Primer
Contents
A mercifully short serial primer covering:
Serial pin functions
Flow Control (CTS/RTS)
Spoofing Flow Control (CTS/RTS)
Start-up (DTR/DSR)
Spoofing DTR/DSR
Serial Comms - Asynchronous, Synchronous, and bit-synchronous
Balanced Serial Interfaces
Unbalanced Serial Interfaces
Our description of the use of DSR and DTR in the sections below was frankly misleading bordering on wrong. Thanks to Steve O'Brien for pointing out the error of our ways. Serial Signal functions
This is not meant to be an exhaustive description of all the signals used in serial communications but rather describes briefly the functionality of TD, RD, CTS, RTS, DSR and DTR signals to assist in building cables that, with a good following wind and downhill, will tend to work.
For the purposes of this primer we will concentrate on joining two Windows PCs (with great apologies to all us non windows desktop users) using a NULL modem interface (A NULL modem interface just means there is no modem) - via their DB9 ports using Asynchronous communications. If you are using real modems the principles are the same but you will need to consider additional signals such as DCD and RI. The Key point to remember is that both PC are DTE's (Data Terminal Equipment) and were originally designed to be connected to a DCE (Data Communication Equipment - typically a modem). Signal Spoofing is the process of convincing (fooling) both ends into having a sensible conversation when both think they are talking to something entirely different.
The Bare Minimum of signals
Yes you can build a cable with only three pins connected (TD, RD and SGND) see below and it may work (typically if 'Flow control' is set to 'none' in the Control Panel at both ends).
CTS/RTS - Flow Control
The above cable has no 'Flow Control' mechanism. 'Flow Control' describes the process by which one end asks for permission from the other end before its transmits data. In systems where traffic is one way only e.g. a mouse this is not an issue. However if you set 'Flow control' in the Control Panel at both ends to 'hardware' then the PCs serial chip will ask for permission to send data (by raising RTS - Request To Send) and waiting for clearance (CTS - Clear To Send) from the other end. A cable incorporating this functionality looks like this (we 'cross' the RTS and CTS signals).
It Gets Worse
Just as you think you understand everything, it can get worse. Suppose one end does not (or cannot) generate a CTS (e.g. 'Flow control' in Control Panel set to 'none') but the other end needs it in response to its RTS ('Flow Control' in Control Panel set to 'hardware')? Well there is no limit to mankind's ingenuity. We are going to create a cable that 'spoofs' the RTS/CTS by using a loop-back so that when one end raises RTS it immediately gets a CTS (actually its own RTS). In the diagram below PC1 needs RTS/CTS but PC2 cannot generate it (and does not need it).
Getting it all Started
Sometimes communication will only start when both ends detect the presence of an active terminal or device. This is usually done by waiting for DTR (Data Terminal Ready) from the other end (and which appears as DSR Data Set Ready) - or most unusually by waiting for DCD (Data Carrier Detect) indicating a synchronized connection. Systems that require DSR will typically also raise Data Terminal Ready (DTR) to indicate they are rarin' to go but are just waiting for the other guy. The cable below will provide this functionality (by crossing DTR and DSR).
Lets Wait - Forever
Now lets assume that one end does not (or cannot) generate DTR but the other end needs DSR before it will start to communicate. We will wait - forever - unless we get out the soldering iron and use our 'spoofing' technique again. In the cable below we assume that PC1 needs DSR (and raises DTR) but PC2 does not need either signal. In order to illustrate yet another technique this cable has also looped the DSR signal to DCD (Data Carrier Detect) as well as DTR. DCD MAY be required by very picky systems and will do no harm in any case. The DCD connection can be omitted.
Note: If DTR is NOT raised by PC1 in this scenario you have a problem because DSR and DCD require a permanent LOW (RS232 is an active LOW interface) and you will need a steady > + 3V < 12V low current source to provide it.
We Ain't Done Yet
It really can get worse than this. The permutations are almost endless (Ah! the joy of serial communications) but the above techniques should allow you to create the cable you need to get that sucker rollin'.
Synchronous, Asynchronous and Bit-Synchronous
A brief overview of the most common serial communication systems.
Asynchronous
Asynchronous systems are the most common standard for serial communications and include your classic internet dial up modem systems. Asynchronous systems are character oriented. They send one character at a time. Asynchronous systems assume that both ends of the link are configured EXACTLY the same and each CHARACTER has enough information to allow the receiver to figure out when a character STARTS and STOPS (there are auto-bauding techniques which use a repetitive character, normally e, to figure out the settings automatically).
Asynchronous systems allow a confusing number of variations including the number of bits in a character (5, 6, 7 or 8 bits), the number of stops bits used (1, 1.5 or 2) and an optional parity bit. Today the most common standard is 8 bit characters, with 1 stop bit and no parity and this is frequently shortened to 8-1-n (or even 8-n-1). A single 8 bit character using 8-1-n therefore consists of 10 bits on the line = 1 START bit, 8 data bits and 1 STOP bit as shown in the diagram below.
Asynchronous 8-1-n serial communications
Notes:
Because the individual characters are framed (they contain enough data for the receiver to detect the start and end), unlike all the other systems described below, no CLOCK data is required or sent between the two ends and hence the pin-count can be kept very low.
RS-232/V.24 use Non Return to Zero (NRZ) encoding on the line as shown above. In this encoding if the following character is the same no level transition occurs.
The gap between characters may be any length (hence asynchronous) and may be either mark (high) or space (low) as shown.
Synchronous
Synchronous systems are sometimes called block mode because communication is in blocks (not characters as in Asynchronous systems). Individual blocks are delimited with special characters called Control Characters, for example, in IBM Bi-Sync systems by STX (Start of Text), ETX (End of Text) and many others. In order to allow the receiver time to synchronise, the block is normally preceded with one or more SYN Control characters. The block is almost always terminated with a Cyclic Redundancy Check (CRC) which is normally 16 bits, but can be 32 bits long.
Synchronous systems transmit a CLOCK (actually two clocks one each for transmit and receive) with the data otherwise the far end could lose synchronisation during reception of a very long block (the transmitter and receiver clocks need not be exactly the same value). The requirement for a CLOCK signal means that Synchronous systems need to use a DB25 connector, a DB9 connector does not provide (and does not have enough pins for) a CLOCK signal.
Using 'special' or Control characters like STX gives us a little problem if we want to send data which includes a value that happens to be same as a STX. This problem is called data transparency. The bi-sync family of protocols provides for this by the use of a special Control character (DLE) placed before the offending character, so the sequence DLE STX is interpreted as a data character STX not a Control character (the DLE is discarded by the receiver) and STX without a preceding DLE is a 'real' STX. The same rule applies to any other Control character including DLE i.e. DLE DLE sends a transparent character with the value of DLE. Synchronous data transmission is shown below.
Synchronous communications
Bit-Synchronous
Bit-Synchronous system represent the pinnacle of achievement in the serial world. HDLC, X.25 and SDLC are the most common protocols that use Bit-synchronous techniques to ensure data transparency. Like their older Synchronous cousins Bit-synchronous systems transmit blocks of data and each block is delimited (starts and ends) with a special FLAG sequence of x'7E (01111110 in binary). To ensure data transparency bit-stuffing is used to make certain that a FLAG pattern (x'7E or 01111110 in binary) never exists in a data frame (block) or RATHER when it does, it CAN ONLY signify start or end of a data frame (block). The process works as shown below:
Note: We show a frame of 2 x 8 bit characters below for simplicity. Other than the flags there is no concept of character alignment ON THE LINE so the data could equally use 3 or 16 bit characters - obviously both ends must have agreed the format beforehand. The characters in red below have been added (bit stuffed) by the transmission hardware - or software if you are unlucky enough to be using Motorola's Coldfire - talk about walking backwards into the future.
Again like its older Synchronous cousin Bit-Synchronous systems always send a CLOCK with the data.
Unbalanced Serial Communications
Unbalanced connections use single connectors for each signal and a common ground. The signal level is relative to the common GROUND. Cheap (fewer pins) but susceptible to 'noise' and hence is almost always lower in speed than its grown-up brother the balanced connector. V.28, RS-232, V.10 etc are all unbalanced serial connections.
Balanced Serial Communications
Balanced connections use pairs of connectors for each signal. The signal level is relative to its paired connector NOT GROUND. More expensive than 'unbalanced' but much less susceptible to noise and hence very high data rates can be achieved reliably. V.35, V.11, RS-485 and RS-422-B are all balanced serial connections. Note also that it is only signals that change rapidly - such as TD and RD - that require the noise protection - most relatively static signal pins use a single pin even in balanced systems.
