嵌入式数据分包以及相关技巧

 

 前些天跟大家解释了如下代码:

offset = len/64 + !!(len%64);

并且跟大家详细聊了一下其中的!!操作，然而这段代码的主要功能还是为了进行分包处理，既然是分包自然而然就会想到一种常用的分包处理方法，这也是本文的重点。

数据分包在嵌入式软件开发中算是一种非常常见的处理，其主要原因还是硬件上的各种限制，不得已而为之，特别是在通信协议的定制过程中尤为常见。

1

传输限制 

玩过各种通信协议的朋友都知道，像非常多的通信方式都是以数据帧的形式来进行传递，不同的通信方式因各方面的因素又存在一个最大传输字节数的限制，考虑到稳定性、容错性等等对单次发送的数据长度进行限制，又或者所接收的设备其内存资源有限，不足以接收、处理过长的数据包。

像zigbee这样的物理层每帧最大只能传输127个字节，通过每层不断的封包到应用层后每包才100个字节。当上层用户协议的数据包过大，无法一次性传输，就只能分包或者分组下发，最终接收方组包后解析提取数据。

2

分包设计的考虑 

有些朋友该说了，我就不喜欢搞大包发送，使用短包，然后通过不同的标识进行不同数据位的定义，简单很多。

当然长包与短包并没有本质上的区别，其目的都是传输数据，但在实践的过程中还是会遇到居多处理上的区别：

数据的同步性方面：

比如当通信的设备转速超了，同时报了一个故障码，如果采用短包上传，很可能故障码和转速位于不同的数据包中，当数据包丢包或许是乱序，就会导致当接收到故障码的时候，此时超标的转速值已经丢失或者延时等，有概率不能准确获得故障时的超标转速。

而使用长包，只需要发送方能够保证打包的时候同步，那么接收方就可以同步获得相应的数据。

通信协议设计自由度方面:

在设计协议的时候，长包会更加的自由，大多数情况都不需要考虑大数据传输的占位问题，甚至在编码上直接copy结构体发送也是相当方便的。

3

计算包数问题

既然长包的设计相对比较方便。那分包处理是少不了的？

分包还不简单？

要发100个字节的数据，每次只能发15个，那发送7包就可以了，直接编码，代码如下:

SendPack = SendNum / PackNum;
if(SendPack % PackNum)SendPack++;

 

这算是常规操作，如果觉得有点难度，还要多敲敲代码。

一般用C语言比较久的朋友都想去简化这种操作，毕竟实现一个简单的功能需要两行代码，强迫症，忍不了~

就有了本文开头的!!处理方式，或者如下处理也是一样的:

#include #define PackNum(total,single)  (total/single + ((total%single)?1:0)) int main(void) {     printf("packNum: %d ",PackNum(100,15));     printf("packNum: %d ",PackNum(150,15));     printf("packNum: %d ",PackNum(200,15));     printf("packNum: %d ",PackNum(5,15));     printf("hello bug ~ ");     return 0; }

仅仅只是秀了一下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个字节的数据，该分配几个扇区？

我相信你已经有答案了~

审核编辑 ：李倩