Introduction
This article delves into the fundamentals of the Universal Asynchronous Receiver-Transmitter or UART a cornerstone of serial communication in computing and electronics. Starting from the historical evolution of the RS-232 standard, which laid the groundwork for modern serial communication, the article progresses to explore UART’s operational principles, including baud rate, framing, and flow control. It further discusses the relevance of UART in today’s technology landscape, especially concerning USB to UART bridges and their critical role in maintaining compatibility between traditional serial interfaces and contemporary USB systems.
A bit of history
The Recommended Standard 232 (RS-232) was originally designed for board-to-board communication. Introduced in 1960, the standard formally defines the connection between Data Terminal Equipment (DTE) and Data Communication Equipment (DCE), facilitating the connection of PCs to peripherals like modems, printers, and mice via serial ports. It became the first widely adopted serial communication method in a world where bits were previously transmitted over bulky parallel buses: the idea was to transmit a sequence of bits over a single line, where each bit was represented by the line’s voltage at a given time. In this system, the line could adopt two possible states, for example, +15V or -15V, to represent a logical 1 or 0, respectively. Communication was achieved by changing the line’s status over time to transmit a sequence of bits.
The standard employed bipolar voltage levels, typically ranging between ±3V and ±15V. This broader voltage range enhanced noise immunity by increasing the separation between logical 0 and 1 on the voltage scale, thereby extending the logical swing. Such a feature supported long-distance communication in environments with significant noise.
Due to its reliability and versatility, RS-232 is still used today, impacting many modern technologies. The data transmitted is primarily in the form of 8-bit words, making it suitable to use encoding scheme such as ASCII: with this approach each word transmitted over the connection represents a character. PCs were outfitted with multiple Communication ports capable of implementing RS-232: these ports were commonly called COM Ports.
RS-232 is closely linked to the world of Terminals. Originally, terminals were tangible devices such as typewriters or teleprinters, enabling users to interact with computers. Over time, software that mimicked these physical terminals, dubbed Terminal Emulators, gained popularity. In the ’80s, these terminals were ubiquitous, and many graphical user interfaces were crafted on terminals using ASCII characters—just don’t expect the refresh rate of a modern WebApp.
RS-232 is also closely related to the concept of terminals. Initially, terminals were physical devices like typewriters or teleprinters that facilitated user interaction with computers. Over time, software that mimicked these physical terminals, dubbed Terminal Emulators, gained popularity. In the ’80s, terminals were everywhere, and lots of computer screens were made using ASCII characters. Cool stuff, just don’t expect the lightning-fast refresh rates of today’s WebApps, think more “snail mail” speed! Terminals are still popular nowadays with examples including Putty and Realterm.
Despite being gradually overtaken by more advanced standards such as Universal Serial Bus (USB) and TCP/IP, RS-232 continues to have a significant presence in the industry. The standard was so prevalent that it had to be considered during the introduction of USB. To ensure a smooth transition and avoid disruption, the consortium developed a USB class specifically designed to maintain backward compatibility with RS-232. This class, known as the Communication Device Class (abbreviated as USB CDC), allows USB devices to be recognized as Virtual COM ports on PCs. With the modern computer shifting from COM port towards USB it became evident the necessity for UART to USB hardware bridges to allow PCs to interface to old devices, driving the success of companies like FTDI.
In the context of RS-232, the UART served as a hardware peripheral designed to implement the communication scheme. Initially, a UART was a standalone chip mounted on the PCBs of larger systems. Nowadays, UARTs are integrated as peripherals within microcontrollers. Although most characteristics have remained consistent, a significant change over time has been the shift in voltage levels. Microcontroller UARTs typically encode bits using unipolar levels, ranging from 0 to 3.3V. Despite these changes, the protocol continues to be used for data exchange between devices in an 8-bit format.
Universal Asynchronous Receiver Transmitter
The UART is a asynchronous serial communication protocol designed to establish a point-to-point link: in other words UART communication occurs between two devices only. Unlike synchronous communication, where timing is strictly coordinated with a shared clock signal, UART does not require a separate clock line.
Connection scheme
The connection scheme in UART communication is straightforward, involving only two devices connected by two wires (one for each direction of communication) along with a common ground. Typically, each device features a transmission line, known as TX, and a reception line, known as RX. The TX line of one device is connected to the RX line of the other.
The two communication lines in UART can function independently, enabling devices to send and receive data simultaneously. This simultaneous two-way communication mode is referred to as full-duplex mode, which is ideal for applications that necessitate a continuous exchange of information.
Additionally, UART can operate in simplex mode, where data transmission is unidirectional, flowing only from sender to receiver. While less common, simplex mode requires only one communication line, either TX or RX, depending on the direction of data flow.
Timing and framing
One of the defining characteristics of the UART protocol is its ability to transmit data without a dedicated clock line. This feature sets it apart from communication protocols such SPI and I2C where devices must share a common clock signal to synchronize data transfer. How, then, does UART manage to accurately send and receive data between two devices without this synchronization signal? The answer lies in Framing and Baud Rate Matching. To understand this better we need to have an overview of the communication protocol.
The data is transmitted between two devices using a protocol that encodes information as logic levels: a high signal represents a binary 1, and a low signal represents a binary 0. For communication to be successful, both the transmitting and receiving devices must first agree on a baud rate, which is the speed at which data is sent and received, measured in bits per second.
As a side note, the speed of an UART comes with some very unusual value which are very familiar to whoever used a terminal more than once (9600, 19200, 38400, 57600, 115200, 230400, etc.). The reason of these speed is historical as these are division of the a common clock frequency used by MCUs and UART back in the days (1.8432MHz).
So if as example the baud rate is set at 115200 bps, then it means that each bit, even those used for the framing, will have a duration of 1/115200 seconds which is about 8.68 microseconds. So if we consider a communication made 1 start bit, 8 data bits and 1 stop bit the entire frame will last 86.8us as shown in the next picture
When no data is being transmitted, the UART line remains in an idle state, signified by a high signal. Communication begins with a start bit, a transition from high to low, signaling the receiver that a data frame is starting. As said, the start bit has the same duration of any other bit which means that the line will stay low for the duration of 1 bit. This initial bit is followed by the data frame itself, which can vary in size from 5 to 9 bits, although 8 bits is the standard size for most communications. Agreement on the number of data bits is essential before the start of communication to ensure both devices correctly interpret the data being sent.
Optionally, a parity bit may be added to the data frame, serving as a basic error-checking mechanism. The parity bit can be configured to make the total number of 1s in the frame either even (even parity) or odd (odd parity), providing a rudimentary form of error detection.
The end of the data frame is marked by a stop bit, which returns the line to a high signal. Unlike the start bit, the stop bit’s primary purpose is not to signal the end of data transmission per se. Indeed if the last bit to be transmitted right before the stop was already a logic 1 the stop bit will not produce any state transition.
The main purpose of the stop bit is to ensure that the line returns to its idle state and holds the state for a sufficient duration before a new data transfer begins. This duration, which can be set to 1, 1.5, or 2 bit lengths, allows internal logic in the devices time to complete necessary operations and prepare for the next data transfer. The customizable duration of the stop bit is a critical feature, ensuring that the communication line remains clear and ready for subsequent transmissions, facilitating smooth and continuous data exchange between the UART devices.
So to correctly establish a communication we will need to define and agree both size few things:
- The baud rate which defines the overall communication speed defining the duration of each bit.
- The size of the data packet itself which can span from 7 to 9 with a typical value of 8 bits. These bits, coming right after the start bit are representing the transmitted data.
- The type of parity which can be disabled (no parity bit), even or odd (an extra bit added after the data frame). IF the parity is enabled, this bit will come right after the data bits.
- The duration of the stop bit which can be set long as 0.5, 1, 1.5 or 2 bits. This final bit completes the communication
Over sampling
The issue with asynchronous communications arises from potential delays in internal logic, which may lead to sampling errors. For instance, at a transmission speed of 115200 bps, the duration of each bit is under 9 microseconds. It is crucial for the logic that samples these bits to be highly precise in timing to avoid incorrect sampling. Additionally, maintaining a clean signal and controlling the line’s capacitance are imperative, especially at higher speeds.
To mitigate the impact of delays and inaccuracies in reading the RX line, UARTs employ oversampling, typically sampling each bit 8 or 16 times. This approach enables the logic to make a more accurate determination of each bit’s value, whether it is a 1 or a 0, based on a predefined rule.
A common method for making this decision is majority voting, where the value of a bit is determined by the majority of the samples. Alternatively, a mechanism may be employed where if a bit’s status is ambiguous (falling within a small, central area of uncertainty), this triggers an error signal in the UART module.
Whatever is the decision matrix, oversampling is a widely adopted technique in contemporary UART peripherals, enhancing their capability to operate at speeds surpassing the actual transmission rate and thereby increasing the hardware’s robustness.
Flow control
Historically, the disparity in data processing capabilities between devices necessitated a method to synchronize data flow in UART communication systems, to ensure that a faster sender does not overwhelm a slower receiver. This synchronization could be achieved through hardware (HW) or software (SW) flow control mechanisms. HW flow control utilizes additional signal lines, like RTS (Request To Send) and CTS (Clear To Send), to manage this process, effectively allowing the receiving device to signal its readiness to accept more data. On the other hand, SW flow control employs special ASCII characters, notably XON (Ctrl-Q or ASCII 17) and XOFF (Ctrl-S or ASCII 19), to pause and resume the data transmission without the need for extra wiring. These characters fit seamlessly into the data stream, enabling control over the data flow directly through the transmitted information.
Although the adoption of flow control in modern systems might not be as prevalent as in the past, it remains an important feature in many microcontrollers (MCUs) and terminal emulators. This is because there are still practical scenarios, such as buffer management and maintaining compatibility with legacy systems, where flow control proves invaluable. For instance, in environments where data must be meticulously managed to prevent loss or in systems where older protocols are still in operation, having the ability to regulate data flow ensures reliable communication.
It’s worth noting that each flow control method comes with its trade-offs. HW flow control requires additional wiring, which can complicate the physical setup, especially in systems aiming for minimal connectivity. SW flow control, while eliminating the need for extra hardware lines, introduces a layer of communication overhead that can detract from the simplicity and low-resource advantages typically associated with UART. This is in contrast to other communication protocols like SPI and I2C, which are designed for simplicity and efficiency without the inherent need for flow control mechanisms. Thus, while UART remains a fundamental communication tool, the decision to implement flow control—and whether to use hardware or software approaches—must be carefully considered in the context of each specific application’s requirements and constraints.
UART bridges
UART interfaces continue to be widely used in today’s embedded systems, serving as a reliable method for serial communication. However, as the prevalent interface for modern devices is USB, UART must adapt to maintain connectivity. While many microcontrollers (MCUs) with built-in USB capabilities can simulate a UART connection using the USB Communication Device Class (CDC) feature, there remains a clear need to bridge traditional UART interfaces with USB systems. This necessity arises because numerous devices still operate with native UART ports and require a conversion mechanism to communicate with USB-centric devices. Thus, bridging solutions play a crucial role in ensuring compatibility and facilitating communication between established UART protocols and contemporary USB interfaces.
UART to USB bridges
One prevalent method of bridging UART to USB is through dedicated hardware devices that feature a USB interface on one end and a UART interface on the other. These devices, when connected via USB, present themselves as a USB Communications Device Class (CDC), effectively translating UART protocols to USB interfaces. A prime example of such hardware is the family of FTDI chips, which are widely used for their reliability and ease of integration.
When utilizing a virtual COM port created by these chips, aligning the baud rate with the UART settings is crucial for ensuring effective communication. These chips are frequently available soldered on affordable breakout boards, allowing for quick and easy connection to a microcontroller providing UART access with just few jumper wires.
Adoption of the UART in modern evaluation kits
Another common bridging approach is found within debugging probes. These are typically specialized microcontrollers that have been programmed with firmware to function as a debugging probes. Many of these tools offer a software bridge from UART to USB, allowing developers to interact with their target systems. It’s commonplace for a modern debugging probe to create a virtual COM port on the host PC, which facilitates a bridge to the target’s UART interface.
In this setup, when connected to a PC, the debugging probe is recognized as a composite USB device, simultaneously exposing both the debugging probe and a virtual COM port for debugging. This configuration will be extensively used in our hands-on exercises, as it provides a straightforward method to utilize a UART without requiring any additional connections.
Conclusions
In conclusion, UART has been a key player in the shift from parallel to serial communications, laying the groundwork for this transition. However, it is important to recognize that as technology has advanced, UART has gradually ceded ground to faster and more efficient protocols such as SPI, I2C and the USB itself. These buses enable quicker data transfers, reflecting a broader evolution in device communication strategies.
