Перейти к содержанию
    

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

Добрый день!

 

Для реализации своей задумки мне необходимо соединить порядка 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. Но не очень нравится костыляция с пустой отправкой байтов.

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если передаваемый байт не совпал с принятым, значит...

... произошло КЗ... драйверы конечно с защитой от КЗ, но насколько корректно закладывать изначально такие конфликты?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ТС забыл указать физ. длину этой шины, потому что, для разруливания коллизий вполне может прокатить LIN-вариант управления передатчиком не через DI, а через TXE. Разумеется, если протокол будет способен гарантированно заткнуть мастеров на время длинной посылки, возникнет соблазн красиво переходить на максимально возможные скорости, тогда надо подумать о том, чтобы вернуть соединение TXD и DI обратно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На КЗ не стоит рассчитывать, шина предположительно защищена от внешних воздействий, если же такое произойдет из-за поломки одного из устройств, это будет заметно.

 

Длину шины я предполагаю метров на 300. RS485 разрешает на 1200 м делать.

 

Скорости 9600 бод вполне хватит. Особо длинных пакетов не будет. Если будет, можно будет и раздробить уже на более высоком уровне. Предположим максимум в 32 байта данных + заголовок

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

На КЗ не стоит рассчитывать...

если на выходе одного передатчика 1, а на выходе другого 0, то они в режиме КЗ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Точно. Но в драйверах ставят защиту от КЗ.

Я рассчитываю использовать ST485. Плюс можно поставить резисторы на выход в линию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

похоже на CAN

 

CAN - дорого: Нужен Контроллер с CAN (120-200р) + драйвер шины .

RS-485: Контроллер за 50 р я присмотрел + RS485 (30 р).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Используйте приемопередатчики CAN. Они представляют собой помесь RS485 и передатчиков с открытым коллектором, поэтому нечувствительны к столкновениям.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть такой лисапедег

 

Имеется доминантный и рецессивный сигналы, как в CAN. В случае с проводами (кто знает, может я ещё и радио или ИК свет буду использовать) доминантный — это прижимание линии данных к земле. В обычном состоянии линия данных имеет подтяжку к +5В. Таким образом, когда устройство видит, что линия уже прижата к земле, оно понимает, что какое-то другое устройство уже шлёт данные, и ждёт освобождения линии. Сами данные кодируются длиною доминантных сигналов. 1T — ноль, 3T — единица, пауза между ними — 1T. Каждая передача начинается инициализацией в виде длинного сигнала в 10T.

 

CAN для нищебродов :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так. ладно. разочаруюсь в RS485.

 

В CAN, как я понимаю, нет адресации, но есть непонятные мне пока фильтры сообщений (смотрю в сторону stm8s208). Даже можно постараться влезть в 8 байт данных для своих нужд.

 

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

Т.е. каждое устройство имеет свой идентификатор (0-254). Зашит в EEPROM, не меняется никогда и заведомо уникален в рамках одной сети.

Первый байт в пакете пусть будет отвечать за адресацию этого сообщения. если 0-254 - принимает ответственное устройство, если 255 - значит, широковещательный пакет, принимают все устройства.

 

В добавок мне нужно, чтобы была возможность перепрошить то или иное устройство в составе сети по этой же сети. Как понимаю из аппноута, стандартным бутлодером мне это не удастся - столкновение протоколов. Где прочитать о создании своего бутлодера для STM8?

 

Как наименьшей кровью реализовать такую или похожую схему? Для чего нужны фильтры, и помогу ли они мне?

Изменено пользователем kt361

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Если использовать расширенные пакеты, то в 29 бит заголовка можно впихнуть очень много.

Ограничением в 8 байт на пакет не пугайтесь. Можно организовать мультипакетную передачу, и собирать из фрагментов единое сообщение.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

если 255 - значит, широковещательный пакет, принимают все устройства.

Для этого существует 9-бит

Так. ладно. разочаруюсь в RS485
.

Перед тем как разочаровываться , Вы разбритесь , что из себя представляет техническая сторона RS485 и протоколы для обмена

в сети.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так помогите разобраться.

В RS ничего кроме физической реализации нет.

Изменено пользователем kt361

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...