Делюсь опытом AdHoc пошаговое руководство

[cheblin]

только для тех, кому это интересно..

пока не разбирался как это прикручивать к ардуино...вероятно генерить С++ код

и да, сервер генерации уже доступен.

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

 

[pvvx]

пока не разбирался как это прикручивать к ардуино...вероятно генерить С++ код

Синтаксис C++, но без конструкций задействующих динамическое распределение памяти из-за отсутствия таковой у многих MCU используемых в Arduino.

 

[A_D]

>> установить любую JAVA IDE
Ну, мне вполне хватает VS и VS Code, зачем мне ещё IDE для ... генерации протокола ? Я понимаю, что для вас это нужно, т.к. разрабатываете на java, но пользователю то она зачем?
>> (далее по тексту и картинкам пробежался)
Правильно ли я понимаю, что надо описать на java что хочется в итоге получить, типа все свойства(переменные), формат и т.д., что бы в итоге получить сгенерённый код того же самого... что мне мешает не ставить IDE, не парится с java, а просто сразу описать то, что я хочу на Си ?

 

[pvvx]

Чтобы ваша работа не прошла даром, выберите пожалуйста какой типовой проект, часто используемый с ESP8266/ESP32 и на нем покажите актуальность использования AdHoc.

Пример типовых проектов:

• Включение/выключение лампочки через Web интерфейс в Arduino (SonOff)
• Погодная станция с публикацией на Народный Мониторинг
• Управление котлом или частотным преобразователем типа ZW-AT1
• Датчик для системы " Мажор сидит дома" и подобным

Ну и т.д.

 

[cheblin]

но без конструкций задействующих динамическое

значит просто будет недоступно на некоторых...

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

но пользователю то она зачем?

вот тут в начале описано

подробнее:
есть кодогенератор, которому нужно в некоторой форме объяснить, что генерировать. Нужна МЕТАинформация it is "data about data."

она может быть в виде XML как Mavlink
можно придумать свой язык как в Protocol Buffers
есть систебы которые читают схему базы данных и по ней генерируют полное web решение как SERENITY

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

например пакет Login должен содержать в себе строку Login и массив/строку Password.
в случае AdHoc как язык описания выбраны конструкции языка JAVA и это будет описано так

public static class Login{
   String Login;
   @__(100) byte Password;
}

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

спецификация проста и наглядна, поменялись требования - меняем спецификацию перегенерируем код

хватает VS и VS Code,

это хорошо! привыкли к комфортному програмированию? вот плагин JAVA под VS Code

что мне мешает не ставить IDE, не парится с java,

ничто не мешает, можно и в блакноте написать, как и програмы на С... однако ж у Вас стоит VS и VS Code

сразу описать то, что я хочу на Си

в AdHoc язык описания JAVA.
одна маленткая строчка в описании протокола может пораждать сотни строк исходников... и не только на С

выберите пожалуйста какой типовой проект, часто используемый

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

уже скачал и пристально поизучал Ваш esp8266web .

можно сделать три типа серваков,

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

сейчас я покопаюсь а ардуино, посмотрю что там и как...
покопаюсь в esp8266/32. Тулчейнов - глаза разбегаются.. это точно всё ещё актуально?
ну и обсуждаемые BLE.

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

Есть уже готовые проекты которые можно попробовать переделать на AdHoc? С удовольствием подключусь.

 

[cheblin]

BLE устройство, пусть это будет PowerProfiler, условно имеет:

1) Два ADC 16 бит изменения напряжения и тока.
2) Два DAC в 14 бит управления выходным напряжением и током
3) Регулировки параметров скорости опроса каждого ADC, с реал-тайм передачей от 0 до 2000 отсчетов в сек.
4) Регулировки параметров выходного тока и напряжения с реал-тайм шагом 0 до 2000 значений в сек.
Плюс ещё пару команд типа старт/стоп передачи и т.д. Т.е. не сложнее простейшего осциллографа, с чего начал свой заход автор AdHoc.

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

 

[pvvx]

уже скачал и пристально поизучал Ваш esp8266web .

Это была игра в целях освоения и указания другим что Web на ESP возможен и не более. Эта игра уже работала до появления Arduino на ESP... Свои цели она выполнила (Arduino до сих пор не дотянулась по многим факторам до этой игрушки - не могут освоить некоторые примитивные вещи и возможности чипа). Но справиться с ограниченной поддержкой TCP на ESP из-за "мало RAM" не смогла и не имела такой цели (не входит в класс изучения простейших).

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

Возможно упростить задачу, до "Передача потока 16-ти битных замеров с ADC", чтобы вам было легче.
Что там возникает:
как-то надо знать когда сделан замер или строгий шаг замеров в пачках с указанием номера замера для анализа выпадений. Вариантов много, как идентифицировать выпадение...
Как это лучше адаптировать в AdHoc знает только автор. Инструкций не обнаружено.

 

[cheblin]

беру за основу это comport?

 

[pvvx]

беру за основу это comport?

Та без разницы, т.к. там USB, а в другом случае BLE, т.е. блочные устройства.
С USB разница только в том, что включите пусть 4 устройства в один HUB USB1.1 (64 байтика на пакет).
Эмульнем 4 BLE соединения...

 

[pvvx]

значит просто будет недоступно на некоторых...

Ура - исключим ваш любимый STM8!
И ещё 90% дешевых чипов BLE, т.е. все с минимальным потреблением для автономных устройств.

 

[pvvx]

беру за основу это comport?

Там суть протокола в том, что этому устройству безразлично какой датчик он использует. Ограничения всего в протоколе i2c (smbus) у него в том, что регистры датчика читаются путем передачи по I2C адреса устройства, номера регистра и 16 бит данных.
Номера регистров и номера на шине i2c устройства задаваемые.
Какой регистр и с каким интервалом в каком перемежении считывать – задаваемо.
Размер пакета и укладка в него замеров – задаваемый. Необходимость в этом возникает когда опрос идет с большим шагом. Пока накопится пакет, пусть в 30 замеров, с секундным интервалом – это будет выглядеть на реал-тайм графике жуткими рывками отображения с шагом в 30 сек
Ждем описания динамического пакета в AdHoc.

 

[pvvx]

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

При задаваемом на ходу динамическом пакете с включением типизированных данных – только тут наблюдается нужда в автомате (возможны ошибки человеческого фактора) и только там нужен ИИ для глобальной оптимизации транзакций под задачу… Т.е. решение Булевских задач - сокращения комбинаторики

 

[cheblin]

паскаль...мдяяя. ржучота.
выбор жэскач

 

[pvvx]

паскаль...мдяяя. ржучота.
выбор жэскач

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

1. Заголовок начала пакета.
2. Тип, что это номер значения от ADC такого-то канала и сам номер.
3. Заголовок типа unsigned short и само значение.
4. Конец пакета.

Итого размер передачи на одно значение от 7 байт, вместо возможных (для случая USB1.1) 2.133334 байт на замер.

Шина full speed отправляет фрейм каждые 1.000 ms ±500 ns.

Максимальный фрейм в дровах USB-UART 64 байта. Специфика стандартных дров, при 64 байтах требует передачу доп.фрейма – конец фрагмента. При менее 64-х байтах этого не требуется, т.к. сам размер пакета указывает что это законченный фрагмент (т.е. полный фрейм и ожидать продолжения не требуется).

Итого: 63 байта *1000 в сек = 63000 в сек.

В случае AdHoc пакет не делится на 7 и даже в случае потоковой передачи имеем предел в 64000/7 = 9142 замера в сек на hub c 4-мя устройствами.

Если включить ИИ, то оно использует пакет в 62 байта, т.к. в нем укладывается тип пакета, необходимый номер о замере для вычисления пропусков и 30 замеров. Т.е. 1000 шт пакетов по 30 замеров. Итог 30000 замеров в сек на hub.
И будет варьировать кол-вом замеров в пакете при увеличении времени опроса замеров от ADC.

Крутая оптимизация в AdHoc – или опять что-то не так?

 

[pvvx]

Теперь энто переносим на BLE - всё тоже-самое, но издержки при AdHoc больше и прут по нарастающей...
ИИ спокойно передает хоть по тому-же алго и тем-же установкам манипуляции размера пакета от частоты опроса ADC... Но всё равно желательно уточнение на 20+27+27+... байтную разбивку на пакеты для BLE при которой достигается максимальная пропускная способность BLE стека... Т.к. устройство приема уже приучено на динамический размер - в нем ничего не меняется...

 

[pvvx]

При динамической типизации AdHoc вообще в полном пролете.

При соединении или во время последующей работы в зависимости от поведения канала ведущий передает ведомому какова будет типизация и набор в пакете… Больше ни одного лишнего бита по каналу, кроме самих данных не передается до следующего уточнения формата. За счет динамической типизации имеет совместимость с любыми жесткими форматами (стороннее ПО).

 

[cheblin]

как будет выглядеть в AdHoc

опять сели на свой конёк порассуждать о AdHoc, не ваше это

Давайте рассуждать о крахе и подъеме Голливуда, не видя ни одного фильма. Давайте сталкивать философов, не читая их работ. Давайте спорить о вкусе устриц и кокосовых орехов с теми, кто их ел, до хрипоты, до драки, воспринимая вкус еды на слух, цвет на зуб, вонь на глаз, представляя себе фильм по названию, живопись по фамилии, страну по "Клубу кинопутешествий", остроту мнений по хрестоматии.

про AdHoc - оставьте мне, справлюсь

куда как интереснее послушать как в Power Profiler сделано сейчас.

 

[pvvx]

Учитывая все совокупности и реалии, к примеру, что сети у нас 100 мегабитные IPv4 и стек TCP мы не пишем сами на свой лад, то разница в оптимизации максимальной пропускной способности без AdHoc, в сравнении с кривым халявным прикручиванием AdHoc в Arduino достигает порядочных 2 миллиона раз.
Основано на подсчете того что имеется в текущих описаниях AdHoc.

 

[cheblin]

куда как интереснее послушать как в Power Profiler сделано сейчас.

 

[pvvx]

куда как интереснее послушать как в Power Profiler сделано сейчас.

Сдался он вам? Оно так выросло само, с того века, путем вклинивания чего не попадя когда надо было и без разбору остального - это про паскаль часть
Та и в теме про PowerProfler написано - жду решений от молодежи... Даю фору по времени