Detailed explanation of RS232/UART/protocol/serial communication

The basic concept of RS232 :
the asynchronous mode in serial communication in serial communication. UART is a protocol in serial communication. In layman's terms:
serial port (basically) = RS232 = UART = USART = U(S/A)RT
Note:
①RS232 is the name of the protocol, and the serial port should also include other protocols, such as: RS485, RS422, etc.;
②U is universal, A is asynchronous, and S is synchronous. Therefore, the difference between UART and USRT is whether there is a synchronous clock, so some serial ports have There are three wires (except the ground wire), and there is an extra clock wire ;
if the distance is a little farther, the synchronous communication is not suitable, and it will be messy if you connect it through;
③RS232 transmission relies on the voltage between TXD and GND to transmit data (similar to receiving and sending), it is a common mode voltage, and the anti-interference ability is poor, resulting in very limited transmission distance;
④ Reason for being widely used: Because of the simplicity and low cost of RS232, whether it is a single-chip microcomputer, ARM, or DSP, it is equipped with this ⑤The real communication between devices must be the serial port
data of RS232 level, which has strong anti-interference ability.

Because the RS232 protocol
is asynchronous communication, how to ensure the reliability of data transmission, then several people are needed to carry the flag, such as start bit, stop bit;
a typical message protocol is mainly divided into the following parts : start bit, data bit, parity bit, stop bit, note: the bit is used here.
There will be some problems if you simply follow the agreement.
1. The parity check capability is too poor.
2. If a wrong data is transmitted, it cannot be retransmitted.
3. Several slaves are hung on the bus, how does the master distinguish which slave sends the data (some devices cannot use the parity bit as the address bit).
4. If the stop bit is not sent successfully, will the receiver wait all the time?
5. The wrong set of data is uploaded on the bus, and it is impossible to locate where (which bit) the problem is.
In view of the above problems, we thought of a solution, which is to encapsulate into frames. One frame of data contains multiple bytes, and one byte of data contains multiple bits (start bits, data bits, etc.).

Customize the protocol Customize the protocol
according to actual needs. Let's take an example (non-universal protocol/criteria), and use "domain" to represent each functional module in the protocol.
1. Frame start.
The start of the frame is generally marked with 0x55 or 0xaa. Why use this number?
5 in hexadecimal is 0101 in binary; A in hexadecimal is 1010 in binary. In this way, 0x55 is 01010101.
0 and 1 appear alternately, one is to facilitate the receiver to realize the adaptive baud rate, and the other is to avoid interference .
a. By detecting the time interval between 0 and 1, the baud rate of the frame data can be known.
b. If it is set to 0xff, then there is an interference on the bus, and the receiving end is likely to mistakenly think that it wants to receive data.
2. Command field.
The command field can be arbitrary, such as: set the upper line to 0x1d, the lower line to 0x3a, the retransmission to 0xb7, and the response to 0x89.
3. Address field (optional).
The address field can also be arbitrary. If the addresses of all devices are different, it only has the point-to-point function.
Of course, you can also set the addresses of certain devices to the same depending on the actual situation, so that the point-to-multipoint function is available.
4. Length field (optional).
If it is to send a fixed-length frame, the length field can be omitted; if it is a frame of non-fixed length, it can be added.
4. Data field.
The data field is generally composed of the number of data and the data.
For example, you want to pass 3 numbers, 0x00 to 0x02. Then the data field is 0x03 0x00 0x01 0x02.
5. Check field.
Check field, you can use checksum or CRC check. For example, if the CRC16 algorithm is used, the check field is 2 bytes.
Generally, except for the start of the frame and the end of the frame, all are sent to the CRC check.
Well, in this case, I want to send an upstream data to the device with the address 0x0a, a total of 3 data (fixed length), which are 0xa0, 0xb0, 0xc0.
Then a frame of data is: 0x55 0x1d 0x0a 0x03 0xa0 0xb0 0xc0 0x53 0xfb
Just send the above frame of data, byte by byte.
Calculating this frame (excluding the start of frame) using CRC-16 yields 0x53FB. As shown below.
6. Acknowledgment and retransmission.
If the receiver receives a frame of data, after CRC verification, the data is correct, then a simple response frame must be transmitted to tell the host that the frame was successfully received.
Response frame, such as: 0x55 0x89 0xa6 0xc1.
If the receiving end receives a frame of data, after CRC verification, it is found that the data is wrong, and then a simple retransmission frame must be transmitted to request retransmission.
Retransmit the frame, such as: 0x55 0xb7 0x76 0x40.
In this way, the function of the serial port is much more powerful.

Summarize:

Whether it is RS232 or other protocols, data is generally transmitted in units of bytes. If you want to send the 12-bit ADC data to the PC through the serial port, then you should divide it into two bytes and fill the high bits with zeros.
From RS232 to USB and Ethernet, it is not difficult to see that the physical layer/physical interface has not changed much, while the protocol/data link layer has become more and more complex.
This also shows that the reliability of transmitted data should not rely too much on the physical layer, but should rely on some mechanisms on the protocol (check, retransmission, etc.).

If you want to realize serial communication, you can only connect these three lines:

If the ground wires are not connected (common ground), there will be a large error in the voltages identified by the two devices, resulting in random data drift.
insert image description here

Guess you like

Origin blog.csdn.net/qq_42308217/article/details/108790155