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

[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
(примитив, всяческое охаивание приветствуется)

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

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

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

[segment]

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

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

[ViKo]

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

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