Недавно закончил проект: BlackBox После чего, в подтверждение зрелости и в качестве демонстрации возможностей BlackBox, в сравнении с MAVLink. успешно реализовал проект конвертации информации о пакетах обмена из формата MAVLink в формат BlackBox.
Все прекрасно работает, все тесты пройдены. Какие преимущества?
Использование в BlackBox в качестве формата описания протокола языка java, предоставляет широкий выбор средств редактирования со всеми возможностями рефакторинга. Описания пакетов обмена и топологии сети представляется в более компактном и привычном для программиста виде, по сравнению с XML форматом используемым в MavLink.
Наследование полей пакетов.
Дополнительные форматы данных: поля со встроенной структурой многомерных массивов, поля разреженных многомерных массивов битовые поля, поля со встроенной структурой многомерных массивов бит. Base 128 Varint сжатие данных.
В одном только MicroAirVehicle.h под 16 000 строчек кода. Кодогенератор генерирует это практически мнгновенно... и без ошибочно. Самое большое время тратится на генерирование туевой хучи исходников тестов сгенерированного кода, компиляция их, и прогон.
С одним из вариантов использования BlackBox можно ознакомиться тут
Сразу вопрос: возможно ли с помощью вашего инструмента сгенерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.
USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Сразу вопрос: возможно ли с помощью вашего инструмента генерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.
мысль интересная. в принципе ничто не мешает. нужно просто грамотно составить спецификацию. собираюсь покопать в этом направлениии, спасибо за наводку.
USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.
если есть готовые примеры и и отжатая документация по протоколу USB, был бы благодарен.
//==============
уже нашел, посмотрел. и знаешь, если не будет сильно больших отличий, похоже что я сейчас это сделаю. не переключайтесь
=========== хотя с другой стороны ведь есть же FT232R USB <-> UART
Э-э-э, это не то. В STM8 нет аппаратной поддержки USB. Я знаю про такие проекты (в духе V-USB), но они представляют мало интереса для серьезного применения. Это скорее "смотрите, и так можно! И даже работает! Офигеть!"
Вот например в STM32 (в некоторых чипах) есть аппаратная поддержка USB - в кремнии выполнена SIE, Serial Interface Engine, которая берет на себя всю работу с битовыми потоками. Задача состоит в том, чтобы, во-первых, взаимодействовать с SIE через память, а, во-вторых, обрабатывать запросы USB с вызовом соответствующих callback-функций. Это достаточно просто по сути, но крайне утомительно для ручной реализации.
Цитата:
похоже что я сейчас это сделаю
Вряд ли. В таких реализациях (софтовый USB на битовом уровне) каждый такт на счету, и критичные блоки написаны на ассемблере, причем с достаточно неочевидными оптимизациями. На Си это просто не будет работать.
Цитата:
хотя с другой стороны ведь есть же FT232R USB <-> UART
Есть. Но иногда хочется, чтобы, например, устройство прикидывалось флешкой (Mass Storage), или звуковой картой, и так далее.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.
У линуксоидов все-равно веселее: modprobe g_ether - бабах, обнаружена usb-сетевка. Ах, флешку хотели? Тогда g_mass_storage! Можно и еще что-нибудь а через configfs можно изобразить наверное что угодно. А программирование - может и черт с ним, если хотелось чтобы за вас все сделали доугие? И даже работает на любой железке с usb-otg для которой драйвер есть как раз. Драйверов конечно же легион. В общем доведенный до абсолюта подход, когда никакие генераторы кода вообще не нужны - код модуля написан, а может даже и скомпилен за вас!
Посмотрел, подумал. Нет. Не прокатит. Это придется делать отдельный продукт.
Когда Вы описываете какие данные будут переданы в пакете, BlackBox гарантирует передачу описанных данных, но их место в пакете кодогенератор выбирает, в зависимости от их типа, самостоятельно. Это позволяет уменьшить объем метаданных хранящихся на клиенте. Например
у вас есть такой пакет поле1 - long поле2 - long поле3 - byte поле4 - String поле5 - long
вместо того чтобы по отдельности описывать, для хранения на клиенте, тип каждого поля,
long long byte String long
кодогенератор делает так 1 поле - byte 3 поля - long 1 поле - String
под USB придется делать отдельный кодогенератор.. просто так не прокатит
их место в пакете кодогенератор выбирает, в зависимости от их типа, самостоятельно
Может я чего-то не понимаю, но, по-моему, это убивает весь смысл идеи. Во многих случаях (в принципе, почти во всех, если говорить о существующих протоколах) положение полей фиксировано и имеет глубокий смысл. Хотя бы в том же TCP/IP - там куча вложенных пакетов, и во всех есть поля одинаковых типов, но располагаться они должны строго на своих местах.
А если как в файлах TDMS (формат выгрузки данных PXI-платформ/LabVIEW)? Там вообще все поля одного размера. Получается, кодогенератор перемешает их, как захочет? И как поддерживать существующие форматы?
Я, наверное, неверно понял, для чего нужен ваш инструмент.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
кодогенератор 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.
А-а-а. Эх. Я-то думал, что этот инструмент позволяет по описанию известного протокола/формата сгенерировать код его разбора... А он генерирует какой-то свой велосипед.
Чем тогда это принципиально отличается от того, чтобы руками сложить все данные в структуру и передавать-принимать ее как массив (с приведением типа)?
А-а-а. Эх. Я-то думал, что этот инструмент позволяет по описанию известного протокола/формата сгенерировать код его разбора... А он генерирует какой-то свой велосипед.
Чем тогда это принципиально отличается от того, чтобы руками сложить все данные в структуру и передавать-принимать ее как массив (с приведением типа)? .
здравствуй big-endian ... а ты что ещё за little-endian.... =================
проблематика весьма обширна, коротко её не изложить. но намекнуть, на некоторые неочевидные моменты попробую.
сделайте поиск по фразе MAVLink, в гугле, а потом на GITHub - попрежнему уверены все эти безумцы чего не понимают в отличии от Вас? а MAVLink сделан существенно более примитивно чем BlackBox.
теперь вернемся к примеру Вашего простого решения на структурах, подумайте, а что если в ваш пакет нужно добавить
необязательные поля, а ещё массивы, необязательные массивы.. а ещё многомерные массивы, а ещё многомерные массивы часть измерений которых динамические а теперь битовые поля + многомерные массивы бит?
ну и в конце всё это нужно на разных языках.
известно что к примеру данный пакет может быть принят и обработан только на хосте А значит только на хосте А нужно сгенерировать код приёма пакета и вытягивания полей. всем остальным участникам нужен только код отправки пакета.
а есть ещё пакет который принимается и отправляется всеми хостами, значит код приёма и обработки нужно сгенерировать всем
а потом вы передумали.....
и так далее.... Вы б не поленились сходили бы почитать документацию, по моим ссылкам.
здравствуй big-endian ... а ты что ещё за little-endian....
В случае описания протоколов порядок байт всегда специфицирован. Развернуть слово труда не составляет.
И, справедливости ради, 99% машин, с которыми я работал, используют little-endian.
Цитата:
сделайте поиск по фразе MAVLink
Сделал. Протокол как протокол.
Цитата:
Уверяю Вас там все совсем не очевидно и просто.
Вы рассказываете это человеку, который плотно разбирался с USB и Ethernet, а также писал парсер TDMS для преобразования этой жути во что-то более удобоваримое (с целью последующей обработки данных). Вот в последнем есть и необязательные поля, и массивы, и массивы свойств...
Про мелочи вроде DMX-512 и всяких WAV я не говорю. Хотя WAV, если копнуть, тоже очень заморочен. Просто в наши дни используется в основном лишь одна его разновидность, позволяющая хранить PCM. Хотя WAV и PCM - это не синонимы.
Цитата:
ну и в конце всё это нужно на разных языках.
В эмбеде применяется Си. Для ПК можно написать DLL/статическую библиотеку на Си и подключать ее к чему угодно.
Цитата:
подумайте, а что если в ваш пакет нужно добавить
Необходимость изобретать неочевидные решения чаще всего свидетельствует о том, что с системой что-то не так на идейном уровне. В этом случае надо не подкладывать костыли, а пересмотреть парадигму. Но это так, к слову.
Например, протокол USB получился таким укуренным потому, что его создатели в наивности своей хотели разом решить все проблемы всех на свете. Но много вы видели устройств, которые используют существенную часть возможностей USB в смысле логической структуры устройства, или хотя бы реализуют свой, не относящийся к стандартным, класс? Для чего-то помимо аудио-видео и накопителей почти исключительно применяется либо HID, либо, чаще всего, CDC. Но все, кто реализует протокол, до сих пор должны тащить все то, что было запихано туда в попытке осчастливить человечество, а теперь по факту является ненужным грузом.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
99% машин, с которыми я работал, используют little-endian.
В java DataInputStream BigEndianсказать почему? Traditionally, internet protocols use big endian, because the machines doing most of the communication were big endian
В случае описания протоколов порядок байт всегда специфицирован. Развернуть слово труда не составляет.
верно развернуть порядок байт КАЖДОГО ПОЛЯ труда не составит. только "победного марша" в виде кастинга структуры в байтовый массив и выливание в сеть уже не получится.
не, конечно, когда ниже TCP/IP не опускаешься, про это можно не читать... Но мы ж про 8 битные микроконтроллеры тоже не забываем. BlackBox такое может.
теперь следующая проблема. имея знания о данных полей можно эффективно и незатратно сжимать данные ОТДЕЛЬНЫХ полей. например Base 128 Varint активно используется в google protobuf
Вот и ладушки. Идеологически 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 другая идеология - каждому свой лунапарк без особых затрат, так, что все кто на борту понимают друг друга, до остального мира дела нет.
А, вот теперь до меня доходит. Ваш продукт, видимо, не предназначен для разбора существующих протоколов, как я по первости подумал. Жалко. Он, как я теперь понимаю, представляет собой генератор кода для своего протокола.
Ну что же, удачи в прозелитизме. Но учитите, что создать решение для всего и сразу невозможно. Многие уже пытались, результат всегда одинаков.
Цитата:
не, конечно, когда ниже TCP/IP не опускаешься, про это можно не читать...
Я, как правило, в силу своих занятий, обычно не поднимаюсь выше TCP/IP и подобного.
Цитата:
BlackBox это может здесь и сейчас + ещё многое.
Прежде чем что-то делать, надо задать себе вопрос "зачем?". Потому главный вопрос - а не делать этого BlackBox может?
Цитата:
Но мы ж про 8 битные микроконтроллеры тоже не забываем. BlackBox такое может.
Тогда вам надо забыть про использование динамического выделения памяти, как минимум. Глубоко код не копал, но это уже режет глаз. По ссылке же код для контроллера? Тогда почему там встречается malloc/free?
Про goto я молчу, все же это автосгенерированный код.
Простите меня, возможно, я чего-то не понял и ошибаюсь, но пока что мне кажется, что в ваших рассуждениях применительно к микроконтроллерной стороне сквозит подход любителя Ардуино.
Цитата:
у него проблема он родился и сразу перестал расти
И слава Богу! Может вы еще DMX-512 или CAN реформировать предложите? А что? Они же такие простые и немодные! Давайте добавим туда массивы переменной длины и еще чего-нибудь по вкусу!
Цитата:
понапридумывают всякие
Да, я уже постил комикс на эту тему.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Тогда вам надо забыть про использование динамического выделения памяти, как минимум. Глубоко код не копал, но это уже режет глаз. По ссылке же код для контроллера? Тогда почему там встречается malloc/free?
Про goto я молчу, все же это авто сгенерированный код.
у вас на удивление шаблонное мышление. вы просто сыпите штампами не понимая их смысла. есть языковые инструменты, которыми нужно грамотно пользоваться. что и происходит в упомянутом коде.
Цитата:
Простите меня, возможно, я чего-то не понял и ошибаюсь, но пока что мне кажется, что в ваших рассуждениях применительно к микроконтроллерной стороне сквозит подход любителя Ардуино.
Может вы еще DMX-512 или CAN реформировать предложите? А что?
давайте придумаем какую нибудь глупость, которую оппонент мог бы совершить, и помечтаем как бы мы выигрышно выглядели бы на этом фоне.
для чего вам эти приемы?
если у вас есть желание разобраться, я готов помочь. не понимаете для чего подобные инструменты, которыми многие пользуются? не сталкивались с подобными задачами? воспользуйтесь случаем расширить кругозор.
у вас на удивление шаблонное мышление. вы просто сыпите штампами не понимая их смысла.
Если вам недостаточно моего мнения, то могу сказать, что использование динамической памяти во встроенных системах запрещено MISRA.
Ну и любому здравому человеку понятно, что устраивать динамическое выделение памяти в устройстве с килобайтом RAM - очень экстравагантно. Вы же с маленькими контроллерами хотите работать, да?
Цитата:
есть языковые инструменты, которыми нужно грамотно пользоваться. что и происходит в упомянутом коде.
Все-все-все, я согласен, ваша идея гениальна, а код - само совершенство, сам Фабрис Беллар не написал бы лучше.
Ладно. Дискуссия приобретает неконструктивный характер. Пойду-ка я из этой темы. Мне такие инструменты и правда не нужны, может кто другой соблазнится.
_________________ Разница между теорией и практикой на практике гораздо больше, чем в теории.
Сразу вопрос: возможно ли с помощью вашего инструмента сгенерировать USB-драйвер с учетом интерфейса конкретной SIE в применяемом МК? Это было бы самым хитовым приложением предлагаемой системы, как по мне.
USB-код в принципе прост идейно (сводится к обработке запросов по правилам), но очень громоздок (запросов огромнейшее количество, а дескрипторы достаточно запутанны). Если бы такие драйвера можно было генерировать автоматически для реализации любого класса USB на любом контроллере с аппаратной поддержкой USB - это был бы прорыв.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 22
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
И даже работает на любой железке с usb-otg для которой драйвер есть как раз. Драйверов конечно же легион. В общем доведенный до абсолюта подход, когда никакие генераторы кода вообще не нужны - код модуля написан, а может даже и скомпилен за вас! 
