Контрольная сумма CRC16: HCS08 против Kermit против XMODEM - PullRequest
Новая
       26

Контрольная сумма CRC16: HCS08 против Kermit против XMODEM

9 голосов
/ 16 декабря 2010

Я пытаюсь добавить обнаружение ошибок CRC16 в приложение микроконтроллера Motorola HCS08. Мои контрольные суммы не совпадают, хотя. Один онлайн-калькулятор CRC предоставляет как результат, который я вижу в своей программе для ПК, так и результат, который я вижу на микро.

Он называет результат микро "XModem", а результат ПК "Kermit".

В чем разница между тем, как эти два древних протокола определяют использование CRC16?

Ответы [ 3 ]

23 голосов
/ 04 августа 2013

вы можете реализовать 16-битные IBM, CCITT, XModem, Kermit и CCITT 1D0F, используя одну и ту же базовую кодовую базу. см. http://www.acooke.org/cute/16bitCRCAl0.html, в котором используется код из http://www.barrgroup.com/Embedded-Systems/How-To/CRC-Calculation-C-Code

В следующей таблице показано, как они отличаются: 

name    polynomial  initial val  reverse byte?  reverse result?  swap result?
CCITT         1021         ffff             no               no            no
XModem        1021         0000             no               no            no
Kermit        1021         0000            yes              yes           yes
CCITT 1D0F    1021         1d0f             no               no            no
IBM           8005         0000            yes              yes            no

где 'обратный байт' означает, что каждый байт перед обработкой инвертируется; «обратный результат» означает, что 16-битный результат инвертируется после обработки; «результат обмена» означает, что два байта в результате заменяются после обработки.

все вышеперечисленное было проверено с помощью тестовых векторов против http://www.lammertbies.nl/comm/info/crc-calculation.html (если это не так, мы все потерялись ...).

так что, в вашем конкретном случае, вы можете преобразовать код для XModem в Kermit, инвертируя биты каждого байта, инвертируя биты в конечном результате, а затем заменяя два байта в результате.

[Я полагаю, но не проверил и не проработал детали, что обращение каждого байта равносильно обращению полинома (плюс некоторые дополнительные детали). вот почему вы увидите очень разные объяснения в разных местах того, что в основном является одним и тем же алгоритмом.

также, описанный выше подход неэффективен, но хорош для тестирования. если вы хотите эффективнее, лучше всего перевести вышеприведенные таблицы в таблицы поиска.]

edit то, что я назвал CCITT выше, задокументировано в каталоге RevEng как CCITT-FALSE. для получения дополнительной информации см. обновление к моему сообщению в блоге по ссылке выше.

4 голосов
/ 16 декабря 2010

Мое воспоминание (я раньше делал модемные вещи, когда), когда Kermit обрабатывает биты в каждом байте данных, используя сначала младший бит.

Большинство программных реализаций CRC (возможно, Xmodem)сначала просмотрите младший байт данных.

При просмотре источника библиотеки (скачайте его с http://www.lammertbies.nl/comm/software/index.html), используемого для страницы вычисления CRC, на которую вы ссылаетесь, вы увидите, что XModem использует CRC16-CCITT, полином для которого: 

x^16 + x^12 + x^5 + 1  /* the '^' character here represents exponentition, not xor */

Полином представлен битовой картой (обратите внимание, что подразумевается бит 16) 

0x1021 == 0001 0000 0010 0001  binary

Реализация Kermit использует: 

0x8408 == 1000 0100 0000 1000  binary

, который является тем же растровым изображением, что и XModem, только в обратном порядке.

В текстовом файле, который сопровождает библиотеку, также упоминается следующая разница для Kermit:

Только для CRC-Kermit и CRC-SICK: после всей обработки ввода вычисляется дополнение к CRC, и два байта CRC меняются местами.

Так что следуетВероятно, будет легко изменить вашу процедуру CRC, чтобы соответствовать результату ПК.Обратите внимание, что источник в библиотеке CRC, кажется, имеет довольно либеральную лицензию - возможно, имеет смысл использовать его более или менее как есть (по крайней мере, части, которые применяются для вашего приложения).

0 голосов
/ 07 августа 2018

X-модем 1K CRC16.

Процесс для байтового CRC-16 с использованием входных данных {0x01, 0x02} и полинома 0x1021

  1. Init crc = 0

  2. Обработка первого входного байта 0x01: 2.1 «Xor-in» первого входного байта 0x01 в MSB (!) Crc: 0000 0000 0000 0000 (crc) 0000 0001 0000 0000 (входной байт 0x01 смещен влево на 8)

    0000 0001 0000 0000 = 0x0100 MSB этого результата является нашей текущей делимой величиной: MSB (0x100) = 0x01.2.2 Итак, 0x01 - это делитель.Получите остаток от делителя из нашей таблицы: crctable16 [0x01] = 0x1021.(Ну, это значение известно из ручного вычисления выше.) Помните, что текущее значение crc составляет 0x0000.Сдвиньте MSB текущего crc и сформите его с текущим остатком, чтобы получить новый CRC: 0001 0000 0010 0001 (0x1021) 0000 0000 0000 0000 (CRC 0x0000 смещено влево на 8 = 0x0000)

    0001 0000 0010 0001 = 0x1021 = промежуточный crc.

  3. Обработка следующего входного байта 0x02: в настоящее время у нас есть промежуточный crc = 0x1021 = 0001 0000 0010 0001. 3.1 входной байт Xor-in0x02 в MSB (!) Crc: 0001 0000 0010 0001 (crc 0x1021) 0000 0010 0000 0000 (входной байт 0x02 смещен влево на 8)

    0001 0010 0010 0001 = 0x1221 MSB этогорезультат - наш текущий делитель: MSB (0x1221) = 0x12.3.2 Итак, 0x12 является делителем.Получите остаток от делителя из нашей таблицы: crctable16 [0x12] = 0x3273.Помните, что текущее значение crc составляет 0x1021.Сдвиньте MSB текущего crc и сформите его с текущим остатком, чтобы получить новый CRC: 0011 0010 0111 0011 (0x3273) 0010 0001 0000 0000 (CRC 0x1021, смещенный влево на 8 = 0x2100)

    0001 0011 0111 0011 = 0x1373 = окончательный CRC.

...