Свой протокол поверх RS-485 Опции

[kt361]

Добрый день!

Для реализации своей задумки мне необходимо соединить порядка 20 устройств по общей шине в режиме Multi-Master.
В любой момент любое устройство независимо должно иметь возможность отправить свое сообщение в шину.
Если любое из устройств зависает или ломается, оно не должно никоим образом влиять на работоспособность других устройств в сети.
Ввиду стоимости и простоты переноса в различные среды я хочу использовать RS-485 на общей шине.

Исходя из условий, приходится отмести условно-стандартный для указанного физического уровня Modbus.
Соответственно, приходится выдумывать некую свою поделку, отправной точкой я хочу взять описание протокола от zap: http://electrotransport.ru/ussr/index.php?...12449#msg112449

Кратко: muli-master протокол с гарантированной отправкой над первичным протоколом, способным отправлять байты, но не биты.
Контроллер всегда слушает то, что творится в линии. Если линия свободна от передаваемых данных, котроллер может передавать свои данные. Если передаваемый байт не совпал с принятым, значит произошла одновременная отправка с другим контроллером. В этом случае оба затыкаются на время передачи двух символов и выбирают на рандом - начать отправлять снова, или ждать.
В описанном протоколе необходимо и для чтения, и для отправки необходимо знать время отправки одного символа (байта).

Реализовать передачу данных в преобразователь (st485/max485 итп) и измерять эти интервалы можно двояко:
1. Подключать встроенный в микроконтроллер UART. Интервал измерять временем выполнения функции uart_write в пустоту, с отключенным DE в преобразователе RS-485.
2. Реализовать UART программно на таймере и прерываниях, из прерываний таймера знаем время передачи одного символа.

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

Благодарю за ответы и рассуждения!

[flakman]

Позвольте добавить свой вопрос. Задача от части похожа на сабж от kt361, по этому прочитал весь топик и не стал создавать отдельный, да и назывался бы он точно также.
Нужно что-то вроде промежуточного варианта между мульти-мастер протоколом и традиционными. Сразу скажу что уйти от RS485 просто не могу - у меня готовое устройство с тем что есть, выбирать не из чего. Сеть может работать и с одним мастером, но особенность в том, что критично время реакции на запрос, счёт идёт на миллисекунды (сеть будет из устройств считывания RFID, всё сделать нужно за время, приемлемое для подноса человеком карты к считывателю). По этой причине хочется заменить опрос слэйвов на сигнализацию самими слэйвами о необходимости связи с мастером.

Есть такая идея. По сравнению с Modbus всё наоборот - мастер не клиент, а сервер. В тишине мастер не опрашивает слэйвов, а ждёт запроса на связь => возникает проблема с коллизиями, которую попытаюсь объяснить как хочу обойти. Слэйвы в спокойном состоянии тоже слушают шину. Что-бы просигналить о необходимости связи, слэйв отсылает пакет определённого формата, включающий его собственный адрес. Мастер, если всё ок, в ответ отсылает пакет на широковещательный адрес, в котором содержится адрес запросившего слэйва. Данный пакет для инициатора связи означает что обмен разрешён, всеми остальными он должен распознаваться как "шина занята" (в пакете не их адрес), и нужно ждать широковещательного пакета означающего освобождение шины. Во избежании глюков можно периодически слать пакет "шина свободна" просто во время тишины. Это поможет и для распознавания вымершего матера. Но механизм поиска нового в моей задаче не стоит. Им в любом случае может быть только софт на ПК с совершенно другой логикой чем у остальных девайсов в сети.

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

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

Возможно это велосипед какого-нибудь протокола вообще без фиксированного матера-сервера (прошу ткнуть носом ), возможно это вообще не будет работать (прошу обсуждения). Изначально рассматривал Modbus, но там как раз традиционный вариант с опросом. Если описанное выше имеет место быть, не знаю - стоит писать с нуля или быстрее будет модифицировать какую-нибудь реализацию Modbus. Это потому-что на самом деле после установки связи, она может происходить точно так-же как в Modbus, что избавляет от написания реализации самого обмена данными.

[=AK=]

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

Похоже что мало кто знает, что помимо "традиционных" протоколов "master-slave", в которых есть какой-то мастер, есть протоколы "producer-consumer", в которых мастера нет в принципе.

В протоколах "producer-consumer" (к которым, в частности, относится CAN) передачу начинает любой "производитель информации", которому "есть что сказать". А принимает информацию не какое-то одно устройство, а все, кому эта информация нужна. В результате этого информация передается очень быстро даже при малых бодовых скоростях. Суммарный выигрыш по скорости при раздаче информации получается на один-два порядка, хоть людям неискушенным в это трудно поверить.

В обычных "master-slave" мастер должен:
- все время опрашивать другие узлы на предмет наличия новой информации
- если у одного из узлов появилось что-то новое, мастер должен прочитать инфу
- после этого мастер должен по очереди разослать инфу тем узлам, которым она нужна

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

Основной проблемой протоколов "producer-consumer" является обнаружение и "разруливание" столкновений (CSMA/CD). Очень хорошим вариантом является предотвращение столкновений (CSMA/CA), для реализации которой как правило используют передатчики с открытым коллектором или их эквиваленты. CAN использует эквивалент открытого коллектора, гибрид ОК и RS485.