Micro Property — минималистичный сериализатор двоичных данных для embedded систем. Часть 2

[Spym]

В исходных требованиях вы, кажется, не писали о том, что формат должен быть самоописывающим (self-describing). Во встраиваемых системах это применяется сравнительно редко. Мы решали схожую задачу в протоколе, ссылку на статью о котором я давал в комментарии к вашей прошлой публикации; если интересно, можете взглянуть здесь: https://uavcan.org/specification/UAVCAN_Specification_v1.0-beta.pdf#page=15 (раздел "data structure description language"). Удаление метаданных из сериализованного сообщения не только уменьшает избыточность (что важно в вашем случае, как я вижу из требований), но и уменьшает вариативность представлений (есть только один способ закодировать данные, в то время как в TLV формате можно, к примеру, поменять местами поля структуры, не затронув семантику сообщения; этот вопрос рассматривается в спецификациях ASN.1 тоже), что удешевляет тестирование в отказоустойчивых приложениях.

[rsashka]

Да, вы совершено правы насчет передачи структуры в самом сообщении, чего например нет в формате protobuf. Мне действительно было важно иметь информацию именно о самых полях, а не сообщении в целом, хотя в явном виде это действительно нигде не отмечено.

[edo1h]

А вот в MessagePack пошли еще дальше! В этом формате минимальные накладные расходы на хранение значения составляют всего 1 (ОДИН!) бит информации. Соответственно, для хранения дополнительной информации может использоваться уже 7 бит, а для указания дополнительной информации о типе поля используются значения с установленным старшим битом.

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

какая у вас в итоге вышла экономия на размере сообщений?

[rsashka]

Так вроде в следующем абзаце это написано, что за счет количества отрицательных чисел, которых можно закодировать с помощью одного байта

(в одном байте можно хранить только 32 отрицательных числа, а для остальных значений уже потребуется второй байт)

В общем итоге, у меня как правило умещаются три значения в одном CAN сообщении, у которого размер полезных данных до 8 байт.

До этого было 1-2 сообщения, т.к. использовалось не упакованное представление двоичных данных не зависимо от его значения. (т.е. 16-бит всегда 2 байт, 32-бит всегда 4 байта + всегда обязательный идентификатор поля или номер версии формата).
Теперь выходит, что выигрыш составляет фактически 1.5-2 раза для отдельных сообщений, т.е. не нужно пересылать номер версии формата, а сами данных хранятся в минимально возможном размере.

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