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 как у вас)

[defunct]

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

Код

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

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

У вас ошибка CRC. Модбас работать не будет.
Д.б. сл. значения

.db 0xA5,0xC3 ;CRC=0xB13A
.db 0xC5,0xA3 ;CRC=0x9912
.db 0xC3,0xA5 ;CRC=0x3B91

[=GM=]

У вас ошибка CRC. Модбас работать не будет.

А вы это ReAl'у скажите, у меня с ним совпало. Что касается ошибки, посмотрите, правильную ли вы используете таблицу для получения коротких таблиц.

[defunct]

А вы это ReAl'у скажите, у меня с ним совпало. Что касается ошибки, посмотрите, правильную ли вы используете таблицу для получения коротких таблиц.

Я не табличкой считал, а старым дедовским способом, описанным в спецификации на modbus (гарантированно правильным). ReAl от Вас хотел только неравенства всех трех значений, а нужно чтоб кроме неравенства еще и считалось _то_ что надо.

[=GM=]

Я не табличкой считал, а старым дедовским способом, описанным в спецификации на modbus (гарантированно правильным). ReAl от Вас хотел только неравенства всех трех значений, а нужно чтоб кроме неравенства еще и считалось _то_ что надо

ReAl считал тремя способами, между прочим, и старым дедовским тоже. И вообще-то, ReAl хотел добиться правды, он её добился, все получили более-менее быстрый алгоритм с таблицей в ВОСЕМЬ раз меньше стандартной таблицы. А я считал по своему алгоритму, и результаты всех четырёх расчётов совпали, вам что, этого мало?

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

[Сергей Борщ]

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

Но ведь это вы "вбросили" сюда неправильную неподходящую таблицу, почему исправлять это недоразумение должны ReAl и defunct? Начали - доводите до конца. И озвучьте характеристики вашего кода (размер/такты), чтобы можно было сравнить.

[=GM=]

Но ведь это вы "вбросили" сюда неправильную неподходящую таблицу, почему исправлять это недоразумение должны ReAl и defunct? Начали - доводите до конца. И озвучьте характеристики вашего кода (размер/такты), чтобы можно было сравнить.

Во, Сергей Борщ объявился, а мы уж и не ждали (:-)! Это ведь вы заварили всю кашу, как, да что, да опубликуйте код...

ReAl ничего не исправлял и не должен, с какой стати? Он посчитал цкс по моей таблице, она совпала с моим расчётом, он и согласился со мной.

Теперь о таблице. Если есть таблица для любого полинома, то можно легко получить укороченную таблицу, что я и пытался показать своим первым кодом (по крайней мере, для меня было трудно написать с ходу), но тут все накинулись, не так, не работает, да и озу, ой как жалко, целых 64 байта...
Короче, дайте таблицу для модбаса, я её подрихтую.

Как я уже говорил, таблица занимает 64 байта озу, программа считает цкс для одного байта в цикле за 22 МЦ, хотя можно уменьшить до 21.

Проблема в том, что не получилось у меня создать таблицу для модбаса (256x16) чтобы работала по вашему алгоритму: crc ^= crctable2[ data ]

defunct, это не алгоритм, мой алгоритм приведен в посте #28. А то, что вы привели, мне бы надо переписать как-то так CRCLUT=crctable2[ data ], выше я уже говорил про это. Вот вам код для расчёта по таблице, случайно оказался дома на одном из двд, 100% рабочий, вырвал из моей старой программы 2001 года, работала с очень неудобным таг-ридером, который проектировал один кетаец в юса, отсюда такая таблица

Код

lcrc=hcrc=0x00FF;
for(i=0;i<nbyte;i++)
{
  indx=(datain[i]^hcrc)&0x00FF;
  crc=crcbuf[indx];
  hcrc=((crc>>8)^lcrc)&0xFF;
  lcrc=crc&0x00FF;
}
hcrc=hcrc^0x00FF; lcrc=lcrc^0x00FF;