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

Question

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

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

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

Answer 1

вы можете реализовать 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 бит после обработки инвертируется по битам; «swap result» означает, что два байта в результате заменяются после обработки.

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

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

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

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

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

Answer 2

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

Большинство программных реализаций 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 

реализация Кермит использует:

0x8408 == 1000 0100 0000 1000 binary 

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

Текстового файл, который сопровождает библиотека также упоминает следующее значение для Кермита:

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

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