Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: адресация устройств на шине RS-485 для AVR
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему
Dmitry Sadikov
Здравствуйте.
Есть у меня несколько atmega128, обьединённых через RS-485 интерфейс, построенный на UARTе. Одна из них ведущая, все остальные - ведомые.
Подскажите пожалуйста, какие есть методы распределения адресов ведомых устройств на такой шине?
В данный момент адреса каждой из ведомых atmegа128 задаются джамперами на плате, подключенными к порту.
VladimirYU
Цитата(Dmitry Sadikov @ Jan 5 2009, 13:40) *
Здравствуйте.
Есть у меня несколько atmega128, обьединённых через RS-485 интерфейс, построенный на UARTе. Одна из них ведущая, все остальные - ведомые.
Подскажите пожалуйста, какие есть методы распределения адресов ведомых устройств на такой шине?
В данный момент адреса каждой из ведомых atmegа128 задаются джамперами на плате, подключенными к порту.

А что не устраивает а вашем способе, или чего хотелось бы?
Dmitry Sadikov
хотелось бы в идеале, чтобы адреса распределял ведущий контроллер. Хотя я не представляю, как это возможно.
VladimirYU
Цитата(Dmitry Sadikov @ Jan 5 2009, 13:54) *
хотелось бы в идеале, чтобы адреса распределял ведущий контроллер. Хотя я не представляю, как это возможно.

Это возможно при поочередном подключению к сети ведомых устройств, по умолчанию настроенных на default-адрес, например 127. Мастер опрашивает этот адрес, если есть ответ, то назначает специальной инструкцией устройству адрес, которого в сети еще нет (например по возрастанию, запоминая первый свободный адрес в своем ЕЕПРОМ). Устройство принимает этот адрес и запоминает его также в ЕЕПРОМ и далее откликается только на него. Способ не идеальный но на практике используется.
Dmitry Sadikov
Спасибо. воспользуюсь этим способом.
ну а при одновременном подключении нескольких устройств с одинаковым начальным адресом, я полагаю, распределить уникальные адреса не получиться?
VladimirYU
Цитата(Dmitry Sadikov @ Jan 5 2009, 14:12) *
Спасибо. воспользуюсь этим способом.
ну а при одновременном подключении нескольких устройств с одинаковым начальным адресом, я полагаю, распределить уникальные адреса не получиться?

В этом случае на команду опроса от мастера одновременно откликнутся несколько устройств, и будут на передачу включены несколько драйверов RS485. В лучшем случае мастер просто ничего не поймет, в худшем кто-то из драйверов может и выйти из строя, зависит от реализации.
ukpyr
Цитата
ну а при одновременном подключении нескольких устройств с одинаковым начальным адресом, я полагаю, распределить уникальные адреса не получиться?
ну можно как-нибудь извратиться, например использовать псевдослучайное время ответа узлов и выделенный начальный адрес (например 0). но это уже будет не совсем Modbus, при работе в одной сети с другими устройствами могут возникнуть проблемы.
_Pasha
Можно зарезервировать какую-л команду для присвоения адреса, а девайсы снабжать длинным уникальным идентификатором, который должен быть виден юзеру (типа наклейка). Но появляется другая проблема - в память ведущего прописывать идентификаторы...

Лично я свожу количество джамперов к минимуму - 2/3/4 штуки. Те девайсы, что делаю под rs-485, имеют фиксированные адресные пространства по их функционалу (например, измерители температуры с адресами 0x30.. 0x3F, приводы 0x28..0x2f). Вот такая песня. Конечно, если конфликтует с чем-то, адреса подвигаются.
Dmitry Sadikov
Цитата(ukpyr @ Jan 5 2009, 15:01) *
ну можно как-нибудь извратиться, например использовать псевдослучайное время ответа узлов и выделенный начальный адрес (например 0). но это уже будет не совсем Modbus, при работе в одной сети с другими устройствами могут возникнуть проблемы.


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

Цитата(_Pasha @ Jan 5 2009, 16:04) *
Можно зарезервировать какую-л команду для присвоения адреса, а девайсы снабжать длинным уникальным идентификатором, который должен быть виден юзеру (типа наклейка). Но появляется другая проблема - в память ведущего прописывать идентификаторы...

Лично я свожу количество джамперов к минимуму - 2/3/4 штуки. Те девайсы, что делаю под rs-485, имеют фиксированные адресные пространства по их функционалу (например, измерители температуры с адресами 0x30.. 0x3F, приводы 0x28..0x2f). Вот такая песня. Конечно, если конфликтует с чем-то, адреса подвигаются.



да. как ни крути, а с джамперами всё значительно проще. у меня их 2 штуки для задания адреса на каждом устройстве. хватает.
вот только при возможном выходе из строя одного из устройств придётся выставльть джамперы в строгом соответствии со сгоревшим девайсом, а делать это возможно придётся посторонним людям. Поэтому и хотелось сделать распределение адресов автоматически.
rx3apf
Цитата(Dmitry Sadikov @ Jan 5 2009, 16:13) *
я тоже думал использовать временные задержки при ответах от ведомых устройств, но это уж совсем как то не очень выглядит. да и при возникновении сбоев кавардак в сети может начяться

Однако, если и в самом деле хочется уйти от первоначального жесткого распределения адресов вручную, думаю, что иного способа не найти. Устройства надо как-то "сериализовать" (т.е. присвоить им уникальные идентификаторы на этапе программирования), и на этапе поиска устройств (отдельная широковещательная команда) они должны отдавать идентификатор хосту. И уж он будет назначать адрес по идентификатору. Я такой метод использовал в беспроводной сети (после запроса ответы в 256 тайм-слотах, главное - использовать генератор случайных чисел с хорошим распределением). При 256 тайм-слотах до полутысячи устройств "разруливаются" за разумное число попыток, предел - порядка 2000 устройств. Для одной ветки RS-485 256 устройств все равно разумный максимум, да и адрес обычно однобайтовый... Правда, у меня скорости были довольно большие и общее время ответа составляло полсекунды. А, скажем, для 9600 это будет заметно дольше. Впрочем, если такой поиск надо проводить однократно или изредка, то почему бы и нет ?
_Pasha
Цитата(rx3apf @ Jan 5 2009, 17:24) *
Для одной ветки RS-485 256 устройств все равно разумный максимум, да и адрес обычно однобайтовый...

Почему 256? 31+адрес общего вызова !!! Так что может быть рандомизация еще оптимистичнее.
smalcom
проблема еще в том, что для 485-го, как указывали выше, коллизия - это плохо. Т.е. помимо написаного аля езернет, надо еще следить какие микросхемы используешь тк вдруг у купленой нет защиты от КЗ. я использовал два варианта для таких вещей
1. дип-свитч. 8-переключателей. из минусов это громоздкость. из плюсов у пользователей(если их можно так назвать) при замене проблем не возникает, тк все просто - поставь "клацалки" на новом так же как на старом.
2. служебный адрес(0x01) и удаленая загрузка конфигурации с писюка. те только что прошитый контроллер имеет адрес 1, а потом мы ему даем любой кроме 1.из минусов - пользователю тяжелее осознать, что все просто. вводить в сеть такие контроллеры надо по одному. надо писать программу и для компа. из плюсов: сидишь на стуле и просто клацаешь. нет съедающего площадь дип-свитча.

зы. а сейчас я безпроводку ипсользую... в ней при коллизии ничего не сгорит
_Pasha
Цитата(Dmitry Sadikov @ Jan 5 2009, 17:17) *
а делать это возможно придётся посторонним людям. Поэтому и хотелось сделать распределение адресов автоматически.

Тогда, пусть давят кнопку "регистрация в сети". Как только девайс сконфигурирован, он из режима вышел. Потом - к следующему... При собсно конфигурации используется некий широковещательный адрес. Слушают все, но отвечает только тот, у кого кнопкодавы включили режим.
Dmitry Sadikov
Цитата(rx3apf @ Jan 5 2009, 16:24) *
Правда, у меня скорости были довольно большие и общее время ответа составляло полсекунды. А, скажем, для 9600 это будет заметно дольше. Впрочем, если такой поиск надо проводить однократно или изредка, то почему бы и нет ?
ну скорость у меня 115200. да и подчинённых устройств в сети всего 4. так что сделать широковещательный запрос и дождаться жёстко разнесённых по времени ответов от них по очереди будет не сложно. но в каждом из девайсов изначально должен быть зашит свой уникальный идентификатор, который он по этой команде отсылает ведущему контроллеру, если я правильно понял? а потом на основании их уже распределяются адреса. может тогда сразу прошивать в каждый девайс уникальный адрес на шине?
Цитата(smalcom @ Jan 5 2009, 16:50) *
1. дип-свитч. 8-переключателей. из минусов это громоздкость. из плюсов у пользователей(если их можно так назвать) при замене проблем не возникает, тк все просто - поставь "клацалки" на новом так же как на старом.
ну вариант с джамперами, как я сейчас и использую, почти аналогичен свитчу. только и делов что поставить два джампера в соответствии с заменяемым девайсом. но как показывает практика, монтажникам ничего не стоит запутаться в 4 платах и выставить одинаковые адреса((((
Цитата(_Pasha @ Jan 5 2009, 16:54) *
Тогда, пусть давят кнопку "регистрация в сети". Как только девайс сконфигурирован, он из режима вышел. Потом - к следующему... При собсно конфигурации используется некий широковещательный адрес. Слушают все, но отвечает только тот, у кого кнопкодавы включили режим.
если доведётся мне ещё раз править плату, то можно и кнопку воткнуть. зато уж не ошибёшся.

От модератора.
Из сообщения удалено излишнее цитирование. Вы нарушаете п.3.4 Правил форума! Учитесь пользоваться редактором сообщений!
ukpyr
Цитата
но в каждом из девайсов изначально должен быть зашит свой уникальный идентификатор, который он по этой команде отсылает ведущему контроллеру, если я правильно понял? а потом на основании их уже распределяются адреса. может тогда сразу прошивать в каждый девайс уникальный адрес на шине?

можно сделать так :
в каждом устройстве крутится генератор случ.чисел.
мастер отправляет широковещательный запрос. в момент приема запроса в слейвах фиксируется текущее случ.число, через время, пропорциональное своим числам слейвы отправляют мастеру свое число. мастер отправляет устройству, пакет от которого пришел первым, пакет установки адреса. все - одно устройство настроено, например можно на некоторое время отключить реакцию на запрос устройств. далее запросы повторяются до тех пор, пока перестанут приходить ответы от устройтсв.
можно также заложить в каждое устройство уникальный серийный номер, и отправлять его в ответе слейва. так можно исключить ситуацию когда сгенерируются одинаковые числа.
Polaris
Помимо джамперов можно еще привязкой к разъему воспользоваться, мы в следующем устройстве собираемся такое делать, на разъем завести от ведомого устройства два лишних провода, а в самом разъеме кодировать, то есть, соединять два лишних пина с землей или питанием.
VladimirYU
Dmitry Sadikov, природу не обманешь, либо заранее жестко определенная адресация, в Вашем случае, когда всего 4 слэйва и мега128, я бы остановился на ней. Если задача потенциально требует расширения, рекомендую все же ранее предложенный мною способ. Он "ложится" практически под любой пртокол, MODBUS например. Аппаратно на устройстве нужно иметь только один джампер( Set default). Далее устройство прописывается в сети. и на ходу, загорелся светодиод обмена, джампер снимается/устанавливается наладчиком. Даже самый "продвинутый" специалист не запутается.
rx3apf
Цитата(_Pasha @ Jan 5 2009, 16:47) *
Почему 256? 31+адрес общего вызова !!! Так что может быть рандомизация еще оптимистичнее.

Ну, это я с запасом взял. Потому как есть трансиверы с пониженной нагрузкой на линию, позволяющие иметь до 256 устройств.

Цитата(Dmitry Sadikov @ Jan 5 2009, 22:09) *
а потом на основании их уже распределяются адреса. может тогда сразу прошивать в каждый девайс уникальный адрес на шине?

Можно, конечно. Но адрес-то сколькоразрядный ? Если есть уверенность, что в одной системе никогда не окажутся два устройства с одинаковым 8-битным (к примеру) адресом - да, можно и так. Я описывал работу своей системы, где изначально идентификаторы вообще неизвестны, и сколько и где будет устройств - никто не знает. Гарантия лишь в неповторяемости номера...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.