Principles of Communication Protocol Design for Embedded Devices and PCs

Embedded devices need to set parameters during operation, which is often accomplished by a PC. A communication protocol must be designed for both parties, with three representative protocols as follows:

From the table above, it can be seen that embedded devices generally have limited memory and computational performance, therefore fixed binary is the preferred communication protocol.

1. Simplicity

The protocol must be a simple solution; obscurity often means difficulty in implementation and a higher chance of errors. The protocol structure should adopt a flat format, with each field serving a clear purpose. The data fields should be designed with fixed lengths and positions whenever possible, with detailed annotations, clear documentation, and rich examples to help users quickly understand and get started.

Protocols generally need the following fields: frame header, length, frame type, destination address, source address, data, checksum, and frame tail.

2. Expandability

It must be ensured that the protocol can still function after adding features or changing hardware in the future, which is often achieved by reserving space. Changes to the protocol should only involve quantitative increases, without altering the protocol structure.

3. Low Coupling

Ideally, each protocol packet should be atomic information, meaning that this protocol packet does not relate to other protocol packets to prevent communication frame loss and errors caused by linked settings.

4. Stability

The length of the protocol packet should be appropriate: if it is too small, it contains too little information, and the variety of protocol packets can lead to communication confusion and linked errors; if it is too large, it contains too much information, leading to poor readability, difficulties in framing and deframing, and making communication susceptible to interference. Generally, the protocol length should be measured by the minimum atomic information.

The protocol must include a checksum mechanism to help the receiver determine whether the protocol packet has been correctly and completely received. If an error occurs, a good mechanism should be in place to ensure successful communication (such as retransmission).

5. High Efficiency

Differentiate protocol packet types by information type, such as setting network information parameters and setting current operating parameters, to facilitate program processing.

Encoding the same type of operation 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 homogeneous pattern as much as possible; if there are differences, at least place the same type of data together so that the program can fully utilize pointers and linear addressing to speed up processing.

6. Ease of Implementation

Minimize the use of complex algorithms. For instance, if the communication link is stable, the checksum of the data frame can be replaced with CheckSum instead of CRC. Unless resources are extremely tight, do not compress too much information into one data packet, as this leads to poor readability and implementation difficulties.

7. Software Development

Try to let hardware ISRs complete the driving work, and do not let the “process” participate 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, the DMA_ISR sends a message to the process. Be careful to handle DMA interruption exceptions (where the received data frame length is normal but the data is incorrect, containing the latter half of the previous frame plus 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.

Related articles: How to Efficiently Parse Variable-Length Protocol Frames

Be cautious of data disorder and timeout exceptions (when data is disordered, the state machine needs to be reset in a timely manner; timeout is generally monitored using a timer).

8. Consider Hardware

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 as fixed length, as shown in Appendix A. This has high efficiency but poor flexibility.

If the communication link is a low-speed bus (such as UART generally 100kbps), it generally generates an interrupt once per byte received, and the protocol can be designed as variable-length frames, as shown in Appendix B. This has high flexibility but lower efficiency.

Appendix A: An Example of a Fixed-Length Protocol Based on DMA Transmission

The 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, identifies the ID number of the target device

• Src: INT8U, identifies the ID number of the source device

• Data: 56-byte storage area, contents depend 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 ‘}’

Data field data structure example:

Appendix B: An Example of a UART Communication Protocol Based on Variable-Length Format

The communication frame between PC and iWL880A (a wireless communication product, see www.rimelink.com) adopts variable-length format, as shown in the figure below. Most devices (commonly PCs) handle receiving based on the “carriage return” mechanism very well, where the Tail in the protocol equals 0x0D (newline).