Вот здесь тренируюсь:
http://crccalc.com/

Почитал здесь для просветления в тонких местах:
https://ru.wikipedia.org/wiki/%D0%A6%D0%B8%...%BA%D0%BE%D0%B4

Ввожу число: 00000000 Hex, вычисляю CRC-32. Для CRC-32/MPEG-2 вижу результат 0xC704DD7B.
Добавляю его к данным: 00000000 C704DD7B
Вычисляю, получаю CRC-32/MPEG-2 0x00000000.
Здесь все понятно, поскольку биты входных данных и результата не реверсируются и выход не инвертируется. С инверсией выхода тоже понятно.

А как дополнить данные, если делается реверс битов? Что добавить к данным 00000000, чтобы результат стал 0x00000000? Что-то не получается.

Разобрался. Для RefIn true, RefOut true, XorOut 0xFFFFFFFF нужно CRC инвертировать и изменить порядок байтов (не битов!).

Для 00000001 CRC-32 = 0x5643EF8A, инверсия: 0xA9BC1075, перестановка байтов: 0x7510BCA9
Для 00000001 7510BCA9 CRC-32 = 0xFFFFFFFF

Почему так? Нет ли ошибки в расчетах на сайте?

Данные можно задавать в поле в таком виде:
00 00 00 01
По байтам. Ничего не меняется.
Ага, значит, CRC работает с байтами. Поэтому результат CRC нужно просто разбить на байты. Но почему тогда CRC без реверса битов не требует перестановки байтов?

>> Ага, значит, CRC работает с байтами.
Вообще, CRC работает с битами. Потомукак реализован в виде сдвигового регистра.
Если считается CRC фрейма в канале связи/контроллере, то там байтов еще не наблюдается.
Настройки заключаются в том как байты или слова различной разрядности преобразуются в этот битовый поток.
ps - табличное вычисление - понятно, что это соптимизированный алгоритм.

Я соображаю, как рассчитывается CRC, однако реализация алгоритма может быть разной.
В STM32 загружается 32-битовое слово и получается 32-битовый результат. Как оно внутри процессора перемалывается, мне неведомо и неважно. Мне надо знать, какое слово подать, чтобы CRC обнулить.

CRCn- это остаток от деления на неприводимый многочлен степени n над GF(2). Чтобы получить нулевую CRC, можно взять значение CRC исходного сообщения, дописать к нему n нулей, вычислить CRC от получившегося короткого сообщения длины 2n и эту новую CRC вычесть ("исключающее или" ) из этого самого короткого сообщения в 2n разрядов. Вот в случае MPEG это самое и проделано )

Если в конце CRC инвертируется, то ее нужно обратно инвертировпть (вот это вот самое
)
А порядок байтов, это, вероятно, из-за little endian - как оно будет выглядеть в памяти, если его записать 32-р числом вслед за строкой байтов? )

Сообщение отредактировал Serge V Iz - May 16 2018, 17:21

Да, правильно. Не так я задавал числа в первом сообщении.

Вот последовательность для CRC-32/JAMCRC:

00000000 01000000 02000000 03000000 CRC-32/JAMCRC = 0xD8715056
00000000 01000000 02000000 03000000 565071D8 CRC-32/JAMCRC = 0x00000000

Т.е., добавляю то же число, посчитанную CRC, просто в окне нужно задавать данные, расположенные по байтам в памяти (little-endian).

В STM32 в функции вычисления CRC реверсирую биты входных данных, аналогично задаю массив:
uint32_t Num[] = { [0] = 0, [1] = 1, [2] = 2, [3] = 3, [4] = 0xD8715056 };
И вычисляется в результате 0x00000000.
Xor выходную не использую.

А для чего это?
для сверки какая разница - ноль или не ноль...
для совсем надежности - два разных алгоритма, тогда подбор "до нуля" теряет смысл, слишком много комбинаций. Тем более, если все место занято именно исполняемым кодом, а не некритичными данными

Не понял, про какой ноль идет речь.
Задача простая. К структуре данных в микроконтроллере по вычисленной CRC данных добавить CRC-дополнение для контроля целостности. Потом, вычисляя CRC "структуры, дополненной CRC" получу результат 0x00000000 или 0xFFFFFFFF (если инверсию на выходе сделаю).
Есть значения элементов структуры по умолчанию. Вот для них хочу вычислить CRC онлайн калькулятором, но таким алгоритмом, чтобы совпадал с функцией внутри микроконтроллера. И сразу забить их в исходный код программы.

Для показанного онлайн калькулятора нашел дополнения для всех CRC. Но остаюсь в недоумении.
Если инверсия выхода не делается, то биты CRC данных в дополнении не инвертируются. Это понятно.
Если реверс входных (и выходных) битов не делается, то байты дополнения задаются в порядке big-endian. Если биты реверсируются, то порядок байтов little-endian. Вот эта особенность мне непонятна!

Ну, для своей задачи я научился считать CRC. Дополняю свои данные CRC-32/JAMCRC. Вычисляю в процессоре CRC с реверсом битов. Проверил в отладчике.

Теперь понятно. Просто сталкивался с модулями флеш-памяти, где умельцы модифицировали код, а потом изменением 4х байт добивались восстановления CRC32 до исходной. Показалось, что здесь решается схожая задача

Ну, средство то же. Цель только другая.

А какой практических смысл таких усилий? Зачем это всё?

Структура, содержащая переменные, управляющие режимами работы прибора, находится в памяти с батарейным питанием. При включении прибора нужно проверить ее целостность.

когда надо экономить наносекунды при получении информаци - скоростные коммутаторы пакетов итп. и аппаратной реализации.

А поподробней можно?

Я не спрашиваю "зачем Вам CRC?" Я спрашиваю "Чем не устраивает простая операция == для проверки правильности CRC?"


Ничего не понял....
Почему не:

???

Так бы и говорили.
А чем ваша операция лучше? CRC все равно нужно хранить. Так почему бы не хранить ее такой, что при проверке структуры вместе с CRC получится 0? Небось, на ноль проверять приятнее.
if (!(CRC32(&data, sizeof(data))) printf("CRC OK");