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

pvvx

Активный участник сообщества
ну да, AdHoc протокол по вертикали интересен не только электронщикам, но и тем кому к примеру в web, gson на что нибудь поприличнее нужно заменить.
Тогда опять - к специалистам по подразделу java - javascript.
да банальный вездесущий UART. это ж очевидно. под это дело в AdHoc и специальный канал сделан
Зачем бинарному программатору типы данных?
У него один формат данных - адрес Flash и данные сектора...
Стандартизация этого дела - см. SEGGER. ... пока его опыт в стандартизации программаторов не впечатляет...
 

cheblin

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

pvvx

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

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

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

pvvx

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

pvvx

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

cheblin

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

cheblin

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

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

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

cheblin

Member
или к примеру необходимо чтобы устройство на микроконтроллере сохраняло свои настройки на 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

Активный участник сообщества
натолкнули на мысль, что мне необходимо в документации очертить круг применения 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

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

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

pvvx

Активный участник сообщества
о! классика жанра

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

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

cheblin

Member
Динамическая длина контекста – это к деревьям Хаффмана…
динамическая длинна - это пунктик такой?

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

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

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

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

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