RS232 Data Interface

RS-232 is simple, universal, well understood and supported but RS-232 has some serious shortcomings as a data interface. The standards for RS-232 and similar interfaces usually restrict RS-232 to 256kbps or less and line lengths of 15M (50 ft) or less but today we see high speed ports on our home PC running very high speeds and with high quality cable maxim distance has increased greatly. The rule of thumb for the length a data cable depends on speed of the data, quality of the cable.

Electronic data communications between elements will generally fall into two broad categories: single-ended and differential. RS232 (single-ended) was introduced in 1962, and despite rumors for its early demise, has remained widely used through the industry.

Independent channels are established for two-way (full-duplex) communications. The RS232 signals are represented by voltage levels with respect to a system common (power / logic ground). The "idle" state (MARK) has the signal level negative with respect to common, and the "active" state (SPACE) has the signal level positive with respect to common. RS232 has numerous handshaking lines (primarily used with modems), and also specifies a communications protocol.

The RS-232 interface presupposes a common ground between the DTE and DCE. This is a reasonable assumption when a short cable connects the DTE to the DCE, but with longer lines and connections between devices that may be on different electrical busses with different grounds, this may not be true.

RS232 data is bi-polar.... +3 TO +12 volts indicates an "ON or 0-state (SPACE) condition" while A -3 to -12 volts indicates an "OFF" 1-state (MARK) condition.... Modern computer equipment ignores the negative level and accepts a zero voltage level as the "OFF" state. In fact, the "ON" state may be achieved with lesser positive potential. This means circuits powered by 5 VDC are capable of driving RS232 circuits directly, however, the overall range that the RS232 signal may be transmitted/received may be dramatically reduced.

The output signal level usually swings between +12V and -12V. The "dead area" between +3v and -3v is designed to absorb line noise. In the various RS-232-like definitions this dead area may vary. For instance, the definition for V.10 has a dead area from +0.3v to -0.3v. Many receivers designed for RS-232 are sensitive to differentials of 1v or less.

This can cause problems when using pin powered widgets - line drivers, converters, modems etc. These type of units need enough voltage & current to power them self's up. Typical URART (the RS-232 I/O chip) allows up to 50ma per output pin - so if the device needs 70ma to run we would need to use at least 2 pins for power. Some devices are very efficient and only require one pin (some times the Transmit or DTR pin) to be high - in the "SPACE" state while idle.

An RS-232 port can supply only limited power to another device. The number of output lines, the type of interface driver IC, and the state of the output lines are important considerations.

The types of driver ICs used in serial ports can be divided into three general categories:

Drivers which require plus (+) and minus (-) voltage power supplies such as the 1488 series of interface integrated circuits. (Most desktop and tower PCs use this type of driver.)
Low power drivers which require one +5 volt power supply. This type of driver has an internal charge pump for voltage conversion. (Many industrial microprocessor controls use this type of driver.)
Low voltage (3.3 v) and low power drivers which meet the EIA-562 Standard. (Used on notebooks and laptops.)

--------------------------------------------------------------------------------

Data is transmitted and received on pins 2 and 3 respectively. Data Set Ready (DSR) is an indication from the Data Set (i.e., the modem or DSU/CSU) that it is on. Similarly, DTR indicates to the Data Set that the DTE is on. Data Carrier Detect (DCD) indicates that a good carrier is being received from the remote modem.

Pins 4 RTS (Request To Send - from the transmitting computer) and 5 CTS (Clear To Send - from the Data set) are used to control. In most Asynchronous situations, RTS and CTS are constantly on throughout the communication session. However where the DTE is connected to a multipoint line, RTS is used to turn carrier on the modem on and off. On a multipoint line, it's imperative that only one station is transmitting at a time (because they share the return phone pair). When a station wants to transmit, it raises RTS. The modem turns on carrier, typically waits a few milliseconds for carrier to stabilize, and then raises CTS. The DTE transmits when it sees CTS up. When the station has finished its transmission, it drops RTS and the modem drops CTS and carrier together.

Clock signals (pins 15, 17, & 24) are only used for synchronous communications. The modem or DSU extracts the clock from the data stream and provides a steady clock signal to the DTE. Note that the transmit and receive clock signals do not have to be the same, or even at the same baud rate.

Note: Transmit and receive leads (2 or 3) can be reversed depending on the use of the equipment - DCE Data Communications Equipment or a DTE Data Terminal Equipment.


--------------------------------------------------------------------------------

Glossary of Abbreviations etc.

CTS Clear To Send [DCE --> DTE]
DCD Data Carrier Detected (Tone from a modem) [DCE --> DTE]
DCE Data Communications Equipment eg. modem
DSR Data Set Ready [DCE --> DTE]
DSRS Data Signal Rate Selector [DCE --> DTE] (Not commonly
used)
DTE Data Terminal Equipment eg. computer, printer
DTR Data Terminal Ready [DTE --> DCE]
FG Frame Ground (screen or chassis)
NC No Connection
RCk Receiver (external) Clock input
RI Ring Indicator (ringing tone detected)
RTS Ready To Send [DTE --> DCE]
RxD Received Data [DCE --> DTE]
SG Signal Ground
SCTS Secondary Clear To Send [DCE --> DTE]
SDCD Secondary Data Carrier Detected (Tone from a modem)
[DCE --> DTE]
SRTS Secondary Ready To Send [DTE --> DCE]
SRxD Secondary Received Data [DCE --> DTE]
STxD Secondary Transmitted Data [DTE --> DTE]
TxD Transmitted Data [DTE --> DTE]


--------------------------------------------------------------------------------

Is Your Interface a DTE or a DCE?

Find out by following these steps: The point of reference for all signals is the terminal (or PC).

1 ) Measure the DC voltages between (DB25) pins 2 & 7 and between pins 3 & 7. Be sure the black lead is connected to pin 7 (Signal Ground) and the red lead to whichever pin you are measuring.

2) If the voltage on pin 2 (TD) is more negative than -3 Volts, then it is a DTE, otherwise it should be near zero volts.

3) If the voltage on pin 3 (RD) is more negative than -3 Volts, then it is a DCE.

4) If both pins 2 & 3 have a voltage of at least 3 volts, then either you are measuring incorrectly, or your device is not a standard EIA-232 device. Call technical support.

5) In general, a DTE provides a voltage on TD, RTS, & DTR, whereas a DCE provides voltage on RD, CTS, DSR, & CD.

Read more!

USB Tutorial

What happens on a USB cable ?
USB looks much more like a network protocol than like RS232 (good old serial cables). Data transmissions follows formatted packets rather than being made of plain characters. However, unlike network protocols like Ethernet, Token Ring, etc. all communications are directed by the host (i.e. your computer), and even 'interrupts' are actually polled by the host.
More informations about this section can be found on

What happens on a USB cable ?
USB looks much more like a network protocol than like RS232 (good old serial cables). Data transmissions follows formatted packets rather than being made of plain characters. However, unlike network protocols like Ethernet, Token Ring, etc. all communications are directed by the host (i.e. your computer), and even 'interrupts' are actually polled by the host.
More informations about this section can be found on Usb In A Nutshell (ch. 3)

USB Packets
These are the smallest formatted things that may transfer on the USB cable. Each USB packet at least have a SYNC header and a EOP trailer that carry no information but help identifying packets boundaries. Each USB must also have a PID field (Packet IDentifier) that tells the role of the packet in a transfer or a transaction.

USB transaction
A transaction is a "single sentence" between the host and a device. Transactions may be used to send/read data from the device, initiate transfers, set up parameters, get information, etc. Each transaction is typically made of 3 packets:

a token packet that always comes from the host and carries the address of the device/endpoint concerned in the transaction. USB defines 4 types of tokens: SETUP (initiates a control transaction), IN (initiates a device->host data transaction) and OUT (initiates a host->device data transaction). Tokens are typically have small fixed size.
a data packet which carries the transaction payload. Depending on the USB version, transfer speed and type of data packet used (DATA0, DATA1, DATA2 or MDATA), the maximum payload may be of 8, 64 or 1024.
a handshake packet which informs the data emitter of the reception status. Handshake may be ACK (data received correctly), NAK (unable to receive/emit data right now, or no data to send) or STALL (device state invalid, host intervention required)
USB transfers
Transactions are used to build more complex protocols like control transfer, interrupt transfer (single small sized status poll), isochronous transfer (periodic non-acknowledged packet transmission, like a sample to play on speakers) and bulk transfer (non-predictable large-sized transfers like a page to print)

More on USB transfers can be found on USB in a nutshell, ch 4 further reading required to know how much on transfers will be required by the implementor
USB Configuration
The configuration part of the USB standard occurs through the notion of descriptors. Descriptors are blocks of information retrieved through the host controller which defines things like vendor/product identifiers for each device and class/subclass/protocol codes for each device's interface. Based on these informations, the Operating System can assign the proper driver to each device/interface.
A list of structures defining USB descriptors is available on Clicker's CVS (usbdescr.h)note that Clicker is (L)GPL. If someone finds some equivalent text in public domain, feel free to post it here

Endpoints
Configuration communications are performed on endpoint 0. The USB device will usually define more endpoints used as communication channels between the device and the host, link those endpoints to interfaces which can be assigned a class, subclass and protocol codes (identifying what the device is able to do). For instance a digital camera could offer a couple of endpoints to implement the USBstorage interface (for the camera's memory card) and other endpoints for a webcam interface.

Reading descriptors
The host has to explicitly request descriptors at the device before it manipulate them. This is achieved by a setup transfer using a GET_DESCRIPTOR as the host->device data and receiving the descriptor as the data from the host. The whole transfer will look like

command transaction:
Setup_TOKEN(addr=device, endpoint=0) : host -> device
DATA[ RequestType=0x80, Request=0x06, value=DESCR_TYPEDESCR_SELECTOR,
index=0, length=wished_length] : h->d, 8 bytes
ACK : host <- device response transaction: IN_TOKEN(addr=device, endpoint=0) : host -> device
DATA(the_descriptor) : host <- device (as much bytes as requested) ACK : host -> device
confirm transaction:
OUT_TOKEN(addr=device, endpoint=0) : host -> device
DATA() : host -> device (empty)
ACK : host <- device The DATA packet in the command transaction is called "Setup Packet" (according to Beyond Logic), and carries almost all of the 'interresting' stuff: the RequestType of 0x80 (DeviceToHost=0x80 StandardRequest=0 DeviceTargetted=0) the Request (command) 0x06 for "GET_DESCRIPTOR" the value (encoding unknown atm)

Read more!