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

[nikolz]

Ранее было написано такое предложение, вырванное из контекста:
При тех-же буферных протоколах есть плоские буферы. Они появились не случайно…
До этого предложения и после всё описано.
На данный обрывок, чтобы уйти от темы вы написали:
??? дома также должны быть и мясные закуски!
Вам ответил, плоские буфера – это по вашей теме и незнание что это перевод на русский flat buffers или название в других кругах. Это уже смущает и намекает на детсад по разбираемой тематике.
Далее, осознав, что гоните совсем пургу вы пишите:
ой спасибо... эта ссылка взята прям из моей документации по AdHoc протоколу..?? Но зачем?
я просто не поспеваю за такими такими прыжками мыслей, и это реально утомляет .
О каком разборе протоколов или как можно донести до вас что либо может идти разговор, если вы притворяетесь дебилом, когда вам указывают на недостатки и недоработки вашего AdHoC?
И так весь диалог.

Вот из последнего вашего ответа:
если для того чтобы работала Сишная конструкция switch на STM8 нужент форсаж - то да, на форсаже.
на самом деле нет.
Это указывает, что AdHoc рассчитан на поток до ста байт в секунду и этим ограничен? Ни о каких использованиях в современных системах или ранее сказанных – типа играх по сети где не хватает пропускной способности разговор уже не идет.
По заданному вами шаблону уклончивого дебила-коммерсанта никто с вами более диалог вести не собирается.
STM8 вы рекомендовали в начале всего разговора. Большее вам не удалось освоить на нем и остановились?
У вас есть уверенность что в него влезет приводимый вами код?
Я должен написать вам, что в роутер c потоком от 100 мбит/c мы поставим STM8... и долго ржать. Нет увольте.
Всё уже и так понятно.

Вы являетесь участником теста тьюринга,
но у Вас завышенные требования к ИИ.

 

[pvvx]

Вам ход мыслей нормального человека описывать?

Обычно, при упоминании для сравнения “плоских буферов” (или чего либо другого) указывается на основное их свойство и/или зачем они были созданы, для решения каких задач.

Т.к. я могу интерпретировать любой сленг, то ваш ответ “??? дома также должны быть и мясные закуски!”, по приоритету свойств и прочего имеет смысл – “В AdHoc это тоже должно быть. И более развитое.”. Но последующий ваш ответ ну никак не согласуется, что намекает на такие вещи – вы осознали и далее лепите лабуду для прикрытия дыр?

 

[pvvx]

Вы являетесь участником теста тьюринга,
но у Вас завышенные требования к ИИ.

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

 

[cheblin]

плоские буфера

я совершенно запутался в этой вашей терминологии, в ваших устах термин "плоские буфера" может означать ВСЁ что угодно, и чаще всего и означает...

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

STM8 вы рекомендовали в

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

В Отличии от...

так в итоге для чего был Вами упомянут flat buffers? как более удачная реализация protocol buffers?
так в своей документации я даю ссылку на ещё более успешную реализацию, на Cap’n Proto ... там и картинки зачётные есть

есть ещё пяток подобных попыток воплотить столь критикуемую Вами идею DSL > кодогенерация > сериализация
ах да... они же все дебилы, на esp8266.ru не ходят, светильника разума не читают

 

[cheblin]

программистом коммерсантом

и это мне пишет некто, постоянно упоминающий про коммерческую тайну своего мегапроекта...

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

 

[pvvx]

и это мне пишет некто, постоянно упоминающий про коммерческую тайну своего мегапроекта...

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

Это простой вопрос - ваши ответы следуют описанному стилю: Вместо ответа или признания что того-то и сего-то пока нет или не реализовано, следует реклама не по теме вопроса, а по выбранным и выдранным из контекста словам. Выглядит как кто-то пытается втюхать бесполезную вещь.
Можете подобрать более подходящее название этому стилю

 

[pvvx]

я совершенно запутался в этой вашей терминологии, в ваших устах термин "плоские буфера" может означать ВСЁ что угодно, и чаще всего и означает...

Обозначает то, чего вы сами пытаетесь описать:

так в итоге для чего был Вами упомянут flat buffers?

как более удачная реализация protocol buffers?
так в своей документации я даю ссылку на ещё более успешную реализацию, на Cap’n Proto ... там и картинки зачётные есть

есть ещё пяток подобных попыток воплотить столь критикуемую Вами идею DSL > кодогенерация > сериализация

Но, отличие flat buffers от Google Protocol Buffers опять замяли
В голове одни "успехи" или реальность, применимость и прочие тех. характеристики?

Телефоны с Android имеют больший успех в России...

 

[pvvx]

Противников с реальными примерами по вашей тематике куча.
Первый попавшийся пример:
Protobuffers — это неправильно
А я всего-то описал чего не хватает в вашем протоколе для переноса в современный мир МК на банках, на частном примере, и как это сделано у других.

 

[pvvx]

... О том, какие задачи стоят у разработчиков в реальности, а не о домохозяйках с Arduino на STM8.

В ответ получены масса тарабарщины с лейбами о некому тут не знакомых названий всего подряд. Вы ещё приведите названия процедур в ваших библиотеках, как совершенно необходимое для понятия что такое сериализация и десериализация с совмещением протокола приемо-передачи между объектами.
Разбираться в лейбочках и путаться в них - это ваше профессиональное, как программера. Наше дело другое - использовать алго и методы и знания их, без лейбочек.

 

[pvvx]

И применительно к тематике данного сайта – у нас простые вопросы:

Как и чем может помочь нам AdHoc в реализации устройств для “вумного дома”.

Имеющиеся актуальные решения тут реализуются на малых WiFi и BLE SoC и – это такие микросхемы типа ESP32 и вокруг и около – что можно к ним прикрутить. Но не STM8, т.к. уж слишком туп и не имеет смысла прикручивать к более развитым SoC.
По новомодной тематике у нас актуал c BLE. Там царствуют стандарты UUID/GATT… Ни в одном из них, пока, нет места для AdHoc. Но есть узкое место, где может быть применима бинарная сериализация – это шлюз WiFi/Lan <-> BLE.
ESP8266 и ESP32 не могут обеспечивать стандарт TCP из-за “мало-RAM”…

Всё это вам уже описано… Ответа нема.
А время уходит и данное место полностью занимает JSON c MQTT в качестве стандарта на многие годы вперед.

 

[cheblin]

Там царствуют стандарты UUID/GATT

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

а если недостаточно, то ВСЕГДА.
ВСЕГДА
(!)
будет и есть UART. и гоняй поверх него хоть Protocol Buffers хоть ZCM хоть AdHoc ...

примеры использования AdHoc и пошаговое руководство скоро будут... но я до 4 числа завис у брата в шенжене и тут обстановка не располагающая к работе.

 

[cheblin]

Но, отличие flat buffers от Google Protocol Buffers опять замяли

пфф

вернулся в привычный уклад..

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

бинарное представление всегда будет эффективнее текстового во всех смыслах

 

[pvvx]

бинарное представление всегда будет эффективнее текстового во всех смыслах

На сколько? Конкретно что даст по эффективности AdHoc при передаче данных от ADC по BLE, к примеру в варианте -> https://esp8266.ru/forum/threads/tlsr8269.4491/page-19#post-68861
Беда в том, что невозможно вечно увеличивать MTU и не все приемники BLE (BT4.2) умеют дружить с большими пакетами...
А для BLE тестера нужен хороший поток (желательно от 2-х тысяч точек в сек по 16 бит и чтобы чипы BLE не захлебнулись и держали связь без выпадений )...
На 16MHz CPU для данного чипа как раз предел стабильности приема-передачи (без выпадений, с работой по оцифровке и соединению) и есть 4 кило в сек чистых данных. Далее надо мудрить с SDK либами или брать более дорогой и жручий чип.

 

[cheblin]

что даст по эффективности AdHoc при передаче данных от

нужно конкретно брать и сравнивать.

невозможно вечно увеличивать MTU и

ненужно ничего увеличивать и уменьшать не нужно. AdHoc как газ, занимает весь выделенный объём.
Работает ДАЖЕ поверх CAN протокола.

Большой AdHoc пакет дробиться передатчиком на мелкие части, и собирается на приемнике.

Всё работает даже если MTU будет один байт.

AdHoc - транспорт агностик, ему пофиг, а при сбое быстро находит начало нового пакета и самовосстанавливается.

не по таймеру

умный.

 

[cheblin]

For unreliable, noisy channels with a high probability of errors, like UART over a radio, an improved, noise-protected version of the AdvProtocol protocol is used. It used CRC16 and Byte(0x55) stuffing framing for fast recovery after an error.

 

[pvvx]

For unreliable, noisy channels with a high probability of errors, like UART over a radio, an improved, noise-protected version of the AdvProtocol protocol is used. It used CRC16 and Byte(0x55) stuffing framing for fast recovery after an error.

CRC в пакете BLE уже есть, начало кадра - так-же есть, метрики родителя и полная идентификация что это и куда так-же есть...
По ответам видно, что AdHoc не годится для BLE

 

[cheblin]

не грусти, а то грудь не будет рости!

бери StdProtocol котрый опирается на сервисы, предоставляемые нижним транспортным уровнем,
Правда, правда, прям так и пишут

 

[pvvx]

не грусти, а то грудь не будет рости!

бери StdProtocol котрый опирается на сервисы, предоставляемые нижним транспортным уровнем,
Правда, правда, прям так и пишут

Та пусть пишут. Пока будете читать я уже сделаю свой рабочий вариант.
Место в бардаке BLE указано - уровень шлюза TCP/IP и BLE, где и UUID/GATT и прочие лейблы и типы данных должны описывать управление и шлюзование...
MQTT там не справится. Пример тот-же "Мажор сидит дома" - переключение лампочек там происходит от 1..2 сек после нажатия кнопы на модуле, при скорости обработки событий у модулей с в 100..1500 us (с полным подтверждением приема-передачи).
Такая "работа" у любого человека вызывает всего одну цепь мыслей:
- выключатель сломался, что-то застряло, надо его долбануть молотком - вдруг что отошло, где молоток..., какой гад мне продал это - теперь ремонт искать, а может это батарейка сдохла(?), вроде вчера менял, да где-же молоток и отвертка(?), оглядывается... На ощупь идет к другому выключателю и тут свет включается... занавес.

 

[pvvx]

Правда, правда, прям так и пишут

Ещё раз UART остался только в устаревших дешевых Arduino, для игр у детей дошкольного возраста...
Во всех остальных проектах, даже судя по данному сайту, если и используется UART, то на скоростях от 1 мегабит килобайтными блоками, сигналами RTS/CTS (связано с мало RAM для буферизации)... И причина использования UART - не заменить на другой интерфейс по причине убогости и древности чипа.

 

[pvvx]

@cheblin Уровень API давно не предполагает побайтную тусовку. Это ныне моветон. (проверьте на скорость - чтение файла побайтно и блоками и опишите разницу )

Давно существует понятие “потока” и буферизация. Это связано с аппаратными тонкостями, чтобы скрыть от пользователя, что данные передаются блоками на аппаратном уровне.
Повторите и зазубрите – при передаче все современные интерфейсы работают с блоками. Пока не вычислена достоверность данных блок не передается выше уровня драйвера. В примитивных системах пока не принята контролька – блок не действителен. В системах с восстановлением аналогично – ничего не возможно восстановить пока блок полностью не принят. В самих каналах передачи давно уже сама модуляция сигнала не подразумевает передачу одного байта – только минимального блока.
Побайтное вытягивание из потока осталось в том веке для текстовых протоколов. UTF и это изменил – единица информации уже не байт.

Если вы этого осознаете, то рожаете AdHoc исключительно для устаревших систем. Есть такое направление – Некромантия (- одна из самых разрушительных и жестоких магий. Так получилось, что эта – единственная школа, у которой просто НЕТ мирного применения. Сила Некроманта основана на страхе, боли и смерти других.) Они любят копаться в могилах... Связь туда по UART протянуть... Но не всегда - телетайп рулит (!)