STM32内置CRC模块的使用

lovablehua

STM32内置CRC模块的使用 [复制链接]

所有的STM32芯片都内置了一个硬件的CRC计算模块，可以很方便地应用到需要进行通信的程序中，这个CRC计算模块使用常见的、在以太网中使用的计算多项式：
  X³² + X²⁶ + X²³ + X²² + X¹⁶ + X¹² + X¹¹ + X¹⁰ +X⁸ + X⁷ + X⁵ + X⁴ + X²+ X +1
写成16进制就是：0x04C11DB7

使用这个内置CRC模块的方法非常简单，既首先复位CRC模块(设置CRC_CR=0x01)，这个操作把CRC计算的余数初始化为0xFFFFFFFF；然后把要计算的数据按每32位分割为一组数据字，并逐个地把这组数据字写入CRC_DR寄存器(既下图中的绿色框)，写完所有的数据字后，就可以从CRC_DR寄存器(既下图中的兰色框)读出计算的结果。

注意：虽然读写操作都是针对CRC_DR寄存器，但实际上是访问的不同物理寄存器。

---

下面是用C语言描述的这个计算模块的算法，大家可以把它放在通信的另一端，对通信的正确性进行验证：

DWORD dwPolynomial = 0x04c11db7;
DWORD cal_crc(DWORD *ptr, int len)
{
    DWORD    xbit;
    DWORD    data;
    DWORD    CRC = 0xFFFFFFFF;    // init
    while (len--) {
        xbit = 1 << 31;

        data = *ptr++;
        for (int bits = 0; bits < 32; bits++) {
            if (CRC & 0x80000000) {
                CRC <<= 1;
                CRC ^= dwPolynomial;
            }
            else
                CRC <<= 1;
            if (data & xbit)
                CRC ^= dwPolynomial;

            xbit >>= 1;
        }
    }
    return CRC;
}

有几点需要说明：

1）上述算法中变量CRC，在每次循环结束包含了计算的余数，它始终是向左移位(既从最低位向最高位移动)，溢出的数据位被丢弃。

2）输入的数据始终是以32位为单位，如果原始数据少于32位，需要在低位补0，当然也可以高位补0。

3）假定输入的DWORD数组中每个分量是按小端存储。

4）输入数据是按照最高位最先计算，最低位最后计算的顺序进行。

例如：
如果输入0x44434241，内存中按字节存放的顺序是：0x41, 0x42, 0x43, 0x44。计算的结果是：0xCF534AE1
如果输入0x41424344，内存中按字节存放的顺序是：0x44, 0x43, 0x42, 0x41。计算的结果是：0xABCF9A63

safasfasffsa

我没有仔细地分析具体原因，但大体看起来应该是移位的方向反了，不太理解它的Reflect()函数的作用。

如果大家有兴趣可以去看看，那个C语言实现的算法是使用查表方式，效率比较高，但需要一个1K字节的存储空间。

请教版主，STM32有内置的硬件CRC计算单元吗？

coveyniu

标准CRC生成多项式如下表：

   名称        生成多项式              简记式*   标准引用 
   CRC-4       x4+x+1                  3         ITU G.704 
   CRC-8       x8+x5+x4+1              0x31                    
   CRC-8       x8+x2+x1+1              0x07                    
   CRC-8       x8+x6+x4+x3+x2+x1       0x5E 
   CRC-12      x12+x11+x3+x+1          80F
   CRC-16      x16+x15+x2+1            8005      IBM SDLC
   CRC16-CCITT x16+x12+x5+1            1021      ISO HDLC, ITU X.25, V.34/V.41/V.42, PPP-FCS 
   CRC-32      x32+x26+x23+...+x2+x+1 04C11DB7 ZIP, RAR, IEEE 802 LAN/FDDI, IEEE 1394, PPP-FCS 
   CRC-32c     x32+x28+x27+...+x8+x6+1 1EDC6F41 SCTP 


注意：crc32的“权”本为0x04C11DB7
由于俺的内部处理（主要为了加密和解密），故将其右移1位
即得到图中的0x02608edb.

设置时，选crc32左移方式后，将初值设为0xffffffff

再输入大端模式的计算值。如图所示：




相关链接:https://bbs.eeworld.com.cn/upfiles/img/20094/2009414204350302.rar

barium2000

                                 又省了不少flash

ajzhumin

标准CRC生成多项式如下表：

   名称        生成多项式              简记式*   标准引用 
   CRC-4       x4+x+1                  3         ITU G.704 
   CRC-8       x8+x5+x4+1              0x31                    
   CRC-8       x8+x2+x1+1              0x07                    
   CRC-8       x8+x6+x4+x3+x2+x1       0x5E 
   CRC-12      x12+x11+x3+x+1          80F
   CRC-16      x16+x15+x2+1            8005      IBM SDLC
   CRC16-CCITT x16+x12+x5+1            1021      ISO HDLC, ITU X.25, V.34/V.41/V.42, PPP-FCS 
   CRC-32      x32+x26+x23+...+x2+x+1 04C11DB7 ZIP, RAR, IEEE 802 LAN/FDDI, IEEE 1394, PPP-FCS 
   CRC-32c     x32+x28+x27+...+x8+x6+1 1EDC6F41 SCTP 

菜农的CRC网上通用演算器基本战法：

1.CRC8(1-Wire bus) 菜农选: 初值=0 权=0x18 右移crc8
CRC-8       x8+x5+x4+1 

2.PEC(HDQ16) 菜农选：初值=0 权=0x03 左移crc8
CRC-8       x8+x2+x1+1

3.CRC16-CCITT  菜农选：初值=0 权=0x0810 左移crc16
CRC16-CCITT x16+x12+x5+1

4.CRC-32(STM32) 菜农选：初值=0xffffffff 权=0x02608edb 左移crc32
CRC-32      x32+x26+x23+...+x2+x+1

momo86

CRC-32是个标准， PC上好多文件的校验都是按这个CRC-32标准。

这个不是好笑吗？ ST的这个CRC32算出的结果竟然与PC的标准不一样，

大家说好不好笑？

pilot

                                  

dudu1981

                                 怪胎呢！

zsda2007

                                 让俺是STM32的CRC设计师肯定把初值搞几个250~~~

happyrun

成成 发表于 2009-3-31 16:08 ST MCU ←返回版面    

20楼： 我用STM32算出来的结果和程序算出来的结果都不一样 

STM32:
1、把STM32的寄存器复位，复位后的值为0xFFFFFFFF
2、按照双字操作方式，直接把0xA5A5A5A5写入DR寄存器
3、读取DR的结果为：0x29928E70
这跟Netjob你给的结果不一样

我的算法计算出的结果是：0xF9494ABA
这也跟Netjob你给的结果不一样
 
 

94179411

                                  

christine

CRC-32-IEEE 802.3

32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 (V.42, MPEG-2, PNG [10], POSIX cksum)

0x04C11DB7 or 0xEDB88320 (0x82608EDB [7])

到维基百科这个网站看看。
http://en.wikipedia.org/wiki/Cyclic_redundancy_check


你算算字符串 “123456789”的CRC-32 IEEE的结果是多少？
【CBF43926】
结果1：
http://www.lammertbies.nl/comm/info/crc-calculation.html
结果2：
http://www.zorc.breitbandkatze.de/crc.html

某些人就是有BUG ，就是不承认！
相关链接:http://www.zorc.breitbandkatze.de/crc.html

huangjiangmin

                                  

wgxys2007

A5A5A5A5得到结果应该是f18eb66b
STM32确实不一致.

yzmb1985

STM32肯定也是正确的,只是不主流,呵呵
相关链接:https://bbs.eeworld.com.cn/upfiles/img/20094/200941423324768.rar

19861105

                                  

qingyin

非常感谢版主的鼎力支持，根据你提供的算法，我已经在PC上做了验证，结果和STM32的硬件实现一致。回头我再把我的算法和你的算法比较一下，看看问题出在哪里。

blsky112

McuIsp 发表于 2009-4-14 23:31 ST MCU ←返回版面    

15楼： HashCalc是符合主流的: 

A5A5A5A5得到结果应该是f18eb66b
STM32确实不一致.
 
HashCalc 
这个程序是把 源数据按 unsigned char *方式来操作的。这种操作可以符合PC,WINZIP,WINARAR等对文件的读取处理。
因此它的结果是A5A5A5A5得到结果应该是f18eb66b

但如果源数据是按 unsigned long *来处理，0xA5A5A5A5就是一个32位，
它的结果是0x74BEB8EA

这个就是纯32位, 所有数据都是以32位来处理的。但似乎没很少人这样来处理！奇怪！

jordan11151985

  关于CRC算法，知其然，如果再知其所以然，事情就会清楚了。CRC算法，最重要的参数当然是生成多项式（CRC Polynomial），但（余数）初值和CRC数据最高位的位置也是很重要的两个参数，而这两个参数需要根据具体情况具体分析的。初值一般是全0或者全1，CRC数据最高位一般在最低字节的最低位或者最高位。

  CRC算法，作为一种检错算法，它的着眼点是出错概率高地方的错误，这在一定程度上决定了后两个参数。下面举例来说明。

1.串口通信在通信电缆的出错概率高，而串口数据是从LSb先发送，所以比较合理的做法是 CRC数据最高位是第1个被发送字节的最低位。如果发送的数据是"123"－0x31 0x32 0x33，那么输入的CRC数据是 1000 1100 0100 1100 1100 1100。另外，串口的缺省数据一般是1，那么比较合理的（余数）初值就是全1。

2.SPI（和I2C）通信在串行通信的出错概率高，而SPI数据（8位）一般是从MSb先发送，所以比较合理的做法是 CRC数据最高位是第1个被发送字节的最高位。如果发送的数据是"123"－0x31 0x32 0x33，那么输入的CRC数据是 0011 0001 0011 0010 0011 0011。另外，SPI的没有缺省数据，那么（余数）初值设置为全0或者全1都可以。

3.存储介质是FLASH（包括NAND、NOR、SPI FLASH），由于缺省数据（在擦除后）
是全1，比较合理的（余数）初值就是全1。

4.存储介质是硬盘，由于缺省数据（买来时）是全0，比较合理的（余数）初值就是全0。

问：SPI FLASH，比较合理的参数是什么？
答：如上所述，比较合理的（余数）初值是全1。
比较合理的做法是 CRC数据最高位是第1个字节的最高位；如果
SPI数据（8位）是从LSb先发送，比较合理的做法是 CRC数据最高位是第1个字节的最低位。

  对于STM32的32位CRC，如果假定它的一个主要目的是为了校验往内部FLASH
存储数据的可靠性，那么（余数）初值是全1当然是比较合理的。
由于STM32的32位CRC是纯32位，即每次必须输入32位的数，所以如果数据不到
32位，应该往低位用1来填充比较合理；另外，如果输入数据是"1234"－0x31 0x32 0x33 0x34，那么输入的CRC数据是 0011 0100 0011 0011 0011 0010 0011 0001，由于STM32的32位CRC是纯32位且STM32是按小端对齐（little endian）的，这也是合理的。

you168you

1. 跟位数无关的，纯32位的就CRC1次，8位的就CRC4次，结果是一样的！

2. 初值标准的算法（PC WINZIP,WINRAR ,PKZIP..）都是0XFFFFFFFF

3. PC X86是小端，ARM也是可以、已经设置是小端。

ST的这个CRC32是不是想偷工减料啊！搞非典！人家如何来兼容啊？