Research on CRC algorithm based on DS18B20 and the realization of MATLAB

Recently on the ARM9 based on the operating system to write a temperature sensor driver, but found that the temperature of ds18b20 sometimes error, so want to the data for CRC check, but looked at half a day chip data, or do not know how to carry out the CRC check, as shown in the figure:

Figure 1 CRC-8 Checksum

So in the online search, found that there are two main ways to achieve: table-checking method and the method of cyclic displacement. The table method is mainly calculated by calculating the CRC value of all the data between the 0x00-0xff, and then the data to be different or after the table to calculate the CRC, the code is as follows:

#include <c8051f350.h> #define UCHAR unsigned char #define UINT unsigned int uchar SJC; 


unsigned char data sfd[3] = {0x01,0x02,0x03}; Uchar Code crc8table[]={0, 94, 188, 226, 97, 63, 221, 131, 194, 156, 126, 32, 163, 253, 31, 65, 157, 195, 33, 127, 25 2, 162, 64, 30, 95, 1, 227, 189, 62, 96, 130, 220, 35, 125, 159, 193, 66, 28, 254, 160, 225, 191, 93, 3, 128, 222, 60, 9 8, 190, 224, 2, 92, 223, 129, 99, 61, 124, 34, 192, 158, 29, 67, 161, 255, 70, 24, 250, 164, 39, 121, 155, 197, 132, 2 18, 56, 102, 229, 187, 89, 7, 219, 133, 103, 57, 186, 228, 6, 88, 25, 71, 165, 251, 120, 38, 196, 154, 101, 59, 217, 1  35, 4, 90, 184, 230, 167, 249, 27, 69, 198, 152, 122, 36, 248, 166, 68, 26, 153, 199, 37, 123, 58, 100, 134, 216, 91, 5, 231, 185, 140, 210, 48, 110, 237, 179, 81, 15, 78, 16, 242, 172, 47, 113, 147, 205, 17, 79, 173, 243, 112, 46, 204, 1  46, 211, 141, 111, 49, 178, 236, 14, 80, 175, 241, 19, 77, 206, 144, 114, 44, 109, 51, 209, 143, 12, 82, 176, 238, 50, 108, 142, 208, 83, 13, 239, 177, 240, 174, 76, 18, 145, 207, 45, 115, 202, 148, 118, 40, 171, 245, 23, 73, 8, 86, 180, 234 , 105, 55, 213, 139, 87, 9, 235, 181, 54, 104, 138, 212, 149, 203, 41, 119, 244, 170, 72, 22, 233, 183, 85, 11, 136, 2 14, 52, 106, 43, 117, 151, 201, 74, 20, 246, 168, 116, 42, 200, 150, 21, 75, 169, 247, 182, 232, 10, 84, 215, 137, 107,
53};

    /** computed CRC Check */UINT crc8_table (Uchar *p, uint counter) {uint CRC8 = 0;
        for (; counter > 0; counter--) {Crc8 = crc8table[crc8^*p];
    p++;

} return (CRC8); } void Main () {while (1) {sjc=crc8_table (sfd,3)}}

The other one uses the cyclic shift method realization, looked several times the code has no clue, the code is as follows:

/********************************************************/  
/*ds18b20 's CRC8 Calibration program */  
/********************** /   
Uchar Calcrc_1byte (uchar abyte)    
{    
   Uchar i,crc_1byte;     
   crc_1byte=0;                Set Crc_1byte initial value to 0 for   
   (i = 0; i < 8; i++)    
    {    
      if (((crc_1byte^abyte) &0x01)    
         {    
           crc_1byte^= 0x18;     
           crc_1byte>>=1;    
           crc_1byte|=0x80;    
          }          
       else     
          crc_1byte>>=1;   
       abyte>>=1;          
     }   
     return crc_1byte;   
}   
Uchar calcrc_bytes (Uchar *p,uchar len)  
{  
 Uchar crc=0;  
 while (len--)//len is the total number of bytes to validate   
  {  
    crc=calcrc_1byte (crc^*p++);  
  }  
 return CRC;  If the final CRC returned is 0, the data transfer is correct   
}  

To tell the truth, before the CRC, and suddenly see the CRC, relatively dizzy, and then looked at the CRC principle, found that CRC actually sub-coding and decoding two processes, wherein the encoding is the data to perform polynomial operations, generate check code

, and then appended to the original data, decoding uses the same polynomial to perform polynomial operations on the data and, if the result is 0, indicates that the data is correct. After understanding the CRC calibration principle, in the analysis of Figure 1, it is not difficult to understand that this is the process of production of CRC, can also be used to solve the CRC, but here we only need to DS18B20 generated EEPROM in 8 bytes of data generated CRC-8, and then compared with the DS18B20 generated by the CRC value, You can tell if the data is correct. In the analysis Figure 1 o'clock, we can easily go into a trap, that is, input data, it is from a byte low to high input, if you understand this, I think it is very simple, here is a matlab I wrote the calibration program, to help you understand:

CRC = [0 0 0 0 0 0 0 0];% Initialize CRC value from low to high
dat = [1 0 0 0 0 0 0 0];% raw data from low to high for
i=1:8
    crctemp = mod (CRC (1) + DAT (i), 2);
    CRC (1) = CRC (2);
    CRC (2) = CRC (3);
    CRC (3) = mod (CRCTEMP+CRC (4), 2);
    CRC (4) = mod (CRCTEMP+CRC (5), 2);
    CRC (5) = CRC (6);
    CRC (6) = CRC (7);
    CRC (7) = CRC (8);
    CRC (8) = crctemp;
End

Note: The usual CRC check does not look like Ds18b20, and the data is entered in reverse order.