总结了嵌入式开发中几种常见的设备通信协议

嵌入式设备在运行中需要设置参数，这个工作经常由PC机来实现，需要为双方通信设计协议，有代表性协议是如下三种：

观察上述表格，很明显，由于内存资源和处理能力通常受到限制，嵌入式设备倾向于采用定长的二进制作为其首选的数据传输格式。

一． 易用性

协议应该简单直观，过于复杂只会增加实施难度并产生错误。建议使用扁平化的结构设计，使得每个区段的功能清晰，数据长度和位置应保持一致性，同时提供详细的注释和文档，辅以充分的实例，以便用户能够迅速掌握和理解。

常见的协议字段包括：帧起始符、长度值、帧类型、目标和源地址、数据内容、校验码以及帧结束符。

二． 扩展性

设计时需考虑到后续增加功能或更换硬件情况下，现有协议是否仍适用。通常，这需要在协议设计中预留出足够的空间，改动应限于结构量的扩展，而非结构性变动。

三． 解耦性

理想的协议设计是，每个数据包是独立且完整的信息单元，避免与其他数据包产生依赖，这有助于减少数据丢失以及系统设置之间产生的连锁错误。

四． 稳定性

数据包的长度要适中：太短会导致信息量不足，使得协议种类繁多，易引起传输错误；而过长则降低可读性，增加数据组装与拆解的难度，并可能引起传输干扰。协议长度应以能够反映最基础信息单位为标准。

协议中必须包含校验机制，以便接收端能确认数据包是否正确和完整地接收到，遇有错误时，应有可靠机制确保数据传输成功（例如，重发机制）。

五． 高效性

根据信息种类划分数据包，例如，网络参数设置和当前操作参数设置应区别对待，便于程序处理。

对相似操作进行编码集合是提高效率的策略，例如，将读操作编码为0x0010，写操作编码为0x0020。

数据设计应尽可能同质化，面对必要的差异时，至少应该将相似类型的数据放在一起，以便程序能够利用指针和线性寻址来加快处理。

六． 可实施性

应尽可能减少复杂算法的使用。例如，当通讯链路稳定时，数据校验可以使用简单的Checksum替代复杂的CRC。除非存在严重的资源限制，应避免在单个数据帧中封装太多信息，因为这可能会降低可读性并增加实施的难度。

七．软件开发

尽可能地让硬件ISR完成驱动工作，不要让“进程”参与复杂的时序逻辑，否则处理器将步履蹒跚且逻辑复杂！如：

接收固定长度的数据帧，可以使用DMA，每接收完一帧DMA_ISR向进程发消息。小心处理DMA断层异常（接收的数据帧长度正常但数据错误，数据为上帧的后半部分+本帧的前半部分）。

接收不定长的数据帧，可以使用状态机，当接收到“帧尾数据”时向进程发消息。小心数据紊乱和超时异常（数据紊乱时需要将状态机及时复位，超时一般使用定时器监控）。

八. 考虑硬件

如果通信链路是高速总线（如SPORT可达100Mbps），一般设计成一帧产生一次中断，它通过长度触发的DMA来实现，需要将协议设计成固定长度，如附录A。它具备高效率，但灵活性较差。

如果通信链路是低速总线（如UART一般100kbps），一般接收一字节产生一次中断，可以将协议设计成变长帧，如附录B。它具备高灵活性，但效率较低。

上图显示了PC发送数据帧的格式，总长为64字节，是4字节的整倍数，符合绝大部分32位处理器结构体对齐的特性。

• 0x3C：INT8U，帧头，可见字符’
• Len：INT8U，本帧的总数据长度，在图4即为64
• Dst：INT8U，标识目标设备的ID号
• Src：INT8U，标识源设备的ID号
• Data：56字节的存储区，内容依赖于具体的通信帧（实例见表2）
• Cmd：INT16U，数据帧的类别
• CS：INT8U, 对它前面所有数据（62字节）进行8位累加和校验
• 0x7D：INT8U, 帧尾，可见字符’｝’

Data域数据结构实例：

一个基于变长格式的UART通信协议实例：

PC与iWL880A（一种无线通信产品，详见www.rimelink.com）通信帧采用变长格式，如下图所示。大部分设备（常见为PC机）对于接收以“回车符”的机制很好处理，协议中的Tail就等于0x0D(换行符)。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！