Re: CRC versus CheckSum



Robert Adsett wrote:
In article <2ridnYl6zIxM-6ranZ2dnUVZ_hudnZ2d@xxxxxxxxxxxx>, msg says...

Hi,
I have a situation where I have a byte in which to place either a checksum
or a CRC.
I am on an embedded system.
I am using a checksum that is

BYTE create_csum(BYTE data_in,BYTE csum)
{
csum += data_in + 3;
while ((csum == 0) || (csum == 0xff))
csum += 3;
return(csum);
}

This function elimitates 0x00 and 0xff being calculated.

Our packets cannot have bytes in a packet swapped in order (the transport
layer sees to that) and we are not using the CRC/Checksum to fix bad
packets just to reject them. I contend that in this case the checksum is
jsut as good as the CRC.

Any opinions?


In some sense you are right. It depends on the pattern of errors you expect to correct. CRCs tend to be optimized for detecting short burst errors such as might occur during communication. Simple checksums tend to have a more even distribution of the errors you can detect. Neither detect all errors (there are after all the same number of states for the sum in either case).

For communications I suspect CRC would be better under the assumption that any interference is likely to occur in short bursts.

Write some test code, and try it on what you consider likely error patterns, on both schemes, and see :

Most error sense systems try to cover like this :
100% Single bit errors
xx% Two bit errors
YY% Three bit errors
etc
In a comms link, things like stretched bits, shifted bits
and dropped bits are likely occurances.

The Sum should be designed so a stuck-line gives an invalid answer,
so commonly the sum complements the bytes
eg - everything _including_ the sum = 0FFH on RX, and as Bytes INC, the CkSum decrements.


-jg




.



Relevant Pages

  • Re: CRC versus CheckSum
    ... I have a situation where I have a byte in which to place either a checksum ... Our packets cannot have bytes in a packet swapped in order (the transport ... jsut as good as the CRC. ... errors such as might occur during communication. ...
    (comp.arch.embedded)
  • Re: CRC versus CheckSum
    ... I have a situation where I have a byte in which to place either a checksum ... Our packets cannot have bytes in a packet swapped in order (the transport ... jsut as good as the CRC. ... The Sum should be designed so a stuck-line gives an invalid answer, ...
    (comp.arch.embedded)
  • Re: Opinions on 16-bit checksums.
    ... it's no longer a checksum, ... >> cancel themselves out, but a CRC would. ... I've witnessed no failures or oddities. ... I don't think it can be assumed that ROMs ...
    (comp.arch.embedded)
  • Re: Opinions on 16-bit checksums.
    ... >> possibly result in an unchanged CRC checksum. ... > There are two big reasons CRCs are used in serial communications: ... algorithms that consider the order of the data as well as the value - a ...
    (comp.arch.embedded)
  • Re: Crc16 on power failure
    ... a checksum is faster to calculate than a CRC by software. ... True, they are faster, but they are not nearly as good at detecting ... coonsider running an EEC on each parameter instead of a block check. ...
    (comp.arch.embedded)