Being a stickler here...
> To calculate the CRC...
This is not a crc but a checksum with only 255 possible values (an lrc
does the same trick with xor rather than addition).
Crc is 16 bit with 2^8 more combinations. C implementation is simple and
on the web.
-Rob Milne
Help needed storing array in EEPROM
Started by ●March 26, 2005
Reply by ●March 28, 20052005-03-28
Reply by ●March 28, 20052005-03-28
In a message dated 3/28/05 12:13:08 P.M. Eastern Standard Time,
robmilne@robm... writes:
Being a stickler here...
> To calculate the CRC...
This is not a crc but a checksum with only 255 possible values (an lrc
does the same trick with xor rather than addition).
Crc is 16 bit with 2^8 more combinations. C implementation is simple and
on the web.
-Rob Milne
======================
Hi Rob. Isnt a checksum just as good as a crc in applications where multiple
bit errors and byte swapping dont occur? In other words, if you add up a
dozen bytes and swap 2 of em, you get the same checksum, but not the same crc.
That would be bad for typing in a lat/long for example, but reading a byte back
from rom would be detected by the checksum calc no prob, right?
Reply by ●March 28, 20052005-03-28
I have a very good paper calle "A Painless Guide to CRC error detection
algoritihms", whi I got from
ftp://ftp.rocksoft.com/papers/crc/crc_v3.txt
However, it doesn't seem to be there right now. If you like, I can see
if I have a machine-readable copy somewhere.
And Rob, I believe you get 65280 more combinations! (65536-256) :-)
but there I go splitting hairs again!
cheers,
Nigel
BobGardner@BobG... wrote:
>
>In a message dated 3/28/05 12:13:08 P.M. Eastern Standard Time,
>robmilne@robm... writes:
>
>Being a stickler here... >
>>To calculate the CRC...
>>
>>
>
>This is not a crc but a checksum with only 255 possible values (an lrc
>does the same trick with xor rather than addition).
>
>Crc is 16 bit with 2^8 more combinations. C implementation is simple and
>on the web.
>
>-Rob Milne >
>
>======================
>Hi Rob. Isnt a checksum just as good as a crc in applications where multiple
>bit errors and byte swapping dont occur? In other words, if you add up a
>dozen bytes and swap 2 of em, you get the same checksum, but not the same crc.
>That would be bad for typing in a lat/long for example, but reading a byte back
> from rom would be detected by the checksum calc no prob, right? >
>
>Yahoo! Groups Links >
>
--
Nigel Johnson
MCSE, MIEEE
VE3ID/G4AJQ
http://nigel.homelinux.net
If time travel ever will be possible, it already is. Ask me again yesterday
algoritihms", whi I got from
ftp://ftp.rocksoft.com/papers/crc/crc_v3.txt
However, it doesn't seem to be there right now. If you like, I can see
if I have a machine-readable copy somewhere.
And Rob, I believe you get 65280 more combinations! (65536-256) :-)
but there I go splitting hairs again!
cheers,
Nigel
BobGardner@BobG... wrote:
>
>In a message dated 3/28/05 12:13:08 P.M. Eastern Standard Time,
>robmilne@robm... writes:
>
>Being a stickler here... >
>>To calculate the CRC...
>>
>>
>
>This is not a crc but a checksum with only 255 possible values (an lrc
>does the same trick with xor rather than addition).
>
>Crc is 16 bit with 2^8 more combinations. C implementation is simple and
>on the web.
>
>-Rob Milne >
>
>======================
>Hi Rob. Isnt a checksum just as good as a crc in applications where multiple
>bit errors and byte swapping dont occur? In other words, if you add up a
>dozen bytes and swap 2 of em, you get the same checksum, but not the same crc.
>That would be bad for typing in a lat/long for example, but reading a byte back
> from rom would be detected by the checksum calc no prob, right? >
>
>Yahoo! Groups Links >
>
--
Nigel Johnson
MCSE, MIEEE
VE3ID/G4AJQ
http://nigel.homelinux.net
If time travel ever will be possible, it already is. Ask me again yesterday
Reply by ●March 28, 20052005-03-28
Well, yes, if as you say only a single byte is wrong and there are no
endian considerations then a checksum is adequate. If two bytes go wrong
in just the right way then the checksum is useless. Crc16 can be likewise
spoofed (with difficulty) and thus the need for SHA1, etc. with secure
stuff. Personally I feel that crc16 is overkill except for integrity
checks on large binaries. A RFID driver that I worked with recently used
crc16 for small transactions which was complete overkill.
endian considerations then a checksum is adequate. If two bytes go wrong
in just the right way then the checksum is useless. Crc16 can be likewise
spoofed (with difficulty) and thus the need for SHA1, etc. with secure
stuff. Personally I feel that crc16 is overkill except for integrity
checks on large binaries. A RFID driver that I worked with recently used
crc16 for small transactions which was complete overkill.
Reply by ●March 28, 20052005-03-28
