What to Consider for Embedded Communication Protocols?

Embedded development often requires communication in many scenarios, making communication protocols essential. The three representative communication protocols are as follows:

As seen in the table above, embedded devices generally have limited memory and computational performance, so fixed binary is the preferred communication protocol.

1. Simplicity

Ensure that the protocol is a simple solution; obscure and difficult-to-understand protocols often lead to implementation challenges and errors. The protocol structure should be flat, with each field having a clear purpose, and the data fields should be designed with fixed lengths and positions whenever possible. Detailed annotations, clear documentation, and rich examples should be provided to facilitate quick understanding.

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

2. Extensibility

It must be ensured that the protocol can still function effectively after future feature additions and hardware changes, often achieved by reserving space. Changes to the protocol should only involve quantitative increases and not structural changes.

3. Low Coupling

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

4. Stability

The length of protocol packets should be appropriate: too small means too little information, and many types of protocol packets can lead to communication confusion and interrelated errors; too large means excessive information, reduced readability, difficulties in framing and deframing, and increased susceptibility to communication interference. Generally, the protocol length should be measured by the minimal atomic information.

The protocol must include a checksum mechanism to allow the receiver to determine whether the protocol packet has been correctly and completely received. If errors occur, a good mechanism should be in place to ensure successful communication (e.g., retransmission).

5. High Efficiency

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

Encoding the same type of operation into a subset is an efficient method; for example, Read operations can be encoded as 0x0010, and Write operations as 0x0020.

Data should be designed in a homogenous pattern whenever possible; if there are differences, at least place the same types of data together so that the program can fully utilize pointers and linear addressing for accelerated processing.

6. Ease of Implementation

Try to minimize the use of complex algorithms; for instance, if the communication link is stable, the checksum for data frames can be replaced with CheckSum instead of CRC. Unless resources are extremely tight, do not cram too much information into one data packet, as this can lead to poor readability and implementation difficulties.

7. Software Development

Whenever possible, let the hardware ISR handle driver work and avoid letting the “process” get involved in complex timing logic; otherwise, the processor will be sluggish and the logic will become complicated! For example:

For receiving fixed-length data frames, DMA can be used, and after receiving each frame, DMA_ISR sends a message to the process. Be careful to handle DMA fragmentation exceptions (where the received data frame length is normal but the data is incorrect, consisting of the latter half of the previous frame plus the first half of the current frame).

For receiving variable-length data frames, a state machine can be used to send a message to the process when “frame tail data” is received. Be cautious of data disorder and timeout exceptions (when data is disordered, the state machine needs to be reset promptly; timeouts are generally monitored using a timer).

8. Consider Hardware

If the communication link is a high-speed bus (e.g., SPORT can reach 100Mbps), generally design it to generate one interrupt per frame, using length-triggered DMA. The protocol should be designed to have a fixed length, as shown in Appendix A. This provides high efficiency but poor flexibility.

If the communication link is a low-speed bus (e.g., UART generally 100kbps), typically one interrupt is generated per byte received, and the protocol can be designed as variable-length frames, as shown in Appendix B. This provides high flexibility but lower efficiency.

The above image 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, in line with 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 destination device
Src: INT8U, identifies the ID number of 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, checksumming all preceding data (62 bytes) with an 8-bit cumulative sum
0x7D: INT8U, frame tail, visible character ‘}’

Example of Data Field Data Structure:

An example of a variable-length format UART communication protocol:

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

Disclaimer:This article contains some materials sourced from the internet, with copyright belonging to the original authors. If there are any copyright issues, please contact me for deletion.