Планирую использование RS485

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

Вопрос - если НЕ энумерованных девайсов несколько?
Когда-то читал, что в этом случае на каждом подобном девайсе в случае широковещательного энумерационного пакета запускается некий _случайный_ таймер, по срабатыванию которого девайс "послушает" эфир и примет решение - пакет "предназначался ему" или нет.

Где можно это подробно почитать или, что, конечно, лучше , - поиметь некие примеры кода в дополнение? Как вообще это грамотно реализовывается?

Если у слейвов есть серийные номера - посмотрите как это реализовано в 1-wire.

Есть хорошие методы позволенные в изначально правильно построенных интерфейсах, хоть очень простых, как OW, хоть таких, как CAN. Проблема с теми многоточечными, которые кривые, как 485 не и не имеют доминирующего уровня - посему алготитмы основанные на возможности гарантированного "монтажного или" на обшей шине заложенное в основу, в том числе, и OW нормально не прокатывают.


Ну так Вы все и описалию Девайс через случайное время с квантом больше времени передачи ответного пакета вылезает на линию и шлет то самое время в качестве своего врEменного идентификатора. По идентификатору уже посылается пакет с конфигурацией этого конкретного девайса. При совпадении "случайных" чисел рассчитывается (без 100% гарантий) на то, что наверное мастер примет из линии что-то "битое" повторит процедуру на которую откликнуся девайсы не получавшие конфигурации в прошлом цикле.

Ну, J1708 никто не отменял... Хотя это не "чистый" 485.

И даже не "грязный" И к тому-же его конкретно похоронил J1939

Все таки первично должно быть ТЗ на такую систему с указанием времени, за которое система должна организоваться после включения питания.
Даже в довольно сложных системах, например с LonWorks, не брезгуют включением устройств в сеть по очереди и последующим прописыванием адреса или установкой его на джамперах.

согласен, вот сижу и думаю - все-таки заморочиться с энумерацией или прописывать жестко в конфигурацию слейвов уникальный ID

со стороны энумерации - я всегда буду точно знать, кто сидит на шине, с какими ID. В пользу жестких ID - никаких заморочек.. передустановкой слэйва в целевой девайс он конфигурится и все..

Вот сижу и думаю - пусть заморачивается заказчик с прописыванием ИД в слэйвы, или заморочиться самому сейчас с энумерацией... а сроки поджимают

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

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

Автоматическая энумерация не есть гуд. Даже в тех интерфейсах, где она просто реализуется - типа OneWire. Если в сети устройства однотипные, то все равно без ручной "прописки" чаще всего не обойтись. Представьте сеть из 4-х термометров ds18b20, контролирующих температуру в разных зонах какого нибудь термошкафа. При автоматической энумерации можно получить 4 идентификатора, но как их привязать к зонам? Все равно придется включать по одному...

ну вот и я к этому пришел..

Но все равно всем спасибо, в любом случае в дальнейшем информация может оказаться полезной

Есть интерфейсы и есть интерфейсы.
Если сеть содержит все семь уровней, то все становится похоже на IP/MAC/DHCP.
Если все семь уровней втоптали в два-три, то конечно, зачем это все?

Какой сервис (имея все 7 уровней) предлагаете пользовать для назначения MAC адреса?
Задача автора как раз в этом.

Пусть MAC будет уникальным. А назначать аля-IP методами аля-DHCP или аля-ZeroConf. Соответствующие схемы взаимодействия уровней в RFC обсосаны, можно изучать и делать свое.

Нет-нет, мне нужно иметь уникальный ID девайса. Но действительно, после получения его хостом, будет невозможно понять - а какому именно слейву был назначен идентификатор, а это необходимо, т.к. в самом слейве изначально никакого уникального MAC и чего-то подобного нет.
Поэтому, т.к. этот самый MAC все равно прописывать придется, то какая разница? Пропишу сразу руками и ID, или только ID, а хост уже будет знать что это такое

Тут произошла подмена понятий, возможно по моей вине.
Да, в том, что предлагали Вы первоначально, действительно мало смысла.
В то же время, имея уникальный номер устройства (MAC-адрес) можно организовать раздачу сетевых адресов, и это имеет смысл для высокоуровневых протоколов, раз уж это придумали для TCP/IP, значит это кому-то нужно ?