Обсуждение AdHoc бинарный протокол.

[pvvx]

ну да, AdHoc протокол по вертикали интересен не только электронщикам, но и тем кому к примеру в web, gson на что нибудь поприличнее нужно заменить.

Тогда опять - к специалистам по подразделу java - javascript.

да банальный вездесущий UART. это ж очевидно. под это дело в AdHoc и специальный канал сделан

Зачем бинарному программатору типы данных?
У него один формат данных - адрес Flash и данные сектора...
Стандартизация этого дела - см. SEGGER. ... пока его опыт в стандартизации программаторов не впечатляет...

 

[cheblin]

опять не понял. причём тут програматор?
> к специалистам по подразделу java - javascript.
один инструмент для всех участников информационного обмена, разве это плохо?

 

[pvvx]

опять не понял. причём тут програматор?
> к специалистам по подразделу java - javascript.
один инструмент для всех участников информационного обмена, разве это плохо?

См. Востребованность инструмента.
----------
В общем, что хотелось донести –

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

Тот-же BT/BLE роутер имеет возможность принимать более 200 маяков в сек. Сама сеть BLE mesh расширяется на десятки тысяч устройств. Все устройства передают данные в своем формате, потуги стандартизации UUID/GATT смешны – на них производители не реагируют. Итог этого бардака пока не ясен.

 

[pvvx]

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

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

 

[pvvx]

Генераторы кода парсеров бинарного/символьного потока - это вроде уже начало 2000 года... имею ввиду использование...
Всё по кругу

 

[cheblin]

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

 

[cheblin]

ок. давай за практику.

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

Ваши действия.

 

[cheblin]

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

отнюдь не банальный массив... настроек много, много вложенностей....

 

[pvvx]

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

во-во. Самое оно - это что-то в области типа BLE. Почему про него и разговор...

 

[pvvx]

ок. давай за практику.

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

Ваши действия.

Все осциллографы, которые видел, имеют один фиксированный буфер "текущего изображения", буфер замеров и настройки по уже стандартному протоколу.

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

отнюдь не банальный массив... настроек много, много вложенностей....

SD и т.п. карта любит (и позволяет) запись разово only сектор. Стирание - фиксед сегмент.
Создаете поля по фикс. адресам в блоке и пишите.
При неизвестном размере записи устройство должно быть снабжено источником резервного питания, что для малых дешевых MCU не актуально.

 

[pvvx]

остаётся верить

Краткое введение:
Минимальная структура для поддержки состояния TCP соединения TIME_WAIT, IPv4.

Внешний IP – 4 байта, Порт – 2 байта, время таймера – 4 байта, внутренний IP – 4 байта (*), внутренний порт – 2 байта, cсостояние – несколько бит (пусть 1 байт).

(*) не обязателен у простейшего контроллера с одним if интерфейсом.

Резерв RAM под такие структуры необходим на время хранения каждой на 120 сек по неверному закрытию соединения у сервера или для всех соединений у клиента. Кол-во портов у простенького устройства = 65536 шт. Т.е. мин. объем в 65536 структур к 16 байтам = 1048576 байт.

По производительности – при открытии нового соединения требуется сканирование всего списка. При открытии TCP соединения MCU должен проверять время окончания состояния TIME_WAIT – сбрасывать отработавшие таймаут. При закрытии – создавать данную структуру, но она и так создается в большем объеме для любого соединения и содержит в минимуме несколько сотен байт, а по закрытию не очищается, т.к. надо выждать 120 сек для исключения повторной связи с использованными IP и портами (внешними и внутренними, что у большого сервера, распределяющего обоих не ограничивает кол-во новых TCP соединений, но и кол-во таких структур используется побольше) ...

Как только это влезет в ESP ?

 

[pvvx]

Пример по ослам: pvvx/DSRemote

 

[pvvx]

Ущё, уточнение по ослам -> SCPI commands -> Standard Commands for Programmable Instruments - Wikipedia
Пример для не поддерживаемых стандарты ослов - Owon.rar (PDS8202T - изжило давно, забыл стереть )

 

[pvvx]

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

COM порт сразу отпадает - это ныне только DIY для детей, и то уже замещается USB.
Как и говорил - AdHoc - это увлечение в игру с java и не более. Пока увлекались, всё остальное прошло стороной...
Современность физики интерфейсов - фиксед. пакет и бешеная скорость передачи самого пакета с любыми паузами, хоть сутки

 

[pvvx]

Исключение - NB-IoT. Но пока не распространен в нашей "народной сфере" - провайдеры медленно осваивают (руссифицируют) зарубежное ПО и оборудование вышек...

 

[pvvx]

Если рассматривать оптимизацию по производительности для всех современных CPU/MCU и т.д. (включая сетевые коммутаторы), то опять имеем такую картину:

Фиксированная выемка/запись из любой памяти в кеш. Даже блок XIP с SPI Flash/pSRAM– 16/32 байта и менее не прочитать/записать. Если менее – пустая затрата времени и энергии, т.к. остальное просто не будет использоваться в обработке, но поставится к ALU в ядро...

Тут сокращение в разборе по типам может быть только аппаратным дешифратором на все биты блока.

Linux… Подавляющее большинство баз данных – опять фиксированный блок по максимальной структуре, хоть для хранения одного бита…

Получается, что динамическая длина контекста изживается на блочную. Фиксированные поля актуальны и для IPv6 и для скоростных коммутаторов, что и происходит…

 

[pvvx]

Динамическая длина контекста – это к деревьям Хаффмана…
Но не вижу аппаратных блоков zip или прочего сжатия в MCU. Наверно время для второго кольца повтора ещё не пришло.
Счас прыжок интеграции (технологии) сразу в 2 раза. С 7..12 nm в 4 nm... + 5G -> Значит сжимать передаваемый поток никому и в голову не придет.

 

[cheblin]

Пример по ослам: pvvx/DSRemote

о! классика жанра

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

 

[pvvx]

о! классика жанра

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

Хде же этот ИИ? Так и не созрел?
Звание программер - это такой чувак, который в аппаратных средствах ни бум-бум. Ему всё только кажется и виртуально.
Как теоретики и практики в физике... Середина встречается очень-очень редко... Ныне вроде прозвали "системным программером"....

ПО заточенное на тесты Его спасает только OTA - такая новая система тестов тестов.
Не забудьте про сертификацию - как же писать ПО без справки?
-------
Надеюсь, что вас убедил, что побитной передачи ныне нет и оптимизация по битам, которая стоит во главе AdHoc никому не нужна.

 

[cheblin]

Динамическая длина контекста – это к деревьям Хаффмана…

динамическая длинна - это пунктик такой?

фиксированная динна пакета - это СТАРЫЙ ламповай подход.
его плюсы - прост как палка.
его минусы - он крайне не эффективен
вне зависимости от того, что из 30 полей в пакете полезного тольно новое значение вот этих двух будут переданны все 30.

поясняю откуда взялась динамическая длинна пакета( и это кстати значительно сложнее фиксированной )
и это следущий этап развития пакетов с фиксированной длинной
в прощессе эксплуатации можно заметить что часть полей как правило заполняется при каждой передачи, а другая часть редко.

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

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

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