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

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

[stells]

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

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

[_Pasha]

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

[Lagman]

похоже на CAN

[kt361]

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

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

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

[stells]

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

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

[kt361]

Точно. Но в драйверах ставят защиту от КЗ.
Я рассчитываю использовать ST485. Плюс можно поставить резисторы на выход в линию.

[kt361]

похоже на CAN

CAN - дорого: Нужен Контроллер с CAN (120-200р) + драйвер шины .
RS-485: Контроллер за 50 р я присмотрел + RS485 (30 р).

[=AK=]

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

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

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

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

[demiurg_spb]

похоже на CAN

+1

[MrYuran]

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

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

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

[kt361]

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

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

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

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

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

Сообщение отредактировал kt361 - Dec 3 2012, 07:17

[редактор]

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

[ILYAUL]

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

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

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

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

[kt361]

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

Сообщение отредактировал kt361 - Dec 3 2012, 13:28