• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

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

pvvx

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

pvvx

Активный участник сообщества
Ну и как пишут "срок исковой давности для УК РФ — 3 года, в особых случаях до 10", то я обычно раскрываю проекты или их детали сделанные 10..15 лет назад :p
 

pvvx

Активный участник сообщества
С одной задачей уже справились: Популярные темы, AdHoc просмотров 1.480

А вот примеры "Китай только повторяет" из сегодняшних новостей:
Intel не теряет надежды освоить выпуск 10-нанометровых процессоров
Китай: Zhaoxin планирует в 2021 году выпустить 7-нанометровые процессоры с поддержкой PCIe 4.0 и DDR5

Ответа по ioctl() так и нет... :(
 

cheblin

Member
на сайте Арудует модератор.
перепечатывать удалёное длинное сообщение не буду. ибо пофиг.

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

cheblin

Member
Всё.
Сделан импорт пакетов и коммуникационных интерфейсов из других файлов описания AdHoc протокола.
Сделан конвертор из формата .proto protocol buffers в формат максимально близкий AdHoc протокола.
Полностю перенести не получится поскольку AdHoc даёт возможность описать топологию обмена, в отличии от...

посмотрел я на эти ваши Web Bluetooth

JavaScript:
function parseHeartRate(data) {
  const flags = data.getUint8(0);
  const rate16Bits = flags & 0x1;
  const result = {};
  let index = 1;
  if (rate16Bits) {
    result.heartRate = data.getUint16(index, /*littleEndian=*/true);
    index += 2;
  } else {
    result.heartRate = data.getUint8(index);
    index += 1;
  }
  const contactDetected = flags & 0x2;
  const contactSensorPresent = flags & 0x4;
  if (contactSensorPresent) {
    result.contactDetected = !!contactDetected;
  }
  const energyPresent = flags & 0x8;
  if (energyPresent) {
    result.energyExpended = data.getUint16(index, /*littleEndian=*/true);
    index += 2;
  }
  const rrIntervalPresent = flags & 0x10;
  if (rrIntervalPresent) {
    const rrIntervals = [];
    for (; index + 1 < data.byteLength; index += 2) {
      rrIntervals.push(data.getUint16(index, /*littleEndian=*/true));
    }
    result.rrIntervals = rrIntervals;
  }
  return result;
}
ржу чёта.
теже фаберже в профиль.

проблема разбора протокола осталась.

думаю сделать таки упрощёную версию на С... так чтобы она гарантированно работала даже на STM8
но толко для пакетов с фиксированной длинной.
соответственно без строк и проч прелестей
 

cheblin

Member
ещё полностью отказался от IMAP в качестве протокола отправки спецификации на сервер.
почтовые провайдеры озверели со своими секюрити.

в AdHocAgent остались только raw TCP и HTTP
 

pvvx

Активный участник сообщества
посмотрел я на эти ваши Web Bluetooth

ржу чёта.
теже фаберже в профиль.

проблема разбора протокола осталась.
У CAN всего 8 байт, в BLE 20 байт данных (пакет 27 байт ).
В BT 5.0 есть расширение на более длинные фреймы...
В спецификции 4.0 максимальная длина PDU составляет 39 байт, а в версии 5.0 длина пакета данных увеличена до 257 байт.

Строки, к примеру, используются при передаче сообщений в часы от смартфона.
Но в основном для ОТА и картинок...
 

pvvx

Активный участник сообщества
Примерное кол-во типов данных (типов форматов блока данных/команд) передаваемых в примере SDK для BLE браслета в одной характеристике (считай канале):
Код:
enum{
    WRIST_CMD_QUERY_VERSION        = 0x01,
    WRIST_CMD_SET_TIME            = 0x02,
    WRIST_CMD_GET_TIME            = 0x03,
    WRIST_CMD_LOOKUP_BRACELET    = 0x0e, // vibrating the bracelet
  WRIST_CMD_READ_BATT_VOLT      = 0x0f,

  WRIST_CMD_HR_GET_STATUS        = 0x20,
  WRIST_CMD_HR_START            = 0x21,
  WRIST_CMD_HR_STOP                = 0x22,
  WRIST_CMD_ACC_NOTIF_START     = 0x23, // Acceleration start
  WRIST_CMD_ACC_NOTIF_STOP      = 0x24, // Acceleration stop

  WRIST_CMD_LIGHT_CTRL            = 0x30,
   
  WRIST_CMD_MSG_NOTIF            = 0x38,
   
    //WRIST_NOTIFY_FIT            = 0x80,
  WRIST_NOTIFY_HR                = 0x81,
    //WRIST_NOTIFY_ATH            = 0x82,
    //WRIST_NOTIFY_UV            = 0x83,
    //WRIST_NOTIFY_ENV            = 0x84,
  WRIST_NOTIFY_HR_RAW            = 0x85,
  WRIST_NOTIFY_ACC                = 0x86,
  WRIST_NOTIFY_KSCAN              = 0x87,

    WRIST_RO_DATA                = 0xa0,

    WRIST_CMD_UNKNOW = 0xff
};
Не все, там ещё подтипы...
Т.е. для элементарщины - более 20 типов.
 

pvvx

Активный участник сообщества
Классический (де)сериализатор - "AT" протокол.
 

pvvx

Активный участник сообщества
фактически единственная фича которая в Protocol Buffers и не имеет у меня аналога. во всем остальном AdHoc гораздо лучше.
и сравненительная таблица будет.
Словами вики у меня такая проблемс: "Тривиальные реализации, которые сериализуют все элементы данных, могут нарушать инкапсуляцию."
Нужен синхро-снимок состояния всех устройств до побитного состояния в едином поле доступа, куда лезут все и асинхронно... Имеющиеся БД перед таким пасуют - производительность падает на от трех порядков...
По ходу опять придется изобретать велосипед в грядущем большом проекте...
 

cheblin

Member
там основная "мякотка" начинается тут

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

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

а в Rust есть SERDE который основан на встроенной мощной макрос инфраструктуре, и код сериализации генерится по исходникам самого rust во время компиляции.
ничего кроме сериализации исходников Rust это serde генерить не может. замкнутая система

AdHoc использует язык java и аннотации для описания протокола и генерит на самых разных языках
 

cheblin

Member
У CAN всего 8 байт, в BLE 20 байт данных (пакет 27 байт ).
В BT 5.0 есть расширение на более длинные фреймы...
В спецификции 4.0 максимальная длина PDU составляет 39 байт, а в версии 5.0 длина пакета данных увеличена до 257 байт.

Строки, к примеру, используются при передаче сообщений в часы от смартфона.
Но в основном для ОТА и картинок...
AdHoc совершенно пофиг на транспорт. у CAN всего 8 байт, а надо передать 80? какое огрорчение, придется сообщение размазать на 10 пакетов. а на приёмной сторорне собрать.

для AdHoc это стандартный режим

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

насколько и каких частей он был разбит при передачи - всё равно.
 

pvvx

Активный участник сообщества
AdHoc совершенно пофиг на транспорт. у CAN всего 8 байт, а надо передать 80? какое огрорчение, придется сообщение размазать на 10 пакетов. а на приёмной сторорне собрать.

для AdHoc это стандартный режим

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

насколько и каких частей он был разбит при передачи - всё равно.
Вы цитируете вики своими словами :)
Сериализация (в программировании) —процесс перевода какой-либо структуры данных в последовательность битов.
 

pvvx

Активный участник сообщества
Я не собираюсь тут писать популярные статьи… токо в краце.

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

Простейший пример:

Имеем картинку, где каждый пиксел имеет свои параметры. Управляющие системы воспринимают состояние сразу полным кадром или синхронной выборкой необходимых точек из текущего снимка. В кино каждый кадр описывает состояние системы... Скорость последовательной передачи (попиксельно) сильно влияет на кол-во кадров в сек. Там передача состояния каждой точки от датчика должна быть синхронизирована с кадровой частотой или на каждую точку описываются свои правила буферизации и включения в общий кадр. Базы данных и текущие реализации SCADA не приспособлены к таким задачам. Пока вы будете последовательно получать из базы разные точки для алгоритма выработки действия, часть точек уже изменится. Это как подав команду включения света последовательно считывая показания с датчиков пытаемся определить включился ли он, а в это время другой процесс уже отключил саму лампочку :) А если кадр представлен в базе одним объектом, то он будет вечно занят (блокирован 99.99%) на асинхронный внос изменений с внешних датчиков и фиг к нему когда получите доступ.

А что в итоге, какова оптимизация – имеем поле точек с линейным индексом адреса, а не каких-то выдуманных индексов, которые необходимо ещё дешифровать. Это к вопросу – а нафига в AdHoc своя система индексации? Для тормоза сборки кадра? Для рассинхронизации? …

Т.е. необходимо описание правил на сервере для каждого ‘пикселя’ и как он заносится в кадр, как выдается внешним попрошайкам информации на их устаревшем языке… Как "пиксели" собираются в группы ответов неспециализированным внешним попрошайкам. И т.д. Специализированные работают просто по индексам адреса (имея описание полей) и никакой типизации на передающих каналах.

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

PS: MIPS 300 МГц в том году обеспечивал 10000 "кадров" (кадр в пару мегабайт) в сек. Или это более 10000 запросов-ответов к виртуальному устройству по сети в стандартных протоколах.
 

pvvx

Активный участник сообщества
Такое виртуальное устройство с технической стороны это как аналог общей памяти для многоядерного процессора. Типа много датчиков и исполнителей у которых память находится в общем виртуальном устройстве. А виртуализация нужна для подмены данных – малому исполнительному устройству подставляются данные от любых других устройств.

Не ясно где там нужен AdHoc, если любой CPU имеет индекс адреса и работает с битами. Зачем это переводить в другие типы на интерфейсе к нему? Это задача виртуализатора и исполняется только в нем.
 

cheblin

Member
мне кажется или это всё тот же "приход" от злоупотребления modbus-ом

я читаю описание какойто сферической задачи котрое начинается со слов

[inline]Простейший пример:[/inline]

и далее ваще не понятно...
[inline]Пока вы будете последовательно получать из базы разные точки для алгоритма выработки действия, часть точек уже изменится.[/inline]

[inline]А если кадр представлен в базе одним объектом, то он будет вечно занят (блокирован 99.99%) на асинхронный внос изменений с внешних датчиков и фиг к нему когда получите доступ.[/inline]

какие колёса? какие насосы?

[inline]имеем поле точек с линейным индексом адреса[/inline]
ок имеем... и дальше опять провал мысли

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

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

pvvx

Активный участник сообщества
мне кажется или это всё тот же "приход" от злоупотребления modbus-ом

я читаю описание какойто сферической задачи котрое начинается со слов

[inline]Простейший пример:[/inline]

и далее ваще не понятно...
[inline]Пока вы будете последовательно получать из базы разные точки для алгоритма выработки действия, часть точек уже изменится.[/inline]

[inline]А если кадр представлен в базе одним объектом, то он будет вечно занят (блокирован 99.99%) на асинхронный внос изменений с внешних датчиков и фиг к нему когда получите доступ.[/inline]

какие колёса? какие насосы?

[inline]имеем поле точек с линейным индексом адреса[/inline]
ок имеем... и дальше опять провал мысли

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

попробуй просто рассказать именно о нём, без перескакиваний.
после этого каким видется решение.
какие существующие инструменты не подходят и почему...
Решение (по описанию выше) уже есть и реализовано (коммерческое). Нужно новое :)
Есть такое понятие - разработка, основа: пойди туда не знаю куда и за чем, но принеси работающее решение.
Зачем обсуждать какие-то инструменты, если они изначально не годятся?
"перескакивания" возникают от непонимания и не владения темой + мои сокращения. Для ввода в курс дел нужно время - от полугода :)
 
Сверху Снизу