Skip to main content

Serial Communication: the Ins and Outs of RS-232

computer com port RS232

A physical COM port (in the centre). A look at the back of any pre-USB era PC or laptop will reveal the 9-pin D-shaped chassis plug of a DTE RS-232 serial data COM port. Note the same-sized connector to the right – it’s a chassis socket for VGA video output – a high-density, 15-way version.

When this blog post was first proposed a few months ago, it was supposed to cover the rather narrow subject of ‘flow control’ and ‘handshaking’ as applied to asynchronous digital communication. Until recently, when I incorporated ‘RS-232’ links into the designs for vintage paper tape reader and teleprinter interfaces, the last time I worked with this communication format was back in the early 1980s. I remembered what an awful job it was; just designing the cable was a cause of much frustration as hardware documentation included strange acronyms like ‘DTE’ and ‘DCE’, and phrases such as ‘’straight-through’ and ‘crossed’. The original Recommended Standard RS-232C, specified line voltages, impedances, and the signal functions and names for a specific type of link – keyboard/display terminal to modem. Adapting it for other purposes led to, at best, confused, at worst, error-strewn documentation, with daft ideas propagating through to the present day. The following is an attempt to straighten things out a bit. If anyone knows better, please comment and straighten me out!

Computers, from mainframes to micros, have always needed to transfer data to and from peripherals (slowly) or to exchange data between processors (rapidly). In the early days, the main requirement was for a one-way interface between the computer and some sort of printer. There was a plentiful supply of telegraphic teleprinters around, working with two-wire connections and asynchronous serial protocols. Mechanical teletypewriters use to send and receive messages directly from the high-voltage telegraphic circuits. With the arrival of so-called ‘glass teletypes’ – electronic keyboards attached to CRT display units - it was realised that a big increase in data rates was possible. Even more exciting was the prospect of computers physically separated from each by hundreds of miles ‘talking’ to each other. The snag was that the telegraphic lines could only handle low signalling frequencies. Telephonic channels (PSTN) however, had a bandwidth of about 8kHz which would allow much higher signalling rates to be achieved. But you can’t just shove a digital signal into a ’phone line; the sharp-edged pulses contain very high harmonic frequencies way above the line’s bandwidth limit.

Modems and the RS-232 standard

The early Modulator-Demodulator equipment or Modems converted each of the ones and zeroes of the serial data to bit-length bursts of a carrier signal in the audio range. The technique is known as Frequency-Shift Keying or FSK modulation. For example, one standard was called Bell 103 that used four frequencies for full-duplex operation:

Originator modem: Mark (logic 1) = 1270Hz, Space (logic 0) = 1070Hz

Answering modem: Mark = 2225Hz, Space = 2025Hz

These audio frequencies fitted comfortably into the available telephonic bandwidth and enabled a data rate of 300baud to be achieved. An earlier standard had a baud rate of 110 which allowed the first mechanical teleprinters with 7-bit ASCII character sets to communicate via the PSTN.

So where does RS-232 fit in? The original standard defines the signals needed for a serial communication link between Data Terminal Equipment (DTE) and Data Communication Equipment (DCE). DTE can be a teleprinter, a dumb terminal, or a computer. DCE is an interface with the communication network, usually a modem. Twenty-five different signals are described in the standard! Fortunately, most basic applications require as few as three; or five if flow control is needed.

RS232 Comms wiring

The ’classic’ arrangement for RS-232 channel hardware linking DTE to DCE is shown in Fig.1a. In this example only five signals are used: Tx data, Rx data, RTS, CTS and Ground. Early implementations used 25-way D-subminiature (D-sub) connectors, which also featured on the first generations of PCs providing access to the serial COM ports as they were known. IBM quickly realised that for most purposes, a subset of the signals defined in the standard would suffice, and so the 9-way DE9 connector replaced the DB25 fitted hitherto (Fig.3). Notice that the correct notation is DE9, not DB9 as frequently found on equipment datasheets. The letter specifies the physical size of the shell required to house the connector terminating a cable.

DE9 Pin Outs


Design conventions

With all the possible permutations of plugs, sockets and signals available, equipment made by different manufacturers could (and did) end up being incompatible communication-wise despite apparent adherence to RS-232 rules. Most eventually settled on some agreed conventions:

  1. The DTE was fitted with a chassis plug. Conversely, DCE used a chassis socket. Initially, both were DB25 format then DE9.
  2. Signal wires were allocated to particular pins (2). Note the pin number order is reversed between the plug and socket. When a plug is fitted to a socket, the pin numbers all line up: pin 1 to pin 1, pin 2 to pin 2, and so on. That’s why the standard cable for an RS-232 link is described as ‘straight-through’ with a plug at one end and a socket at the other.
  3. The pin-to-pin correspondence would appear to mean that outputs are connected together; the same with inputs. That doesn’t happen because the Tx pin on a DTE module is an output, but an input on a DCE. See the table in 2.
  4. It would be nice to say that the actual signals used were the same for all manufacturers. Unfortunately, apart from Tx, Rx and Ground, it was a free-for-all, and any owner of a shiny new serial printer had to find out for themselves how its interface was wired, and make a compatible cable before they could print anything!

RS-232 communication now

For an introduction to the basic asynchronous serial communications take a look at article: Catching a Bus: Basic Serial Communication Part 1, the UART. Since the much more powerful USB replaced the COM port on PCs, you might have assumed that UART/RS-232 low-speed communication would have disappeared from the scene altogether. While USB dominates local connectivity between computers and peripherals such as printers in domestic and office settings, RS-232 is still widely used in electrically noisy industrial environments where robustness is given a higher priority than speed. Fortunately for the design engineer, manufacturers of development boards such as MikroElektronika and Digilent include DCE RS-232 driver modules in their Click (174-5607) and Pmod (134-6444) ranges respectively. Annoyingly, since PCs no longer sport a DTE COM socket, nobody seems to make a DTE module, leaving the designer no choice but to use another DCE unit plugged into the MCU development board. This means that the normal ‘straight-through’ cable must be replaced by a ‘crossed’ type. In summary:

DTE to DCE RS-232 connection requires: DE9 Female to Male Straight-Through cable

DCE to DCE RS-232 connection requires: DE9 Male to Male Crossed cable

DTE to DTE RS-232 connection requires: DE9 Female to Female Crossed cable

The availability of inexpensive, short-range wireless modules has seen RS-232 cabling largely replaced by Bluetooth and Wi-Fi. Direct TTL-level signalling between UARTs for inter-board or inter-chip links is still popular for embedded applications. For instance, many commercial wireless modules use a UART channel to communicate with the on-board microcontroller. Hence, current microcontrollers feature at least one on-chip UART, often two or three. Early versions had no flow control circuits, but now most offer RTS/CTS handshaking, greatly simplifying the task of designing a data link.

Flow Control

Not all applications require flow control. For example, a remote weather station that sends small amounts of data back to a base station at a low-data rate via wireless link. The receiver’s wireless module transfers data over a UART link to a microcontroller (MCU). The MCU can easily process each byte as it comes in without any need to halt transmission.

Terminal to Modem Hardware Flow Control – DTE to DCE

The original application for RS-232 communication – a link between a keyboard terminal and a modem - required the ability of the modem to stop or prevent the terminal from sending data out when a message was coming in from the remote terminal. Why this half-duplex operation when the hardware could handle data moving in both directions at the same time – sending messages from the keyboard while displaying/printing incoming text? It’s the human-machine interface (HMI) that’s the problem. When you type on a keyboard, you expect the characters to appear on the display, or the printout. This is called typewriter mode. But the keyboard circuits are not connected to the printer side, so the ‘local echo’ is sent back from the remote terminal, and that might cause a problem if the remote terminal is trying to send its own keyboard input at the same time. Hence RTS/CTS at your end perform a ‘handshake’ to block keyboard data being sent out if the modem is receiving data from the distant terminal. Note this only works to stop data movement from DTE to DCE.

The handshake is quite simple:

  1. Pressing a keyboard key causes the DTE interface to assert Request-to-Send by taking RTS low.
  2. If the line from the distant terminal is idle, the DCE will assert Clear-to-Send by taking CTS low.
  3. The DTE sends a character to the DCE which is then passed on to the remote terminal. It continues to send the rest of the message while CTS is low, and then de-asserts RTS by taking it high.
  4. Should the DCE start receiving a character from the remote terminal, it will immediately de-assert CTS, but the DTE will only suspend transmission after it finishes sending the current character.

This form of flow control is called handshaking because both DTE and DCE each have to assert a control signal, RTS and CTS, before a data transaction can take place.

PC to PC Hardware Flow Control – DTE to DTE

When desktop computers arrived, they featured at least one DTE socket on the back panel, known as a COM port. This allowed the computer to drive a DCE modem and connect with other distant computers. At a local level, it allowed two PCs to be connected together directly by cable. Desktop software was now capable of generating large data files, stored on increasingly large hard disk drives. The problem was: how do you transfer a multi-megabyte file from one computer to another when the only portable storage devices available (floppy disks) had a maximum capacity of a mere 1.44MB? A piece of software called LapLink became very popular – they even included the necessary COM port cable in the box!

The snag: the connection was no longer DTE to DCE. It was, of course, DTE to DTE. The solution was simple: replace the male-female straight-through cable with a female-female ‘crossed’ cable, where Rx/Tx signal wires are transposed in one of the cable’s connectors, as are RTS/CTS (Fig.1b). This gives us a symmetrical arrangement for data movement in both directions each with a single flow control signal. In other words, we have full-duplex operation. These are the steps of flow control enabling PC1 to receive data from PC2. The same procedure is followed for PC2 receiving data from PC1.

  1. PC1 asserts RTS low indicating to PC2 its readiness to receive characters.
  2. Finding its CTS input low, PC2 begins sending a character to PC1, if its transmit buffer contains something to send.
  3. PC2 continues sending characters all the while its CTS remains low.
  4. If PC1 cannot accept a further character beyond the one currently in transmission, it will de-assert its RTS taking PC2’s CTS input high.
  5. PC2 will suspend transmission to PC1 after the current character has been sent.
  6. If and when PC1 is ready for more, it returns to Step 1.

MCU to Peripheral Hardware Flow Control – DCE to DCE

As suggested above, short DTE-DCE RS-232 links between two MCU development boards is problematic because the plug-in interface modules available (that I know of) are all DCE format. It just means you need to use a male-male crossed cable and proceed as for a DTE-DTE connection. That’s what I used in my project to link the interface for a vintage a paper tape reader to a host MikroElektronika Clicker 2 MCU board. I should point out that the precise operation of any flow control is not defined as part of the RS-232 standard, and you should check the MCU manufacturer’s datasheets as to how RTS and CTS are manipulated by their on-chip hardware. That said, I believe most use the scheme for DTE-DTE communication outlined above.

MCU to Peripheral Hardware Flow Control – No RS-232

This is the arrangement used in the embedded world of microcontroller boards with plug-in sensor and wireless modules. Each of these peripheral modules often has ‘intelligence’ in the form of its own MCU pre-processing data and communicating with the host MCU via a very short UART link. In this case, the RS-232 line drivers are dispensed with and signals remain at TTL voltage levels. All the complication of DTE/DCE and cable gender disappears - just remember to link the Tx outputs of one module to the Rx inputs of the other; similarly, for RTS and CTS.

DE9 Connector formats


Well, that took rather longer than I anticipated. And I know I’ve left a lot of stuff out. As a final thought, when examining datasheets for MCU boards, peripheral boards and even chips: always treat references to ‘RS-232 serial ports’ with extreme suspicion. RS-232 buffers are rarely provided and what you get are just the TTL-level signals directly from the UART pins. Should you inadvertently link a genuine RS-232 signal to a TTL input, its up to ±15volts will do the latter no good at all.

If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues. To see my back catalogue of recent DesignSpark blog posts type “billsblog” into the Search box above.

Engineer, PhD, lecturer, freelance technical writer, blogger & tweeter interested in robots, AI, planetary explorers and all things electronic. STEM ambassador. Designed, built and programmed my first microcomputer in 1976. Still learning, still building, still coding today.
DesignSpark Electrical Logolinkedin