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

[pvvx]

А задача элементарная - сократить внутреннюю себестоимость продукции замещая чужое дорогущее оборудование с AdHoc и подобным.
Чтобы оно было рентабельно - стоимость должна быть в от 10 раз менее, а надежность в 10 более
Вот часть конкретики вопроса из вики:
Чтобы озадачить конкурентов в плане создания аналогичных продуктов, разработчики патентованного программного обеспечения часто держат детали форматов сериализации своих программ в секрете. Некоторые намеренно запутывают или даже шифруют сериализованные данные.

 

[cheblin]

понятнее не стало, но

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

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

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

иначе говоря - сериализовать.

AdHoc позволяет это делать не испытывая боли и унижения...

 

[cheblin]

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

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

но
можно договориться

 

[pvvx]

понятнее не стало, но

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

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

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

иначе говоря - сериализовать.

AdHoc позволяет это делать не испытывая боли и унижения...

Каким образом "AdHoc позволяет это делать не испытывая боли и унижения" если все устройства уже имеют свои протоколы?
Для примера был дан nRF Nordic Semiconductor Infocenter
- а там тупикал SLIP.
У детей с EPS он тоже в программаторе в UART ворочается...
А более, чем прошить или послать JSON по указанному на сайте формату для MQTT не требуется.
Следующим формат наблюдаем у Xiaomi в протоколах к BLE.
Т.е. области применения никаких своих форматов в данном сегменте "народное творчество" нет.
А в пром.сфере другие приколы и пока с AdHoc выходит как "обизянка и очки"...

 

[pvvx]

Если опуститься ниже по иерархии железок, то дискетами, винчестерами, телефонными модемами никто уже не пользуется, как IR приемо-передатчиками. Это там необходим самосинхронизирующийся побитно протокол. Почему-то пользуются flash с параллельным доступом, а физику USB, торчащую из мамки, на AdHoc пользователю не поменять и здесь никто не разрабатывает интерфейсов для PC.

В итоге единственное применение AdHoc выходит если его использовать (инкапсулировать) в транспорт Modbus или наоборот Других пока не дано, т.к. физический и аппаратный уровень бытового хлама давно обеспечивает функциональность AdHoc.

 

[cheblin]

опять перескочил...

у всех своё форматостроительство, именно по причине отсутствия нормального решения.

да тут, в соседней ветке на вопрос как увязать несколько ESP между собой сыпятся предложения типа MQTT, HTTP и прочие непотребства.

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

установи MQTT -​

на

составь спецификацию AdHoc протокола и получи сгенерённый код​

и всё станет ОК

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

 

[pvvx]

опять перескочил...

у всех своё форматостроительство, именно по причине отсутствия нормального решения.

Вот ещё пример:
Инкапсуляция и декапсуляция, PDU, уровни OSI.
Смотрим до:
На физический уровень кадры передаются уже в виде сигналов битов и следуют через другие сетевые устройства в пункт назначения.
На этом уровне и предполагается работа AdHoc (?).
Как мы можем 'вынести' это 'жиробасное безсмысленные решение'? Откажемся от сети интернет?

 

[pvvx]

Поглядим на WiFi…

Влезем в низкий уровень аппаратуры и начнем гонять AdHoc raw пакеты. Какой роутер это поймет? Сами сделаем свои роутеры – каждый в одиночку, послав скрипт описания на ваш сайт?

 

[cheblin]

На этом уровне и предполагается работа AdHoc (?).

нет конечно.

о ужас. неужели я так плохо пишу документацию.

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

по приведеной ссылке AdHoc на уровне представления и выше

 

[pvvx]

IpV6 – фрейм в минимум 1280 октетов, Payload Length 65535 октетов, пакет данных до 4294967295 байт. В MCU получаем сразу-же для параллельного доступа в виде 34359738360 бит, а не побитно и не побайтно. При меньшей длине равносильно потери производительности и скорости канала.

Многие методы передачи через физические (реальные) среды не подразумевают побитную передачу. Только скопом с восстановлением. Это о связи со спутниками…

 

[cheblin]

ответы все сильнее напоминают мем...

у коня член 50 см...
однако здравствуйте!

причём тут побитнаяя передача? откуда вот это всё?

 

[pvvx]

Постоянные отсылки к Rust. А это: Ключевые особенности языка: параллелизм путём передачи сообщений между задачами путем коммутации пакетами (дейтаграммами) мелкого размера.

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

 

[pvvx]

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

Может с начала надо вытеснить бессмысленные игры в языки к неподходящим для них платформам? А не перекладывать их задачу на нижний непроизводительный слой МК?
И пора привыкнуть к параллельному или блочному доступу.
У UART в том веке появилась FIFO, без которой I386 не мог обработать поток в 115200 бит... Но когда стал работать пачкой, то всё полетело...
У ESP8266 UART 128*8 битный

 

[cheblin]

Rust - фантастически классный язык, собравший вокруг себя прекрасное комюнити!

 

[pvvx]

Это был наглядный комент про Rust и необходимость сериализации на MK и связей между MK
У многих USB-UART микрух вроде 384 байта блок... Но не менее 64 - это от USB1.1, а на дворе USB3+... При меньшем - потери производительности канала.

 

[pvvx]

Rust - фантастически классный язык, собравший вокруг себя прекрасное комюнити!

Угу - "Танчики"
--------
"Rust". Как корабль назовешь так он и поплывет...

 

[pvvx]

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

 

[cheblin]

знающий тему

неа.

 

[pvvx]

неа.

Выводы о AdHoc уже сделали по вашему описанию:

Играйте в танчики и мнимые черные ящики – там прекрасное комюнити!

А обмен между МК нам говорит: передача на 9600 бод с AdHoc имеет больше размер прошивки, больше затрат процессорного времени на прерывания и обработку каждого символа чем переключение на 3мбит/c с DMA и передача всей RAM MK сотню раз в сек без всякой индексации, типизации, сериализации, сжатия потока,…

 

[cheblin]

готово!
для случая когда язык кодо генерации С и генерируемые пакеты фиксированной длинны ( в качестве данных полей не используются строки или динамические массивы) к генерируему коду прикладывается упрощёный рантайм. Который совершенно точно влезет даже в STM8.

к чему это и как это использовать?

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

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

сейчас делаю демонстрационное пошаговое руководство