И аз, като чета какво си написал!
CRC=Cyclic Redundancy Check, хеш функция със съответна разредност, изработваща контролна сума от определен набор от данни, като например интернет пакет или файл. Тази контролна сума се използва за откриване на грешки при предаване на данните или при записа им в някаква медия. Предварително пресметнатата контролна сума се прибавя към блока данни при предаване, а приемащата страна я сравнява с изчислената от самата нея след приемането, за да се удостовери, че е прието това, което е изпратено.
На това аз му викам проверка на грешки. Ако ти го наричаш по друг начин, проблема е някъде в теб, защото горните няколко реда можеш да откриеш и в този източник, на който определено може да се вярва!
Ако ти си открил някакво ново приложение на CRC, сподели с нас!

това ти е проблема!!!!
ползваш wiki-то без да се замислиш!
то това е проблем на доста хора....
в това дето си го написал:"Тази контролна сума се използва за откриване на грешки при предаване на данните или при записа им в някаква медия." си е казано проверка на съобщението ЗА грешка!
а защо ти упорито го разбираш като проверка НА грешка не мога да си обясня даже и wiki-то не може да каже....
а дали деленето на полином(каквото по себе си е CRC) е HASH също може да се поспори но е за тема "други празни приказки"

Умирам си някой да ми каже какви са ми проблемите!
Ама ти си по-добре: твоя е единствен: @null.

Стига бе колеги, пак се разводни темата, един мой познат казваше като се почерпи за GSM-te - Sony, Nokia ако ще и Респром да е важното е да върши работа Та и за протоколите така...
Иначе още чакам от Комет-а чарковете, дано се разбързат и си ги получа утре

Мммм гледам че нещо не напрдва тая тема, конкретно на въпроса, не може слейв у-во да разпознае по погрешка пакета, защото той не е просто един байт. Предаваш да речем следното :
Byte 1 start byte
Byte 2 Package lenght
Byte 3 Recipient Address
Byte 4 Package type
Byte 5 Data
Byte N Data
Byte N+1 CRC16 high byte
Byte N+2 CRC16 low byte
Тук те съветвам да подменяш и байтовете за да е по сигурно, т.е. старт байта ти е твърд, да речем 0xFF, за да няма нееднозначност го предаваш като 0xFF 0X00 а ако в данните имаш 0xFF го предаваш като 0xFF 0x01. Ето ти го и като пример :
Адрес - 0х12, тип пакет 0х01, дани 0хFF, за което прдаваш
0xFF
0x00*
0x05**
0x12
0xFF
0x01*
CRC H
CRC L
* - замяна на байтовете за да бъде еднозначно опредлен стартовия
** - дължината като се предплага че в CRC няма 0xFF .. не ми с есмята във момента CRC-то
Дължината включва и CRC а CRC не включва стартовия байт и дължината.
По този начин на предаван еимаш еднозначно опредлен пакет, у-вото няма как да примене данни за адрес.
Когато получиш данни на RS проверяваш ако е 0xFF вдига си флаг, ако следващия получен байт е 0х00 казваш че това е старт на пакет, ако не е нулираш флага и продължаваш да слушаш. Ако е начало на пакет следващия приет байт ще ти зададе дължината която трябва да приемеш. След като дойдат N на брой байта опредлени от тази дължина си проверяваш CRC, т.е. генерираш CRC на пакета който си получил и го сравняваш с полученото, ако съвпадне значи пакета е валиден, тогава проверяваш първия приет байт, ако той съвпада с адреса на у-вото продължаваш нататък, ако не съвпада нулираш всичко и продължаваш да слушаш.
За да работи правилно трябва да си определиш някакъв тайм аут на всеки един етап, нулираш го при получаване на старт байт или 0хFF и ако докато изтече не си получил остатъка от данните почваш да слушаш отначало.
Това е изпитан метод който работи безпроблемно, мисля че няма да имаш проблем, ако вече нивото на смущения са сериозни тогава може да се мисли и за по надеждно предаване на данните.

Това вече е нещо което наистина помага
@ТоНu, значи няма смисъл да предавам първият байт с 9 бита който се приема за адресен? Ако си осигуря че няма да имам данни примерно като FF /невъзможно ми се струва в 2 стаи да има натиснати едновременно 4 бутона/ има ли смисъл да подменям байтовете?
В този случай ще има ли смисъл да предавам и дължината на пакета, която за моя случай си е фиксирана?
И последно не мога ли да използвам нещо елементарно за за изчисляване на CRC, да не се занимавам с сметки и таблици?

Ако дължината ти е фиксирана, естествено няма да я предаваш! За СРС-то можеш да ползваш предварително сметнати стойности в таблица. Но може да се окаже по-голямо като обем. Преценявай, защото не са ти пък чак толкова и бързи евентите, за да можеш да я смяташ контролната сума. Има готови сорсове в нета, потърси, аз ще постна довечера един-два.

Според закона на Мърфи има такава възможност и то с доста голяма вероятност , по-добре не рискувай ами предвиди и тази възможност. Примерно в една стая ако има човек, който вече подбелва очите и комшиите му не могат да станат веднага, е възможно всички в стаята да си натиснат паник бутоните.....

Правилно, по добре да предам още един байт за да се застраховам от тази вероятност!

Поствам един документ в апендикса на който открих сорсове и таблици за LRC i CRC които ми се сториха единствените лесноразбираеми които съм срещал в моята мирезрна практика рисърч по темата. Сториха ми се полезни затова го поствам. От страница 115 до края е далаверата.

Някъде в началото ти препоръчах ASCII вариант на протокола.
Няма проблем с FF,
Няма проблем с CRC, контролната сума ти е модулна побайтова сума - EOR
Ще предаваш два пъти по-дълго съобщение, но плътността на информацията ти е толкова малка, че даже няма да го забележиш

@asp, няма какво да кажа, интересно четиво

CRC-то е тежко нещо бе, хора. Ако ползвате 8 битово MCU на примерно 4 MHz, голяма част от ресурсите ще отиват само за комуникацията.

Ако му дойде на нагоре на CPU-то може да "изнесе" сметките в някое CPLD
Друг вариант е да използва look-up таблица, обаче ако е скромно от кьм памет контролерчето ще трябва и вьншен EPROM да слага и малко логика за XOR-овете и то стана маса чарколяк по платката.
В случай, че можеш да си позволиш да внесеш малко повече редундантност може да използваш и Hamming-Code. При N бита носещи информация добавяш К бита редундантност, като
и си имаш Single Error Correction, Double Error Detection код, чиято реализация е сравнително по-елементарна от тази на CRC, не че има някакво значение ако слагаш CPLD и не цепиш наносекундата. Освен това в дебелите книги пише, че е лоша практика да се използа Hamming-Code при серийно предаване, но си е вариант.

Хм .. що да е тежко, в последното проектче имам проц на сигнал, пакета който се праща е къде 3200 байта, и нямам особенни проблеми с CRC-то, да не кажа никакви.
code const unsigned short CRC16_table[256] = {
0x0000, 0x8005, 0x800F, 0x000A, 0x801B, 0x001E, 0x0014, 0x8011,
0x8033, 0x0036, 0x003C, 0x8039, 0x0028, 0x802D, 0x8027, 0x0022,
0x8063, 0x0066, 0x006C, 0x8069, 0x0078, 0x807D, 0x8077, 0x0072,
0x0050, 0x8055, 0x805F, 0x005A, 0x804B, 0x004E, 0x0044, 0x8041,
0x80C3, 0x00C6, 0x00CC, 0x80C9, 0x00D8, 0x80DD, 0x80D7, 0x00D2,
0x00F0, 0x80F5, 0x80FF, 0x00FA, 0x80EB, 0x00EE, 0x00E4, 0x80E1,
0x00A0, 0x80A5, 0x80AF, 0x00AA, 0x80BB, 0x00BE, 0x00B4, 0x80B1,
0x8093, 0x0096, 0x009C, 0x8099, 0x0088, 0x808D, 0x8087, 0x0082,
0x8183, 0x0186, 0x018C, 0x8189, 0x0198, 0x819D, 0x8197, 0x0192,
0x01B0, 0x81B5, 0x81BF, 0x01BA, 0x81AB, 0x01AE, 0x01A4, 0x81A1,
0x01E0, 0x81E5, 0x81EF, 0x01EA, 0x81FB, 0x01FE, 0x01F4, 0x81F1,
0x81D3, 0x01D6, 0x01DC, 0x81D9, 0x01C8, 0x81CD, 0x81C7, 0x01C2,
0x0140, 0x8145, 0x814F, 0x014A, 0x815B, 0x015E, 0x0154, 0x8151,
0x8173, 0x0176, 0x017C, 0x8179, 0x0168, 0x816D, 0x8167, 0x0162,
0x8123, 0x0126, 0x012C, 0x8129, 0x0138, 0x813D, 0x8137, 0x0132,
0x0110, 0x8115, 0x811F, 0x011A, 0x810B, 0x010E, 0x0104, 0x8101,
0x8303, 0x0306, 0x030C, 0x8309, 0x0318, 0x831D, 0x8317, 0x0312,
0x0330, 0x8335, 0x833F, 0x033A, 0x832B, 0x032E, 0x0324, 0x8321,
0x0360, 0x8365, 0x836F, 0x036A, 0x837B, 0x037E, 0x0374, 0x8371,
0x8353, 0x0356, 0x035C, 0x8359, 0x0348, 0x834D, 0x8347, 0x0342,
0x03C0, 0x83C5, 0x83CF, 0x03CA, 0x83DB, 0x03DE, 0x03D4, 0x83D1,
0x83F3, 0x03F6, 0x03FC, 0x83F9, 0x03E8, 0x83ED, 0x83E7, 0x03E2,
0x83A3, 0x03A6, 0x03AC, 0x83A9, 0x03B8, 0x83BD, 0x83B7, 0x03B2,
0x0390, 0x8395, 0x839F, 0x039A, 0x838B, 0x038E, 0x0384, 0x8381,
0x0280, 0x8285, 0x828F, 0x028A, 0x829B, 0x029E, 0x0294, 0x8291,
0x82B3, 0x02B6, 0x02BC, 0x82B9, 0x02A8, 0x82AD, 0x82A7, 0x02A2,
0x82E3, 0x02E6, 0x02EC, 0x82E9, 0x02F8, 0x82FD, 0x82F7, 0x02F2,
0x02D0, 0x82D5, 0x82DF, 0x02DA, 0x82CB, 0x02CE, 0x02C4, 0x82C1,
0x8243, 0x0246, 0x024C, 0x8249, 0x0258, 0x825D, 0x8257, 0x0252,
0x0270, 0x8275, 0x827F, 0x027A, 0x826B, 0x026E, 0x0264, 0x8261,
0x0220, 0x8225, 0x822F, 0x022A, 0x823B, 0x023E, 0x0234, 0x8231,
0x8213, 0x0216, 0x021C, 0x8219, 0x0208, 0x820D, 0x8207, 0x0202
};

unsigned int CRC16( BYTE *source, unsigned int size, unsigned int init_value)
{
unsigned int crc = init_value;
unsigned int i;
for(i = 0; i < size; i++)
{
crc = CRC16_table[(crc >> 8 & 0xFF) ^ *(source+i)] ^(crc << ;
}
return crc;
}

ето това е функцията която ползвам.