Что-то не может RS485 как CAN давать коллизии при одновременной передаче двумя устройствами. А как тогда инициализацию делать? Неожиданно, конечно, но при 6-байтном идентификаторе кроме как отлавливать коллизии - других способов не придумаю.

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

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

А разве в сетях с передачей маркера нет алгоритма обнаружения коллизий??? CSMA/CD без обнаружения коллизий не работает.....А в RS485 - коллизию кроме как по току не представляю обнаружения..

CD это ж есть collision detection. А маркер предполагает, что только одно устройство мастерит в данный момент. И пока оно маркер не отдало, все остальные не смеют гавкать.

Вобщем по сути:
Навскидку вспоминается три способа:
1. Один мастер поочередно поллит все слэйвы.
2. Мультимастер с передачей маркера - отослал свои данные, передал права мастера следующему и заткнулся.
3. Разбивка на тайм-слоты. Каждый слэйв имеет право вякнуть только в определенный интервал времени.

Кто-то дополнит?

Я наверное не правильно объяснил. До пола мне все устройства найти надо. По уникальным идентификаторам (грубо говоря MAC-адресам). Уже потом использовать приведенные выше режимы общения. Так вот именно поиск надо придумать. С учетом очень малых ресурсов ведомых устройств.

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

Я делал такую штуку. Алгоритм там не особо сложный. Может даже найду, контроллерный варинат не могу дать, а компьютерный наверное получится.
Надо использовать определённое включение драйвера rs485. Об этом на форуме неоднократно писалось. Например здесь

Тут получается противоречивый сценарий взаимодействия.
Ну допустим главный в сети дивайс получил информацию об адресах каких-то дивайсов.
Но он все равно не знает, что это за дивайсы и что с ними делать.
Даже если давайсы сообщат о себе всю информацию они все равно не сообщат где они стоят в общей системе управления. Этой информацией распологает только главный.
Т.е по любому вам надо что-то делать руками: либо забивать таблицу адресов слэйвов в главном дивайсе заранее, либо ее формировать динамически в процессе инсталяции, но с участием человека который бы указывал функции каждому конкретному дивайсу.
А MAC адреса нужны для сред где могут существовать абсолютно независимые сети, как радиосети, Ethernet и т.д.
В сетях RS485 я не слыхал чтобы делались независимые сети на одной физической паре, т.е. и глобально уникальные MAC адреса там не имеют смысла.
Насколько имел опыт с CAN и CANOpen там всегда каждому дивайсу руками назначают адрес перемычками или дистанционно, и этапа поиска физических адресов там нет, мастеру всегда дают таблицу с уже записанными адресами.
Другой пример, в ZigBee есть поиск адресов дивайсов в сети, но с точки зрения инсталятора все опять сводится к ручному назначению хоть формально и не адресов, но идетрифицируемых числами функций или профилей.

Выделить специальный адрес для первоначального опроса. Ответ разбиваем на некоторое количество окон-таймслотов. Абонент отвечает в окне, выбранном по псевдослучайному принципу (затравкой ГСЧ будет его уникальный номер). Моделирование этого метода дает неплохой результат - для нахождения 250 абонентов при 256 тайм-слотах достаточно типично пяти циклов.

Не понял - а как быть с коллизиями?

Видимо они "усредняются" повторными запросами.

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

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

Да, если отказаться от байт-ориентированного протокола на этапе "разруливания" - можно изобразить что-нибудь типа механизма детектирования устройств на шине 1-wire или механизма антиколлизий в ISO14443.

А такой вариант:

Мастер посылает запрос "Кто есть на шине в таком-то диапазоне адресов?"
Слейвы отвечают на это переводом шины в активное состояние (передача 0) на некоторое время.
Т.е. мастер принимает break, как ответ что в этом диапазоне есть как минимум 1 слейв.
Ну а опрос можно свести к подобию половинного деления.
Т.е. для N разрядного адреса девайса:
- и 1-ом слейве его адрес найдётся за N итераций.
- и 2-х слейвах их адрес найдётся за от N+1 до 2N-1 итераций.
и т.д.

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

Диапазон можно сделать как адрес, и маску деиствительных бит в нём.

ЗЫ немного похож на этот метод опрос всех девайсов в микролане от далласа, где идентификаторы слейвов унакальные 64-х разрядные прошитые при изготовлении.

Ага, то есть коллизии есть. А на 485 их теоретически быть не должно

Думали мы о варианте с колизиями:
Мастер - Озовись кто живой (с совпадающей частью адреса)!
;?%*%:%
Мастер - ага. наверно колизия (СRC не сошелся).
ну и так далее.
Но как здесь было сказано - RS485 колизий не допускает. В случае множественной колизии (одновременный ответ n устройств) можно получить перегруз по питанию системы. Мы питаем 12В и 2 проводи на интерфейс связи. В результате отказались.
Хотя красивая была идея - монтажник на плане записывает заводские номера модулей, а потом система их сама находит, а оператору остается привезать модули к "местности". Что где находиться.
Но решили что будет терминал, который напрямую конектится напрямую к модулю, дает ему адрес и запоминает у себя. При подключении терминала к системе, мастер с него забирает данные о адресах модулей. Так и реализуем систему.

Пожалуй алгоритм 1wire будет оптимальным, только слушать вход придется в режиме pio.

Такую отсебятину в CANOpen пресекают на корню.
По этому стандарту на каждом дивайсе на видном месте должны стоять перемычки или декадные микропереключатели однозначно сообщающие инсталятору номер дивайса.

Спасибо всем откликнувшимся. Имено до исключения каждого ответившего слейва я и додумася пока.
rx3apf - вы меня успокоили, значит это не бред. А чтобы перегрузки линии питания не происходило - думаю ограничить ток драйвера по питанию сверху (по плюсу, милиампер этак до 50) - тогда - полное подобие CAN получится, и коллизии появятся Критика будет?

Ну если вы еще имеете возможность вмешаться в схемотехнику, то ограничьте ток драйверов не по питанию, а последовательными резисторами 22 ома между выходами драйвера и линиями А и В. Если при этом использовать описанный выше прием с передачей только нуля, и формированием единицы подтяжками и короткими импульсами в начале бита, то получим вполне безопасную для драйверов шину на которой допустимы коллизии и можно реализовать подобие поиска 1-wire. А если приемником слушать свои же посылки уже с линий А и В (после резисторов), и по эху определять наличие коллизий - можно сделать подобие арбитража CAN.
Но увы, это все будет несовместимо с чужими "честными" устройствами.
P.S. Блин, почему это обсуждение не произошло когда я свою систему придумывал??? Теперь мучаюсь перебором (у меня 2 байта адрес), а можно было так красиво сделать поиск а-ля 1-wire. Но я последовательные резисторы забыл

На мой взгляд - неплохой вариант. С резисторами (как предложил Сергей) - тоже неплохо.

А скорости большие ? А время "настройки" сильно лимитировано ? А то ведь можно сделать вариацию того, что делал я - перебираем старший байт, по младшему распыляем по тайм-слотам. Коллизии невозможны (при условии уникальности 16-битного номера). У меня такое делать нельзя, поскольку недопустимо долго (поиск производится при каждом сеансе), а вот если речь о разовой конфигурации - думаю, вполне вариант...

Вот здесь upload/DOCs/Standarts&Specifications&Gosts/Profibus/SPEC.PDF "старый велосипед" описан.

ИМХО
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 ошибся.

ЗЫ. Надеюсь не очепятался. Проще алгоритм написать.

Только
1. для вышеописанного обязательно должна быть схема включения с доминатным нулём.
2. Потому что у "честных" единица настоящая и как говорили выше будет конфликтовать с настоящим нулём

Прикрепляю свой алгоритм(VC7.0).

2 Сергей Борщ: С двумя резисторами, как мне кажется - доминантного нуля не получится....без него коллизию или break не обнаружить если например два устройства тянут вверх и лишь одно - в ноль.
Да и break - не удобно. Не все контролеры могут так слушать без использования PIO. Есть желание все-таки сделать доминантный ноль и отказаться от break:

1. Простой уарт всегда отловит отрицательный перепад и примет хотя-бы один байт при возникновении коллизии. Тогда простое сравнение CRC и длины посылки с тайм-аутом даст четкий признак коллизии.

2. Если "честное" устройство всетаки присутствует, то в процессе поиска можно заставлять его отдать первичный идентификатор, дать ему вторичный идентификатор и тем самым заставить молчать при повторном поиске устройств в том-же диапазоне.

Мне кажется, что достаточно просто ограничить потребление драйвера и один из пунктов сработает обязательно.

Спасибо за внимание. Жду критики.

Чуть не забыл. Мне тоже (кажется) придется поддерживать горячее включение. Так вот. Перед поиском широковещательно думаю стирать всем слейвам вторичный идентификатор. Сам алгоритм поиска думаю использовать как в M-Bus плюс - перезапрос всех, кто не получал вторичного идентификатора (типа не FF).

Или я чего не понимаю, или....
С break-ом не нужен доминантный 0. У трансивера 485 есть 3 состояния.
- передача (силовая) нуля
- передача (силовая) единица
- высокий импеданс
Так вот передача нуля несколькими устройствами не будет конфликтовать с высоким импедансом остальных девайсов. Ну а "конфликт" двух (нескольких) передатчиков передающих одно и тоже состояние (в данном случае 0) на порядки более мягкий чем когда борятся единица с нулём.


Перепад отловит, а вот стопового бита может и не быть.... и соответственно приёма байта тоже.

Какой CRC в одном байте или где?

Попытайтесь рассказать нам весь обмен по опросу всех девайсов, желательно на примере?

Теперь думаю так:

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...

Вроде так я себе это представляю. Мож где ошибся? Критика?

Насколько я знаю в 485 интерфейсе драйвера A и B "одинаковые". И единицы и нолики передаются по обоим проводам в противофазе. На входе стоят просто компараторы между А и В. Стандартные драйвера не имеют смещения, поэтому очень часто начальное смещение шины в единицу делают с помощью резюков на А и В к питанию и земле. Таким образом в типовой 485 сети, при прочих равных, выходная единица одного устройства поборет нолик с другого.
Ваша идея с резюком на А или В ничего не даст, кроме снижения помехозащищённости, скорострельности, максимальной длины шины и т.д. Резюк с диодом может и поможет, но как быть если 10 единиц против одного нолика и т.д.
Ну и ещё раз ИМХО. 485 не предназначен для коллизий и т.д., если создавать/менять/править железячный интерфейс - ставте CAN-драйвера и гоняйте байты с UART-ов.


Примерно понял что вы хотите. Некий симбиоз половинного деления и перебора.

В любом монгобайтном ответе слейва есть как минимум следующие параметры
1. Задержка от запроса до первого байта ответа (T1)
2. Битрейт передачи
3. Задержка между байтами пакета. (T2)

Для T1 как правило даётся довольно большой диапазон.
Для T2 обычно поменьше.
Поэтому у Вас легко случиться такое что сначала ответит один девайс (CRC для которого совпадёт), а потом второй. Особенно при больших скоростях передачи.

Ну и не понимаю я зачем генерить коллизии с:Вместо одного нулевого (длинного) импульса. Мастеру UART скажет либо брейк, либо ошибку (stop-bit !=1), в зависимости от контроллера UARTа.