kt361 0 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба Добрый день! Для реализации своей задумки мне необходимо соединить порядка 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 12 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба Если передаваемый байт не совпал с принятым, значит... ... произошло КЗ... драйверы конечно с защитой от КЗ, но насколько корректно закладывать изначально такие конфликты? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба ТС забыл указать физ. длину этой шины, потому что, для разруливания коллизий вполне может прокатить LIN-вариант управления передатчиком не через DI, а через TXE. Разумеется, если протокол будет способен гарантированно заткнуть мастеров на время длинной посылки, возникнет соблазн красиво переходить на максимально возможные скорости, тогда надо подумать о том, чтобы вернуть соединение TXD и DI обратно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Lagman 1 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба похоже на CAN Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба На КЗ не стоит рассчитывать, шина предположительно защищена от внешних воздействий, если же такое произойдет из-за поломки одного из устройств, это будет заметно. Длину шины я предполагаю метров на 300. RS485 разрешает на 1200 м делать. Скорости 9600 бод вполне хватит. Особо длинных пакетов не будет. Если будет, можно будет и раздробить уже на более высоком уровне. Предположим максимум в 32 байта данных + заголовок Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
stells 12 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба На КЗ не стоит рассчитывать... если на выходе одного передатчика 1, а на выходе другого 0, то они в режиме КЗ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба Точно. Но в драйверах ставят защиту от КЗ. Я рассчитываю использовать ST485. Плюс можно поставить резисторы на выход в линию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 2 декабря, 2012 Опубликовано 2 декабря, 2012 · Жалоба похоже на CAN CAN - дорого: Нужен Контроллер с CAN (120-200р) + драйвер шины . RS-485: Контроллер за 50 р я присмотрел + RS485 (30 р). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
=AK= 18 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба Контроллер всегда слушает то, что творится в линии. Если линия свободна от передаваемых данных, котроллер может передавать свои данные. Если передаваемый байт не совпал с принятым, значит произошла одновременная отправка с другим контроллером. В этом случае оба затыкаются на время передачи двух символов и выбирают на рандом - начать отправлять снова, или ждать. Используйте приемопередатчики CAN. Они представляют собой помесь RS485 и передатчиков с открытым коллектором, поэтому нечувствительны к столкновениям. Если выход приемника соединить не только со входом UART, но также завести на вход внешнего прерывания, то можно получить прерывание по старт-биту. В этом прерывании нетрудно определить, свой это старт-бит или чужой, и, соответственно, в большинстве случаев просто избежать столкновений. А для тех редких случаев, когда два узла начали передавать одновременно и потому не обнаружили столкновения в самом начале, там уже можно обнаруживать столкновения по несовпадению переданных и принятых байт, затыкаться и ждать рэндом интервал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба похоже на CAN+1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 29 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба Есть такой лисапедег Имеется доминантный и рецессивный сигналы, как в CAN. В случае с проводами (кто знает, может я ещё и радио или ИК свет буду использовать) доминантный — это прижимание линии данных к земле. В обычном состоянии линия данных имеет подтяжку к +5В. Таким образом, когда устройство видит, что линия уже прижата к земле, оно понимает, что какое-то другое устройство уже шлёт данные, и ждёт освобождения линии. Сами данные кодируются длиною доминантных сигналов. 1T — ноль, 3T — единица, пауза между ними — 1T. Каждая передача начинается инициализацией в виде длинного сигнала в 10T. CAN для нищебродов :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 3 декабря, 2012 Опубликовано 3 декабря, 2012 (изменено) · Жалоба Так. ладно. разочаруюсь в RS485. В CAN, как я понимаю, нет адресации, но есть непонятные мне пока фильтры сообщений (смотрю в сторону stm8s208). Даже можно постараться влезть в 8 байт данных для своих нужд. Мне хотелось, чтобы устройства могли посылать широковещательные пакеты и направленные одному адресату. Т.е. каждое устройство имеет свой идентификатор (0-254). Зашит в EEPROM, не меняется никогда и заведомо уникален в рамках одной сети. Первый байт в пакете пусть будет отвечать за адресацию этого сообщения. если 0-254 - принимает ответственное устройство, если 255 - значит, широковещательный пакет, принимают все устройства. В добавок мне нужно, чтобы была возможность перепрошить то или иное устройство в составе сети по этой же сети. Как понимаю из аппноута, стандартным бутлодером мне это не удастся - столкновение протоколов. Где прочитать о создании своего бутлодера для STM8? Как наименьшей кровью реализовать такую или похожую схему? Для чего нужны фильтры, и помогу ли они мне? Изменено 3 декабря, 2012 пользователем kt361 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба раз уж речь зашла о CAN, и стандартные протоколы не устраивают (непонятно и т.д), то в заголовок CAN-сообщения можно вставить некоторую информацию (например адрес устройства, отправляющего пакет). Пакеты в CAN принимают все устройства, но используют только те, кому это необходимо. Остальные отбраковывают пакет с помощью фильтров (аппаратно) и программно. Если использовать расширенные пакеты, то в 29 бит заголовка можно впихнуть очень много. Ограничением в 8 байт на пакет не пугайтесь. Можно организовать мультипакетную передачу, и собирать из фрагментов единое сообщение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ILYAUL 0 3 декабря, 2012 Опубликовано 3 декабря, 2012 · Жалоба если 255 - значит, широковещательный пакет, принимают все устройства. Для этого существует 9-бит Так. ладно. разочаруюсь в RS485. Перед тем как разочаровываться , Вы разбритесь , что из себя представляет техническая сторона RS485 и протоколы для обмена в сети. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kt361 0 3 декабря, 2012 Опубликовано 3 декабря, 2012 (изменено) · Жалоба Так помогите разобраться. В RS ничего кроме физической реализации нет. Изменено 3 декабря, 2012 пользователем kt361 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
