Думали мы о варианте с колизиями:
Мастер - Озовись кто живой (с совпадающей частью адреса)!
;?%*%:%
Мастер - ага. наверно колизия (С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а.