UART/USART Serial Communication-RS232

Keywords: Embedded systems, RS-232, UART, Serial Communication


I have been using Serial communication in embedded systems from quite long time. Honestly speaking I have been thinking of UART serial port to be RS-232 communication. This may be due to the fact that RS-232 is discussed side by side to UART serial communication in microcontrollers programming books. The fact is RS-232 and UART/USART are not the same. RS-232 is one of many standard (so the RS= recommended standard) for serial communication. Other standard and non-standard serial communication protocols include I2C, SPI, RS-422, RS-485, CAN, and Ethernet etc.

In this tutorial we will try to introduce serial communication, RS-232, and UART. A link will be created for how these terms are linked with each other and finally a soft touch will be given like how exactly protocol framing, error detection etc. is implemented.

1. What is Serial Communication?

In telecommunication and data transmission, serial communication is the process of sending data one bit at a time, sequentially, over a communication channel or computer bus [1].
That’s it….. one bit a time…. How the data/bits are encoded, error correction etc. is not concern of serial communication definition.

2. Recommended Standard-232 (RS-232):

RS-232 (ANSI/EIA-232 Standard) is one of the initial steps to go digital from analog world. It was initially developed for modems and teletypewriter. The standard was introduced in 1962 and revised many times till 1997. Historically it was the sole standard for data exchange between digital devices and PCs back in in 1960s.

By that time most of the communication were analog over analog channels. Analog signal are highly prone to noise especially over long distance communication. The use of repeaters (that rebuild the signal) and filters to remove noise from signal were making communication not only difficult by but also highly costly.

As far as the RS-232 was/is concerned, the aim was to transmit digital information over long distance with enhanced SNR (signal to noise ratio). In simple words, the standard was designed keeping in mind mainly signals immunity to noise. The voltage levels were specified in such a way that made it immune to noise disturbances and subsequently reduced the error in data exchange. Electrical signal characteristics such as voltage levels, signaling rate, timing, and slew-rate of signals, voltage withstand level, short-circuit behavior, and maximum load capacitance were highlights of the standard [2].

In RS-232 data is bi-polar (voltage swing on both side of 0-reference level, both –ive and +ive levels). To have flexibility in standard, +3 to +15 volts are said to indicate ON state (logic-1) while a -3 to -15 volts indicates OFF state or Logic-0. Any two devices agreed on certain voltage levels interpret negative voltage as bit-0 and positive voltage as bit-1.

As we mentioned before that one of the RS-232 standard design focus was noise immunity so The output signal level usually swings between +15V and -15V. The “dead area” between +3v and -3v is designed to absorb line noise- Figure-1 [3].

Remember: The recommended standard-232 itself only specifies various signals, the voltage levels and (later on) pins/wire configuration. Character encoding, data Packetization / framing, and error detection are not part of standard.

3. Is it RS-232 or EIA232?

By the time RS-232 was developed, its protocol usage and requirements of the near future devices was underestimated. The focused was majorly on standard signals and electrical characteristics to reduce noise immunity. As the electronics industry grew, more and more digital devices were developed. Inter communication and data exchange between these devices was one the major problems e.g. between printer and computer. By that time RS-232 was the only protocol used for data transmission in modems and teletypewriters. So it was adopted by many digital devices for data exchange interface.

The flexibility in electrical signal levels and interface connector led to non-standard pin assignment on connectors, incorrect or missing control signals and incorrect signal levels. As a result although multiple devices were providing RS-232 communication interface still devices were unable to communicate due to non-standard connector usage, missing signals and/or mismatch signals levels.

In order to partially solve this problem, few manufacturer were agreed to choose certain signal level and a common connector pins thus implementing sort of standard/sub-standard on top of RS-232. They built Transmitters that supplied +5 V and −5 V and labeled them as “RS-232 compatible”. For so many years this rs-232 compatible transmitters were used on electronic devices.

The standard has been revised many times after the initial one and updated by Electronic industries association. The name of standard was also changed from RS232 to EIA232. The Electronic Industries Association published three modifications, the most recent being EIA232F introduced in 1997. [4] Table-1 shows Standard Signals and Signal pins on DB-9 connector.

4. Universal Asynchronous Receiver Transmitter (UART):

As mentioned earlier, the aim of RS-232 standard was mostly on electrical characteristics and its signals. The standard does not define character encoding (i.e. ASCII, EBCDIC, or others), framing (start or stop bits, etc.), transmission order of bits and error detection protocols.

So in order to achieve this, a hardware is used on both side of RS-232 to provide serial data to RS-232 interface, and after transmission on RS-232 bus, the un-packing and error detection is done. This device is called UART. The output signals from UART swings between 0-volts to 5-volts, Figure-2.

The main reason why UART is used in serial communication is its ability to convert from bits from Parallel to Serial and vise versa. i.e. On transmitter side it takes A byte of data and puts its bits one by one on serial line. This serial data is further feed to RS-232 line drivers to transmit on RS-232 link. On the receiver side, the serial data (after RS-232 driver) is converted from serial to Parallel to receive a frame of data. Figure-3 shows how serial communication is done b/w UARTs over RS-232 transmission line.

4.1. UART Frame:

In order to facilitate serial communication and not overburden both transmitter and receiver, UART data is organized in packet/frame format. The frame normally consists of 1-start bit (compulsory and high-to-low transition), 5-8 data bits, 1-bit optional parity bit for single bit error detection and 1/1.5/2 stop bits that indicate end of packet transmission- Figure-4.

4.1.1. Start bit:

Start bit indicate the start of transmission. This bit also acts a reference point to calculate the estimated time to read reaming bits (explained later). The UART Tx line normally remains high, at the start of transmission, it pull this line down for 1-bit duration to indicate to Receiver to get ready for data reception.

4.1.2. Stop bit:

These bits indicates end of frame of transmission. It can be configured to 1-bit, 1.5-bits, and/or 2-bits. There is no transition detection associated with this bit but the Tx line should go to normal i.e. Logic-1 so it be ready for next start bit. At start bit, the UART pulls the Tx line high. Personally I couldn’t figure it out what’s the real purpose of these bits except they give some time to the receiver to shift received bits from internal shift register to UART Rx-Data register.

4.1.3. Parity bit:

Parity bit helps in detecting 1-bit error. It can be either Even or Odd that the transmitter and receiver both agreed upon. Further information on Parity bit can be find in [5].

4.1.4. Baud-rate:

So far we discussed the internals of RS-232 and UART. One of the most important aspect of communication is speed at which data is transmitted from transmitter to receiver. Asynchronous communication speed is normally associated with term baud-rate rather than bits-rate. Technically Baud Rate represents the number of bits that are actually being sent over the media, not the amount of data that is actually moved from one device to another. The Baud count includes the overhead bits Start, Stop and Parity that are generated by the transmitter UART and removed by the receiving UART. For example let’s say a dump device can send 12-bits/second (1-start, 8-data, 1-parity and 2-stop). Then the baud-rate will be 12 (total) while the bits rate would be 8 (actual data bits).

The simplest form of device interconnection for UART serial communication is shown in Figure-5.

5. UART bits detection mechanism:

Now lets get into the details of how bits are send and receive by UARTs on both sides of serial lines. Technically, UART requires local clock to be used as a reference time. The clock ticks / has frequency exactly 16-times that of baudrate. For example if the baudrate is set to 9600, the local clock frequency should be 153,600Hz. On transmitter side, UART pulls down the Tx line (Start bit) and after 16-cycles of local reference clock, it send each of the remaining bits in the frame till the stop bits.
On the Receiver side, by the time it receives transition of start bit, it waits for 16-cycles (the end of Start-bit) and 8 more cycles to reach the mid of first bit, read the first bit and then after each 16-cycles of refernce clock, it reads the remaining bits – Figure-6 [6].

One of the thing for error free serial communication, the local clock on both sides must be ticking at same rate. The error in frequency should not be more the 3%. If the transmitting and receiving clocks don’t match exactly, the receiver will read each new bit closer and closer to an edge of the bit.

6. Flow Control:

Devices communicating over serial interface may not have the same buffer storage. In such case if transmitter sends more data than the capacity of receiver buffer, the buffer on receiver side will overflow and data will be lost. In order to prevent this, flow control mechanism is implemented in serial communication. Flow Control is a method for slow and fast devices to communicate with each other over UART without the risk of losing data. In flow control, when the receiver reaches its capacity it inform transmitter to stop sending futher data until it is informed to do so. The transmitter waits for signal (hard/soft) from receiver device and as soon as it receives the signal, it restarts sending data.
Flow control in serial communication is implemented in two ways.

  • Hardware Flow Control
  • Software Flow Control

6.1. Hardware Flow Control:

In Hardware flow control, two extra PHYSICAL lines are provided in addition to data lines on UART. These signals are:

  1. RTS (Request to Send)
  2. CTS (Clear to Send)

These two lines are cross-coupled between two devices. RTS on one device is connected to CTS on the other device and vice versa. The RTS line is used as output to inform other device that it is ready to receive data. The CTS signal is actually input line on which the RTS signal to be read. Devices continuously monitor CTS signal to see if the other device is ready to read the pending or future expected data.

As long as a device is ready to accept more data it will keep the RTS line asserted. It will deassert RTS some time before its receive buffer is full. There might still be data on the line and in the other device transmit registers which has to be received even after RTS has been deasserted. The other device is required to respect the flow control signal and pause the transmission until RTS is again asserted.

6.2. Software Flow Control:

The problem with Hardware control is that it adds two extra line besides data lines which makes number of lines closer to parallel lines. It also increases the complexity and cost. To solve this problem, software flow control was introduced. In this mechanism the same data lines (Tx, Rx) are used for data transmission but some special ASCII codes (Xoff = 0x11, Xon = 0x13) are used to indicate to trasmitter when to stop data transmission.If device A sends XOFF to device B it means that B should halt transmission to A until B receives an XON character from A. The software flow control has the disadvantage that the codes need to be compare to each byte received over serial line which creates a bit overhead over the transmission.


References:

[1] – Serial communication – Wiki

[2] – RS-232 – Wiki

[3] – RS-232 Serial Communication

[4] – RS232: Basics, Implementation & Specification

[5] – Parity bit

[6] – Serial Port Complete.



219 thoughts on “UART/USART Serial Communication-RS232”

Leave a Reply

Your email address will not be published. Required fields are marked *