| |
|
  |
 CRC16(ModBus) на С для ATmega128, помогите разобраться |
|
|
|
|
 Sep 19 2008, 12:07
|
Ambidexter
Группа: Свой
Сообщений: 1 589
Регистрация: 22-06-06
Из: Oxford, UK
Пользователь №: 18 282
|
Идея простая, как веник. Ну вот как-то так, таблица должна быть настроена на границу 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
--------------------
Делай сразу хорошо, плохо само получится
|
|
|
|
|
|
|
|
Sep 19 2008, 15:16
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Цитата(=GM= @ Sep 19 2008, 15:07)  Идея простая, как веник. Ну вот как-то так, таблица должна быть настроена на границу 256 байт, можно и 64. И что, именно этот веник действительно метёт? Сколько я не смотрел в сторону 4-битной табличной реализации, она ну никак не выходила быстрее реализаций, подобных приведенной тут либо в util/crc.h.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
Sep 19 2008, 20:27
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Цитата(Rst7 @ Sep 19 2008, 19:06) Ну и пара огрехов других, например, надо сдвигать yl влево на один бит. Это ладно, я не это имел ввиду, когда писал Цитата(ReAl @ Sep 19 2008, 18:16) И что, именно этот веник действительно метёт? Даже если исправить эти мелкие огрехи, в переводе на С тот ассемблерный кусок выглядит приблизительно так: Код 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 - выйдет дольше, чем обсуждавшиеся методы.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
Sep 19 2008, 23:17
|
Ambidexter
Группа: Свой
Сообщений: 1 589
Регистрация: 22-06-06
Из: Oxford, UK
Пользователь №: 18 282
|
Цитата(ReAl @ Sep 19 2008, 19:27) в переводе на С тот ассемблерный кусок выглядит приблизительно так: Код 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?
--------------------
Делай сразу хорошо, плохо само получится
|
|
|
|
|
|
|
|
Sep 20 2008, 07:16
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Цитата(=GM= @ Sep 20 2008, 02:17) Я бы ещё усилил, примерно так Код void crc_update(uint8_t data)
{
crc ^= crctable2[ data ];
} Кажется, речь шла о коде, который не вычисляет CRC с помощью таблички для 4 битов, а не при помощи таблички для 8 битов. Хотя с 256-словной таблицей алгоритм не вычисляет CRC быстрее, спору нет. Цитата(=GM= @ Sep 20 2008, 02:17) А это чисто табличный метод счёта crc. Возражения есть(:-)? В посте #18 я дал чисто идею реализации. Да какие уж тут возражения... "слов нет"
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
Sep 20 2008, 20:51
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Цитата(=GM= @ Sep 20 2008, 20:36) Речь я вёл о том, что путём чисто математических преобразований можно показать идентичность вашего фрагмента в посте #21 моему фрагменту в посте #22. Толку с того, если они оба не считают CRC ни при каких таблицах. И для этого достаточно посмотреть даже на код из моего сообщения №21, ещё дальше можно не залазить. Но если Вам так нравится этот Ваш фрагмент из сообщения №22, повторю Цитата он не считает CRC быстрее, чем код из сообщения №18 и его (подправленный) C-аналог из сообщения №21
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
Sep 21 2008, 22:30
|
Ambidexter
Группа: Свой
Сообщений: 1 589
Регистрация: 22-06-06
Из: Oxford, UK
Пользователь №: 18 282
|
Цитата(ReAl @ Sep 19 2008, 19:27) Что-то не пахнет тут 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
};
--------------------
Делай сразу хорошо, плохо само получится
|
|
|
|
|
|
|
|
Sep 22 2008, 11:09
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Вы так упорствуете в своих заблуждениях... Цитата(=GM= @ Sep 22 2008, 01:30) А вот интересно, какая по-вашему будет crc для последовательностей
1) 0xA5, 0xC3
2) 0xC3, 0xA5
3) 0xC5, 0xA3 ? Ну я не факир-вычислитель, сразу так не скажу, но что она будет разной - уверен. Какой именно будет - сейчас сбацаем тест. Цитата(=GM= @ Sep 22 2008, 01:30) Таблица для справки Код 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
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
Sep 23 2008, 11:51
|
Ambidexter
Группа: Свой
Сообщений: 1 589
Регистрация: 22-06-06
Из: Oxford, UK
Пользователь №: 18 282
|
Ну, я не упорствую, но вот это ваше "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 как у вас)
--------------------
Делай сразу хорошо, плохо само получится
|
|
|
|
|
|
|
|
Sep 23 2008, 18:48
|
дятел
Группа: Свой
Сообщений: 1 681
Регистрация: 13-05-06
Из: Питер
Пользователь №: 17 065
|
Цитата(=GM= @ Sep 23 2008, 15:51) (Замечу в скобках, обычно цкс начинают считать с 0xFFFF, а не с 0х0000 как у вас) А вот и не всегда... Modbus CRC-16 calculation Polynomial: x^16 + x^15 + x^2 + 1 (0xa001) Initial value: 0xffff CRC-XMODEM calculation. Polynomial: x^16 + x^12 + x^5 + 1 (0x1021) Initial value: 0x0 CRC-CCITT calculation. Polynomial: x^16 + x^12 + x^5 + 1 (0x8408) Initial value: 0xffff Dallas iButton 8-bit CRC calculation. Polynomial: x^8 + x^5 + x^4 + 1 (0x8C) Initial value: 0x0 Так что не всегда с FF(FF) начинают, зависит от применения, хотя конечно для обсуждаемого здесь Modbus начинают всегда с 0xFFFF, и начинать с 0 для передачи по UART плохо...
|
|
|
|
|
|
|
|
Sep 23 2008, 21:33
|
Нечётный пользователь.
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417
|
Цитата(=GM= @ Sep 23 2008, 14:51) Ну, я не упорствую, но вот это ваше "return crc^crctable[data]" как-то слишком прямолинейно, даже для меня. Это ж просто выборка из таблицы для вычисления цкс, а можно сделать выборку, используя тетрады данных, тогда размер таблицы уменьшится с 512 байт до 64 байт, надеюсь, вам это понятно. Понятно, именно потому при переводе Вашего ассемблерного кода на С я оставил потетрадное обращение. Однако с каких это пор return crc^crctable[data] моё? Я только ушёл от глобальной переменной, мне так удобнее было. И "это ж просто выборкой" оно стало, когда стало "моим", а пока было Ваше, оно было "чисто табличным методом вычисления CRC": Цитата(=GM= @ Sep 20 2008, 02:17) Я бы ещё усилил, примерно так Код void crc_update(uint8_t data)
{
crc ^= crctable2[ data ];
} А это чисто табличный метод счёта crc. Возражения есть(:-)? Ну так что, оно таки считает CRC ??? Вы сами сказали, что оно "эквивалентно" тому, что я написал в качестве аналога Вашего ассемблерного кода. Не этого, конечно: Цитата(=GM= @ Sep 23 2008, 14:51) Код 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 А этого: Цитата(=GM= @ Sep 19 2008, 15:07) Идея простая, как веник. Ну вот как-то так, таблица должна быть настроена на границу 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 тактов и выиграша по скорости у "быстрого бестабличного" метода не будет)Цитата(=GM= @ Sep 23 2008, 14:51) Для ваших тестовых строк даёт те же цкс Код .db 0xA5,0xC3 ;CRC=0x0BA4
.db 0xC5,0xA3 ;CRC=0xA648
.db 0xC3,0xA5 ;CRC=0x6C28 даёт. Цитата(=GM= @ Sep 23 2008, 14:51) (Замечу в скобках, обычно цкс начинают считать с 0xFFFF) Разные CRC принято считать начиная с разного инициализатора. Полином из Вашей таблички применяется в протоколе XMODEM_CRC с инициализацией нулями, о чём уже сказано. Была бы предложена другая табличка, я бы глянул, что принято для того полинома для сравнимости результатов. Цитата(singlskv @ Sep 23 2008, 21:48) Так что не всегда с FF(FF) начинают, зависит от применения, хотя конечно для обсуждаемого здесь Modbus начинают всегда с 0xFFFF,
и начинать с 0 для передачи по UART плохо... Для XMODEM, на мой взгляд, всё равно. Пакет начинается с ненулевого спецсимвола и после него в аккумуляторе CRC будет уже не ноль, проблема неразличения последовательностей нулей разной длины в начале пакета пропадает. А до него и пакет не начался.
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
