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

[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

[k155la3]

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

[aaarrr]

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

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

[k155la3]

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

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

[jcxz]

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

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

[k155la3]

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

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

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

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

[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 подряд).
Вобщем - изобрёл костыль к своему творению.
Приходится реализовывать - делать нечего. А ещё - девайс-то батарейный. Этому пареньку то пофигу под виндой, а у меня каждый мА на счету, а тут куча лишних вычислений по перетасовке данных....
Пытаюсь вразумить заказчика, показывая ему, что сложность реализации и потенциальные глюки получившегося колхоза уже много сложнее всех байт-стаффингов вместе взятых. Он уже молчит. Потом говорит, что уже много девайсов продано. И переделывать всё заново - слишком долго и накладно. Ну сделали - фиг с ним, постарался побыстрее забыть этот мрак.

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

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

[k155la3]

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

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

[mantech]

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

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