Problem in this checksum method!!!!!!!!!!!!

[absfast123]

I have got checksum method from a book. that is
1) add all bytes dropping carries (example add all bytes into a byte type variable)
2) takes invert of all bytes sum add 1 (it will be 2's compliment)
3) this will be the checksum

verification:
add all bytes and checksum the answer will the 0
if not it means wrong checksum
problem is that in electronics world many times if there is a problem in PIN that will be low(o). if that is the data pin then all data will be the zero, hence checksum will also be the zero and upon verification it will say correct data arrived. I need its solution.
code of upper algo is as

unsigned char calc_checksum(unsigned char *Array,unsigned char len)
{
     unsigned char i;
     unsigned char sum=0;
     
     for(i=0;i<len;i++)
     sum+=*Array++;
     return ~sum+1;
     
}

unsigned char verify_checksum(unsigned char *Array,unsigned char len)
{
         unsigned char sum=0;
         while(len--)
          {
          sum+=*Array++;
          }
         if(!sum)
          return 1;
         else
          return 0;
}

.AB Sami

 

[Pommie]

The only solution that springs to mind is to make a packet of all zeroes invalid. So, add a non zero start character.

However, how are you receiving data? Normally you would have some kind of start bit or hardware to ensure random data isn't received.

Mike.

 

[MrAl]

Hi,


It seems to me that if you receive all zero's then you have not actually received any data yet anyway. That should trigger an error by itself.

There are much better check sum algorithms than that one anyway maybe you should check into these on the web.

 

[absfast123]

I have can have data from i2c, spi or manual protocol but this is general checksum method i was using due to this problem i have to revise it. anyway What is the professional checksum method algorithm that results in one byte checksum.

 

[Pommie]

The most common method is a Cyclic Redundancy Check.

Mike.

 

[absfast123]

Thanks Mike,
Do you have any example in c language where crc8 or 7 is implimented.
Regards,
AB sami.

 

[Pommie]

Here is a fast implementation of the CRC8 algorithm as used by the Dallas one wire devices.

unsigned char Dat[8]={0x10,0xDE,0x9A,0x06,0x00,0x08,0x00,0x59};

void main(void)
{	
unsigned char i,temp,CRC;
    CRC=0;
    for(i=0;i<7;i++){
        CRC^=Dat[i];
        temp=0;
        if(CRC&1)
            temp^=0x5e;
        if(CRC&2)
            temp^=0xbc;
        if(CRC&4)
            temp^=0x61;
        if(CRC&8)
            temp^=0xc2;
        if(CRC&16)
            temp^=0x9d;
        if(CRC&32)
            temp^=0x23;
        if(CRC&64)
            temp^=0x46;
        if(CRC&128)
            temp^=0x8c;
        CRC=temp;
    }    
    while(1);
}

The data is from an actual DS18B20 and the last byte is the CRC byte. After completing the loop, CRC will be the same as the last byte of the data. If you change the loop to 8, the CRC will be zero.

Mike.

 

[absfast123]

Hi Mike,
I have understood this algo. but i dont think there is any better thing in crc8 than previous one.what you say.
.AB Sami

 

[Pommie]

I don't understand your question. Actually, I don't know what it is!

Mike.

 

[MrAl]

Hi,


I dont know if you can implement this in your actual application, but if you have the receive device mirror the byte sent it makes it hard not to detect an error.

For example, send the byte 0x34, then wait for an input byte that equals 0x34. If all the pins are stuck low, you'll get 0x00 back instead of 0x34.
If you send 0x00 then you can wait for a mirror of 0xFF or something else. The receiver is responsible for sending the mirror byte back to the transmitter.
The nice thing about this is it doesnt have to use separate pins for input and output if you switch during the sending and receiving.

There are CRC algo's that are pretty good, although it's been a while since i wrote a program for a CRC32 algorithm so i dont remember too much of the theory now. The basic idea is that a single bad byte of data can change the entire crc code rather than just one byte, so it's probably better if you are using a 16 bit CRC code.

Remember also that any 8 bit error detection scheme has a fairly high collision probability, while 16 bit is much better and of course 32 bit is incredibly hard to get the wrong result with.