讨论一下串口解析应该怎么设计比较合理(二)？

会飞的猪_2020

讨论一下串口解析应该怎么设计比较合理？
https://forum.anfulai.cn/forum.p ... 5&fromuid=32469
(出处: 硬汉嵌入式论坛)





今天我遇到一个第三方的设备，它本身没有重传机制，所以我按照第一种方式进行解析。
有包头包尾checksum和字节长度。

我大概花了一天的时间去写解析函数，思考了一下貌似没办法适配所有情况。

协议如下


然后它没有做重传机制

它的上报数据如下：

[C] 纯文本查看 复制代码

//{0xA5, 0xFC, 0x02, 0x00, 0xA3, 0x9A, 0x0C, 0x00, 0xB1, 0xFA, 0x01, 0xFB, 0xA5, 0xFC, 0x07, 0x00, 0xA0, 0x91, 0x0D, 0x1A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x11, 0x69, 0x01, 0xFB}

在数据都正确的情况下，怎么解析都是没有问题的。我脑补了几种极端的情况，有没有办法解析？



情况1：
假设帧头发送了两次。这种情况下能否解析？

[C] 纯文本查看 复制代码

//{0xA5, 0xFC,0xA5, 0xFC, 0x02, 0x00, 0xA3, 0x9A, 0x0C, 0x00, 0xB1, 0xXX, 0xXX, 0xFB}

情况2：
假设断帧，能否解析？

[C] 纯文本查看 复制代码

//{0xA5, 0xFC,0xA5, 0xFC, 0x02, 0x00, 0xA3, 0x9A, 0x0C, 0x00, 0xB1, 0xXX, 0xXX}

[C] 纯文本查看 复制代码

//{0xFB}

情况3：
假设长度字节出错，能否解析？如何分辨是断帧还是长度字节出错？（例如这里长度字节变成了0X0102明显大大超出）

[C] 纯文本查看 复制代码

//{0xA5, 0xFC,0xA5, 0xFC, 0x02, 0x01, 0xA3, 0x9A, 0x0C, 0x00, 0xFB, 0xXX, 0xXX, 0xFB}

如果依靠包尾去判断情况2和情况3，那么如果数据段里面有字节和包尾一样，如何解析？

[C] 纯文本查看 复制代码

//{0xA5, 0xFC,0xA5, 0xFC, 0x02, 0x01, 0xA3, 0x9A, 0x0C, 0x00, 0xFB, 0xXX, 0xXX, 0xFB}

会飞的猪_2020

目前我就是无法判断是长度字节出错，还是断帧。
当这两种情况发生的时候，现象就是接受到的长度小于通过长度字节计算的理论的长度。
断帧的话需要不丢弃数据等待数据的到来，而长度字节出错，需要丢弃数据。
我无法兼容这两种情况。

如果我依靠包尾去辅助判断的话，仿佛又没办法兼容数据段里面包含包尾的情况。

eric2013

这种的实际上是设备限制了稳定性更好的通信机制。

这种通信还是Modbus做的稳定些，有CRC校验判断帧错，还有字节数判断和帧间隔判断。

yono

仅针对情况1帧头发送了两次显然是可以特殊处理的，正常解析流下，原本的数据长度部分出现 0xA5, 0xFC帧头显然太可疑了。但是我觉得如果不是确实发现这种情况，不如直接当错误帧弃掉。

情况2，断续帧有很简单的方法，我所有的通信都有这个机制


情况3，长度字节出错，直接弃帧吧，如果长度字节出错，那么显然数据字节也不可靠，无法判断帧尾究竟是帧尾还是数据字节出错产生的假帧尾。

会飞的猪_2020

yono 发表于 2024-12-13 10:06
仅针对情况1帧头发送了两次显然是可以特殊处理的，正常解析流下，原本的数据长度部分出现 0xA5, 0xFC帧头显 ...

嗯，我最后也是引入了一个参数，最大长度。
如果接收到断帧之后，长度小于最大长度就继续接收，如果大于就判断出错，去清理buff。

正义属于世界

yono 发表于 2024-12-13 10:06
仅针对情况1帧头发送了两次显然是可以特殊处理的，正常解析流下，原本的数据长度部分出现 0xA5, 0xFC帧头显 ...

你这个图是通过什么软件制作的啊？

yono

会飞的猪_2020 发表于 2024-12-13 10:10
嗯，我最后也是引入了一个参数，最大长度。
如果接收到断帧之后，长度小于最大长度就继续接收，如果大于 ...

我的思考是像按键消抖，做数据帧的消抖，确立电平和无效电平的判断逻辑

h_007

这种类型的发送/接收的实现，通常用DMA+IDLE中断模式整体处理nbytes，也不会占用过多CPU中断进出时间

Piii

这个还得靠协议完善才行，比如加入转码机制，只有帧头能出现特定的字符，比如如果帧头是0X55的话
（1）发送方：如遇0x55，转码为0xFF 0x00；如遇0xFF，转码为0xFF 0xFF。
（2）接收方：如遇0xFF 0xFF，转码为0xFF；如遇0xFF 0x00，转码为0x55。

Piii

还得完善协议才行，比如除了帧起始字节（FS）以外，帧内的数据不允许出现与FS一致的数值，如果帧头是0x55的话
发送方：如遇0x55，转码为0xFF 0x00；如遇0xFF，转码为0xFF 0xFF。
接收方：如遇0xFF 0xFF，转码为0xFF；如遇0xFF 0x00，转码为0x55。

Piii

回复不了什么鬼

cctv180

DMA+IDLE+环形缓冲更爽

tovinz

用COBS把原始数据包打包一下，再用0x00作为包间隔，方便又可靠。甚至你还有把打包后的所有数据都加一个值M，用M作为包间隔

高效可靠的数据字节编码算法COBS，可用于串口通信
https://forum.anfulai.cn/forum.p ... 9&fromuid=41790
(出处: 硬汉嵌入式论坛)

会飞的猪_2020

tovinz 发表于 2024-12-13 15:55
用COBS把原始数据包打包一下，再用0x00作为包间隔，方便又可靠。甚至你还有把打包后的所有数据都加一个值M ...

我是对接了第三方的设备，所以协议上没办法选择，只能是适配它的。

会飞的猪_2020

Piii 发表于 2024-12-13 11:47
这个还得靠协议完善才行，比如加入转码机制，只有帧头能出现特定的字符，比如如果帧头是0X55的话
（1）发 ...

是的，稳定性还是需要依靠协议完善。
目前我想到的办法只能是限制最大接收的字节数，去判断。

yono

正义属于世界 发表于 2024-12-13 10:35
你这个图是通过什么软件制作的啊？

excalidraw 开源白板，中文支持你可以自己探索一下

踩姑娘的小蘑菇

2个字节的作为包长的确实需要限制包长，2个字节如果出错了可能要一直读60k才能丢弃
如果是1个字节作为包长，出错的帧最多读255字节即可校验和丢弃

踩姑娘的小蘑菇

楼上的COBS如果两边都支持也不错，比自己造轮子方便
空闲分包有个隐藏问题是速度不可能做高

tovinz

踩姑娘的小蘑菇 发表于 2024-12-16 17:44
楼上的COBS如果两边都支持也不错，比自己造轮子方便
空闲分包有个隐藏问题是速度不可能做高

是这样的，因为不需要分包时间间隔，使用流式传输的方式使得串口链路利用率相当高。我之前测试应用层数据的收发速率可以达到串口波特率的98%以上，挺适合两个单片机之间的高速数据包通信