CRC算法 | 树莓派 | python3

最近工作上做了一个数据传输的小工具，使用UART传输，python语言写的，都知道python的跨平台特性，所以刚开始在自己PC上调试通过之后，想着万事大吉，把代码放到树莓派上面验证一下就可以了，谁知道事情并不是那么简单。

4M的串口波特率，在PC上面的传输速度在180k/s，900k的文件大概就是5s左右传输完成，感觉这个速度还可以，到了树莓派上面，惊呆了，12k/s的速度，相差10倍还多。要知道产线上时间就是产能，产能就是金钱。所以花了很长的时间来找这个原因，刚开始怀疑树莓派内核版本太老，串口属性设置不对等等原因，到最后发现是因为CRC16算法问题。

CRC算法，全称叫：循环冗余校验（Cyclic Redundancy Check， CRC）是一种根据网络数据包或计算机文件等数据产生简短固定位数校验码的一种信道编码技术，主要用来检测或校验数据传输或者保存后可能出现的错误。它是利用除法及余数的原理来作错误侦测的。

因为传输数据需要确定数据在传输过程的准确性，所以需要用到校验算法来校验每包的数据。

---

CRC16算法分为按位计算CRC和按字节计算CRC(查表法)，刚开始我用的方法是按位计算的方法，代码如下：

def CRC16(bytes):     
  wcrc = 0     
  byte_array = bytearray(bytes)
  for i in byte_array:
      c = i
      for _ in range(8):
          treat = c & 0x80
          c <<= 1
          bcrc = (wcrc >> 8) & 0x80
          wcrc <<= 1
          wcrc = wcrc & 0xffff           
          if (treat != bcrc):             
              wcrc ^= 0x1021     
   return wcrc

按位计算的优点在于不占空间，几乎没有内存的占用，但是缺点就是计算运算量比较大，花费时间较长。

---

通过逻辑分析仪抓取数据传输的波形发现，第一包数据发送结束，3ms会有一个ACK的回复，但是在ACK之后80ms，第二包数据才发出，所以这80ms的时间，大部分是用在了计算CRC上。

因为我的PC是八核处理器，单核处理器在2.3G的主频，所以计算时间很快，这个问题几乎没有影响，但是树莓派是单核700M的主频，所以计算起来捉襟见肘。

找到问题原因之后，开始解决问题，既然是运算能力不足，那就找一种运算量小的算法方式，那就是按字节计算（查表法），实现代码如下：

const uint16_t crc_table[256] ={
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50a5, 0x60c6, 0x70e7, 
0x8108, 0x9129, 0xa14a, 0xb16b, 0xc18c, 0xd1ad, 0xe1ce, 0xf1ef, 
0x1231, 0x0210, 0x3273, 0x2252, 0x52b5, 0x4294, 0x72f7, 0x62d6, 
0x9339, 0x8318, 0xb37b, 0xa35a, 0xd3bd, 0xc39c, 0xf3ff, 0xe3de, 
0x2462, 0x3443, 0x0420, 0x1401, 0x64e6, 0x74c7, 0x44a4, 0x5485, 
0xa56a, 0xb54b, 0x8528, 0x9509, 0xe5ee, 0xf5cf, 0xc5ac, 0xd58d, 
0x3653, 0x2672, 0x1611, 0x0630, 0x76d7, 0x66f6, 0x5695, 0x46b4, 
0xb75b, 0xa77a, 0x9719, 0x8738, 0xf7df, 0xe7fe, 0xd79d, 0xc7bc, 
0x48c4, 0x58e5, 0x6886, 0x78a7, 0x0840, 0x1861, 0x2802, 0x3823, 
0xc9cc, 0xd9ed, 0xe98e, 0xf9af, 0x8948, 0x9969, 0xa90a, 0xb92b, 
0x5af5, 0x4ad4, 0x7ab7, 0x6a96, 0x1a71, 0x0a50, 0x3a33, 0x2a12, 
0xdbfd, 0xcbdc, 0xfbbf, 0xeb9e, 0x9b79, 0x8b58, 0xbb3b, 0xab1a, 
0x6ca6, 0x7c87, 0x4ce4, 0x5cc5, 0x2c22, 0x3c03, 0x0c60, 0x1c41, 
0xedae, 0xfd8f, 0xcdec, 0xddcd, 0xad2a, 0xbd0b, 0x8d68, 0x9d49, 
0x7e97, 0x6eb6, 0x5ed5, 0x4ef4, 0x3e13, 0x2e32, 0x1e51, 0x0e70, 
0xff9f, 0xefbe, 0xdfdd, 0xcffc, 0xbf1b, 0xaf3a, 0x9f59, 0x8f78, 
0x9188, 0x81a9, 0xb1ca, 0xa1eb, 0xd10c, 0xc12d, 0xf14e, 0xe16f, 
0x1080, 0x00a1, 0x30c2, 0x20e3, 0x5004, 0x4025, 0x7046, 0x6067, 
0x83b9, 0x9398, 0xa3fb, 0xb3da, 0xc33d, 0xd31c, 0xe37f, 0xf35e, 
0x02b1, 0x1290, 0x22f3, 0x32d2, 0x4235, 0x5214, 0x6277, 0x7256, 
0xb5ea, 0xa5cb, 0x95a8, 0x8589, 0xf56e, 0xe54f, 0xd52c, 0xc50d, 
0x34e2, 0x24c3, 0x14a0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405, 
0xa7db, 0xb7fa, 0x8799, 0x97b8, 0xe75f, 0xf77e, 0xc71d, 0xd73c, 
0x26d3, 0x36f2, 0x0691, 0x16b0, 0x6657, 0x7676, 0x4615, 0x5634, 
0xd94c, 0xc96d, 0xf90e, 0xe92f, 0x99c8, 0x89e9, 0xb98a, 0xa9ab, 
0x5844, 0x4865, 0x7806, 0x6827, 0x18c0, 0x08e1, 0x3882, 0x28a3, 
0xcb7d, 0xdb5c, 0xeb3f, 0xfb1e, 0x8bf9, 0x9bd8, 0xabbb, 0xbb9a, 
0x4a75, 0x5a54, 0x6a37, 0x7a16, 0x0af1, 0x1ad0, 0x2ab3, 0x3a92, 
0xfd2e, 0xed0f, 0xdd6c, 0xcd4d, 0xbdaa, 0xad8b, 0x9de8, 0x8dc9, 
0x7c26, 0x6c07, 0x5c64, 0x4c45, 0x3ca2, 0x2c83, 0x1ce0, 0x0cc1, 
0xef1f, 0xff3e, 0xcf5d, 0xdf7c, 0xaf9b, 0xbfba, 0x8fd9, 0x9ff8, 
0x6e17, 0x7e36, 0x4e55, 0x5e74, 0x2e93, 0x3eb2, 0x0ed1, 0x1ef0};

uint16_t crc_16(uint8_t *data, uint16_t len)
{
    uint16_t crc16 = 0x0000;
    uint16_t crc_h8, crc_l8;
    
    while( len-- ) {
        crc_h8 = (crc16 >> 8);
        crc_l8 = (crc16 << 8);
        crc16 = crc_l8 ^ crc_table[crc_h8 ^ *data];
        data++;
    }
    return crc16;
}

按字节计算的方式优点是运算量小，缺点是占用内存空间大，但是树莓盘1G的内存，而我只关心计算速度，内存消耗不是关注点，所以按字节计算满足我的需求。

---

以上只是C代码，但是我的工具为了跨平台使用的python，所以需要在python下引用C代码具体方法是：

创建CRC.c文件，实现CRC算法
使用GCC编译器编译特定平台的库文件
  e.g：arm-linux-gnueabihf-gcc -shared -Wl,-soname,adder -o crc.so -fPIC CRC.c
  生成crc.so文件
python代码中import ctype 模块
引用C代码实现的函数
完成

最终的实现代码如下：

import ctype
adder = ctypes.cdll.LoadLibrary('./crc.so')

def CRC16(bytes):
     wcrc = 0
     byte_array = bytearray(bytes)
     wcrc = adder.CRC_16(bytes,len(byte_array))
     wcrc = wcrc & 0xFFFF
     return wcrc

这个问题困扰了我很久，因为刚开始怀疑内核版本太老，因为我的虚拟机的内核版本是5.4，但是树莓派是4.14版本，然后从树莓派官网下载工具和源码，编译的最新的5.4内核装机之后还是不行，编译内核和修改内核配置的历程真是艰难，尤其是编译完成，内核更新之后速度依旧很慢。

 还好最后定位到真正原因，找到了解决问题的办法，才有了这篇文章，有时间会梳理一下树莓派裁剪编译内核的步骤写成文章分享出来。