RS232 Protocol Explained: Basics, Custom Protocols, and Wiring Practice

RS232 is a common interface for “transmitting small amounts of data” between devices, widely used for communication between microcontrollers and computers, sensors and controllers. This article sets aside complex terminology and explains the core logic of RS232 in plain language, covering basic concepts, protocol rules, custom optimization, and hands-on wiring step by step.

I. RS232 Basics: Concepts and Relationships

1.1 Differences Between Serial Port, RS232, and UART

• Serial port is a broad category, like fruit; RS232 and RS485 are specific varieties within serial ports, like apples and oranges.
• UART is a working mode of serial ports (asynchronous communication). It does not require an extra clock line and transmits data according to agreed rules; if a clock line is added, it is called USRT (synchronous communication).
• What is usually called RS232 is basically UART mode, so it is often said that serial port ≈ RS232 ≈ UART.

1.2 Advantages and Disadvantages of RS232

II. RS232 Communication Rules: Asynchronous Communication and Frame Structure

2.1 Four Elements of Asynchronous Communication

RS232 is asynchronous communication, with no clock line for synchronization. The receiver relies on the start bit, data bits, parity bit, and stop bit to identify valid data. Each byte is transmitted together with these four parts:

• Start bit: Tells the receiver that data transmission is about to begin, usually one low level.
• Data bits: The actual content to be transmitted, for example 8 bits (1 byte), such as 0x66 (binary 01100110).
• Parity bit: A simple check of whether the data is wrong, such as odd parity or even parity. But its error-detection capability is crude; if 2 bits are wrong, it may not detect it.
• Stop bit: Tells the receiver that this data transmission is finished, usually one or two high levels.

2.2 Common Issues and Limitations

• The parity bit has poor error-detection capability, so transmission errors may go unnoticed;
• If data is wrong, there is no way to ask the other party to retransmit;
• When multiple devices are connected to the bus, the host cannot tell which device sent the data;
• If the stop bit has not finished, the receiver will keep waiting, causing subsequent data to become disordered.

The solution is to “package data into frames”—one frame contains multiple bytes, each byte carries start/stop bits, and additional functional fields are added to solve the above problems.

III. Custom Protocol: Packaging Data to Improve Reliability

3.1 Custom Frame Structure

A custom protocol designs a fixed structure according to actual requirements. Common fields are as follows:

3.2 Key Field Design Points

• Choose 0x55 or 0xaa for frame start: Binary 01010101 and 10101010, with 0 and 1 alternating, allow the receiver to identify the baud rate (e.g., 9600bps, 115200bps); if 0xff (all 1s) is used, external interference can easily be mistaken for a start signal.
• Command field: Clarifies the purpose of the data, such as uplink, downlink, retransmission request, or response.
• Address field: Gives each device a unique address. When the host sends data with an address, only the corresponding device receives it; the same address can also be set to achieve one-to-many communication.
• Length field: Used when the data length is variable; it can be omitted when the length is fixed.
• Data field: Business data, often including the number of data items, e.g., 0x03 indicates that 3 data items follow.
• Check field: More reliable than a parity bit; CRC16 is commonly used, and all fields except the frame start participate in the check.

3.3 Complete Data Frame Example

To send a frame of uplink data to a device at address 0x0a, containing 3 data items 0xa0, 0xb0, and 0xc0, the complete frame is:

0x55 (frame start) + 0x1d (command field) + 0x0a (address field) + 0x03 (number of data items) + 0xa0 + 0xb0 + 0xc0 (data field) + 0x53 + 0xfb (CRC16 check)

3.4 Response and Retransmission Mechanism

• If the receiver verifies that the data is correct, it sends a response frame (e.g., 0x55+0x89+check value).
• If the data is wrong, it sends a retransmission frame (e.g., 0x55+0xb7+check value) to ask the other party to resend.

IV. Hands-on Wiring: Three Wires Are Enough

4.1 Core Wiring Method

For two devices to communicate via RS232, the core requires only 3 wires:

1. TXD (transmit line): Device A's TXD connects to Device B's RXD. It cannot be reversed, otherwise data cannot be sent.
2. RXD (receive line): Device B's RXD connects to Device A's TXD, corresponding to the above.
3. GND (ground line): Must be connected! Without a common ground, the voltage levels recognized by the two devices will differ greatly, and data will drift, e.g., data that should be 0 becomes 1.

4.2 Precautions

• Before wiring, confirm that TXD and RXD are cross-connected;
• The ground line must never be omitted, otherwise communication will be unstable;
• For long-distance communication, level conversion and anti-interference measures must be considered.

V. Summary and Extensions

RS232 or other communication protocols basically transmit data in bytes. For example, to transmit 12-bit ADC data (range 0-4095), it needs to be split into two bytes (with the high bits padded with 0) before transmission.

From RS232 to USB and Ethernet, the physical interface does not change much, but protocols become increasingly complex—this shows that relying only on the hardware layer to ensure data reliability is not enough. Checksums, retransmissions, and other mechanisms in the protocol are also needed to make data transmission accurate and stable.

This article refers to some online content; if there is any infringement, please contact us for deletion.