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=]

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

Код

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

Что-то не пахнет тут CRC.

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

Код

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

А это чисто табличный метод счёта crc. Возражения есть(:-)? В посте #18 я дал чисто идею реализации. Посчитал поточнее, получился 21 такт, включая загрузку байта из буфера и счётчик байт. В симуляторе вроде дышит, доберусь до работы, проверю поточнее. А может у кого под рукой есть тестовая строка с вычисленной crc?

[ReAl]

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

Код

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

Кажется, речь шла о коде, который не вычисляет CRC с помощью таблички для 4 битов, а не при помощи таблички для 8 битов.
Хотя с 256-словной таблицей алгоритм не вычисляет CRC быстрее, спору нет.

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

Да какие уж тут возражения... "слов нет"