Serial Ports Deep Dive: Custom Frames for Multi-Device Communication
This tutorial explains UART asynchronous serial communication, frame structure, parity check, baud rate concepts and data transmission workflow.
COMPONENTS
PROJECT DESCRIPTION
【Preliminary Note】The original hardware example in this article was written based on the RP2040. The actual hardware used in this hands-on demonstration features the W55RP20 as the main controller chip. The circuit logic and UF2 flashing operation principles are universally applicable, with only the main controller model differing. The original chip model mentioned in the circuit descriptions below is provided for reference purposes only.
Tweet
1. Basic Concepts
Consider the following application scenarios:
The receiver needs to receive data of variable length
The sender will send different types of data at irregular intervals (for example, a three-axis gyroscope sends information about the angle, angular velocity and acceleration in the x, y and z directions).
Multiple devices are connected to a single bus (for example RS485), how to determine which device the received data is intended for
It can be seen that when facing the above scenarios, we need to include more content in the serial communication, such as the type and length of the transmitted data, the number of the device to be received, etc. At this point, we can use our custom one between the transmitting device and the receiving device serial communication protocol frame.Simply put, it refers to assembling multiple data packets transmitted in serial communication into one frame of data. Data packets in different transmission sequences carry different meanings (for example, the valid data bits in the third transmitted data packet represent the device number of the device to receive the data, etc.). By parsing the frame of data composed of multiple data packets, the receiving device can obtain the required data accurately and without errors.
Serial Communication Hierarchy Diagram
2. Custom Protocol Frame Format
For custom protocol frames, they typically consist of the following components: frame header, frame tail, address information, data type, data length, data block, check code, etc. The common format of a custom protocol frame is as follows:
3. Packetization and Depacketization of Custom Protocols
Here, packaging refers to adding identifiers (such as frame header, device address, command, command type, data length, frame tail, check code, etc.) to the beginning and end of the data to be sent, while unpacking refers to filtering out the parts other than the sent data from the received data frame for display.
The common process of data unpacking is as follows:
After receiving each data packet of the data frame, we need to check it:
Upon receiving the first data, determine whether it is a frame header; if it is a frame header, receive the next data, meanwhile set the flag indicating that the frame header has been fully received, and store the frame header in a pre-declared list or other data structure for caching, so as to facilitate further processing of the data after the reception is completed; otherwise, do not set the flag indicating that the frame header has been fully received, and re-determine whether the next received data is a frame header.
When receiving function codes (i. e., device addresses, command types, instructions, etc.), the process is the same as above: first, determine whether the data falls within one of the parameter ranges preset for the function code, that is, perform an entry parameter check (for example, there are only 3 types of commands, namely 0x51,0x52, and 0x53, and it is necessary to determine whether the received command is one of the three). If the data belongs to one of the parameter ranges preset for the function code, set the flag indicating that the function code has been completely received, and store it in the data structure for buffering; otherwise, restart the reception from the frame header.It should be particularly noted here that, for the data length function code, the data length range needs to be judged; otherwise, a memory overflow problem may be caused by the reception error of the data length range (for example, the received data length exceeds the preset list size).
After the verification is successfully completed, extract the data and instructions from the data structure used for caching, and then perform the next operation based on the extracted data and instructions.
Serial Communication Hierarchy Diagram 
