ti的cc1100e无线模块，发送大于255字节的数据包

只看该作者 · 2012-8-29 17:03

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

只看该作者 · 2012-8-29 17:10

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

只看该作者 · 2012-8-29 17:10

我觉得难点在于，接收方不知道要收的数据包长度是否大于255，又要兼容以前的协议，所以在接收时什么时候采用可变数据包长度模式接收，什么时候该采用无线长度数据包模式？？
我想到的办法有：
第一种：分包，拆成多个包，每包数据长度不超过255，包里还有总的包数及当前包数，接收所有包后处理。
因以前的协议里不含有总包数和当前包数一说，所以通过命令码区别来解码。
(第一种方法就没有采用CC1100E手册里讲到的采用无限长度数据包模式)

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

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

只看该作者 · 2012-8-29 17:19

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

只看该作者 · 2012-8-29 17:28

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

只看该作者 · 2012-8-29 19:01

mark

只看该作者 · 2012-8-30 09:15

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

1万 · 2012-8-30 09:40

拆包发送每包都加校验

只看该作者 · 2012-8-30 14:01

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

只看该作者 · 2012-8-30 14:08

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

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

只看该作者 · 2012-8-30 14:27

10# zhl100

只看该作者 · 2012-8-30 14:31

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

只看该作者 · 2012-8-30 15:52

12# hwk612167

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

-247 · 2012-8-30 19:44

这个真的不错

-247 · 2012-8-30 19:44

这个真的不错，可以借鉴。

只看该作者 · 2012-8-31 09:51

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

只看该作者 · 2012-12-6 16:57

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

ti的cc1100e无线模块，发送大于255字节的数据包

相关下载

相关帖子

社区建设奖章

欢快之小溪

七世轮回

技术导师奖章

湍急之河流

技术领袖奖章

突出贡献奖章

沉静之湖泊

技术奇才奖章

缘定三生

核心会员奖章

十世金身

坚毅之洋流

技术新星奖章