关于制定通信协议

制定一个通信协议：

制定协议一定要考虑，可靠性ecc，完备性，可扩展性，除了考虑带宽而节省字节数的pack紧凑外，还有考虑不对齐问题引发的cpu处理头元数据的低效问题

分片和重组问题，重传问题。

安全性问题，加密，防伪，防***, 认证防伪

如何识别包头的分帧问题，引入magic头和magic尾。即同步问题, 收发端同步

1）OBD：

数据都是ascii码，\r\n作为一帧数据的结束，所以，如果有一帧串口数据接收错误，长度错误例如本应10字节，结果收到5字节，那么由于\r\n的判断，所以不会影响下一帧的数据。即出错很快就能恢复，而不是连环错误。 另外OBD数据命令都是AT开头，回复数据都是$OBD开头。2）胎压检测：数据是16进制，这样数据长度较短，另外由于数据很简单，所以格式是固定的长度，而且规定了每一帧的数据的开头magic为0xA5，结束magic数为0xDD。所以如果有一帧串口数据接收错误，长度错误例如本应10字节，结果收到5字节，那么可以通过这些，很快的恢复，所以不会影响下一帧的数据。即出错很快就能恢复，而不是连环错误。

3）行车记录仪：

数据也得考虑怎么样才能区分出一帧、一帧的数据，如果某一帧长度接收出错，那么如何快速区分另外一帧。快速恢复，而不连环出错。特别是我们还要回传一幅图像，那么这个十几KB字节的数据是各种值都有可能的，要是它解析错误，那么后面数据就很乱了。例如以太网，除了物理层的简单的保证数据的起始、结束帧特征外

802.3有特征前导码用于帧同步。而且每帧长度有各最大值。所以能快速恢复。

串口物理层，只有简单的START和STOP简单标记区分简单的数据帧。需要上层协议来做帧错误恢复。

所以行车记录仪数据格式可能需要考虑帧同步问题，即需要特殊的前导码magic数。

关于制定一个通信协议：

需要考虑：1）通讯的错误处理2）如何判断出现错误3）出现错误如何恢复，特别是帧长度错误时的快速恢复。4）一帧数据长度，最大长度值。5）协议的完备性。6）32位操作系统，系统快速处理，head格式最好4字节对齐。7)时间戳方面，需要明确以什么时区为标准。另外一般系统以64位长度作为时间戳比较多。另外，unix提供的gettimeofday()一般以 Epoch为基准，即1970-01-01 00：00：00 +0000(UTC). 不清楚java是否有特殊的api进行这样的转换到特定时间8)ECC9) TLV 格式 type length value10）安全性。

magic魔数头的作用是，如果某帧crc校验失败，那么是否这帧的数据错误、帧头错误？ 如果length就是错的，那么你按照这个length去找流的下一帧，那么后面所有帧都不可能正常解析，这就失同步了。所以有magic头，那么从第一个错帧开始，搜索后面的所有数据，找magic头，如果有，那么在按照格式去检查，如果不对，那么说明那个magic不是magic头，而不数据内容，只是刚好和magic头相同而已，那么就继续找，直到找到满足要求的magic头，即可以按照格式解析出正常的通过crc校验的数据。这个找magic头的过程叫做重新同步。 这个过程对于那种stream流式数据的帧数据分析很重要。

详细的说明，请见：

链接: 提取码: un1h

另外我的相关培训视频请看：

欢迎观看我发布的各个课程：

另外我的免费的linux各种驱动开发课程如下：