| |
 Полный Ликбез: RS485 - двухпроводная шина., Как искать устройства. |
|
|
|
|
 Mar 2 2007, 10:05
|
http://uschema.com
Группа: Свой
Сообщений: 708
Регистрация: 16-02-06
Из: UK(Ukrainian_Kingdom) Kharkov
Пользователь №: 14 394
|
Цитата(nameless @ Mar 2 2007, 07:48)  Что-то не может RS485 как CAN давать коллизии при одновременной передаче двумя устройствами. А как тогда инициализацию делать? Неожиданно, конечно, но при 6-байтном идентификаторе кроме как отлавливать коллизии - других способов не придумаю. причем тут колизии? это же 485й(по сути тотже 232й) для поиска - перебираете адреса, с контрольной посылкой в нужном Вам порядке и ожидаете ответа: если ответа нет - девайса нет(или не отвечает) если ответ есть - следовательно железка есть. такой же алгоритм при поиске на какой скорости работают железки - и все по ходу... может быть, есть и более умные алгоритмы для 485го - но мне они не известны...
--------------------
|
|
|
|
|
|
|
|
Mar 2 2007, 10:20
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(PrSt @ Mar 2 2007, 10:05) Цитата(nameless @ Mar 2 2007, 07:48) Что-то не может RS485 как CAN давать коллизии при одновременной передаче двумя устройствами. А как тогда инициализацию делать? Неожиданно, конечно, но при 6-байтном идентификаторе кроме как отлавливать коллизии - других способов не придумаю. причем тут колизии? это же 485й(по сути тотже 232й) для поиска - перебираете адреса, с контрольной посылкой в нужном Вам порядке и ожидаете ответа: если ответа нет - девайса нет(или не отвечает) если ответ есть - следовательно железка есть. такой же алгоритм при поиске на какой скорости работают железки - и все по ходу... может быть, есть и более умные алгоритмы для 485го - но мне они не известны... Этот вариант пригоден лишь для архитектуры "клиент-сервер". Если же необходимо сделать мультимастерную систему, то лучше почитать о сетях с передачей маркёра. Описывается этот метод доступа практически в любой книге, посвященной сетям передачи данных.
|
|
|
|
|
|
|
|
Mar 2 2007, 11:27
|
Профессионал
Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380
|
Цитата CSMA/CD без обнаружения коллизий не работает..... CD это ж есть collision detection. А маркер предполагает, что только одно устройство мастерит в данный момент. И пока оно маркер не отдало, все остальные не смеют гавкать. Вобщем по сути: Навскидку вспоминается три способа: 1. Один мастер поочередно поллит все слэйвы. 2. Мультимастер с передачей маркера - отослал свои данные, передал права мастера следующему и заткнулся. 3. Разбивка на тайм-слоты. Каждый слэйв имеет право вякнуть только в определенный интервал времени. Кто-то дополнит?
--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
|
|
|
|
|
|
|
|
Mar 2 2007, 11:54
|
Профессионал
Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380
|
Цитата Так вот именно поиск надо придумать. Т.е. адресов в сети слишком много, чтобы опросить их все последовательно? Трудно чем-то помочь.
--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
|
|
|
|
|
|
|
|
Mar 2 2007, 15:12
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Тут получается противоречивый сценарий взаимодействия. Ну допустим главный в сети дивайс получил информацию об адресах каких-то дивайсов. Но он все равно не знает, что это за дивайсы и что с ними делать. Даже если давайсы сообщат о себе всю информацию они все равно не сообщат где они стоят в общей системе управления. Этой информацией распологает только главный. Т.е по любому вам надо что-то делать руками: либо забивать таблицу адресов слэйвов в главном дивайсе заранее, либо ее формировать динамически в процессе инсталяции, но с участием человека который бы указывал функции каждому конкретному дивайсу. А MAC адреса нужны для сред где могут существовать абсолютно независимые сети, как радиосети, Ethernet и т.д. В сетях RS485 я не слыхал чтобы делались независимые сети на одной физической паре, т.е. и глобально уникальные MAC адреса там не имеют смысла. Насколько имел опыт с CAN и CANOpen там всегда каждому дивайсу руками назначают адрес перемычками или дистанционно, и этапа поиска физических адресов там нет, мастеру всегда дают таблицу с уже записанными адресами. Другой пример, в ZigBee есть поиск адресов дивайсов в сети, но с точки зрения инсталятора все опять сводится к ручному назначению хоть формально и не адресов, но идетрифицируемых числами функций или профилей. Цитата(nameless @ Mar 2 2007, 13:14) Я наверное не правильно объяснил. До пола мне все устройства найти надо. По уникальным идентификаторам (грубо говоря MAC-адресам). Уже потом использовать приведенные выше режимы общения. Так вот именно поиск надо придумать. С учетом очень малых ресурсов ведомых устройств.
|
|
|
|
|
|
|
|
Mar 2 2007, 19:06
|
Гуру
Группа: Участник
Сообщений: 3 834
Регистрация: 14-06-06
Из: Moscow, Russia
Пользователь №: 18 047
|
Цитата(rezident @ Mar 2 2007, 18:58) Цитата(Сергей Борщ @ Mar 2 2007, 20:50) Цитата(rx3apf @ Mar 2 2007, 14:54)
Выделить специальный адрес для первоначального опроса. Ответ разбиваем на некоторое количество окон-таймслотов. Абонент отвечает в окне, выбранном по псевдослучайному принципу (затравкой ГСЧ будет его уникальный номер). Моделирование этого метода дает неплохой результат - для нахождения 250 абонентов при 256 тайм-слотах достаточно типично пяти циклов.
Не понял - а как быть с коллизиями? Видимо они "усредняются" повторными запросами. Виноват, я "недосказал". Обнаруженные ответы обрабатываются - абонентам отсылается уведомление, что они обнаружены (как вариант, при ограниченном общем количестве - отсылкой им адреса, по которому они будут в дальнейшем выбираться), и тем самым они исключаются из последующих циклов опроса. Если абонентов мало, то, может быть, это и не требуется. В моем случае я исключал абонентов до тех пор, пока при двух опросах подряд отклики вообще не исчезнут - значит, "расправились" со всеми. Но у меня специфика - радиоканал с непредсказуемым взаиморасположением объектов. Примерно так же работают RFID с UHF-накачкой, однако детального описания реализации мне найти не удалось, поэтому начал творить отсебятину... Коллизия в моем случае не обнаруживается вообще (в худшем случае), в соответствующем тайм-слоте ничего не принято (в лучшем - услышу того, кто мощнее, в случае проводной связи, может быть, можно засечь факт какой-то активности достаточно надежно). Да, если отказаться от байт-ориентированного протокола на этапе "разруливания" - можно изобразить что-нибудь типа механизма детектирования устройств на шине 1-wire или механизма антиколлизий в ISO14443.
Сообщение отредактировал rx3apf - Mar 2 2007, 19:17
|
|
|
|
|
|
|
|
Mar 3 2007, 14:23
|
Частый гость
Группа: Свой
Сообщений: 174
Регистрация: 9-07-04
Пользователь №: 305
|
Спасибо всем откликнувшимся. Имено до исключения каждого ответившего слейва я и додумася пока. rx3apf - вы меня успокоили, значит это не бред. А чтобы перегрузки линии питания не происходило - думаю ограничить ток драйвера по питанию сверху (по плюсу, милиампер этак до 50) - тогда - полное подобие CAN получится, и коллизии появятся  Критика будет?
|
|
|
|
|
|
|
|
Mar 3 2007, 14:44
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Цитата(nameless @ Mar 3 2007, 13:23) Критика будет? Ну если вы еще имеете возможность вмешаться в схемотехнику, то ограничьте ток драйверов не по питанию, а последовательными резисторами 22 ома между выходами драйвера и линиями А и В. Если при этом использовать описанный выше прием с передачей только нуля, и формированием единицы подтяжками и короткими импульсами в начале бита, то получим вполне безопасную для драйверов шину на которой допустимы коллизии и можно реализовать подобие поиска 1-wire. А если приемником слушать свои же посылки уже с линий А и В (после резисторов), и по эху определять наличие коллизий - можно сделать подобие арбитража CAN. Но увы, это все будет несовместимо с чужими "честными" устройствами. P.S. Блин, почему это обсуждение не произошло когда я свою систему придумывал??? Теперь мучаюсь перебором (у меня 2 байта адрес), а можно было так красиво сделать поиск а-ля 1-wire. Но я последовательные резисторы забыл 
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
Mar 3 2007, 15:23
|
Гуру
Группа: Участник
Сообщений: 3 834
Регистрация: 14-06-06
Из: Moscow, Russia
Пользователь №: 18 047
|
Цитата(Сергей Борщ @ Mar 3 2007, 14:44) P.S. Блин, почему это обсуждение не произошло когда я свою систему придумывал??? Теперь мучаюсь перебором (у меня 2 байта адрес), а можно было так красиво сделать поиск а-ля 1-wire. Но я последовательные резисторы забыл А скорости большие ? А время "настройки" сильно лимитировано ? А то ведь можно сделать вариацию того, что делал я - перебираем старший байт, по младшему распыляем по тайм-слотам. Коллизии невозможны (при условии уникальности 16-битного номера). У меня такое делать нельзя, поскольку недопустимо долго (поиск производится при каждом сеансе), а вот если речь о разовой конфигурации - думаю, вполне вариант...
|
|
|
|
|
|
|
|
Mar 4 2007, 09:39
|
Местный
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034
|
ИМХО 1. Нормальные драйверы 485 имеют защиту по току 2. 485 не предназначен для коллизий, и тут "писями по воде виляно" кто кого поборет. Драйвер одного производителя легко "заборет" другого и т.д. Соответственно не всегда возможно обнаружить коллизию. 3. Очень трудно синхронизировать ответы нескольких слейвов. В способе описанном мной выше никаких коллизий не будет (Одновременную трансляцию одного и тогоже состояния (нуля) несколькими слейвами я за коллизию не считаю). Допустим что: 1. скорость передачи у нас 9600бод, тогда время передачи одного символа 1000000/9600*11 = 1145,833мкс (для 2-х стопбитов) или не менее 1.2мс. 2. Допустим что время реакции слейва на запрос мастера нормируется в диапазоне 10..20мс, тогда время передачи слейвами сигнала break (который понимается многими UART-ами и не надо переводить Rx в мастере в режим PIO) должно быть не менее чем MAX(1.2, 20-10)=10мс. С запасом берём 15мс. Т.е. передача несколькими слейвами сигнала break выражается в приёме мастером этого break-а длительностью 15..25мс. 3. Слейвы передают сигнал break сначала переводя Tx UART-а в 0, а уж потом включают трансивер 485 на 15мс. Пример для байтового адреса и 2-х девайсов с адресами 0x88 и 0x92: Обмен: 1. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x00 .. 0x7F?" и запоминает "точку возврата" (0x80 .. 0xFF) В ответ тишина... больше 20мс+небольшой запасик смысла ждать мастеру нет. уходим на ближайшую "точку возврата" 2. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x80 .. 0xFF?" В ответ сигнал break (от обоих девайсов) Ага, ктото есть. Мастер ждёт окончания сигнала break. 3. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x80 .. 0xBF?" и запоминает "точку возврата" (0xС0 .. 0xFF) В ответ сигнал break (от обоих девайсов) Ага, ктото есть. Мастер ждёт окончания сигнала break. 4. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x80 .. 0x9F?" и запоминает "точку возврата" (0xA0 .. 0xBF) В ответ сигнал break (от обоих девайсов) Ага, ктото есть. Мастер ждёт окончания сигнала break. 5. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x80 .. 0x8F?" и запоминает "точку возврата" (0x90 .. 0x9F) В ответ сигнал break (от девайса 0x88) Ага, ктото есть. Мастер ждёт окончания сигнала break. 6. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x80 .. 0x87?" и запоминает "точку возврата" (0x88 .. 0x8F) В ответ тишина... уходим на ближайшую "точку возврата" 7. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x88 .. 0x8F?" В ответ сигнал break (от девайса 0x88) Ага, ктото есть. Мастер ждёт окончания сигнала break. 8. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x88 .. 0x8B?" и запоминает "точку возврата" (0x8C .. 0x8F) В ответ сигнал break (от девайса 0x88) Ага, ктото есть. Мастер ждёт окончания сигнала break. 9. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x88 .. 0x89?" и запоминает "точку возврата" (0x8A .. 0x8B) В ответ сигнал break (от девайса 0x88) Ага, ктото есть. Мастер ждёт окончания сигнала break. 10. Мастер шлёт запрос "Ктонить есть на шине из диапазона 0x88 .. 0x88?" и запоминает "точку возврата" (0x89 .. 0x89) В ответ сигнал break (от девайса 0x88) Ага, ктото есть. Мастер ждёт окончания сигнала break. Ура! Нашли первый девайс 0x88!!! Далее возращаясь на "точки возврата" аналогично находится всё остальное. На самом деле никакие "точки возврата" не надо запоминать, всё вычисляется из текущего диапазона и глубины вложенности. С количеством итераций в моём посте выше, я раза в 2 ошибся. ЗЫ. Надеюсь не очепятался. Проще алгоритм написать.
|
|
|
|
|
|
|
|
Mar 4 2007, 10:05
|
Местный
Группа: Свой
Сообщений: 278
Регистрация: 18-01-05
Из: Санкт-Петербург
Пользователь №: 2 031
|
Только 1. для вышеописанного обязательно должна быть схема включения с доминатным нулём. 2. Цитата Но увы, это все будет несовместимо с чужими "честными" устройствами. Потому что у "честных" единица настоящая и как говорили выше будет конфликтовать с настоящим нулём Прикрепляю свой алгоритм(VC7.0).
|
|
|
|
|
|
|
|
Mar 5 2007, 07:55
|
Местный
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034
|
Цитата(nameless @ Mar 4 2007, 15:34) 2 Сергей Борщ: С двумя резисторами, как мне кажется - доминантного нуля не получится....без него коллизию или break не обнаружить если например два устройства тянут вверх и лишь одно - в ноль.
Да и break - не удобно. Не все контролеры могут так слушать без использования PIO. Есть желание все-таки сделать доминантный ноль и отказаться от break: Или я чего не понимаю, или.... С break-ом не нужен доминантный 0. У трансивера 485 есть 3 состояния. - передача (силовая) нуля - передача (силовая) единица - высокий импеданс Так вот передача нуля несколькими устройствами не будет конфликтовать с высоким импедансом остальных девайсов. Ну а "конфликт" двух (нескольких) передатчиков передающих одно и тоже состояние (в данном случае 0) на порядки более мягкий чем когда борятся единица с нулём. Цитата 1. Простой уарт всегда отловит отрицательный перепад и примет хотя-бы один байт при возникновении коллизии. Перепад отловит, а вот стопового бита может и не быть.... и соответственно приёма байта тоже. Цитата Тогда простое сравнение CRC и длины посылки с тайм-аутом даст четкий признак коллизии. Какой CRC в одном байте или где? Цитата 2. Если "честное" устройство всетаки присутствует, то в процессе поиска можно заставлять его отдать первичный идентификатор, дать ему вторичный идентификатор и тем самым заставить молчать при повторном поиске устройств в том-же диапазоне. Попытайтесь рассказать нам весь обмен по опросу всех девайсов, желательно на примере?
|
|
|
|
|
|
|
|
Mar 5 2007, 10:48
|
Частый гость
Группа: Свой
Сообщений: 174
Регистрация: 9-07-04
Пользователь №: 305
|
Теперь думаю так:
1. При включении слейв имеет вторичный идентификатор FF. Ток "единицы" ограничен у всех устройств либо резистором по питанию либо последовательно в линию "А" (если нулю соответствует B+ и A-, то B+ одного устройства перетягивает А+ других).
2. Мастер говорит: Все, у кого (например двухбайтный уник. адрес) с маской FFFF совпадает с оным - отвечайте...если есть - отвечают все. В ответе - полная галиматья, но (думаю) со стопроцентной вероятностью есть отрицательный перепад, старт-признак то есть. Frame Error никто не отменял. Мастер видит, что есть как минимум битый (stop-bit !=1) байт, а значит - устройства ЕСТЬ.
3. Мастер говорит: Все, у кого адрес с маской 0FFF есть тот-же адрес - отвечайте. Пусть есть три устройства: 1234, 1244 и 1355. Никто не отвечает.
4. Мастер приращает старший полубайт до 1. - Все отвечают. Опять галиматья. Но признак есть.
4. Повторяем, перебирая младший полубайт старшего байта адреса от нуля вверх, оставляя в старшем 1.
5. Дошли до 12 в старшем байте. Отвечают первый и второй. Коллизия
6. Говорим 120F - никого....продолжаем до 123F. отвечает первый. Отвечает именно полным адресом плюс CRC. Видим, что все в порядке по длине и по CRC - говорим ему, что у него есть вторичный идентификатор 0.
7. Повторяем последний запрос с маской 12FF. Отвечает 1244 полным адресом с CRC. А первый не отвечает, так как у него есть вторичный идентификатор.
8. Повторяем последний запрос с маской 12FF. Никто не отвечает. Даже стартового перепада нет.
9. Генерим маску 13FF. Последний отвечает.
10. Повторяем 13FF. Никто не отвечает
11. Маска 14FF - ни одного. Продложаем до 1EFF - никого.
12. Маски остались только 2FFF - по EFFF...
Вроде так я себе это представляю. Мож где ошибся? Критика?
|
|
|
|
|
|
|
|
Mar 5 2007, 11:55
|
Местный
Группа: Свой
Сообщений: 359
Регистрация: 9-12-05
Пользователь №: 12 034
|
Цитата(nameless @ Mar 5 2007, 12:48) Теперь думаю так:
1. При включении слейв имеет вторичный идентификатор FF. Ток "единицы" ограничен у всех устройств либо резистором по питанию либо последовательно в линию "А" (если нулю соответствует B+ и A-, то B+ одного устройства перетягивает А+ других). Насколько я знаю в 485 интерфейсе драйвера A и B "одинаковые". И единицы и нолики передаются по обоим проводам в противофазе. На входе стоят просто компараторы между А и В. Стандартные драйвера не имеют смещения, поэтому очень часто начальное смещение шины в единицу делают с помощью резюков на А и В к питанию и земле. Таким образом в типовой 485 сети, при прочих равных, выходная единица одного устройства поборет нолик с другого. Ваша идея с резюком на А или В ничего не даст, кроме снижения помехозащищённости, скорострельности, максимальной длины шины и т.д. Резюк с диодом может и поможет, но как быть если 10 единиц против одного нолика и т.д. Ну и ещё раз ИМХО. 485 не предназначен для коллизий и т.д., если создавать/менять/править железячный интерфейс - ставте CAN-драйвера и гоняйте байты с UART-ов. Цитата 2. Мастер говорит: ...
Вроде так я себе это представляю. Мож где ошибся? Критика? Примерно понял что вы хотите. Некий симбиоз половинного деления и перебора. В любом монгобайтном ответе слейва есть как минимум следующие параметры 1. Задержка от запроса до первого байта ответа (T1) 2. Битрейт передачи 3. Задержка между байтами пакета. (T2) Для T1 как правило даётся довольно большой диапазон. Для T2 обычно поменьше. Поэтому у Вас легко случиться такое что сначала ответит один девайс (CRC для которого совпадёт), а потом второй. Особенно при больших скоростях передачи. Ну и не понимаю я зачем генерить коллизии с: Цитата В ответе - полная галиматья, но (думаю) со стопроцентной вероятностью есть отрицательный перепад, старт-признак то есть. Frame Error никто не отменял. Мастер видит, что есть как минимум битый (stop-bit !=1) байт, а значит - устройства ЕСТЬ. Вместо одного нулевого (длинного) импульса. Мастеру UART скажет либо брейк, либо ошибку (stop-bit !=1), в зависимости от контроллера UARTа.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
