Communication protocols designed for embedded devices typically fall into three categories:
Considering the limited memory and computing power of embedded devices, fixed binary is the preferred communication protocol.
The following analyzes the characteristics that embedded device communication protocols should have.
Simplicity
Ensuring that the protocol is a simple solution is crucial; complexity often leads to implementation difficulties and errors. The protocol structure should be flat, with clear roles for each field, fixed length and position for data fields whenever possible, detailed annotations, clear documentation, and rich examples to help users quickly understand and get started.
Protocols generally require the following fields: frame header, length, frame type, destination address, source address, data, checksum, and frame tail.
The serial communication packet format is shown in the figure below.
Scalability
It must be ensured that the protocol can still function after adding features and changing hardware in the future, which is often achieved by reserving space. Changes to the protocol should only increase the quantity, without altering the structure of the protocol.
Low Coupling
Ideally, each protocol packet should contain atomic information, meaning this protocol packet should not be linked to other protocol packets to prevent communication frame loss and errors caused by interdependencies.
Stability
The length of the protocol packets should be appropriate: if too small, the information contained is insufficient, and the variety of protocol packets can lead to communication confusion and interdependent errors; if too large, the information contained is excessive, resulting in poor readability, difficulty in framing and deframing, and susceptibility to communication interference. Generally, the protocol length should be measured by the smallest atomic information.
The protocol must include a verification mechanism to allow the receiving party to determine whether the protocol packet has been correctly and completely received. In case of errors, there should be a good mechanism to ensure communication success (such as retransmission).
High Efficiency
Different categories of protocol packets should be distinguished by information type, such as setting network information parameters and current operating parameters, to facilitate program processing.
Encoding similar operations into a subset is an efficient method, for example, Read operation encoded as 0x0010, Write operation encoded as 0x0020.
Data should be designed in a homogenous pattern whenever possible; if there are differences, at least similar types of data should be grouped together, allowing the program to fully utilize pointers and linear addressing for faster processing.
Ease of Implementation
The use of complex algorithms should be minimized. For instance, if the communication link is stable, the checksum for data frames can replace CRC. Unless resources are extremely tight, do not cram too much information into one piece of data, as it leads to poor readability and implementation difficulties.
Where possible, let hardware ISRs handle driving work without involving “processes” in complex timing logic; otherwise, the processor will be sluggish and the logic complicated! For example:
To receive fixed-length data frames, DMA can be used, and after each frame is received, DMA_ISR sends a message to the process. Care should be taken to handle DMA fragmentation exceptions (where the received data frame length is normal but the data is incorrect, containing the latter half of the previous frame + the first half of the current frame).
To receive variable-length data frames, a state machine can be used, sending a message to the process when “frame tail data” is received. Care should be taken with data disorder and timeout exceptions (when data is disordered, the state machine should be reset promptly; timeouts are generally monitored using timers).
Hardware Compatibility
If the communication link is a high-speed bus (such as SPORT reaching 100Mbps), it is generally designed to generate an interrupt once per frame, implemented through length-triggered DMA, requiring the protocol to be designed with a fixed length, as shown in Appendix A. This provides high efficiency but lower flexibility.
If the communication link is a low-speed bus (such as UART generally 100kbps), an interrupt is generated for each byte received, allowing the protocol to be designed with variable-length frames, as shown in Appendix B. This provides high flexibility but lower efficiency.
The above figure shows the format of the data frame sent by the PC, with a total length of 64 bytes, which is a multiple of 4 bytes, conforming to the alignment characteristics of most 32-bit processor structures.
-
0x3C: INT8U, frame header, visible character ‘<’
-
Len: INT8U, total data length of this frame, which is 64 in Figure 4
-
Dst: INT8U, ID number identifying the target device
-
Src: INT8U, ID number identifying the source device
-
Data: 56-byte storage area, content depends on the specific communication frame (see Table 2)
-
Cmd: INT16U, category of the data frame
-
CS: INT8U, checksum for all preceding data (62 bytes)
-
0x7D: INT8U, frame tail, visible character ‘}’
Example of Data field data structure:
An example of a UART communication protocol based on variable-length format:
