Key Considerations for Embedded Communication Protocols

Follow+Star Public Account, don’t miss out on exciting content

Source | Internet

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

As can be seen from the table above, embedded devices generally have limited memory and computing performance, so fixed binary is the preferred communication protocol.

1. Simplicity

Ensure that the protocol is a simple solution; obscure and complex designs often lead to implementation difficulties and errors. The structure of the protocol should be flat, with each field having a clear purpose. The data fields should be designed with fixed lengths and positions where possible, with detailed comments, clear documentation, and rich examples to facilitate quick understanding and implementation.

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

2. Scalability

It is essential to ensure that the protocol can still function adequately after adding features or changing hardware in the future. This is often achieved by reserving space; changes to the protocol should only increase the quantity without altering its structure.

3. Low Coupling

Ideally, each protocol packet should be 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 the protocol packet should be appropriate: too small contains too little information, and a wide variety of packet types can lead to communication confusion and interdependencies; too large contains too much information, resulting in poor readability and difficulty in framing and deframing, as well as vulnerabilities to communication interference. Generally, the protocol length should be based on the minimum 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 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 approach, for example, coding Read operations as 0x0010 and Write operations as 0x0020.

Design data to be as homogenous as possible; if there are differences, at least group the same type of data together so that programs 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 replace CRC. Unless resources are extremely tight, avoid cramming too much information into a single data frame, as this leads to poor readability and implementation difficulties.

7. Software Development

Try to let hardware ISRs handle the driving work without involving the “process” in complex timing logic; otherwise, the processor will become sluggish and the logic will be 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 cautious about handling DMA discontinuity exceptions (where the received data frame length is normal but the data is incorrect, with data being 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 upon receiving the “frame tail data.” Be careful about data disorder and timeout exceptions (when data is disordered, the state machine needs to be reset in a timely manner, and timeouts are generally monitored using timers).

8. Consider Hardware

If the communication link is a high-speed bus (e.g., SPORT can reach 100Mbps), it is generally designed to generate an interrupt once per frame, implemented through length-triggered DMA, and the protocol should be designed to be of fixed length, as shown in Appendix A. This provides high efficiency but lower flexibility.

If the communication link is a low-speed bus (e.g., UART generally 100kbps), an interrupt can be generated for each byte received, and the protocol can be designed for variable-length frames, as shown in Appendix B. This offers 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, 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 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, checksum for all data before it (62 bytes)

• 0x7D: INT8U, frame tail, visible character ‘}’

Data field data structure example:

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) adopts a variable-length format, as shown in the following diagram. Most devices (commonly PCs) handle receiving well with the “carriage return” mechanism, where the Tail in the protocol equals 0x0D (newline character).

Note:Some materials in this article are sourced from the internet, and the copyright belongs to the original author. If there are copyright issues, please contact me for removal.