[arhiv6 15]

Добрый день. Посоветуйте, пожалуйста, протокол для обмена данными по асинхронному каналу (UART, RS485 и т.п.) между микроконтроллером (slave) и ПК (master). Чего хочется: пакетный режим, с подтверждением доставки. Насколько я понимаю, раз используется пакетный режим - должно быть оговорено начало посылки (заголовок); т.к. данные могут быть любыми - среди них может попасться заголовок, а значит нужен byte stuffing; для гарантированной доставки необходимо добавить crc и т.д. и т.п. Всё это можно сделать, отладить, документировать, потратить время, но наверняка же это будет свой велосипед? Наверняка же есть уже готовые, стандартные протоколы? Т.к. будет использоваться на МК, реализация протокола не должны быть требовательной к ресурсам. Погуглил, вроде для этого используют протокол WAKE, но как-то мало по нему информации, это тоже чей-то велосипед? Ещё слышал о ModBus ASCII, наверное попробую на нём реализовать, но перед тем как этим заняться, решил спросить - а какие ещё есть стандартные протоколы и какой мне подойдёт лучше?

P.S. Возможно, когда-нибудь захочу канал связи заменить на беспроводной на чипах СС1101, будет плюсом, если выбранный сейчас протокол поможет сделать такой переход лёгким (но это не главное).

[AlexandrY 3]

Погуглил, вроде для этого используют протокол WAKE, но как-то мало по нему информации, это тоже чей-то велосипед? Ещё слышал о ModBus ASCII, наверное попробую на нём реализовать, но перед тем как этим заняться, решил спросить - а какие ещё есть стандартные протоколы и какой мне подойдёт лучше?

 

Да конечно это велосипеды.

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

Поле CMD тоже ни к чему. Это все от попыток совместить в одном протоколе физический, канальный и прикладной уровни.

В MODBUS тоже почти все регламинтирует прикладной уровень, Интересно, что сделав MODBUS все равно не получите совместимость с оборудованием других разработчиков автоматически. Нужен еще правильный мапинг типов данных и адресов данных.

В общем, это все лишнее.

Зачем реализовывать чужие представления о прикладном уровне?

 

Все что нужно: хидер, длина пакета, данные, CRC (если CRC не проверяет физика).

И все. Это делается за день в слепую.

[MrYuran 18]

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

щито?!

[esaulenka 7]

щито?!

Очевидно ж, что по одному проводу течёт ток, по второму - напряжение, а по третьему - косинус фи.

Или это не про модбас? :-)

[Aner 4]

Очевидно ж, что по одному проводу течёт ток, по второму - напряжение, а по третьему - косинус фи.

Или это не про модбас? :-)

Но уж напряжение, косинус течь то никак не могут.

[AlexandrY 3]

щито?!

 

Не в курсе!?

 

На Arduino такого нет, не правда ли?

 

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

[jcxz 215]

P.S. Возможно, когда-нибудь захочу канал связи заменить на беспроводной на чипах СС1101, будет плюсом, если выбранный сейчас протокол поможет сделать такой переход лёгким (но это не главное).

Вряд-ли сразу сделаете что-то на все случаи жизни. Протокол выбирается под задачу. И у протокола есть разные уровни. Транспортного уровня (или как он там правильно называется, выделяющего кадры из потока байт) в пакетно-ориентированных каналах не нужно по определению.

Для RS-232/RS-485 канала первый уровень который Вам надо реализовать - выделение кадра из потока байт. Ну и обратное - преобразование кадра в поток байт. Делается это или байт-стаффингом или временными интервалами (модбас). Я, для своих самопальных протоколов, предпочитаю байт-стаффинг, так как он хорош совместим - хоть по UART передавай, хоть инкапсулированным внутрь других каких-то кадров другого протокола последовательностями байт произвольной длины.

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

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

 

Можете почитать описание например: МЭК-101 или DLMS-COSEM (канальный уровень, зелёная книга). Там всё подробно расписано.

[iosifk 3]

Добрый день. Посоветуйте, пожалуйста, протокол для обмена данными по асинхронному каналу (UART, RS485 и т.п.) между микроконтроллером (slave) и ПК (master). Чего хочется: пакетный режим, с подтверждением доставки.

Либо передавать символьными кодами и 0A и 0D использовать как конец кадра. Тогда на ПК годится любая терминалка. Но требует на 1 байт данных 2 байта в линии. Зато просто!

Либо протокол с байт-стаффингом. Либо с бит-стаффингом, хотя он на стороне ПК работает медленнее из-за сдвигов битов при обработке данных...

Что касается Wake, то к нему выложены исходники и это хорошо...

[AlexandrY 3]

Делается это или байт-стаффингом или временными интервалами (модбас). Я, для своих самопальных протоколов, предпочитаю байт-стаффинг, так как он хорош совместим - хоть по UART передавай, хоть инкапсулированным внутрь других каких-то кадров другого протокола последовательностями байт произвольной длины.

 

В чем великий смысл байт-стаффинга?

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

 

 

Если же искажений нет или они пренебрежимо редкие, как в RS каналах и бывает, то поле с длинной пакета более чем достаточно, да и парсинг гораздо проще.

 

Вот когда каналы работали на 120 бод и пакеты были по нескольку байт, вот тогда стаффинг наверно давал какую-то экономию времени передачи.

[arhiv6 15]

В чем великий смысл байт-стаффинга?

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

[mcheb 0]

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

Я пользую AT=.......<CRC16><LF><CR> и ASCII символы

 

[zltigo 1]

В чем великий смысл байт-стаффинга? Если канал подвержен искажениям байт-стаффинг не поможет.

Вообще-то помогает и даже очень, быстрому восстановлению фреймой синхронизации при ошибках в отличие от "с длинной пакета" при котором начинаются и танцы с бубном в поисках начала после битого фрейма, и введение ОБЯЗАТЕЛЬНЫХ таймаутов (сжирающих производительность канала) для разборок с потеряными байтами. В этом и есть его смысл, как и в том, что это совершенно независимый уровень передачи фрейма, а не ошметок протокола другого уровня.

 

Я пользую AT=.......<CRC16><LF><CR> и ASCII символы

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

Что касается Wake, то к нему выложены исходники и это хорошо...

Wake это разумная замена дебильному MODBUS-RTU, то есть решает аналогичные задачи. Но как что-то "универсальное" он совершенно никчему. Вся его соль собственно в классическом байстаффинге, используемом, например, в том-же классическом SLIP протоколе, который совершенно чист и незамутнен никакими прибамбасами другого уровня протокола, и хоть и используется (исходя их названия) для инкапсуляции IP фреймов, абсолютно универсален.

[jcxz 215]

Вообще-то помогает и даже очень, быстрому восстановлению фреймой синхронизации при ошибках в отличие от "с длинной пакета" при котором начинаются и танцы с бубном в поисках начала битого фрейма, и введение ОБЯЗАТЕЛЬНЫХ таймаутов (сжирающих производительность канала) для разборок с потеряными байтами. В этом и есть его смысл, как и в том, что это совершенно независимый уровень передачи фрейма, а не ошметок протокола другого уровня.

Согласен полностью.

 

В чем великий смысл байт-стаффинга?

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

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

Если скажем Ваш приёмник подключается в любой момент времени к потоку байт которым передаются некоторые кадры, то как в Вашем случае (с где-то переданной длиной кадра) ему засинхронизироваться с границами кадров при условии что внутри кадров передаются произвольные данные?

А теперь представьте более сложный случай - UART не физический, а виртуальный, проброшенный через какой-то другой протокол, возможно беспроводной, пакетный, с помехами и без гарантированной доставки. Значит имеют место быть периодические выпадения произвольных фрагментов потока байт. Байт-стаффинг к этому устойчив - будет синхронизирован по ближайшей границе кадра. А что делать с Вашим методом? Первое-же выпадение и где теперь искать где начало кадра где конец???

[AlexandrY 3]

Вообще-то помогает и даже очень, быстрому восстановлению фреймой синхронизации при ошибках в отличие от "с длинной пакета" при котором начинаются и танцы с бубном в поисках начала после битого фрейма, и введение ОБЯЗАТЕЛЬНЫХ таймаутов (сжирающих производительность канала) для разборок с потеряными байтами. В этом и есть его смысл, как и в том, что это совершенно независимый уровень передачи фрейма, а не ошметок протокола другого уровня.

 

Однако я 100% уверен что вы нам не продемонстрируете никаких цифр подтверждающих эффективность стаффинга против простого хидера с полем длинны на реальных линиях.

Ибо это тонкие исследования не оправданные в этом случае.

Таймауты понадобятся и со стафингом, поскольку требуется квитирование.

 

 

 

 

 

[zltigo 1]

Однако я 100% уверен что вы нам не продемонстрируете никаких цифр подтверждающих эффективность стаффинга против простого хидера с полем длинны на реальных линиях.

После этой фразы я еще раз убедился, что Вы ничего не понимаете, но продолжаете гнать пугру :( пытясь пудрить мозги некими неведомыми "реальными линиями" в которых уровень и тип ошибок может позволит "оправдать" протокол сделанный через анус, хотя НИЧЕГО, кроме скудоумия, не мешает реализовывать фрейминг без рассчетов на то, что чего-то там в "реальных" линиях не случиться. Причина проста - Вы всегда пользовались какими-то готовыми протокольными кубиками и никогда из не писали НИЧЕГО серьезного (сложнее маркер+размер) самостоятельно и уж тем более не задумывались о том как и почему рождались ПРОФЕССИОНАЛЬНЫЕ и в том числе научно выверенные СТЕКИ протоколов. Очень прочищает мозги хотя-бы закомство со стеком протколов X.25 - дедушкой всех стеков протоколов. Там внизу в основе лежат бит/байтстаффигги.

Таймауты понадобятся и со стафингом, поскольку требуется квитирование.

Вот я и говорю - каша :( - квитирование это уже ДРУГОЙ уровень протокола и соответственно таймауты ДРУГОГО протокольного уровня. Все, конечно, можно вульгаризировать до сваливания всех уровней в одну кучу, игнорирования обработок ошибок, единственного таймаута на верхнем уровне протокола...