Vlákno názorů k článku CRC (kontrolní součet) od Jirka - Tak se mi zda, ze na poslednim miste...

Tak se mi zda, ze na poslednim miste takto vygenerovaneho CRC by byla vzdy nula. Totiz na 4. pridanou nulu se pri xorovani dostaneme jen v pripade, ze nulujeme jednicku na 1.miste pridanych 4 cisel, ale to uz je mimo definici. Takze GP je prilis kratky na to, aby zmenil posledni cislo. Je tomu tak?

no, to bude, a ted nevim, jestli je chyba ve me, nebo jestli je to vubec chyba ;-), mno, kazdopadne staci na konec pridat (je-li GP n-bitovy) n-1 nul, a vysledek je n-1 bitovy, ale fakt nevim kde je chyba, mluvi-li se o 16-bit CRC, nemelo by se raci mluvit o 15-bit CRC? Protoze GP je kazdopadne 16-bitovy a ta nula tam skutecne bude.

Je pravda, ze nestavim raketoplan :-), tak to hledat nebudu, ale jako pravdepodobne reseni bych videl, ze 16-bit CRC bude znamenat, ze se prenasi 16 kontrolnich bitu, ale GP bude 17 bit. GP se asi neprenasi, takze to nemusi byt zaokrouhleny :-).

Asi to tak bude (alespoň u některých doporučených GP, např x16+x12+x5+1). GP má 17 bitů, ale při použití tohoto polynomu pro zabezpečení dat na disketě končí pole dvěma byte CRC.
Dík za nasměrování.

Asi trošku pozdě, ale koukni se na:
https://www.maximintegrated.com/en/app-notes/index.mvp/id/27