BlackBox: генератор исходников обработки бинарного протокола

[cheblin]

Недавно закончил проект: BlackBox
После чего, в подтверждение зрелости и в качестве демонстрации возможностей BlackBox, в сравнении с MAVLink. успешно реализовал проект конвертации информации о пакетах обмена из формата MAVLink в формат BlackBox.

Все прекрасно работает, все тесты пройдены.
Какие преимущества?

• Использование в BlackBox в качестве формата описания протокола языка java, предоставляет широкий выбор средств редактирования со всеми возможностями рефакторинга. Описания пакетов обмена и топологии сети представляется в более компактном и привычном для программиста виде, по сравнению с XML форматом используемым в MavLink.
  
  
  Наследование полей пакетов.
  
  Дополнительные форматы данных:
  поля со встроенной структурой многомерных массивов,
  поля разреженных многомерных массивов
  битовые поля,
  поля со встроенной структурой многомерных массивов бит.
  Base 128 Varint сжатие данных.

Подробнее можно прочитать тут.

предлагаю оценить объем сгенерированного по этой спецификации кода на С

В одном только MicroAirVehicle.h под 16 000 строчек кода.
Кодогенератор генерирует это практически мнгновенно... и без ошибочно.
Самое большое время тратится на генерирование туевой хучи исходников тестов сгенерированного кода, компиляция их, и прогон.

С одним из вариантов использования BlackBox можно ознакомиться тут

[YS]

Сразу вопрос: возможно ли с помощью вашего инструмента сгенерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.

USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.

[cheblin]

[uquote="YS",url="/forum/viewtopic.php?p=3308699#p3308699"]Сразу вопрос: возможно ли с помощью вашего инструмента генерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.[/uquote]

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

[uquote="YS",url="/forum/viewtopic.php?p=3308699#p3308699"]USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.[/uquote]

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

//==============

уже нашел, посмотрел. и знаешь, если не будет сильно больших отличий, похоже что я сейчас это сделаю. не переключайтесь

===========
хотя с другой стороны ведь есть же FT232R USB <-> UART

[YS]

отжатая документация по протоколу USB

USB made simple

USB in a nutshell

готовые примеры

Посмотрите как, например, сделана LUFA.

уже нашел, посмотрел.

Э-э-э, это не то. В STM8 нет аппаратной поддержки USB. Я знаю про такие проекты (в духе V-USB), но они представляют мало интереса для серьезного применения. Это скорее "смотрите, и так можно! И даже работает! Офигеть!"

Вот например в STM32 (в некоторых чипах) есть аппаратная поддержка USB - в кремнии выполнена SIE, Serial Interface Engine, которая берет на себя всю работу с битовыми потоками. Задача состоит в том, чтобы, во-первых, взаимодействовать с SIE через память, а, во-вторых, обрабатывать запросы USB с вызовом соответствующих callback-функций. Это достаточно просто по сути, но крайне утомительно для ручной реализации.

похоже что я сейчас это сделаю

Вряд ли. В таких реализациях (софтовый USB на битовом уровне) каждый такт на счету, и критичные блоки написаны на ассемблере, причем с достаточно неочевидными оптимизациями. На Си это просто не будет работать.

хотя с другой стороны ведь есть же FT232R USB <-> UART

Есть. Но иногда хочется, чтобы, например, устройство прикидывалось флешкой (Mass Storage), или звуковой картой, и так далее.

[cheblin]

спасибо. ценно. подумаю что тут можно сделать

[linuxdude]

[uquote="YS",url="/forum/viewtopic.php?p=3308699#p3308699"]Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.[/uquote]
У линуксоидов все-равно веселее: modprobe g_ether - бабах, обнаружена usb-сетевка. Ах, флешку хотели? Тогда g_mass_storage! Можно и еще что-нибудь а через configfs можно изобразить наверное что угодно. А программирование - может и черт с ним, если хотелось чтобы за вас все сделали доугие? И даже работает на любой железке с usb-otg для которой драйвер есть как раз. Драйверов конечно же легион. В общем доведенный до абсолюта подход, когда никакие генераторы кода вообще не нужны - код модуля написан, а может даже и скомпилен за вас!

[YS]

linuxdude, что-то мне кажется, мы с вами говорим о разных вещах.

[cheblin]

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

Когда Вы описываете какие данные будут переданы в пакете, BlackBox гарантирует передачу описанных данных, но их место в пакете кодогенератор выбирает, в зависимости от их типа, самостоятельно. Это позволяет уменьшить объем метаданных хранящихся на клиенте. Например

у вас есть такой пакет
поле1 - long
поле2 - long
поле3 - byte
поле4 - String
поле5 - long

вместо того чтобы по отдельности описывать, для хранения на клиенте, тип каждого поля,

long
long
byte
String
long

кодогенератор делает так
1 поле - byte
3 поля - long
1 поле - String

под USB придется делать отдельный кодогенератор.. просто так не прокатит

[YS]

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

Может я чего-то не понимаю, но, по-моему, это убивает весь смысл идеи. Во многих случаях (в принципе, почти во всех, если говорить о существующих протоколах) положение полей фиксировано и имеет глубокий смысл. Хотя бы в том же TCP/IP - там куча вложенных пакетов, и во всех есть поля одинаковых типов, но располагаться они должны строго на своих местах.

А если как в файлах TDMS (формат выгрузки данных PXI-платформ/LabVIEW)? Там вообще все поля одного размера. Получается, кодогенератор перемешает их, как захочет? И как поддерживать существующие форматы?

Я, наверное, неверно понял, для чего нужен ваш инструмент.

[cheblin]

кодогенератор BlackBox согласно спецификации в которой описано КАКИЕ данные передавать, генерирует исходный код который гарантирует выполнение этой задачи.

еще раз, кодогенератор BlackBox гарантирует передачу перечисленных данных, а не позицию (положение) этих данных в пакете.

теперь почему сделано так.

среди типов данных BlackBox есть битовые поля и даже многомерные массивы битовых полей.
описываются такие БИТОВЫЕ поля с помощью аннотации @B
предположим что у нас есть маленький пакет

Код: Выделить всё

class DemoPack {
	@B(2) byte filed_2bits; //двухБИТОВОЕ поле
	byte  one_byte_field; // одноБАЙТОВОЕ поле
	short two_byte_field; // двуБАЙТОВОЕ поле
	@B(4) byte filed_4bits; //четырехБИТОВОЕ поле
	@B(2) byte filed2_2bits; //двухБИТОВОЕ поле
}

очевидно, что минимальная порция информация которой оперирует проц и которую можно переслать, является байт.
если не менять порядок полей в данном пакете, то

возможны 2 варианта. упаковки

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

очевидно, что в этом случае происходит неэффективное использование пространства пакета. но быстрый доступ к цельнобайтным полям

второй вариант, с плотной упаковкой

отводим первые два бита первого байта пакета на первое поле filed_2bits.
следующее поле one_byte_field займет оставшиеся 6 бит первого байта, и 2 бита следующего байта,.. и так далее

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


BlackBox пошел по другому пути.

В BlackBox происходит разделение полей на цельнобайтные и битовые.
чтобы максимально упаковать данные пакета и не потерять в производительности
положения полей меняется, так, что вначале идут цельнобайтные поля, а в конце собираются битовые поля.

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


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

потому проект и называется BlackBox.
Вас совершенно не должно интересовать, что там происходит там внутри этого BlackBox.

BlackBox каждый раз генерирует разный код обработки. Полученные байты он конвертирует в пакеты а пакеты в байты.

он может работать как поверх TCP/IP так и поверх UART.

[YS]

А-а-а. Эх. Я-то думал, что этот инструмент позволяет по описанию известного протокола/формата сгенерировать код его разбора... А он генерирует какой-то свой велосипед.

Чем тогда это принципиально отличается от того, чтобы руками сложить все данные в структуру и передавать-принимать ее как массив (с приведением типа)?

Код: Выделить всё

#pragma pack (1)
typedef struct {
    uint8_t field1;
    uint16_t field2;
    ...
} test_t;

test_t packet;

...

uint16_t k;

for (k=0; k<sizeof(test_t); k++)
{
    SendByte(((uint8_t *)(&packet))[k]);
}

И все, никакие кодогенераторы не нужны...

[cheblin]

[uquote="YS",url="/forum/viewtopic.php?p=3309554#p3309554"]А-а-а. Эх. Я-то думал, что этот инструмент позволяет по описанию известного протокола/формата сгенерировать код его разбора... А он генерирует какой-то свой велосипед.

Чем тогда это принципиально отличается от того, чтобы руками сложить все данные в структуру и передавать-принимать ее как массив (с приведением типа)?
.[/uquote]
здравствуй big-endian ... а ты что ещё за little-endian....
=================

проблематика весьма обширна, коротко её не изложить.
но намекнуть, на некоторые неочевидные моменты попробую.

сделайте поиск по фразе MAVLink, в гугле, а потом на GITHub - попрежнему уверены все эти безумцы чего не понимают в отличии от Вас?
а MAVLink сделан существенно более примитивно чем BlackBox.

теперь вернемся к примеру Вашего простого решения на структурах,
подумайте, а что если в ваш пакет нужно добавить

необязательные поля,
а ещё массивы,
необязательные массивы..
а ещё многомерные массивы,
а ещё многомерные массивы часть измерений которых динамические
а теперь битовые поля + многомерные массивы бит?

ну и в конце всё это нужно на разных языках.

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

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

а потом вы передумали.....

и так далее.... Вы б не поленились сходили бы почитать документацию, по моим ссылкам.

Уверяю Вас там все совсем не очевидно и просто.

+ посмотрите это и это видео.

людям свойственно конечно изобретать колесо. но это совсем не тот случай.

[AndyBig]

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

[YS]

здравствуй big-endian ... а ты что ещё за little-endian....

В случае описания протоколов порядок байт всегда специфицирован. Развернуть слово труда не составляет.

И, справедливости ради, 99% машин, с которыми я работал, используют little-endian.

сделайте поиск по фразе MAVLink

Сделал. Протокол как протокол.

Уверяю Вас там все совсем не очевидно и просто.

Вы рассказываете это человеку, который плотно разбирался с USB и Ethernet, а также писал парсер TDMS для преобразования этой жути во что-то более удобоваримое (с целью последующей обработки данных). Вот в последнем есть и необязательные поля, и массивы, и массивы свойств...

Про мелочи вроде DMX-512 и всяких WAV я не говорю. Хотя WAV, если копнуть, тоже очень заморочен. Просто в наши дни используется в основном лишь одна его разновидность, позволяющая хранить PCM. Хотя WAV и PCM - это не синонимы.

ну и в конце всё это нужно на разных языках.

В эмбеде применяется Си. Для ПК можно написать DLL/статическую библиотеку на Си и подключать ее к чему угодно.

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

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

Например, протокол USB получился таким укуренным потому, что его создатели в наивности своей хотели разом решить все проблемы всех на свете. Но много вы видели устройств, которые используют существенную часть возможностей USB в смысле логической структуры устройства, или хотя бы реализуют свой, не относящийся к стандартным, класс? Для чего-то помимо аудио-видео и накопителей почти исключительно применяется либо HID, либо, чаще всего, CDC. Но все, кто реализует протокол, до сих пор должны тащить все то, что было запихано туда в попытке осчастливить человечество, а теперь по факту является ненужным грузом.

[cheblin]

99% машин, с которыми я работал, используют little-endian.

В java DataInputStream BigEndian сказать почему?
Traditionally, internet protocols use big endian, because the machines doing most of the communication were big endian

а большой мир Android устройств == java

[uquote="YS",url="/forum/viewtopic.php?p=3309814#p3309814"]В случае описания протоколов порядок байт всегда специфицирован. Развернуть слово труда не составляет.[/uquote]

верно развернуть порядок байт КАЖДОГО ПОЛЯ труда не составит. только "победного марша" в виде кастинга структуры в байтовый массив и выливание в сеть уже не получится.

+ почитайте ещё про Bit and Byte Stuffing про framing почитайте.

не, конечно, когда ниже TCP/IP не опускаешься, про это можно не читать...
Но мы ж про 8 битные микроконтроллеры тоже не забываем. BlackBox такое может.

теперь следующая проблема.
имея знания о данных полей можно эффективно и незатратно сжимать данные ОТДЕЛЬНЫХ полей. например Base 128 Varint активно используется в google protobuf


[uquote="YS",url="/forum/viewtopic.php?p=3309814#p3309814"]MAVLink
Сделал. Протокол как протокол.[/uquote]

Вот и ладушки. Идеологически MAVLink - тоже самое что и BlackBox только у него проблема он родился и сразу перестал расти.

вот эти планы там с 2009 года

Future Work / Ideas
Variable length arrays
Support for bitfields (e.g. packing 8 boolean values into one uint8_t, but providing C-function calls to all eight booleans. So users would not have to fiddle with shifting / masking themselves.)
Variable header, allowing to set target system and target component (no change to protocol, only convenience functions to access it)

BlackBox это может здесь и сейчас + ещё многое.

Для ПК можно написать DLL/статическую библиотеку на Си и подключать ее к чему угодно.

можно, но только мир BlackBox НЕ ограничивается компьютерами и может быть применен и для решения таких проблем

Вы рассказываете это человеку, который плотно разбирался с USB и Ethernet, а также писал парсер TDMS для преобразования этой жути во что-то более удобоваримое

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

TCP/IP выполняет для вас только функцию надежного транспорта. какие байты при этом в payload передаются (какой протокол) это на усмотрения Вашего приложения.
в чистом виде, без разбора принятых байт TCP для вас бесполезен.

а разбор байт не так уж и примитивен, как было показано выше.

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

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

Добавлено after 51 minute 17 seconds:
[uquote="AndyBig",url="/forum/viewtopic.php?p=3309754#p3309754"]У меня сложилось впечатление, что людям свойственно изобретать какие-то абстрактные проблемы и потом с ними бороться.[/uquote]

точно! понапридумывают всякие
MQTT
MQTT-SN
CoAP
SMCP
STOMP
XMPP
XMPP-IoT
Mihini/M3DA
AMQP
DDS
LLAP
LWM2M
SSI

сиди тут разгребай...ведь жили как то диды без этого всего..

[YS]

А, вот теперь до меня доходит. Ваш продукт, видимо, не предназначен для разбора существующих протоколов, как я по первости подумал. Жалко. Он, как я теперь понимаю, представляет собой генератор кода для своего протокола.

Ну что же, удачи в прозелитизме. Но учитите, что создать решение для всего и сразу невозможно. Многие уже пытались, результат всегда одинаков.

не, конечно, когда ниже TCP/IP не опускаешься, про это можно не читать...

Я, как правило, в силу своих занятий, обычно не поднимаюсь выше TCP/IP и подобного.

BlackBox это может здесь и сейчас + ещё многое.

Прежде чем что-то делать, надо задать себе вопрос "зачем?". Потому главный вопрос - а не делать этого BlackBox может?

Но мы ж про 8 битные микроконтроллеры тоже не забываем. BlackBox такое может.

Тогда вам надо забыть про использование динамического выделения памяти, как минимум. Глубоко код не копал, но это уже режет глаз. По ссылке же код для контроллера? Тогда почему там встречается malloc/free?

Про goto я молчу, все же это автосгенерированный код.

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

у него проблема он родился и сразу перестал расти

И слава Богу! Может вы еще DMX-512 или CAN реформировать предложите? А что? Они же такие простые и немодные! Давайте добавим туда массивы переменной длины и еще чего-нибудь по вкусу!

понапридумывают всякие

Да, я уже постил комикс на эту тему.

[cheblin]

Тогда вам надо забыть про использование динамического выделения памяти, как минимум. Глубоко код не копал, но это уже режет глаз. По ссылке же код для контроллера? Тогда почему там встречается malloc/free?

Про goto я молчу, все же это авто сгенерированный код.

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

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

ни дня на ардуино не писал, а мою библиотеку для STM8 можно найти там же по ссылке

Может вы еще DMX-512 или CAN реформировать предложите? А что?

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

для чего вам эти приемы?

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

[YS]

у вас на удивление шаблонное мышление. вы просто сыпите штампами не понимая их смысла.

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

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

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

Все-все-все, я согласен, ваша идея гениальна, а код - само совершенство, сам Фабрис Беллар не написал бы лучше.

Ладно. Дискуссия приобретает неконструктивный характер. Пойду-ка я из этой темы. Мне такие инструменты и правда не нужны, может кто другой соблазнится.

[cheblin]

[uquote="YS",url="/forum/viewtopic.php?p=3310070#p3310070"]Все-все-все, я согласен, ваша идея гениальна, а код - само совершенство, сам Фабрис Беллар не написал бы лучше. [/uquote]
да что ж Вас так колбасит-то... соберитесь.

[cheblin]

обсуждение на geektimes

Добавлено after 3 hours 16 minutes 57 seconds:
[uquote="YS",url="/forum/viewtopic.php?p=3308699#p3308699"]Сразу вопрос: возможно ли с помощью вашего инструмента сгенерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.

USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.[/uquote]

кстати отвечая на этот вопрос.

со мной связался создатель того проекта
этот проект делает именно то, чего Вам хочется.

по формальному описанию полей и их размеров парсит структуры