Протокол TBFP

[@viordash]

Не хватает поля версии самого протокола. Чтобы обеспечить связь со старым оборудованием

версия 2 -> preamble 0xA6
версия 3 -> preamble 0xA7
и т.д.

[@aabzel]

Ну конечно! Спасибо. Я бы до такого никогда не додумался.

[@JBFW]

А если вместо CRC автокоррекцию использовать? Хемминг, Рида-Соломона?Восстановился код - ок, не восстановился - сильно битый.

[@aabzel]

Это уж слишком сложно.

[@NightShad0w]

Чтобы не тратить всуе лишнее процессороне время и не писать лишний код на разворот байтов это многобайтовое поле следует передавать в формате little-endian.

А микроконтроллеры чаще little-endian? Контринтуитивно передавать куда-то байты не в сетевом порядке байт.

[@aabzel]

Да. Arm Cortex -m little endian. Хотя компилятор gcc имеет ключи переключения на big endian. Однако я их ни разу не проверял.

[@randomsimplenumber]

Не совсем понятно, зачем для тестирования интерфейсов свой собственный diy протокол.

[@aabzel]

Всё очень просто. Есть беспроводной интерфейс (например LoRa) и драйвер интерфейса взятый из интернета.
Надо проверить как ведет себя реализация на Hi-load.

Классический тест. Посылать сплошной поток пакетов с увеличением порядкового номера пакетов. Оставить на 24 часа.

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

Вот и нужен протокол с 16битным SN пакета.

[@randomsimplenumber]

printf(счетчик, crc)

[@aabzel]

Выглядит, как hardcode.
Ну, Ок, однако надо еще и команду на reboot как-то посылать.

[@randomsimplenumber]

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

[@aabzel]

Уж лучше так, чем никак.

[@aabzel]

Коллеги вообще топят за использование Protobuf

[@vmx]

В каких бинарных протоколах есть поле порядковый номер пакета разрядностью минимум 16 бит?

В TCP? Там есть 32-битный sequence number.

В каких бинарных протоколах есть порядковый номер передаваемого пакета?

Иногда в "односторонние" UDP-based протоколы добавляют порядковые номера, чтобы понимать сколько пакетов потерялось. В netflow/ipfix есть sequence number.

Существую ли бинарные протоколы реализованные аппаратно?

Какой-то очень сложный вопрос. Сейчас грань между "программно" и "аппаратно" немного размыта, но вообще сетевой стек (Ethernet, IP и даже TCP/UDP) парсится и модифицируется на многих бытовых сетевых карточках "аппаратно": https://en.wikipedia.org/wiki/TCP_offload_engine

Хотя это старая статья, сейчас даже мало кто говорит "tcp offload", обычно это называют "nic offloads".

[@yappari]

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

Для этого придумали Byte stuffing. Чуть сложнее, поэтому следует определиться, что важнее: размер или надёжность выхватывания пакета.

[@aabzel]

 Byte stuffing - очень крутая технология, но информации по ней на русском исчезающе мало.

[@DrGluck07]

Да вроде даже на википедии всё понятно описано. А ещё на микроконтроллерах раньше любили использовать 9-битную передачу. Тогда признаком начала кадра служил девятый бит. Но мы уже давно так не делаем.

[@DrGluck07]

По поводу 8-битного CRC. Внутри железки платы общались через I2C. Внезапно раз в несколько секунд на дисплее стали появляться ошибки и неправильные парадоксальные данные. Полезли разбираться, оказалось, что иногда приходят пакеты с правильным CRC, но внутри пакета часть данных явно из другого пакета. В итоге оказалось, что примерно треть пакетов приходит битая с неправильным CRC. Они, естественно, отбрасываются. Но иногда CRC случайно совпадал. На шине передаётся пара сотен пакетов в секунду, часть из них битые, примерно у каждого 1 из 256 совпадает CRC, что логично.

Конечно мы нашли ошибку в работе с буферами на передающей стороне. И количество ошибочных пакетов упало до нуля. Но всё равно решили изменить CRC на 16-битное.