[AlexandrY 3]

закомство со стеком протколов X.25 - дедушкой всех стеков протоколов.

 

Мда, а еще старее ничего не нашлось?

 

Стаффинг это пережиток.

Сейчас если ориентироваться на перспективные каналы передачи о стафинге беспокоится не имеет смысла. Все что надо делается физикой.

Особенно в радиоканалах.

 

Какие-то трудности с отслеживание начала потока тоже сомнительны.

Если общение в форме запрос-ответ то никого потока нет.

Не надо путать со спутниковыми HDLC потоками.

 

[zltigo 1]

Мда, а еще старее ничего не нашлось?

Из полностью продуманного ничего, стройнее и проще не нашлось. Хорошая база для ознакомления с миром комуникационных протоколов. Можете и на SS7 посмотреть - как там транспортные уровни. Тот-же TCP/IP просто усеченный огрызок того, что было в стеке X.25

Стаффинг это пережиток.

Сейчас если ориентироваться на перспективные каналы передачи о стафинге беспокоится не имеет смысла. Все что надо делается физикой.

Шедеврально. Так-сказать квинтесенция уровня мышления законченного "программиста". Если что-то делается "физикой", то значит НЕ СУЩЕСТВУЕТ. Увы, физикой делается именно бит и байт стаффинг. В данном случае НИЧЕГО физикой RS232/485 не делается, посему речь и идет о том, как реализовать фрейм. В, например, HDLC контролллер здесь никто не предлагает дополнительно фреймы на транспортном уровне БЕЗ дополнительной на то надобности, оформлять.

Какие-то трудности с отслеживание начала потока тоже сомнительны.

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

Если общение в форме запрос-ответ то никого потока нет.

Ой! Да неужели? Значит объявляем битовые синхронные потоки, где постоянно идет заполнение синхропоследовательностью несуществующими :). Как и заполнение асинхронного канала разделителем фрейма :).

Не надо путать со спутниковыми HDLC потоками.

Если-бы Вы хоть чуть-чуть вместо хи-хи над X.25 посмотрели на него, то узнали-бы, что HDLC это нижний уровень описанный в X.25 и с тех пор живущий во всех синхронных каналах, хоть спутниковых, хоть в теперь уже допотопных каналах проводной телефонии. Путать не надо :) :) :)

[arhiv6 14]

Сегодня подробнее изучил WAKE и ModBus ASCII, посмотрел их реализации. Хотя Wake и не является стандартизированным протоколом, очень понравилась реализация - всё просто и понятно, требует мало ресурсов, похоже отлично подойдёт под мою задачу. Отсутствие стандарта компенсируется простотой документации и самого протокола.

А какие ещё есть протоколы, похожие на WAKE и ModBus ASCII?

[AlexandrY 3]

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

 

Да так же как и я вы используете готовый софт.

К исследованию протоколов и особенно сетевых никакого отношения не имеете.

Что вам там дали в либе ZigBee от Ember, то и юзаете. Исходников даже не имеете.

 

Че прикидываться не знаю.

Короче формулы: [хидер][длина][данные][CRC] хватит выше крыши и на все случаи жизни.

 

[zltigo 1]

Да так же как и я вы используете готовый софт.

К исследованию протоколов и особенно сетевых никакого отношения не имеете.

Что вам там дали в либе ZigBee от Ember, то и юзаете. Исходников даже не имеете.

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

действительно тот минимум, с которым никак не обойти производителя чипа :(. Но это все-же не ZigBee, только IEEE 802.15.4

Собственно ZigBee пошло лесом. Никакой радости я от использования "библиотек" не испытываю :(, а от куска обрабатывающего очереди сообщений, который ввиду убогости и не продуманности API, авторы были вынуждены показать в исходниках, мне стало дурно. Сначала я доооолго читал-перечитывал, думал, что там какая-то наихитрейшая хитрость, но потом понял, что "программисты" просто нифига не понимают, как API корректно использовать :(. Переписал всю эту муть в несколько десятков строк.

Короче формулы: [хидер][длина][данные][CRC] хватит выше крыши и на все случаи жизни.

Для создания очередного "шедевра" под присказку, "а чего тут думать - трясти надо", конечно хватит :(.

 

 

 

А какие ещё есть протоколы, похожие на WAKE и ModBus ASCII?

SLIP https://tools.ietf.org/html/rfc1055 - ничего лишнего прикрученного к WAKE для обеспечения MODBUS-образного функционала. Только фреймер. Остальное можете по вкусу добавлять.

[ASN 0]

arhiv6

Присоединяюсь у уважаемому zltigo - SLIP: просто, надёжно. Используем уже более 15 лет.

 

[jcxz 192]

arhiv6

Присоединяюсь у уважаемому zltigo - SLIP: просто, надёжно. Используем уже более 15 лет.

И я присоединюсь.

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

[DogPawlowa 0]

Я использую самопал по мотивам SNMP, т.е. можно, кроме записи/считывания переменной, запросить ее имя, а сама переменная может быть текстовой, что позволяет вкладывать готовые форматы (например, строку HEX-файла)

Индексация переменных ограничена двумя уровнями.

В результате прибор получается самодокументируемый - подключил интерфейс и посмотрел, что там в приборе доступно, есть прожка для просмотра. И для скриптов управления с компьютера.

Логи обмена смотрятся обычной терминалкой.

Порты под широко используемые семейства, реализация слэйв/мастер.

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

 

Пример лога, имя прибора забито, ессно.

 

1 17:03:01.865 Get objects count >1 a2?

2 17:03:01.868 Objects count is 16 <1 A2=16

1 17:03:01.896 Get value of variable «1 A0» >1 a0?

2 17:03:01.911 Value is: 10 <1 A0=10

1 17:03:01.961 Get name of variable «1 A0» >1 a0#

2 17:03:01.969 Name is: xxxxxx <1 A0#"xxxxxx"

1 17:03:02.072 Get value of variable «1 A1» >1 a1?

2 17:03:02.077 Value is: -------------- <1 A1/"-------------- "

1 17:03:02.104 Get name of variable «1 A1» >1 a1#

2 17:03:02.108 Name is: Ver <1 A1#"Ver"

1 17:03:02.184 Get value of variable «1 A2» >1 a2?

2 17:03:02.187 Value is: 16 <1 A2=16

1 17:03:02.216 Get name of variable «1 A2» >1 a2#

2 17:03:02.219 Name is: Obj qty <1 A2#"Obj qty"

1 17:03:02.312 Get value of variable «1 A3» >1 a3?

2 17:03:02.314 Value is: 2015.05.25 12:03:41 <1 A3/"2015.05.25 12:03:41"

1 17:03:02.344 Get name of variable «1 A3» >1 a3#

2 17:03:02.345 Name is: Actual time <1 A3#"Actual time"

 

 

 

[Integro 0]

WAKE явно усложнен. Адрес там ни к чему. Это на физическом уровне передается контроллером RS485.

Извиняюсь, что не по теме, но как это? что вы понимаете под физическим уровнем? покажите мне контроллер в которм на борту есть переферия RS485 и регистр RS485_SLAVE_ADDR?

 

По теме, пользую WAKE, полем адрес разделаю тип сообщений, например ADDR=1-10 принимают слейвы, по адресу 100 валят дебажные сообщения, которые слушаю на PC. D вашем случае (передача AT комманд), избытоность не повлияет на производительность.

[AlexandrY 3]

Извиняюсь, что не по теме, но как это? что вы понимаете под физическим уровнем? покажите мне контроллер в которм на борту есть переферия RS485 и регистр RS485_SLAVE_ADDR?

 

Это делается сцепленным DMA. Фильтрация адресов тоже аппаратная.

Я думаю вопрос адреса можно закрыть.

Адрес в протоколе не нужен. Также как и поле команды.

 

например ADDR=1-10 принимают слейвы, по адресу 100 валят дебажные сообщения, которые слушаю на PC. D вашем случае (передача AT комманд), избытоность не повлияет на производительность.

 

Криво конечно сделали , но это было неизбежно.

Адрес тут действительно ни к селу ни к городу.

[Lagman 1]

Присоединяюсь у уважаемому zltigo - SLIP: просто, надёжно. Используем уже более 15 лет.

 

И я присоединюсь.

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

 

Так в SLIP же нет контрольной суммы пакета, там пишут, что т.к. в TCP/IP пакете уже есть контрольная сумма то в SLIP не стали вводить контрольную сумму из за избыточности. Т.е. к SLIP надо еще TCP/IP стек прибавить или свой контроль вводить, но тогда получится WAKE.

 

- error detection/correction:

 

noisy phone lines will corrupt packets in transit. Because the

line speed is probably quite low (likely 2400 baud),

retransmitting a packet is very expensive. Error detection is

not absolutely necessary at the SLIP level because any IP

application should detect damaged packets (IP header and UDP

and TCP checksums should suffice), although some common

applications like NFS usually ignore the checksum and depend on

the network media to detect damaged packets. Because it takes

so long to retransmit a packet which was corrupted by line

noise, it would be efficient if SLIP could provide some sort of

simple error correction mechanism of its own.

[=AK= 10]

Чего хочется: пакетный режим, с подтверждением доставки. Насколько я понимаю, раз используется пакетный режим - должно быть оговорено начало посылки (заголовок); т.к. данные могут быть любыми - среди них может попасться заголовок, а значит нужен byte stuffing; для гарантированной доставки необходимо добавить crc и т.д. и т.п.

 

Если не лень сделать свой протокол, то советую обратить внимание на элегантный COBS. А уж к нему элементарно добавите все, что вам нужно.

[zltigo 1]

Так в SLIP же нет контрольной суммы пакета...

Я писал - это фреймер. Все остальное добавляется, или инкапсулируется готовое по вкусу. Самое главное - на этом уровне не накладывается никаких ограничений и специфических требований для обеспечения каких-то условий других уровней. Это ПРИЦИПИАЛЬНОЕ отличие от того-же WAKE в котором уже вложен и СЛЕДУЮЩИЙ уровень, котороый уже решает какие-то задачи автора WAKE, но неизвестно, насколько они совпадают с задачами автора темы. Так-что идем по шагам.

1. Асинхронный БАЙТОВЫЙ приемопередатчик а-ля UART c любой физикой (условие поставленное автором)

2. Фреймер в стиле SLIP, поскольку автор говорил о пакетном обмене.

 

Дальше нужно слушать автора о конкретике. Все может ограничится минимум миниморумом, типа добавили во фрейм код пакета и контрольную сумму, или двигаться дальше, ну, хотя-бы в ситле того-же IP, где пошли адреса и порты за ними, механизмы буферизации, квитирования, повтора... Причем, если действительно "все(почти :)) хочу", то и берем тот-же TCP/UDP/IP...

[AlexandrY 3]

Я использую самопал по мотивам SNMP,

 

Не, у вас здесь мотивы не SNMP, а скорее AT команд.

 

В SNMP самое главное MIB файлы, которые грузятся и в дивайс и в SNMP менеджер на компьютере.

Я даже создал специальную программу которая генерировала одновременно и MIB для менеджера и текст на C-и с тем же деревом сущностей для дивайса.

Генерирует не только сущности но и описатели событий для Trap-ов

 

SNMP хорош тем что для него есть готовые мощные менеджеры с аналитикой под PC.

Для подключения SNMP к PC через RS232 я использую PPP (вот где есть байт стаффинг по полной) с протоколом прямого подключения к PC.

Влет пойдет и через RS485 и через радиосети.

 

Но это требует полного TCP стека увы и ресурсов соответствующих.

 

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

WAKE в этом смысле вообще голый.

 

Хороший выбор - MQTT

Есть реализации для PC на многих языках программирования. Есть клиенты на PC для всех популярных IDE. Для RAD Studio например.

 

 

 

 

Если не лень сделать свой протокол, то советую обратить внимание на элегантный COBS. А уж к нему элементарно добавите все, что вам нужно.

 

Ну если уж говорить о кодировании в пакетах, то тогда сразу человека надо отправить к ASN.1 и кодировке BER

Самое смешное, что у всех это валяется буквально под ногами.

Это же составная часть SNMP протокола в lwIP которая идет с FreeRTOS, которая сопровождает все эти дешевые киты на STM32, LPC, SAM и проч.

 

[MrYuran 17]

Прошу высказываться конструктивно.

Первый раз слышу про "контроллер RS-485", в котором адрес передается аппаратно, что его можно даже выкинуть из пакета Modbus.

Просто не могу представить, что бы это могло быть.

Вообще-то, стандарт RS-485 на физическом уровне даже структуру фрейма не оговаривает, хоть манчестер гони, не говоря уже о более высоких протоколах. То есть это тупо дифференциальная линия с оговоренными параметрами сигнала и возможностью переключения в Z-состояние