Форум РадиоКот

Всем привет. Подскажите как организовать сеть RS-485. Один мастер и много ведомых. У каждого будет зашит свой номер. По этому номеру при инициализации будет присваиваться адрес. Но как считать этот номер. Ведь при выдачи запроса, например, GET_ID все начнут его выдавать будет конфликт. Наверняка существуют какие-то решения

Случайные числа помогут.

Максимальное число устройств в сети известно?
Можно заранее прошить в ведомых некие порядковые номера от 1 до максимума и запрограммировать их так, чтобы они отвечали только после n-го запроса GET-ID, где n - порядковый номер устройства.
Т.е. выдаете в сеть столько запросов GET-ID, сколько м.б. устройств в Вашей сети, после каждого запроса от соотв. устройства приходит (или не приходит ответ...
Пойдет такой вариант?

Максимальное число устройств 6. Данный вариант не подходит потому что устройства будут разные. Т.е. нельзя заранее сказать с какими ID в сети будут устройства. Может все таки пойти на конфликт шины и сделать так как это реализовано в MicroLan. Каким образом я могу применить метод случайных чисел? Предполагается 32битный ID. Должен же быть какой то способ получения номера без конфликта на шине

Как в МикроЛан не получится там открытый сток. Мда

kj писал(а):устройства будут разные.

Должен же быть какой то способ получения номера без конфликта на шине

Случайные числа, случайные паузы.

То есть предлагается каждому номеру сопоставить выдержку через которую он будет отвечать? Если максимальное число 4 млрд то какая это будет выдержка

kj писал(а):То есть предлагается каждому номеру сопоставить выдержку через которую он будет отвечать?

Вы слово СЛУЧАЙНОЕ понимаете ?

Если сопоставить заранее - это будет случайное ?

Хорошо допустим. Скорость при инициализации 9600. Посылка 8-ми байтовая. Для получения номера -- 2 посылки. Все это займет примерно 15 мс. Максимальное время инициализации 5с. Делим 5 на 15мс. Получаем 333. А если устройств будет произведено тысячи, десятки тысяч. Согласитесь довольно высока вероятность что в одной сети совпадут устройства с одинаковой выдержкой, что недопустимо

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

Однако здесь возможен косяк при неодновременном включении устройств.

Вообще, в broadcast сетях (а речь, похоже, именно о такой) используется random acсess time, т.е. после подачи команды устройство отсылает свой ID через случайное время, лежащее в некотором диапазоне. В этой ситуации коллизии возможны, но вероятность их невелика, при возникновении коллизии надо просто повторить опрос.

Можно скрестить эти варианты: после команды устройство возвращает айдишник по прошествии времени, заданного джампером на устройстве.

Вообще, некоторые нюансы все же будут зависить от очередности подачи питания на устройства.

К сожалению оно должно быть программное. Самый оптимальный вариант на корпусе нанести серийный номер и при конфигурации вписать мастеру все серийники. Но к сожалению данный способ не подходит по целому ряду причин. DIP ы тоже не подходят. К сожалению. Вот поэтому и парюсь. Должен же быть какойто способ. Ведь в промышленности RS 485 рулит. Тот же ProfiBus, ModBus. Может кто знает?

Тогда пробуйте по принципу broadcast'a, только все же обработчик коллизий надо продумать будет.

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

kj писал(а):Должен же быть какойто способ.

Уж несколько раз его вам сказал.

Необходимо ПОЛНОСТЬЮ исключить вероятность ошибки при конфигурирровании. Каково это будет если в 1000 случаях кофигурация будет нормальная. а в 1001 случае попадутся 2 устройства с совпадающей выдержкой. Согласитесь диапазон случайных чисел от 0 до 333 не такой уж большой

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

возможно, tych и имел ввиду примерно это, но прямо не сказал по свойственной ему привычке отвечать либо ссылкой на свой сайт (очевидно, скоро появится сайт rs485network123.nаrоd.ru ) либо загадочной фразой...

Дак уж разъясняли что полностью исключить колизеум нельзя. А он максималист похоже.

kj писал(а):Ну конечно сначала broadcast запрос -- получаю все номера, адресую. А потом чтоб скорость была максимальная никаких коллизий возникать не должно. Обратился по адресу -- получил ответ. Все остальные молчат

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

Вот насчет того что ведомый (который в данный момент передает) может слушать линию я не подумал. Очень хорошая идея. Насчет выдержек и всего остального это уже дело техники. Всем спасибо

А объясните мне пожалуйста, как происходит инициализация кучи термометров на шине 1-wire?