приведение crc32 к uint8_t

У меня есть аппаратный модуль, который может довольно быстро вычислить crc для проекта, над которым я работаю, однако он возвращает 32-битное число (так как это crc32). Мне нужно поместить crc в uint8_t для используемого форматирования протокола.

Я думал, что, поскольку crc представляет собой остаток от 32-битного полиномиального деления, если я просто возьму самый значимый байт, который будет эквивалентом округления остатка до 8 бит. Я понимаю, что у меня не будет возможности обнаруживать ошибки так же хорошо, как с 32-битной CRC, но будет ли это так же хорошо, как выполнение 8-битной CRC в программном обеспечении? Конечно, результат будет одинаковым для обеих сторон, поскольку они оба имеют доступ к одним и тем же данным и полиномам, но будет ли этот результат иметь все свойства CRC?

Спасибо


person othane    schedule 04.03.2013    source источник
comment
Моим первым побуждением было бы использовать 8 младших битов, поскольку они будут перемешивать больше, но этот подход не будет таким сильным, как реальный CRC-8, поскольку вы используете усеченный полином. Рекомендую написать симуляцию для сравнения результатов.   -  person guga    schedule 04.03.2013
comment
Это звучит как разумная идея, я читал, что расстояние Хэмминга (HD) является хорошим показателем того, насколько хорошо работает алгоритм, возможно, я изучу это подробнее. Спасибо.   -  person othane    schedule 05.03.2013


Ответы (2)


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

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

Ниже представлена ​​8-битная реализация CRC с использованием тщательно подобранного 8-битного полинома.

#include <stddef.h>

/* 8-bit CRC with polynomial x^8+x^6+x^3+x^2+1, 0x14D.
   Chosen based on Koopman, et al. (0xA6 in his notation = 0x14D >> 1):
   http://www.ece.cmu.edu/~koopman/roses/dsn04/koopman04_crc_poly_embedded.pdf
 */

static unsigned char crc8_table[] = {
    0x00, 0x3e, 0x7c, 0x42, 0xf8, 0xc6, 0x84, 0xba, 0x95, 0xab, 0xe9, 0xd7,
    0x6d, 0x53, 0x11, 0x2f, 0x4f, 0x71, 0x33, 0x0d, 0xb7, 0x89, 0xcb, 0xf5,
    0xda, 0xe4, 0xa6, 0x98, 0x22, 0x1c, 0x5e, 0x60, 0x9e, 0xa0, 0xe2, 0xdc,
    0x66, 0x58, 0x1a, 0x24, 0x0b, 0x35, 0x77, 0x49, 0xf3, 0xcd, 0x8f, 0xb1,
    0xd1, 0xef, 0xad, 0x93, 0x29, 0x17, 0x55, 0x6b, 0x44, 0x7a, 0x38, 0x06,
    0xbc, 0x82, 0xc0, 0xfe, 0x59, 0x67, 0x25, 0x1b, 0xa1, 0x9f, 0xdd, 0xe3,
    0xcc, 0xf2, 0xb0, 0x8e, 0x34, 0x0a, 0x48, 0x76, 0x16, 0x28, 0x6a, 0x54,
    0xee, 0xd0, 0x92, 0xac, 0x83, 0xbd, 0xff, 0xc1, 0x7b, 0x45, 0x07, 0x39,
    0xc7, 0xf9, 0xbb, 0x85, 0x3f, 0x01, 0x43, 0x7d, 0x52, 0x6c, 0x2e, 0x10,
    0xaa, 0x94, 0xd6, 0xe8, 0x88, 0xb6, 0xf4, 0xca, 0x70, 0x4e, 0x0c, 0x32,
    0x1d, 0x23, 0x61, 0x5f, 0xe5, 0xdb, 0x99, 0xa7, 0xb2, 0x8c, 0xce, 0xf0,
    0x4a, 0x74, 0x36, 0x08, 0x27, 0x19, 0x5b, 0x65, 0xdf, 0xe1, 0xa3, 0x9d,
    0xfd, 0xc3, 0x81, 0xbf, 0x05, 0x3b, 0x79, 0x47, 0x68, 0x56, 0x14, 0x2a,
    0x90, 0xae, 0xec, 0xd2, 0x2c, 0x12, 0x50, 0x6e, 0xd4, 0xea, 0xa8, 0x96,
    0xb9, 0x87, 0xc5, 0xfb, 0x41, 0x7f, 0x3d, 0x03, 0x63, 0x5d, 0x1f, 0x21,
    0x9b, 0xa5, 0xe7, 0xd9, 0xf6, 0xc8, 0x8a, 0xb4, 0x0e, 0x30, 0x72, 0x4c,
    0xeb, 0xd5, 0x97, 0xa9, 0x13, 0x2d, 0x6f, 0x51, 0x7e, 0x40, 0x02, 0x3c,
    0x86, 0xb8, 0xfa, 0xc4, 0xa4, 0x9a, 0xd8, 0xe6, 0x5c, 0x62, 0x20, 0x1e,
    0x31, 0x0f, 0x4d, 0x73, 0xc9, 0xf7, 0xb5, 0x8b, 0x75, 0x4b, 0x09, 0x37,
    0x8d, 0xb3, 0xf1, 0xcf, 0xe0, 0xde, 0x9c, 0xa2, 0x18, 0x26, 0x64, 0x5a,
    0x3a, 0x04, 0x46, 0x78, 0xc2, 0xfc, 0xbe, 0x80, 0xaf, 0x91, 0xd3, 0xed,
    0x57, 0x69, 0x2b, 0x15};

unsigned crc8(unsigned crc, unsigned char *data, size_t len)
{
    unsigned char *end;

    if (len == 0)
        return crc;
    crc ^= 0xff;
    end = data + len;
    do {
        crc = crc8_table[crc ^ *data++];
    } while (data < end);
    return crc ^ 0xff;
}

/* this was used to generate the table and to test the table-version

#define POLY 0xB2

unsigned crc8_slow(unsigned crc, unsigned char *data, size_t len)
{
    unsigned char *end;

    if (len == 0)
        return crc;
    crc ^= 0xff;
    end = data + len;
    do {
        crc ^= *data++;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
        crc = crc & 1 ? (crc >> 1) ^ POLY : crc >> 1;
    } while (data < end);
    return crc ^ 0xff;
}
*/

#include <stdio.h>

#define SIZE 16384

int main(void)
{
    unsigned char data[SIZE];
    size_t got;
    unsigned crc;

    crc = 0;
    do {
        got = fread(data, 1, SIZE, stdin);
        crc = crc8(crc, data, got);
    } while (got == SIZE);
    printf("%02x\n", crc);
    return 0;
}
person Mark Adler    schedule 04.03.2013
comment
Комментарий заголовка в вашем коде упоминает poly 0xA6, который нравится Купману, но более позднее определение - #define POLY 0xB2. Не могли бы вы уточнить? - person srking; 04.03.2013
comment
Есть два способа определить CRC: прямые или обратные биты. Реализации CRC очень часто используют соглашение об обратных битах, что и используется в этой. 0xb2 - это 0x4d в обратном порядке. Другое распространенное соглашение - инвертировать все биты CRC, что позволяет избежать последовательности нулей при нулевом CRC, приводящей к нулевому CRC. Код выше делает то же самое. - person Mark Adler; 05.03.2013
comment
Спасибо, Марк, это лучший ответ, насколько я понимаю. Но я до сих пор не уверен, почему он не будет так хорош, как настоящая 8-битная версия. Я бегло прочитал опубликованную вами статью о выборе полинома для различных методов CRC. Но все же мне не ясно, будет ли старший старший байт улавливать столько же битовых ошибок, сколько 8-битная версия, а если нет, то почему? - person othane; 05.03.2013
comment
Самый простой пример - обнаружение пакетных ошибок. Любая CRC- n может обнаруживать пакетные ошибки длиной n бит в сообщении. CRC-8 гарантированно обнаружит любую комбинацию ошибок длиной 8 бит в любом месте сообщения. Однако 8 бит, извлеченные из CRC-32, не имеют такой гарантии. Есть много других свойств, таких как расстояние Хэмминга, производительность при случайных битовых ошибках при различных коэффициентах ошибок и т. Д., Которые можно измерить, чтобы выбрать хороший полином CRC. Вся эта работа, вложенная в выбор полинома CRC, полностью отбрасывается при использовании подмножества результирующего CRC. - person Mark Adler; 05.03.2013

безусловно, результат будет одинаковым для обеих сторон, поскольку они оба имеют доступ к одним и тем же данным и полиномам.

Нет, не всегда! Прочтите мое объяснение.

но сохранит ли этот результат все свойства crc?

Да, CRC по-прежнему будет CRC. Не имеет значения, какой у него масштаб: 8, 16 или 32 бита.

CRC-8 сортирует все сообщения до одного из ваших 256 значений. Но если ваше сообщение больше нескольких байтов, вероятность того, что несколько входов будут иметь одинаковое хеш-значение, становится все выше и выше.

CRC-8: ‹64 байта

CRC-16: ‹16 Кбайт

CRC-32: ‹512 МБ

CRC-32 дает вам около 4 миллиардов доступных значений хэша, поэтому вероятность того, что несколько входов будут иметь один и тот же хеш, мала.

person 01010100101001010    schedule 04.03.2013
comment
Извините, возможно, было непонятно, что я пытался сказать. Я выполняю расчет CRC с полным 32-битным разрешением с обеих сторон. Это просто сравнение, которое проводится на 8 битах, так как я не могу уместить его в размере пакета протокола. Итак, я понимаю, что 8-битная версия обнаружит меньше битовых ошибок, чем 32-битная версия. Я хочу знать, если я сравню только 8 бит CRC, будут ли они иметь ту же способность обнаружения ошибок, что и использование 8 бит с самого начала? - person othane; 05.03.2013