Битые записи в массиве. Опции

[Jenya7]

Я принимаю пакеты данных из очереди

Код

check_queue = FRTOS1_xQueueReceive(Global_Queue_Handle, &lt_rec_buff, 0);
if(check_queue)
{
    memcpy(queue_buff, lt_rec_buff, 13);
}

И на основе принятых данных строю запись.

Код

qRxBuffer[0] = 0x55;
qRxBuffer[1] = queue_buff[0];
qRxBuffer[2] = queue_buff[1];

qRxBuffer[3] = time.Day;
qRxBuffer[4] = time.Month;
qRxBuffer[5] = time.Year;
qRxBuffer[6] = time.Hour;
qRxBuffer[7] = time.Minute;
qRxBuffer[8] = time.Second;

temp.all = globalSysTimer & 0xFFFFFFFF;
qRxBuffer[9]  = temp.nByte[0];
qRxBuffer[10] = temp.nByte[1];
qRxBuffer[11] = temp.nByte[2];
qRxBuffer[12] = temp.nByte[3];

qRxBuffer[13] = queue_buff[4];  //DLC
qRxBuffer[14] = queue_buff[5];  //BYTE 0
qRxBuffer[15] = queue_buff[6];  //BYTE 1
qRxBuffer[16] = queue_buff[7];  //BYTE 2
qRxBuffer[17] = queue_buff[8];  //BYTE 3
qRxBuffer[18] = queue_buff[9];  //BYTE 4
qRxBuffer[19] = queue_buff[10]; //BYTE 5
qRxBuffer[20] = queue_buff[11]; //BYTE 6
qRxBuffer[21] = queue_buff[12]; //BYTE 7

calcRes.all = UTL_CRC_srvCalculate_CRC16_CCITT(qRxBuffer, 22);
qRxBuffer[22] = calcRes.nByte[0];
qRxBuffer[23] = calcRes.nByte[1];

Для проверки записи я вывожу ее на терминал

Код

for (g_idx = 0; g_idx < 24; g_idx++)
{
    send_hex_num16_uart0(qRxBuffer[g_idx]);
    send_msg_uart0(" ", 1);
}
send_msg_uart0("\r", 1);

Вижу правильные записи. Послал 20 получил 20 - все красиво.
Каждую запись я добавляю в массив размером 4096 байт. И когда массив полный - вывожу его на терминал

Код

//check if there is enough space for the message
if ( (4096 - data_index) >= sizeof(qRxBuffer) )
{
    memcpy(&log_data[data_index], qRxBuffer, sizeof(qRxBuffer));
    data_index += sizeof(qRxBuffer);
}
else //the page is full
{
    data_index  = 0;

    for (g_idx = 0; g_idx < 4096; g_idx++)
    {
        if (&log_data[g_idx] == 0x55)
        send_msg_uart0("\r", 1);

        send_hex_num16_uart0(&log_data[g_idx]);
        send_msg_uart0(" ", 1);
    }
}

И что я вижу? Битые записи! Вот например

Код

55 5 0 0 0 0 0 0 0 19 7B 9 0 7 1 9F 80 2E 80 0 0 0 A6 19
55 4 0 0 0 0 0 0 0 2C 7B 9 0 3 1 B B8 0 0 1 B B8 1A 83
55 5 0 0 0 0 0 0 0 2D 7B 9 0 7 1 9F 80 2E 80 0 0 0 D7 27
55 4 0 0 0 0 0 0 0 40 7B 9 0 3 1 B B8 0 0 1 B B8
55 FA
55 5 0 0 0 0 0 0 0 41 7B 9 0 7 1 9F 80 2E 80 0 0 0 98 5E
55 4 0 0 0 0 0 0 0
55 7B 9 0 3 1 B B8 0 0 1 B B8 2F AC
55 5 0 0 0 0 0 0 0 56 7B 9 0 7 1 9F 80 2E 80 0 0 0 24 82
55 4 0 0 0 0 0 0 0 69 7B 9 0 3 1 B B8 0 0 1 B B8 4 99
55 5 0 0 0 0 0 0 0 6A 7B 9 0 7 1 9F 80 2E 80 0 0 0 F B7
55 4 0 0 0 0 0 0 0 7D 7B 9 0 3 1 B B8 0 0 1 B B8 1D 8A

Причем битые записи могут быть в разных местах при одной и той же посылке данных.
Как? Как записи могли не прописаться в массив в РАМ?

Сообщение отредактировал Jenya7 - Jul 16 2018, 06:43

[aaarrr]

А если так рассмотреть - не битые?

Код

55 5 0 0 0 0 0 0 0 19 7B 9 0 7 1 9F 80 2E 80 0 0 0  A6 19
55 4 0 0 0 0 0 0 0 2C 7B 9 0 3 1 B  B8 0  0  1 B B8 1A 83
55 5 0 0 0 0 0 0 0 2D 7B 9 0 7 1 9F 80 2E 80 0 0 0  D7 27
55 4 0 0 0 0 0 0 0 40 7B 9 0 3 1 B  B8 0  0  1 B B8 55 FA
55 5 0 0 0 0 0 0 0 41 7B 9 0 7 1 9F 80 2E 80 0 0 0  98 5E
55 4 0 0 0 0 0 0 0 55 7B 9 0 3 1 B  B8 0  0  1 B B8 2F AC
55 5 0 0 0 0 0 0 0 56 7B 9 0 7 1 9F 80 2E 80 0 0 0  24 82
55 4 0 0 0 0 0 0 0 69 7B 9 0 3 1 B  B8 0  0  1 B B8 4  99
55 5 0 0 0 0 0 0 0 6A 7B 9 0 7 1 9F 80 2E 80 0 0 0  F  B7
55 4 0 0 0 0 0 0 0 7D 7B 9 0 3 1 B  B8 0  0  1 B B8 1D 8A

[Jenya7]

А если так рассмотреть - не битые?

Код

55 5 0 0 0 0 0 0 0 19 7B 9 0 7 1 9F 80 2E 80 0 0 0  A6 19
55 4 0 0 0 0 0 0 0 2C 7B 9 0 3 1 B  B8 0  0  1 B B8 1A 83
55 5 0 0 0 0 0 0 0 2D 7B 9 0 7 1 9F 80 2E 80 0 0 0  D7 27
55 4 0 0 0 0 0 0 0 40 7B 9 0 3 1 B  B8 0  0  1 B B8 55 FA
55 5 0 0 0 0 0 0 0 41 7B 9 0 7 1 9F 80 2E 80 0 0 0  98 5E
55 4 0 0 0 0 0 0 0 55 7B 9 0 3 1 B  B8 0  0  1 B B8 2F AC
55 5 0 0 0 0 0 0 0 56 7B 9 0 7 1 9F 80 2E 80 0 0 0  24 82
55 4 0 0 0 0 0 0 0 69 7B 9 0 3 1 B  B8 0  0  1 B B8 4  99
55 5 0 0 0 0 0 0 0 6A 7B 9 0 7 1 9F 80 2E 80 0 0 0  F  B7
55 4 0 0 0 0 0 0 0 7D 7B 9 0 3 1 B  B8 0  0  1 B B8 1D 8A

не понял что вы хотите сказать. с не битыми все хорошо.

Сообщение отредактировал Jenya7 - Jul 16 2018, 07:16

[aaarrr]

не понял что вы хотите сказать. с не битыми все хорошо.

Что является признаком "битости"?

[Jenya7]

Что является признаком "битости"?

не битый 24 байта
по моему сравнив две строчки
55 5 0 0 0 0 0 0 0 2D 7B 9 0 7 1 9F 80 2E 80 0 0 0 D7 27
55 FA
или
55 5 0 0 0 0 0 0 0 41 7B 9 0 7 1 9F 80 2E 80 0 0 0 98 5E
55 4 0 0 0 0 0 0 0
все ясно

Сообщение отредактировал Jenya7 - Jul 16 2018, 07:26

[iosifk]

не понял что вы хотите сказать. с не битыми все хорошо.

aaarrr хотел сказать, что у Вас 55 в данных не отличается от 55 в начале строки. И когда Вы находите 55, то всегда считаете это началом строки, хотя это и не так.
Смотрите термин байт-стаффинг и esc-последовательности.

[Jenya7]

aaarrr хотел сказать, что у Вас 55 в данных не отличается от 55 в начале строки. И когда Вы находите 55, то всегда считаете это началом строки, хотя это и не так.
Смотрите термин байт-стаффинг и esc-последовательности.

ааааа......понял. мда... я не учел что последние байты чексам и он может совпасть с заголовочным байтом. спасибо.

[ViKo]

"чексам"... Етить-колотить!

[k155la3]

Если протокол бинарный-байтовый, то единственная возможность выделить пакет - межпакетная пауза. Иначе рискуете постояннно или спародически ловить грабли.
"Стартовать" разбор пакета по маркерному байту допустимо только для протокола вроде MODBUS-ASCI.
Если же от маркерного байта уходить не желательно, и в то же время требуется передавать бинарные данные, для пакетов небольшого размера
можно использовать "вынос" старшего бита всех полей и служебной инф. пакета в отдельное, дополнительное поле (и CRC поле тоже).
"Освободившиеся" 128 байт можно использовать как управляющие, адресные итп.
Для такого решения можно передавать не пакет, а поток байтов.

[aaarrr]

Если протокол бинарный-байтовый, то единственная возможность выделить пакет...

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

[k155la3]

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

Да. Для больших пакетов и переменной длины. Но усложняется алгоритм.
"Городить" байт-стаффинг для пакета из 5-10 байт как-то сомнительно.

[jcxz]

спародически ловить грабли.

Опечатка по Фрейду.... Спорадически. А "спародически" - это видимо от "пародия"?
Тогда полностью согласен с Вами - сообщения определённых местных товарищей (не будем показывать пальцем, но все догадались о ком речь) иначе и назвать нельзя

[k155la3]

Опечатка по Фрейду....

Да, хотя с "граблями", Вы правы, смотрится вполне гармонично

[Kabdim]

Попутно стоит рассказать про "%02X" вместо просто "%X".

[jcxz]

Да. Для больших пакетов и переменной длины. Но усложняется алгоритм.
"Городить" байт-стаффинг для пакета из 5-10 байт как-то сомнительно.

Как только возникает необходимость пробросить обмен не через железный UART, а через что-то виртуальное, с непредсказуемыми задержками в непредсказуемых местах, так вся эта кажущаяся простота выходит боком.
Лучше всё-таки использовать канальное кодирование. Не обязательно байт-стаффингом. Есть например COBS. У него "переменность" длины пакета намного ниже чем при байт-стаффинге.
Да и кодер/декодер сравнительно простые: у меня сейчас в текущем проекте поверх TCP-сокета работает COBS, через который идёт обмен с устройством с потоком до ~0.5МБ/с (дуплексный, но бОльший поток - от устройства в комп). Так загрузка CPU этим потоком составляет менее 10% при 144МГц тактовой. И никаких проблем с передачей границ кадров через виртуальный канал.

[Jenya7]

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

[k155la3]

. . . Есть например COBS. . . .

COBS, pdf - насколько я понял. Спасибо, поглядим, "что за зверь".

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

Ну, например. У Вас максимальный размер поля данных - 4 байта (бинарные)
"прореживаете" все поля данных 0x00.
Заголовок пакета 5 байт: 0x55 - 0x01 - 0x02 - 0x03 - 0x04
Завершаете пакет 0x00 - 0x00 - 0x00 - CRC_Hi - CRC_Lo
(примитив, всяческое охаивание приветствуется)

[Jenya7]

COBS, pdf - насколько я понял. Спасибо, поглядим, "что за зверь".


Ну, например. У Вас максимальный размер поля данных - 4 байта (бинарные)
"прореживаете" все поля данных 0x00.
Заголовок пакета 5 байт: 0x55 - 0x01 - 0x02 - 0x03 - 0x04
Завершаете пакет 0x00 - 0x00 - 0x00 - CRC_Hi - CRC_Lo
(примитив, всяческое охаивание приветствуется)

а что гарантирует что CRC_Hi - CRC_Lo примут отличное от заголовка значение?

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

Сообщение отредактировал Jenya7 - Jul 16 2018, 12:12

[k155la3]

а что гарантирует что CRC_Hi - CRC_Lo примут отличное от заголовка значение?

заголовок состоит из 5 байт.

[mantech]

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

Если уж так неохота возиться с подменой символа, то делайте преамбулу, 4-6 байт с уникальными числами, вероятность совпадения будет ничтожно малой, да и если совпадет преамбула, то уж точно не сойдется КС...

[megajohn]

COBS, pdf - насколько я понял. Спасибо, поглядим, "что за зверь".

дык классический PPP тоже вполне юзабелен

[XVR]

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

Зачем вам заголовок? У вас все записи одинаковой длинны, никаких заголовков не нужно

[Jenya7]

Зачем вам заголовок? У вас все записи одинаковой длинны, никаких заголовков не нужно

а как узнать где начало следующей записи? я не могу гарантировать что запись начнется с нулевого индекса.

[XVR]

а как узнать где начало следующей записи? я не могу гарантировать что запись начнется с нулевого индекса.

А с какого ещё она может начаться? Вы заполняете блок фиксированного размера записями так же фиксированного размера. При этом запись не пересекает границу блока. Т.е. каждая запись начинается с индекса N*sizeof(record) (где N - номер записи).

[jcxz]

COBS, pdf - насколько я понял. Спасибо, поглядим, "что за зверь".

В википедии достаточно хорошо описано: https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing
И размер кадра вовсе не ограничивается 254 байтами - легко расширяется до любого размера. Просто оверхед будет равен:

Код

//вычисление величины увеличения размера данных при кодировании payload байт в COBS
#define CobsCodedOver(payload) ((sizeof(payload) - 1) / 254 + 1)

[segment]

И размер кадра вовсе не ограничивается 254 байтами - легко расширяется до любого размера.

Поясните, пожалуйста, как размер кадра расширяется.

[jcxz]

Поясните, пожалуйста, как размер кадра расширяется.

Вы почитайте описание протокола и подумайте логически.

[HardEgor]

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

Достаточно сделать заголовок пакета 0x55FA, постоянную длину пакета и контрольную сумму в конце пакета.

Тогда начало определяем по заголовку, набираем из потока байтов(или буфера) постоянную длину и проверяем контрольную сумму.
Если контроль не прошёл, то значит 0x55FA это данные, а не заголовок.
Ищем в набранном заголовок, если не находим, то отбрасываем набранное вообще, если находим - набираем еще байтов от нового заголовка.
И т.д. пока не засинхронизируемся с потоком.

[jcxz]

Достаточно сделать заголовок пакета 0x55FA, постоянную длину пакета и контрольную сумму в конце пакета.
Тогда начало определяем по заголовку, набираем из потока байтов(или буфера) постоянную длину и проверяем контрольную сумму.

Этот колхоз вообще никакого отношения не имеет к COBS.
COBS - кодонезависимый протокол, не нуждающийся в костылях типа контрольных сумм и поисках чего-то. И однопроходный.

[Arlleex]

Для связи между платами (или MCU<->CPU/FPGA) практически всегда использую байт-стаффинг. Простой, надежный. Переменная длина сообщений вообще радует - сделал себе что-то наподобие мессенджера - при этом не нужны поля размера пакета в структурах обмена и связанные с этим головные боли тоже ушли.
COBS слышал, не применял, не знаю

[k155la3]

Giihub, SLIP, COBS

[jcxz]

Простой, надежный. Переменная длина сообщений вообще радует - сделал себе что-то наподобие мессенджера - при этом не нужны поля размера пакета в структурах обмена и связанные с этим головные боли тоже ушли.
COBS слышал, не применял, не знаю

COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый.
У байт-стаффинговых протоколов есть существенный недостаток: увеличение длины сообщения после кодирования зависит от содержащихся в сообщении данных. Это может быть существенным минусом например когда нужно заранее перед кодированием знать длину вых.сообщения, или когда пропускная способность канала ограничена.
У COBS увеличение длины сообщения после кодирования никак не зависит от данных в сообщении: всегда +1 дополнительный байт на каждые 254 входных байтов. Что я и представил формулой:
#define CobsCodedOver(payload) ((sizeof(payload) - 1) / 254 + 1)
где sizeof(payload) - длина исходного некодированного сообщения.

PS: Естественно никакие "размеры пакета" или "контрольные суммы" никакому из кодонезависимых протоколов (ни байт-стаффинговым ни COBS) не нужны. Всё это элементы протоколов более высокого уровня, над фреймером. Но чайники как правило всё это мешают в кучу.

[Arlleex]

COBS тоже - простой, надёжный, с произвольной длиной сообщений, кодонезависимый.

Изучу более детально в ближайшем будущем в своем проекте, спасибо

[Kabdim]

Ну, например. У Вас максимальный размер поля данных - 4 байта (бинарные)
"прореживаете" все поля данных 0x00.
Заголовок пакета 5 байт: 0x55 - 0x01 - 0x02 - 0x03 - 0x04
Завершаете пакет 0x00 - 0x00 - 0x00 - CRC_Hi - CRC_Lo
(примитив, всяческое охаивание приветствуется)

Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два.

[k155la3]

Вот зачем придумывать плохонькое, но свое, если готовых вариантов (в том числе стандартов) не один и не два.

Не думаю, что это "мое-свое", какой-нибудь частный-урезанный случай вышеупомянутых методов. Зато легко-понимаемый.

[jcxz]

Не думаю, что это "мое-свое", какой-нибудь частный-урезанный случай вышеупомянутых методов. Зато легко-понимаемый.

Это грабли на ровном месте. Себе в будущем. Сколько уже раз так наступал.
Помнится в очередном проекте мне упорно доказывали, что: "нафиг не нужна никакая кодонезависимость от протокола, мы отправляемые данные так подберём, чтобы у нас в них не было спец.символов, ограничивающих кадр" (такими символами хотели сделать 0xFF). Пытаюсь доказывать, что устройство будет передавать в том числе и данные с АЦП, где 0xFF обязательно будет. В ответ присылают замороченный алгоритм как преобразовывать данные от АЦП (а там не только сырые данные и но обработанные), чтобы не было 0xFF. С потерями в сигнале, естественно. Говорю: "А в других местах, где надо будет передавать двоичные данные - как?" (таких мест тогда было известно ещё одно). В ответ - опять набор правил как выбирать данные, так чтобы там не было 0xFF. С кучей ограничений.
Пытаюсь спросить: "Зачем куча таких ограничений если можно реализовать просто элементарный стандартный протокол с байт-стаффингом???" В ответ что-то невразумительное, типа: "Ваш байт-стаффинг какой-то слишком сложный для нашей задачи. Нам такие сложности не нужны. Можно всё проще сделать".
Пытаюсь доказывать, что всё это - сплошной колхоз, обнесённый забором из грабель - бесполезно: "Мы хотим так, заказчик всегда прав".
Пытаюсь доказывать, что в будущем почти наверняка потребуется что-то доработать, расширить функционал, а такой кривой протокол будет всегда бить по башке. Не слышат. Как об стенку.

Чувствую, что не сам это заказчик придумал, а кто-то за ним говорит, его языком. Там у него был такой паренёк, который на компе под виндой должен был взаимодействие по данному протоколу с устройством писать. Чувствую что это он заказчиком рулит - в уши ему дует, а тот слушает (благо - он под боком всё время, а я - далеко). Позже пообщавшись с этим пареньком, по некоторым техническим вопросам реализации собственно обмена, на некоторых аспектах просто выпадаю в осадок - ни о каком уровне профессионализма там даже говорить не приходится! Становится ясно, почему "байт-стаффинг слишком сложный".
Ок - пишу для него функции приёма и передачи, которые он просто вставит в свой код, даст приёмной() на вход поток байт, а она ему будет выплёвывать кадры, ну и передающую() - в обратном порядке.
Отправляю ему с описанием куда и чего нужно подавать. Проходит время.... тишина - то ли не понял, то ли что-то не получилось. Вобщем - ни в какую не хочет использовать кодонезависимый фрейминг.
Ну что делать - пришлось скрепя сердце согласиться делать этот колхоз на квадратных колёсах.

Ну и естественно как и ожидалось - ещё даже на этапе написания первых версий ПО, вдруг потребовалась передача дополнительных данных, которые опять произвольные двоичные. Да ещё в них просто так не удалишь какие-то значения заменив на соседние как с данными АЦП (там просто ну чуть больше шума появляется). Что делать? Тот паренёк долго думает, потом придумывает ещё более развесистый колхоз, когда надо было в данных что-то искать (не помню уже что), и "если так - то так, если этак - то этак". Границы кадров сделать по 5 шт. 0xFF. А те данные, где могут появляться 0xFF, обнести другими, в которых 0xFF заведомо нет (максимальный размер каждого данного был 4 байта, поэтому если их проредить другими, то будет не более 4 шт. 0xFF подряд).
Вобщем - изобрёл костыль к своему творению.
Приходится реализовывать - делать нечего. А ещё - девайс-то батарейный. Этому пареньку то пофигу под виндой, а у меня каждый мА на счету, а тут куча лишних вычислений по перетасовке данных....
Пытаюсь вразумить заказчика, показывая ему, что сложность реализации и потенциальные глюки получившегося колхоза уже много сложнее всех байт-стаффингов вместе взятых. Он уже молчит. Потом говорит, что уже много девайсов продано. И переделывать всё заново - слишком долго и накладно. Ну сделали - фиг с ним, постарался побыстрее забыть этот мрак.

Проходит пару лет, тот же заказчик стучится, просит ещё кой-какой функционал добавить. Оказывается - для полной реализации всех хотелок надо всё-таки нормальные двоичные данные передавать. А с имеющимся колхозом - никак. Говорю: "Я же вас предупреждал ещё тогда, много раз!". В ответ: "Да, надо было делать конечно как правильно, но тогда надо было побыстрее и думали что на том и остановимся и больше ничего не надо будет. Ну а теперь сделай что можешь, а уже лучше мы сделаем в следующем девайсе". Приходится заказчику урезать свои хотелки - сам виноват.
Попутно выясняю, что паренёк тот уволился из конторы, бросил этот проект так и не доведя его до рабочего состояния. Заложив им такую кучу г@#$а, что до сих пор разгрести не могут.

Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".

[Kabdim]

Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком.

[Arlleex]

Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".

Спасибо за рассказ, читал с пониманием всего и вся - тоже проходили такое Особенно про "добавить функционал, там же немножечко..."

[segment]

Вы почитайте описание протокола и подумайте логически.

Нет, все-таки поясните, как Вы можете надежно передать пакет размером >254 байт без участия дополнительного поля общей длины пакета.

[ViKo]

Нет, все-таки поясните, как Вы можете надежно передать пакет размером >254 байт без участия дополнительного поля общей длины пакета.

Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается.
https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing
Посмотрите строки 8 и 9 в таблице.

[segment]

Единственным нулем только в конце пакета любой длины. Все остальные нули в пакете заменяются смещением на следующий нуль. А если смещение равно FF, то это вставленный нуль, он выбрасывается.
https://en.wikipedia.org/wiki/Consistent_Ov...d_Byte_Stuffing
Посмотрите строки 8 и 9 в таблице.

Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля.

[jcxz]

Мне вот всегда такие объяснения лениво писать даже заказчику, а уж на форуме тем более. Спасибо что выразили всё это письменным языком.

Тема просто у меня наболевшая - долго это тянулось. Вот недавно опять напомнили - просили добавить функционал немного. И опять на эти грабли напоролись.

Да, все верно. Внутри пакета меньше 254 байт легко отслеживается состояние пакета, так как знаем количество байт до следующего нуля. Но если байт 0х00 потерян, а за ним следует длинный пакет начинающийся с 0xFF? В случае утери — проскакиваем эту проверку и вычитываем весь (все) следующие пакеты до следующего нуля.

Естественно - 0 граница кадра. От него и начинаем читать кадр. Если произошёл сбой, то приёмник должен перейти в состояние "несинхронизирован", в котором он просто читает вх. поток в поисках 0.
Приёмник должен переходить в состояние "несинхронизирован" при любых ошибках в приёме, в том числе и из-за переполнения (слишком длинный кадр).

[k155la3]

Это грабли на ровном месте. . . . . Вот такая грустная история про самописные протоколы "лишь бы попроще, и так сойдёт".

Это не "история". Это "сага"
С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна".
У каждого свой реестр таких ситуаций.
За критику спасибо, принимается.

[mantech]

С меня упорно требовали убрать поле CRC в пакете, под тем "соусом", что "кабель короткий и передаваемая инф-я не может исказиться или быть потеряна".

Бывает такое, как-то дорабатывал табло, в нем тоже 1200 бод, нет КС, т.к. "комп рядом стоял", а потом начальник взял да и поставил комп в другом крыле, примерно метров 15-20 было... И началось

[Dog Pawlowa]

Вообще-то во многих странах на протоколы связи с устройствами есть стандарты.
Типичный протокол не предусматривает передачи любых данных.
Старый добрый пакет STX data ETX BCC1 BCC2 вместе с запросами и подтверждениями ENQ/ DLE вполне решает все проблемы.

Длина/скорость передачи критичны в единицах случаев.
Возвращайтесь к истокам, коллеги!