数据包长度可能大于255

1万 · 2019-10-13 18:05

RT，有没有什么好的办法？以前的协议里最大数据包长度不超过255，所以采用的是可变数据包长度模式，同步字后面跟着的一字节数据就是数据包长度。
现在因为需要改进，数据包长度可能大于255(大于255，需要采用无限长度模式)，为兼容以前的协议的情况下，有什么好的办法处理？

1万 · 2019-10-13 18:09

这个片子自动加长度和CRC保证接收到的正确性

1万 · 2019-10-13 18:11

是的，按照楼主说法，你可以自己另加包头包尾和校验了，保证数据包长度大于255时正确接收，自己加个CRC16

1万 · 2019-10-13 18:16

我觉得难点在于，接收方不知道要收的数据包长度是否大于255，又要兼容以前的协议，所以在接收时什么时候采用可变数据包长度模式接收，什么时候该采用无线长度数据包模式？？

1万 · 2019-10-13 18:19

我想到的办法有：
第一种：分包，拆成多个包，每包数据长度不超过255，包里还有总的包数及当前包数，接收所有包后处理。
因以前的协议里不含有总包数和当前包数一说，所以通过命令码区别来解码。
(第一种方法就没有采用CC1100E手册里讲到的采用无限长度数据包模式)

1万 · 2019-10-13 18:22

第二种：发送方在知道将要发送的数据包长度超过255字节时，先发送一个通知指令数据包，且包里含有将要发送的数据包总长度，接收方收到通知指令后，开启无限长度接收模式。。。。。（接下来按照手册中说的做）

不知道采用哪种方法好，或者大家有什么好的办法来处理呢？？？

1万 · 2019-10-13 18:26

可以搞一个字来标记，区别数据包长度的不同，然后接收程序里校验处理数据

1万 · 2019-10-13 18:29

1、第二种合理，多发几次而已。改动较小。不过发送时间长，就会带来第二个问题，功耗和数据碰撞
2、长度，包头包尾，crc，一次发完，功耗小和冲突可能性小一点。
3、主各有各的好处，斟酌考虑

1万 · 2019-10-13 18:33

时间上应该差不多吧？能不能再详细说说，谢谢

1万 · 2019-10-13 18:36

拆包发送每包都加校验

1万 · 2019-10-13 18:39

跟TI手册中讲道德采用无限长度数据包模式相比，有何优缺点呢？

2万 · 2019-10-13 19:18

时间差很多，不管你用多高的波特率发送，都有个发送延时和接收延时，每发送一次数据包，发送和接收都需要位同步即收发送01010101和字节同步固有的硬件地址。如果分多个包发送，则会增加发送时间。我记得burst是连续发送吧，你再试试单字节的。一个数据包分着发也是同样道理。

2万 · 2019-10-13 19:20

如果按你的第二种想法，先判断数据包长度是否大于255，如果大于255，再发命令字+有效数据，将数据包长度定义到最大即接近255，分包发送，总发送数据格式为:包头+长度+crc16+包尾

1万 · 2019-10-13 19:23

第一种拆包方式发送你说的对，但第2种方式采用无限长度模式就没有分包一说，但是接接收方不知道来的数据包是否大于255，所以发送方需先通知接收方，也需要一个通知包。不知我说的对不对？

1万 · 2019-10-13 19:26

包头+长度+crc16+包尾长度就是数据包总长度（大于255的数据长度）

1万 · 2019-10-13 19:28

如果拆成了几个包，接收方是每收到一个包应答一下，通知接收方发送下一个包？还是等收到全部的数据包后，再应答呢

1万 · 2019-10-13 19:32

我发80个字节，拆成2个包，但是出现了数据碰撞问题，我现在不知道怎么解决碰撞问题，有高手指点思路吗？

1万 · 2019-10-13 19:38

这个拆包发送吧，，大于255的数据包会给带来错误的。

1万 · 2019-10-13 19:41

搞定了，呵呵，犯了低级错误…

1万 · 2019-10-15 13:32

当数据小于255时与之前一样
当大于等于255时，长度为3个字节，长度的第一个字节为0xff,后面两个字节表示为实际长度