Планирую использование 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, значит это кому-то нужно ?

А если устройства до безобразия однотипные - скажем модемы, и хосту не важно кто есть кто? Хосту важно найти и подключить устройства в общий пул, чтобы потом пользовать первый попавшийся свободный. Для такой задачи энумерация (раздача MAC адресов) не выглядит бессмысленной.

действительно, для однотипных (с точки зрения хоста) девайсов подход в раздаче ID - очень хорошая вещь.

Но у меня немного иная цель - каждый девайс будет жестко закреплен за неким участком и вся статистика привязывается именно к участку...

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

Но тут еще обдумывал это все дело много раз... ведь можно в девайс вкрутить какой-нибудь 1-Wire Dallas с 64-битным ID и пользовать его. Просто лепить на девайс стикер с его номером (ID), пусть в базу хоста вносят и привязывают куда и к чему хотят, а тот будет опрашивать по этому ID

Тогда без сожалений забудьте про энумерацию. Разделите адресное пространство на служебные адреса 0x00 и рабочие адреса - 0x1-0xFF.
Пусть все устройства всегда стартуют в служебном режиме (режим конфигурирования) со служебным адресом и миганием светодиода, или другим способом показывают пользователю, что они в служебном режиме. Пусть сконфигурированные устройства переходят в рабочий режим по заданному таймауту, а несконфигурированные устройства так и остаются в служебном режиме и никогда не переходят в рабочий режим.
Host, управляющий системой, пусть никогда не опрашивает служебные адреса.

Тогда все становится просто. Включаете систему - видите какие девайсы "не в теме", поочереди конфигурируете их специальной программой которая работает со служебным адресом "0x00". Для перекофигурации системы, отлючаете от системы Host, подключаетесь вместо него той же специальной программой и поочереди - передергиваете устройства, которые надо переконфигурировать.
Будет просто и достаточно удобно.

Кстати этот подход позволит Вам в будущем добавить и автоматическую энумерацию. Т.к. известен адрес несконфигурированных устройств.

Не совсем "оно"... Девайс ОБЯЗАН подняться в рабочий режим, естесственно, с подачи хоста. Прописать неизвестный доселе девайс в базу хоста, чтобы внести в базу учета, сможет технарь, но контролировать его на компе все равно будет кто-то с мозгом блондинки. Там ей будет что-то типа нет связи, полный швах, нет ответа целевого девайса и т.д.

Новые девайсы в системе всегда будет ставить квалифицированный дядька, вот я к чему

Ну дык, и чем не подходит описанное выше? Под пользователем там, подразумевался технарь, который настраивает / монтирует систему.
А блондинка пусть работает исключительно с Host'ом, который в свою очередь работает только со сконфигурированными и внесенными в базу устройствами.

вот тут-то как раз затык ИБО

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


кстати, 2 all

кто-нибудь пользовал подобные вещи - MAX3075 ? Как они себя ведут при максимальном количестве трансиверов? На какой скорости при длине кабеля 5-й категории метров 100-150?

Я бы посоветовал применить более адекватные разъемы, пусть и более дорогие.
Ни в коем случае нельзя допускать зависимость всей системы от отдельно взятого усройства.
Но это конечно же дело Ваше.

дык

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

Гм... странный заказчик какой-то ;> Или Вы недостаточно четко обрисовали ему перспективу сидеть с нерабочей системой пока бригада монтажников будет бегать и искать среди 200-т устройств одно неисправное.

Насчет цены:
- RJ45 - грубо 0.2$ но их надо 2 штуки + ответные, итого ~0.5-0.7$ на девайс.
- винтовой 4-х контактный разъем с ответной частью ~0.5$ и нужен только 1 итого ~0.5$ на девайс.
Где же логика?

насчет нерабочей системы на время замены и конфигурации -- это, все-таки, его проблема
что касаемо разъемов - пока бодаемся, типа тут щелк-щелк, а тут вертеть (кстати, без доп платы не решается вопрос отсоединения девайса от сети без разрыва при одной плате с разъемами для 485)

Насчет логики - кризис, за ногу его, все пытаются, по ходу, и для себя скрысить хоть что-то


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

Не думаю что я понял о чем Вы говорите...

Посмотрите в сторону вот таких разъемов:
http://www.radiodetali.com/prioritet/klemmnik2.htm
Сеть прикручена к ответной части клеммника например к этой, которая просто отщелкивается от снимаемого модуля и все. (на модуле запаян например этот разъем). И никакого ущерба для сети, отлючайте хоть все сразу хоть поочереди.. И не надо никаких доп. плат.

спасибо, что-то о таких клеммниках я не подумал.. но тогда вход-выход (D+ с D+ и D- с D-) придется крутить на одну клемму?

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

Если еще актуальна задача, посмотрите в сторону маркерных методов доступа и сделайте мультимастер.
На RS485 мультимастер только так и реализуется, и никакой мороки с горячим подключением. главное правильно продумать протоколы обмена и оборота маркера. Подсказка - FDDI.

Решал схожую задачу на RS-485. Использовал MAX13442E, очень хорошие драйверы, за 7000 уже выпущенных девайсов отказов их не было, только проблемы непропаев (с десяток максимум, но это вопросы к производству). Используется режим горячей замены девайсов, который реализован, благодаря разъёмам и корпусам Phoenix, полазьте у них на сайте.
Насчёт энумерации. Хотел использовать далласовские уникальные идентификаторы, но начальство захотело сэкономить и пришлось эту задачу вынести опять же на производство, где уникальный номер програмируется при настройке модуля и указывается на шильде/панели.
Для облегчения задачи "поднятия" сети (т.е., произвести опрос мастером всех, кто есть на шине) с нашими модулями было решено отказаться от элемента "посмотрел на модуль, вбил в базу мастера" разделил логику основного обмена и режима опроса. При таком подходе прерывается связь АРМа с модулями в момент первого опроса и "поднятия" сети (у нас это допускается, т.к. делается один раз при настройке или добавлении нового модуля, что происходит крайне редко). Использовал технологию широковещательных пакетов и таймеров со случайными числами. Всё работает как часы. Адреса модулей - 4 байта. Сеть из 32 модулей (можно использовать и бОльшее кол-во) с произвольными адресами поднимается за 4-7 секунд. В протоколе "поднятия" сети учитываются всевозможные коллизии. Список адресов модулей хранится в энергонезависимой памяти мастера, что позволяет при отключении питания максимально быстро установить связь со всеми.