On 12 Dec 2017 at 11:37, Isaac M. Bavaresco wrote:

> > I could spread the CRC8 value over 2 bytes, similar to what I've done w=
ith the digits.=20
> > Though I don't see any major problem with sticking to 1 byte and transl=
ating a CRC=20
> > of 0xFF into say 0x5A. It does feel a little cheeky, but it's not like =
I'm transmitting the=20
> > data between devices... the CRC function will be literally the same cod=
e on the=20
> > same device for both reading and writing.
>=20
> This way, anytime you find a saved CRC value of 0x5A, you will have to
> accept the data if the calculated CRC is 0xFF too.
> It will weaken the confidence on your data.

Agreed, there were 1 in 256 patterns in 10^6 or 0.36% that have the CRC val=
ue=20
0x5A, now there will be twice as many: 2 in 256 or 0.78%. It doesn't change=
 the=20
odds for the other 254 out of 256 possible CRC values, so not a huge weakne=
ss.

Just reminding myself why I am doing this: By avoiding 0xFF as a CRC value =
I=20
avoid incorrectly reading as valid a record where the data was written to E=
EPROM=20
but the CRC was never written (which normally happens after validation), wi=
th 0xFF=20
simply being the erased state of the EEPROM.

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.