温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

关于制定通信协议

发布时间:2020-07-22 03:28:08 来源:网络 阅读:355 作者:GaoNeil 栏目:移动开发

关于制定通信协议

制定一个通信协议:
制定协议一定要考虑,可靠性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)ECC
9) TLV 格式 type length value
10)安全性。

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

关于制定通信协议

详细的说明,请见:
链接: https://pan.baidu.com/s/1baI0oOIkM8Jd-Mh-dzDQ4w 提取码: un1h

另外我的相关培训视频请看:
欢迎观看我发布的各个课程: https://edu.51cto.com/lecturer/8896847.html

另外我的免费的linux各种驱动开发课程如下:
https://edu.51cto.com/course/17138.html

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI