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

[pvvx]

вот тут я уже выложил пример сгенерированного кода первого урока, там всё открыто.
думаю часть ответов там есть.

Я его видел и изучил.

AdHoc

НЕ занимается вопросами разделения доступа к своим данным. это ложиться на плечи погромиста

А что он ещё не делает? Или что он делает?

 

[cheblin]

Мне надо передать массив, описанный в си так:

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

 

[pvvx]

Мои действия примитивны – передаем с устройства как есть. Пусть у него мозга нет совсем и ему некогда, он умеет всего перекладывать из I2С в описанный массив и, получив sizeof(acc_data), передает балок байт передатчику.
Сервер, приемник, принимает и тупо коммутирует – блокирует доступ к “кадру” и раскладывает побайтно в “кадр” в соответствии с указанной заранее таблицей, созданной после прохода скрипта описания пакетов от этого устройства. Разрешает доступ к “кадру”. Всё.
Всё остальное относится к протоколам ниже уровнем.
Ну и пример примитивный и навеян последними тестами неизвестного акселерометра в браслете с BLE...

И sizeof(acc_data) будет равен 4*2+3*2=14 байт И фиг с этими 2-мя лишними всё равно в пакет BLE (20 байт) вмешается.

 

[cheblin]

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

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

 

[pvvx]

Чтобы описать общие возможности виртуального устройства и что и как там ворочается и взаимосвязано потребуется накалякать слов больше чем мы уже тут наплодили в теме. Дешифрация (парсер) входных пакетов от внешних устройств это только первый эшелон пути до “кадра”. Он умеет разбирать и побитно (но на практике это не пригодилось) и дополнять и расширять данные до других типов, фиксировать время приема для устройств не несущих метки, ... Прослойка уровня помещения данных в “кадр” тоже имеет атрибуты для каждого поля “кадра” – что и как ему делать в зависимости от какого сознательного уровня датчика он получает данные – из внешнего или внутреннего кольца, что надо буферизировать в соответствии с другими флагами и значениями в “кадре”, что дополнительно поместить в фифо для медленно опрашивающих внешних устройств и т.д. Это только малая цепочка поступления данных, но она умеет разгребать все форматы, включая Modbus, JSON, XML, прочие пром.протоколы… Описывается примитивным скриптовым языком с обработкой на ходу (трансляцией) в необходимые флаги для парсера. Скриптовое описание дополняется и отарабатывается со стандартных интерфейсов – HTTPS, SSH,… в любой момент. К сериализации и AdHoc это отношения не имеет, кроме того что он не вписывается никак в такую систему, а было сказано что оно именно для этого…
На выходе типа такая-же фигня, но наоборот. Т.е. вывод данных из кадра в любом формате. Формат можно задать в самом запросе.
Я понимаю, что вам такого не надо. У вас задачи мигать до 10 светодиодами..

 

[pvvx]

ну Ы?

Ну получился такой динамический сериализатор с синхронизацией многопользовательских запросов-ответов и сохранением атомарности до полной карты всех устройств. К примеру для лога и поиска сбоя - берем снимок и видим полное состояние, а так-же для замещения на ходу вышедших из строя/горячей замены и замены на ходу алгоритмов управления...
Если писалось на Rust то не влезло бы в платку по 800 рупь.
Вроде более ничего.

 

[pvvx]

Далее на "кадр" предполагается натравить бестолковый ИИ. Он плохо работает с последовательными данными... Ему весь кадр подавай с динамикой... кратковременные и долговременные области хранения подавай...

 

[cheblin]

AdHoc .... не вписывается никак в такую систему,

Отлично. Так, так и пиши... типа у меня тут мега проект... и всякие AdHoc в нём как пятая нога.

все поймут, простят и даже порадуются.
можешь про мега проект даже в отдельную ветку запилить... и я туда со своим богомерзким AdHoc на 9600 бод даже близко не подойду

точно-точно....
ну разве только почитать и порадоваться за успех.

 

[cheblin]

обновил транспиляцию MavLINK message definitions в AdHoc protocol description формат.

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

... AdHoc кодогенератор на это способен.

 

[pvvx]

обновил транспиляцию MavLINK message definitions в AdHoc protocol description формат.

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

... AdHoc кодогенератор на это способен.

На что способен?
Простой вопрос на указном примере:

Хочу получать для обработки такие данные из указанного cheblin/mavlink2adhoc

@id(27) { @I long time_usec short xacc; }
@id(153) {@I short adc2; }
@id(151) { short mag_ofs_z; }

Потом другие… Короче выборочно по всему списку и возможно какие другие, которых нет в списке.
Коптер уже в полете...

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

 

[pvvx]

Отлично. Так, так и пиши... типа у меня тут мега проект... и всякие AdHoc в нём как пятая нога.

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

 

[pvvx]

Ответ на вопрос поставленный в предыдущем соо:

Экскурс в историю начала третьей четверти того века:

Каждое исполнительное устройство или датчик имеет внутреннюю карту регистров и битов состояния.

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

Далее общаемся с помощью этих назначенных номеров пакетов. Когда надо на ходу меняем или добавляем описание нового пакета. Это сокращает поток в тысячи раз и дает совместимость протокола для любого случая.
Было реализовано в том веке в большинстве пром. устройств т.к. требует минимальных ресурсов у контроллера – задаваемую таблицу. Является расширением над ModBus и реализуется на нем-же, но имеет другие названия (переставлены биты для несовместимости = ком.фича)

 

[pvvx]

Вот это - cheblin/mavlink2adhoc
Вы описали карту регистров своего контроллера и присвоили им именные названия для работы человека программиста.
Предположим у меня другой проект, уже готовый и необходимо стыковать с вашим. Но у меня имена переменных другие и рабочие примитивы структур тоже другие…
Вопрос – как это адаптировать/стыковать через AdHoc? Писать ещё отдельный дешифратор - ещё одну прослойку между AdHoc?
PS: Переводим с русского на англ., потом на китайский и обратно...

 

[pvvx]

ModBus: Недостатки стандарта

Стандарт в своей основе был разработан в 1979 году с учётом потребностей и вычислительных возможностей того времени, и многие актуальные для современных промышленных сетей вопросы не были учтены[6]. Необходимо отметить, что отсутствие перечисленных возможностей является следствием простоты протокола, которая облегчает его изучение и ускоряет внедрение.

1. Стандарт специфицирует метод передачи только двух типов данных[7]. Отсутствие чёткого указания в стандарте привело к тому, что с другими типами данных сторонние производители MODBUS-решений поступали по своему усмотрению. Различие мнений производителей оборудования в этом вопросе не позволило впоследствии сделать уточнения в официальном документе: это вызвало бы всплеск недовольства производителей несогласных с предлагавшимися поправками стандарта и возможную войну форматов.

В каком протоколе или стандарте этого нет (войны форматов)?


2. Стандарт не регламентирует начальную инициализацию системы. Назначение сетевых адресов и прописывание в системе параметров каждого конкретного устройства выполняются вручную на этапе адаптации и программирования системы.



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

3. Не предусмотрена передача сообщений по инициативе подчинённого устройства (прерываний). Ведущее устройство должно периодически опрашивать ведомые.

Единственная гадость в Modbus RTU при использовании одной линии UART.Совсем не значится в Modbus TCP, т.к. контроллер может одновременно являться и ведущим и ведомым с помощью нескольких одновременных TCP соединений или такого понятия как шлюз.

Тот-же HTTP, как и множество других протоколов и стандартов имеет аналогичные проблемы.

4. Длина запроса ограничена, а данные могут быть запрошены только из последовательно расположенных регистров. Это увеличивает задержки и накладные расходы при использовании сети, так как для получения данных из регистров, расположенных далеко друг от друга в адресном пространстве, мастер должен либо запрашивать ненужные данные, либо использовать несколько запросов.

Тут ошибка в вики: Во первых длина запроса и ответа ограничена в любом стандарте протоколов. Во вторых:

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

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

Решается опросом счетчика или таймаутом запросов от ведущего, т.е. ‘пингом’ как и в других протоколах. Высосанный из пальца недостаток присущий большинству протоколов



Сравнение с AdHoc:

1. Стандарт специфицирует метод передачи только одного типа данных – байта.

2. Аналогично.

3. Аналогично.

4. Не имеет и не предусматривает произвольную выборку.

5. Аналогично. Решается ‘пингом’.

Итого: AdHoc проигрывает у Modbus по нескольким пунктам. За время существования Modbus было навыдумано много новых ‘стандартов’ не имеющих описываемых проблем, но они не прижились, кроме мелких эстетических модификаций позволяющих производителям устроить несовместимость с чужой продукцией…

 

[nikolz]

Ямщик, ты о чем поешь?
Так что вижу, так о том и пою.
--------------------

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

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

 

[cheblin]

Предположим у меня другой проект, уже готовый и необходимо стыковать с вашим. Но у меня имена переменных другие и рабочие примитивы структур тоже другие…
Вопрос – как это адаптировать/стыковать через AdHoc? Писать ещё отдельный дешифратор - ещё одну прослойку между AdHoc?

"Алло, Галочка, ты сейчас умрешь!"(C)

AdHoc пакеты сами посебе имеют достаточно быстрый и удобный API для того чтобы выдёргивать данные из себя. Однако на случай уже существующей структуры данных в AdHoc генерируется адаптеры позволяющие легко импортировать, экспортировать данные... И(!) при изменении протокола т.е. при изменнении сгенерированного API легко отслеживать проблемы с импортом/экспортом. как это сделано?
в разных языках по разному.
в силу своей ограниченности, на С это сделано на макросах.

например простейший пакет Vector3 который при описании протокола выглядит вот так

@id(6)
public class Vector3 {
  float x;
  float y;
  float z;
}

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

static inline float p6_x_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  0, 4)))    ;
}
static inline float p6_y_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  4, 4)))    ;
}
static inline float p6_z_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  8, 4)))    ;
}

тут не всё, ещё есть много разных других ыункций
помимо кода доступа к данным будет сгенерирован код импорта экспорта

это экспорт из Vector3 в то, куда будет написано в функциях которые ожидает макрос, просто скопируй их из хелпа и замени <DST> на более понятное

/
*The macro to simplifies writing code to export data from the pack.
* Macro is expecting and calls the following functions..
static inline void <DST>_x_SET( float * src, <DST> * dst  ){}
static inline void <DST>_y_SET( float * src, <DST> * dst  ){}
static inline void <DST>_z_SET( float * src, <DST> * dst  ){}
*/

#define p6_Vector3_PUSH_INTO(DST)\
    static inline void p6_Vector3_push_into_##DST ( p6_Vector3 * src, DST * dst) {\
        DST##_x_SET( p6_x_GET( src  ), dst  );\
        DST##_y_SET( p6_y_GET( src  ), dst  );\
        DST##_z_SET( p6_z_GET( src  ), dst  );\
    }

а в тесте прям сгенерирован пример использования импорта экспорта

 

[cheblin]

рассол

употребляете алкоголь? постарайтесь этого избегать...

 

[cheblin]

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

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

 

[pvvx]

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

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

Это к тому, что в AdHoc невозможно передать произвольную заказную выборку? Только выбирать данные из больших и ненужных пакетов засоряющих канал?

 

[pvvx]

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

static inline float p6_x_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  0, 4)))    ;
}
static inline float p6_y_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  4, 4)))    ;
}
static inline float p6_z_GET(p6_Vector3 * src)
{
    return (intBitsToFloat(get_bytes(src,  8, 4)))    ;
}

А - Arduino. Времени на обработку такого кода и объема кода не жалко... 3..4-ре светодиода или один акселерометр с одной точкой в секунду... Пойдет.
Программирование ради программирования...