大家好,我是bug菌~前些天跟大家解释了如下代码:
offset=len/64+!!(len%64);
并且跟大家详细聊了一下其中的!!操作,然而这段代码的主要功能还是为了进行分包处理,既然是分包自然而然就会想到一种常用的分包处理方法,这也是本文的重点。
数据分包在嵌入式软件开发中算是一种非常常见的处理,其主要原因还是硬件上的各种限制,不得已而为之,特别是在通信协议的定制过程中尤为常见。
1
传输限制
玩过各种通信协议的朋友都知道,像非常多的通信方式都是以数据帧的形式来进行传递,不同的通信方式因各方面的因素又存在一个最大传输字节数的限制,考虑到稳定性、容错性等等对单次发送的数据长度进行限制,又或者所接收的设备其内存资源有限,不足以接收、处理过长的数据包。
像zigbee这样的物理层每帧最大只能传输127个字节,通过每层不断的封包到应用层后每包才100个字节。当上层用户协议的数据包过大,无法一次性传输,就只能分包或者分组下发,最终接收方组包后解析提取数据。
2
分包设计的考虑
有些朋友该说了,我就不喜欢搞大包发送,使用短包,然后通过不同的标识进行不同数据位的定义,简单很多。
当然长包与短包并没有本质上的区别,其目的都是传输数据,但在实践的过程中还是会遇到居多处理上的区别:
数据的同步性方面:
比如当通信的设备转速超了,同时报了一个故障码,如果采用短包上传,很可能故障码和转速位于不同的数据包中,当数据包丢包或许是乱序,就会导致当接收到故障码的时候,此时超标的转速值已经丢失或者延时等,有概率不能准确获得故障时的超标转速。
而使用长包,只需要发送方能够保证打包的时候同步,那么接收方就可以同步获得相应的数据。
通信协议设计自由度方面:
在设计协议的时候,长包会更加的自由,大多数情况都不需要考虑大数据传输的占位问题,甚至在编码上直接copy结构体发送也是相当方便的。
3
计算包数问题
既然长包的设计相对比较方便。那分包处理是少不了的?
分包还不简单?
要发100个字节的数据,每次只能发15个,那发送7包就可以了,直接编码,代码如下:
SendPack=SendNum/PackNum;
if(SendPack%PackNum)SendPack++;
这算是常规操作,如果觉得有点难度,还要多敲敲代码。
一般用C语言比较久的朋友都想去简化这种操作,毕竟实现一个简单的功能需要两行代码,强迫症,忍不了~
就有了本文开头的!!处理方式,或者如下处理也是一样的:
#include
仅仅只是秀了一下C语言的几个小技巧罢了,并没有实质性的改善。
很明显,本文的重点并不是介绍如上两种办法,而是如下更加高效的代码:
PackNum=(total+(singleNum-1))/singleNum;
对于一些以往没有使用的朋友或许有点懵,那bug菌这是唠叨几句:
该表达式主要是利用了取整的特性来达到+1的目的。
直接除单包个数,不能整除的情况,结果都会少1,比如10/6,应该是2包,而由于最终除法结果只能是1。
所以通过补偿(singleNum - 1)后,结果就分两种情况:
1、原本能够整除的数,补偿后无法整除,结果与之前一致;
2、原本不能够整除的数,其余数必然在【1~(singleNum- 1)】之间,所以补偿以后,其余数范围在【singleNum~(singleNum+ singleNum- 2)】,则其结果为整除部分+1。
与我们分包个数是一致的,相当巧妙。
4
扩展
这种方法不仅仅只是用于通信的分组中,把思维进一步泛化。
只要是类似分组的处理都可以使用该算法。
比如内存的分区,flash的设计上都是一个扇区一个扇区的分布。
现在想分配整数个扇形区域用于存储某些数据,每一个扇区512个字节,存储2000个字节的数据,该分配几个扇区?
我相信你已经有答案了~
-
数据
+关注
关注
8文章
6842浏览量
88758 -
数据包
+关注
关注
0文章
248浏览量
24347 -
代码
+关注
关注
30文章
4730浏览量
68265
原文标题:谈谈数据分包及相关小技巧
文章出处:【微信号:gh_c472c2199c88,微信公众号:嵌入式微处理器】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论