Почему CRC, равный "1", дает сам полином-генератор? - PullRequest
Новая
       87

Почему CRC, равный "1", дает сам полином-генератор?

0 голосов
/ 07 октября 2018

При тестировании реализации CRC я заметил, что CRC 0x01 обычно (?), Кажется, сам полином.Однако, пытаясь вручную выполнить двоичное длинное деление, я все время теряю ведущую «1» полинома, например, с сообщением «0x01» и полиномом «0x1021», я получаю 

      1 0000 0000 0000 (zero padded value)
(XOR) 1 0000 0010 0001
-----------------
      0 0000 0010 0001 = 0x0021

Но любая примерная реализация (я имею в виду XMODEM-CRC здесь) приводит к 0x1021 для данного ввода.

Глядя на https://en.wikipedia.org/wiki/Computation_of_cyclic_redundancy_checks, Я могу видеть, как шаг XOR старшего битавыход из регистра сдвига с полиномом генератора вызовет этот результат.Что я не понимаю, так это то, почему этот шаг вообще выполняется таким образом, поскольку он явно меняет результат истинного полиномиального деления?

1 Ответ

0 голосов
/ 07 октября 2018

Я только что прочитал http://www.ross.net/crc/download/crc_v3.txt и заметил, что в разделе 9 есть упоминание о неявно добавленном 1 для обеспечения требуемой ширины полинома.

В моем примере это означает, что фактический полином, используемый в качестве делителя, будет не 0x1021, а 0x11021.Это приводит к удалению первой «1», а оставшейся части является «предполагаемый» 16-разрядный полином: 

      1 0000 0000 0000 0000 (zero padded value)
(XOR) 1 0001 0000 0010 0001
-----------------
      0 0001 0000 0010 0001 = 0x1021
...