CRC16(ModBus) на С для ATmega128, помогите разобраться Опции

[sf9]

Всем доброе время суток!
Прошу помочь мне разобраться в С коде.Сам только недавно начал осваивать.
нужно реализовать CRC16 для ModBus.
Я знаю,что есть куча готовых реализаций.Простым(последовательным) и табличным способом.
Но хочу реализовать сам.
У меня проблема в том,что для вычисления CRC нужно смотреть на состояние младшого бита. Если "1" - то выполнять XOR,если нет,то крутить дальше.

Вот мой код:

int crc16 (unsigned char a) // a - 8-bit data for calculation CRC
{
unsigned int reg, tmp;
int i;

reg = 0xFFFF; // step1: initial loading of 16-bit register
reg ^= (unsigned int)a; // step2: a XOR reg

for(i = 0;i<8;i++) //step3: 8-iteration to calculate CRC
{
reg >>= 1;
tmp = reg;
tmp <<= 15;
if(tmp == 0x8000) reg ^= 0xA001; // checking: if LSB = "1" reg=reg^0xA001
}
return reg;
}

проверку я выолняю поразрядным сдвигом 16-битного reg влево, и, если там "1",то xor.

ниже преведена другая реализация CRC16 и она работет корректно!!!!

int crc16 (unsigned char a)
{
unsigned int reg;
unsigned char i, tmp;

reg = 0xFFFF;
reg ^= (unsigned int)a;
for(i = 0;i<8;i++)
{
tmp = (unsigned char)(reg&0x0001);
reg >>= 1;
if(tmp) reg ^= 0xA001;
}
return reg;
}

Поясните,что не так в первой реализачии.

[Rst7]

Идея простая, как веник.

Только таблички в ОЗУ надо хранить. А это вечно недостающий ресурс.

Ну и пара огрехов других, например, надо сдвигать yl влево на один бит. Ну или y+ заменить на y и subi yl,0-16 - это тоже тактов не добавит.

[ReAl]

Ну и пара огрехов других, например, надо сдвигать yl влево на один бит.

Это ладно, я не это имел ввиду, когда писал

И что, именно этот веник действительно метёт?

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

Код

extern uint16_t crctable[32];
uint16_t crc;

void crc_update(uint8_t data) {
    crc ^= crctable[ data & 0x0F ];
    crc ^= crctable[ 16 + (data >>4) ];
}

Что-то не пахнет тут CRC.
Мне кажется, что это ничем не лучше простой XORки всех байтов сообщения.
Независимо от таблицы реакция на последовательность 0xA5 0xC3 будет та же, что и на
0xC3 0xA5 или на 0xC5 0xA3.

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

[=GM=]

Что-то не пахнет тут CRC. Мне кажется, что это ничем не лучше простой XORки всех байтов сообщения. Независимо от таблицы реакция на последовательность 0xA5 0xC3 будет та же, что и на 0xC3 0xA5 или на 0xC5 0xA3

А вот интересно, какая по-вашему будет crc для последовательностей
1) 0xA5, 0xC3
2) 0xC3, 0xA5
3) 0xC5, 0xA3 ?

Таблица для справки

Код

LOCAL_D int  crcbuf[256]=
{
0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7,
0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF,
0x1231,0x0210,0x3273,0x2252,0x52B5,0x4294,0x72F7,0x62D6,
0x9339,0x8318,0xB37B,0xA35A,0xD3BD,0xC39C,0xF3FF,0xE3DE,
0x2462,0x3443,0x0420,0x1401,0x64E6,0x74C7,0x44A4,0x5485,
0xA56A,0xB54B,0x8528,0x9509,0xE5EE,0xF5CF,0xC5AC,0xD58D,
0x3653,0x2672,0x1611,0x0630,0x76D7,0x66F6,0x5695,0x46B4,
0xB75B,0xA77A,0x9719,0x8738,0xF7DF,0xE7FE,0xD79D,0xC7BC,
0x48C4,0x58E5,0x6886,0x78A7,0x0840,0x1861,0x2802,0x3823,
0xC9CC,0xD9ED,0xE98E,0xF9AF,0x8948,0x9969,0xA90A,0xB92B,
0x5AF5,0x4AD4,0x7AB7,0x6A96,0x1A71,0x0A50,0x3A33,0x2A12,
0xDBFD,0xCBDC,0xFBBF,0xEB9E,0x9B79,0x8B58,0xBB3B,0xAB1A,
0x6CA6,0x7C87,0x4CE4,0x5CC5,0x2C22,0x3C03,0x0C60,0x1C41,
0xEDAE,0xFD8F,0xCDEC,0xDDCD,0xAD2A,0xBD0B,0x8D68,0x9D49,
0x7E97,0x6EB6,0x5ED5,0x4EF4,0x3E13,0x2E32,0x1E51,0x0E70,
0xFF9F,0xEFBE,0xDFDD,0xCFFC,0xBF1B,0xAF3A,0x9F59,0x8F78,
0x9188,0x81A9,0xB1CA,0xA1EB,0xD10C,0xC12D,0xF14E,0xE16F,
0x1080,0x00A1,0x30C2,0x20E3,0x5004,0x4025,0x7046,0x6067,
0x83B9,0x9398,0xA3FB,0xB3DA,0xC33D,0xD31C,0xE37F,0xF35E,
0x02B1,0x1290,0x22F3,0x32D2,0x4235,0x5214,0x6277,0x7256,
0xB5EA,0xA5CB,0x95A8,0x8589,0xF56E,0xE54F,0xD52C,0xC50D,
0x34E2,0x24C3,0x14A0,0x0481,0x7466,0x6447,0x5424,0x4405,
0xA7DB,0xB7FA,0x8799,0x97B8,0xE75F,0xF77E,0xC71D,0xD73C,
0x26D3,0x36F2,0x0691,0x16B0,0x6657,0x7676,0x4615,0x5634,
0xD94C,0xC96D,0xF90E,0xE92F,0x99C8,0x89E9,0xB98A,0xA9AB,
0x5844,0x4865,0x7806,0x6827,0x18C0,0x08E1,0x3882,0x28A3,
0xCB7D,0xDB5C,0xEB3F,0xFB1E,0x8BF9,0x9BD8,0xABBB,0xBB9A,
0x4A75,0x5A54,0x6A37,0x7A16,0x0AF1,0x1AD0,0x2AB3,0x3A92,
0xFD2E,0xED0F,0xDD6C,0xCD4D,0xBDAA,0xAD8B,0x9DE8,0x8DC9,
0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1,
0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8,
0x6E17,0x7E36,0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0
};

[ReAl]

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

А вот интересно, какая по-вашему будет crc для последовательностей
1) 0xA5, 0xC3
2) 0xC3, 0xA5
3) 0xC5, 0xA3 ?

Ну я не факир-вычислитель, сразу так не скажу, но что она будет разной - уверен. Какой именно будет - сейчас сбацаем тест.

Таблица для справки

Код

LOCAL_D int  crcbuf[256]=
{
0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7,
...};

Таблица не для того полинома и направления сдвига, который обсуждается в теме, ну да ладно... Для основной темы это только частичный оффтопик, но тема веников наконец-то будет раскрыта.

CODE

#include <stdint.h>
#include <stdio.h>

uint16_t crctable[256]=
{
0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7,
0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF,
0x1231,0x0210,0x3273,0x2252,0x52B5,0x4294,0x72F7,0x62D6,
0x9339,0x8318,0xB37B,0xA35A,0xD3BD,0xC39C,0xF3FF,0xE3DE,
0x2462,0x3443,0x0420,0x1401,0x64E6,0x74C7,0x44A4,0x5485,
0xA56A,0xB54B,0x8528,0x9509,0xE5EE,0xF5CF,0xC5AC,0xD58D,
0x3653,0x2672,0x1611,0x0630,0x76D7,0x66F6,0x5695,0x46B4,
0xB75B,0xA77A,0x9719,0x8738,0xF7DF,0xE7FE,0xD79D,0xC7BC,
0x48C4,0x58E5,0x6886,0x78A7,0x0840,0x1861,0x2802,0x3823,
0xC9CC,0xD9ED,0xE98E,0xF9AF,0x8948,0x9969,0xA90A,0xB92B,
0x5AF5,0x4AD4,0x7AB7,0x6A96,0x1A71,0x0A50,0x3A33,0x2A12,
0xDBFD,0xCBDC,0xFBBF,0xEB9E,0x9B79,0x8B58,0xBB3B,0xAB1A,
0x6CA6,0x7C87,0x4CE4,0x5CC5,0x2C22,0x3C03,0x0C60,0x1C41,
0xEDAE,0xFD8F,0xCDEC,0xDDCD,0xAD2A,0xBD0B,0x8D68,0x9D49,
0x7E97,0x6EB6,0x5ED5,0x4EF4,0x3E13,0x2E32,0x1E51,0x0E70,
0xFF9F,0xEFBE,0xDFDD,0xCFFC,0xBF1B,0xAF3A,0x9F59,0x8F78,
0x9188,0x81A9,0xB1CA,0xA1EB,0xD10C,0xC12D,0xF14E,0xE16F,
0x1080,0x00A1,0x30C2,0x20E3,0x5004,0x4025,0x7046,0x6067,
0x83B9,0x9398,0xA3FB,0xB3DA,0xC33D,0xD31C,0xE37F,0xF35E,
0x02B1,0x1290,0x22F3,0x32D2,0x4235,0x5214,0x6277,0x7256,
0xB5EA,0xA5CB,0x95A8,0x8589,0xF56E,0xE54F,0xD52C,0xC50D,
0x34E2,0x24C3,0x14A0,0x0481,0x7466,0x6447,0x5424,0x4405,
0xA7DB,0xB7FA,0x8799,0x97B8,0xE75F,0xF77E,0xC71D,0xD73C,
0x26D3,0x36F2,0x0691,0x16B0,0x6657,0x7676,0x4615,0x5634,
0xD94C,0xC96D,0xF90E,0xE92F,0x99C8,0x89E9,0xB98A,0xA9AB,
0x5844,0x4865,0x7806,0x6827,0x18C0,0x08E1,0x3882,0x28A3,
0xCB7D,0xDB5C,0xEB3F,0xFB1E,0x8BF9,0x9BD8,0xABBB,0xBB9A,
0x4A75,0x5A54,0x6A37,0x7A16,0x0AF1,0x1AD0,0x2AB3,0x3A92,
0xFD2E,0xED0F,0xDD6C,0xCD4D,0xBDAA,0xAD8B,0x9DE8,0x8DC9,
0x7C26,0x6C07,0x5C64,0x4C45,0x3CA2,0x2C83,0x1CE0,0x0CC1,
0xEF1F,0xFF3E,0xCF5D,0xDF7C,0xAF9B,0xBFBA,0x8FD9,0x9FF8,
0x6E17,0x7E36,0x4E55,0x5E74,0x2E93,0x3EB2,0x0ED1,0x1EF0
};


uint16_t gm_crc_update(uint16_t crc, uint8_t data)
{
return crc ^ crctable[ data ];
}


uint16_t canonical_crc_update(uint16_t crc, uint8_t data)
{
crc = crc ^ ((uint16_t)data << 8);
for (int i=0; i<8; i++) {
if (crc & 0x8000)
crc = (crc << 1) ^ 0x1021;
else
crc <<= 1;
}

return crc;
}


uint16_t fast_table_crc_update(uint16_t crc, uint8_t data)
{
uint8_t index = (crc >> 8) ^ data;
crc = (crc << 8) ^ crctable[index];
return crc;
}


uint16_t fast_non_table_crc_update(uint16_t crc, uint8_t data)
{
uint8_t carry = (crc >> 8) ^ data;
carry = carry ^ (carry >> 4);
crc = (((crc ^ (carry << 4)) << 8) | carry) ^ (carry << 5);
return crc;
}


//-------------------------------------------------------------------------

uint16_t calc_crc( uint16_t (*crc_update)(uint16_t, uint8_t), const uint8_t *buf, int len)
{
uint16_t crc = 0;
while(len--)
crc = crc_update(crc, *buf++);
return crc;
}

void show_crc( uint16_t (*crc_update)(uint16_t, uint8_t), const uint8_t *buf, int len)
{
printf("crc = %04X for buf = ", calc_crc( crc_update, buf, len) );
for(int i = 0; i < len; ++i)
printf(" %2X", buf[i]);
putchar('\n');
}

const uint8_t buf1[] = { 0xA5, 0xC3 };
const uint8_t buf2[] = { 0xC3, 0xA5 };
const uint8_t buf3[] = { 0xC5, 0xA3 };


int main()
{
printf("\n=== GM super-fast table algorithm ==========\n");
show_crc( gm_crc_update, buf1, sizeof(buf1) );
show_crc( gm_crc_update, buf2, sizeof(buf2) );
show_crc( gm_crc_update, buf3, sizeof(buf3) );

printf("\n=== Canonical bitwise algorithm ============\n");
show_crc( canonical_crc_update, buf1, sizeof(buf1) );
show_crc( canonical_crc_update, buf2, sizeof(buf2) );
show_crc( canonical_crc_update, buf3, sizeof(buf3) );

printf("\n=== Correct table bytewise algorithm =======\n");
show_crc( fast_table_crc_update, buf1, sizeof(buf1) );
show_crc( fast_table_crc_update, buf2, sizeof(buf2) );
show_crc( fast_table_crc_update, buf3, sizeof(buf3) );

printf("\n=== Fast non-table bytewise algorithm =======\n");
show_crc( fast_non_table_crc_update, buf1, sizeof(buf1) );
show_crc( fast_non_table_crc_update, buf2, sizeof(buf2) );
show_crc( fast_non_table_crc_update, buf3, sizeof(buf3) );
}

Код

===  GM super-fast table algorithm ==========
crc = 0C60 for buf =  A5 C3
crc = 0C60 for buf =  C3 A5
crc = 0C60 for buf =  C5 A3

===  Canonical bitwise algorithm ============
crc = 0BA4 for buf =  A5 C3
crc = A648 for buf =  C3 A5
crc = 6C28 for buf =  C5 A3

===  Correct table bytewise algorithm =======
crc = 0BA4 for buf =  A5 C3
crc = A648 for buf =  C3 A5
crc = 6C28 for buf =  C5 A3

===  Fast non-table bytewise algorithm =======
crc = 0BA4 for buf =  A5 C3
crc = A648 for buf =  C3 A5
crc = 6C28 for buf =  C5 A3

Dixi

[=GM=]

Ну, я не упорствую, но вот это ваше "return crc^crctable[data]" как-то слишком прямолинейно, даже для меня. Это ж просто выборка из таблицы для вычисления цкс, а можно сделать выборку, используя тетрады данных, тогда размер таблицы уменьшится с 512 байт до 64 байт, надеюсь, вам это понятно. Собственно вот код, который так и делает. Как видите, веник метёт, и неплохо(:-).

Код

crcloop: ld      data,z+
         eor     data,crch
         mov     crch,crcl
         mov     yl,data
         andi    yl,0x0F
         ld      crcl,y
         ldd     tmp,y+16
         eor     crch,tmp
         eor     yl,data
         swap    yl
         ldd     tmp,y+32
         eor     crcl,tmp
         ldd     tmp,y+48
         eor     crch,tmp
         dec     datcnt
         brne    crcloop

Для ваших тестовых строк даёт те же цкс

Код

        .db   0xA5,0xC3      ;CRC=0x0BA4
        .db   0xC5,0xA3      ;CRC=0x6С28
        .db   0xC3,0xA5      ;CRC=0xA648

(Замечу в скобках, обычно цкс начинают считать с 0xFFFF, а не с 0х0000 как у вас)

[ReAl]

Ну, я не упорствую, но вот это ваше "return crc^crctable[data]" как-то слишком прямолинейно, даже для меня. Это ж просто выборка из таблицы для вычисления цкс, а можно сделать выборку, используя тетрады данных, тогда размер таблицы уменьшится с 512 байт до 64 байт, надеюсь, вам это понятно.

Понятно, именно потому при переводе Вашего ассемблерного кода на С я оставил потетрадное обращение.
Однако с каких это пор return crc^crctable[data] моё?
Я только ушёл от глобальной переменной, мне так удобнее было. И "это ж просто выборкой" оно стало, когда стало "моим", а пока было Ваше, оно было "чисто табличным методом вычисления CRC":

Я бы ещё усилил, примерно так

Код

void crc_update(uint8_t data)
{
  crc ^= crctable2[ data ];
}

А это чисто табличный метод счёта crc. Возражения есть(:-)?

Ну так что, оно таки считает CRC ???
Вы сами сказали, что оно "эквивалентно" тому, что я написал в качестве аналога Вашего ассемблерного кода.
Не этого, конечно:

Код

crcloop: ld      data,z+
         eor     data,crch
         mov     crch,crcl
         mov     yl,data
         andi    yl,0x0F
         ld      crcl,y
         ldd     tmp,y+16
         eor     crch,tmp
         eor     yl,data
         swap    yl
         ldd     tmp,y+32
         eor     crcl,tmp
         ldd     tmp,y+48
         eor     crch,tmp
         dec     datcnt
         brne    crcloop

А этого:

Идея простая, как веник. Ну вот как-то так, таблица должна быть настроена на границу 256 байт, можно и 64.

Код

        lxi     yh,high(crctable)
        mov     yl,data
        ani     yl,0x0F
        ld      tmp,y+
        eor     crcl,tmp
        ld      tmp,y+
        eor     crch,tmp
        mov     yl,data
        swap    yl
        ani     yl,0x0F
        sbci    yl,-32
        ld      tmp,y+
        eor     crcl,tmp
        ld      tmp,y+
        eor     crch,tmp

Который таки считает CRC или нет? Честно говоря, на моё замечание об одинаковости результата для разных двухбайтовых последовательностей я ожидал от Вас чего-то в духе "ой, если так, то я где-то на ночь глядя ошибся, сейчас гляну". Вместо этого Вы поинтересовались моим мнением "так какая же CRC должна быть" и предложили табличку.
Если бы с самого начала код хоть немного был похож на тот, который теперь, я бы ни слова не сказал. А так - для демонстрации считывания из двух маленьких таблиц тут слишком много лишнего, для демонстрации вычисления CRC слишком многого недостаёт.
(Ну, возможно повторил бы мысль Rst7, что ОЗУ чаще жалко, чем код, и даже сотношение 64ОЗУ : 512флеша лучше в сторону процентов от флеша, чем оно обычно у AVR. В случае же LPM вместо LDD добавится эдак 6-8 тактов и выиграша по скорости у "быстрого бестабличного" метода не будет)

Для ваших тестовых строк даёт те же цкс

Код

        .db   0xA5,0xC3      ;CRC=0x0BA4
        .db   0xC5,0xA3      ;CRC=0xA648
        .db   0xC3,0xA5      ;CRC=0x6C28

Теперь даёт.

(Замечу в скобках, обычно цкс начинают считать с 0xFFFF)

Разные CRC принято считать начиная с разного инициализатора. Полином из Вашей таблички применяется в протоколе XMODEM_CRC с инициализацией нулями, о чём уже сказано.
Была бы предложена другая табличка, я бы глянул, что принято для того полинома для сравнимости результатов.

Так что не всегда с FF(FF) начинают, зависит от применения, хотя конечно для обсуждаемого здесь Modbus начинают всегда с 0xFFFF,
и начинать с 0 для передачи по UART плохо...

Для XMODEM, на мой взгляд, всё равно.
Пакет начинается с ненулевого спецсимвола и после него в аккумуляторе CRC будет уже не ноль, проблема неразличения последовательностей нулей разной длины в начале пакета пропадает.
А до него и пакет не начался.

[=GM=]

Вы сами сказали, что оно "эквивалентно" тому, что я написал в качестве аналога Вашего ассемблерного кода

Ну, я рад, что все высказали всё, что хотели(:-). Кое-чему и поучиться можно было. Со своей стороны отмечу только, что до поста #16 у меня даже понятия не было о реализации подобным образом, идея возникла спонтанно. И самым сложным для меня было показать, каким образом получить цкс из укороченной таблицы, конечно, надо было обозвать операцию типа crclut, а не crc, что привело к ошибочному пониманию метода. Была ещё одна идея, как посчитать цкс без таблиц, занимает от 16 до 32 тактов, в среднем 24, ну это уже неинтересно.