Что-то не может 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.

Сообщение отредактировал rx3apf - Mar 2 2007, 19:17

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

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

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

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

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

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