Интерфейс для маленькой "сети", где несколько Master'ов Опции

[C.S.]

Всем здравствуйте! Лето началось, снова я со скуки берусь за хобби. С диммером справился, пора для него разработать интерфейс
Приношу свои извинения, но кроме соединений типа точка-точка (RS-232) я ничего не знаю; тема почти вольная и начнётся с тупых вопросов.
Я хочу получить игрушку в виде "умного дома" в виде нескольких модулей. Вижу я себе это вот как:
1. Есть n-ое количество модулей, которые вешаются на какую-то общую шину. Модуль - это например диммер, реле или датчики (ну вполне напоминает промышленные контроллеры, да).
2. Есть "панель управления" - девайс с кнопочками и дисплейчиком. Через меню мы можем управлять/считывать состояние навешанных на шину модулей.
3. Есть комп, который тоже подключён к этой шине (двоякое управление: автономное через (2) и через комп). Фактически комп выступает в роли такой же панели управления.

Наваял схематически примерный вид сети:


Ньюансы:
а) Панелей управления (2) будет несколько: хочу сделать управление освещением, соответственно заменяю ими выключатели.
б) Модули будут конечно адресоваться. Автодетект адресов модулей не нужен - могу и так вписать их в кофигурацию.
в) НЕ понимаю, как сделать несколько Мастеров. Было два варианта:
в.1.) Инфа о статусе хранится в Модулях. У Мастеров и Модулей есть уникальные адреса. Раз в nn времени каждый Мастер захватывает канал связи и поочерёдно опрашивает модули на тему, чего у них включено и чего выключено.
в.2.) Есть какой-то служебный узел сети. Любой модуль читает из него то, что он должен выполнить, а любой Мастер пишет туда что надо выполнить.
г) Всё это - полуигрушеченое и хобби для меня самого (типа кулибинство в квартире и поковыряться). На чём делать Мастера - не решил, для Модулей есть запас мелких ATMega8 в DIP'е. Есть ещё ATMega32.

Фактически, работу всего этого я вижу так, что на одной панели включили свет. Потом дошли до компа - там его погасили (естественно состояние отображается). Или погасили с другого места управления. Модулю должны сыпаться почти низкоуровневые команды типа ВКЛВыход1 - ОК. ЯркостьВыход2=25% - ОК. А на всех панелях - правильное состояние системы.

Господа Гуру - подскажите пожалуйста, чего подойдёт под мои задачи из интерфейсов (фактически натолкните на какие-то существующие ссылками, чтобы я мог выбрать и реализовать)? Связь всего этого будет ну по квартире - положим метров 30-50 максимум.
В принципе, как самое топорное решение, я могу и LAN прикрутить, если это решит мои проблемы (устройства, адреса). НО проблемы, кажется, логические - как делают, когда управление может быть из нескольих мест? Как делают грамотно? Мне видится, что скорость у этого всего была бы мелкая, кроме команд установки яркости: их может сыпаться много из-за плавного гашения-зажигания... Ну и если правда это можно реализовать на LAN - то тогда я хочу LAN

P.S. Мои хотелки на ТЗ не тянут, описал совсем на пальцах.
P.S.2. Тема - немного флудастая. Подниму ещё раз, когда реально сяду за дела. Пока хочу спроектировать саму "сеть".

UPD: Глянул в раздел интерфейсы. Появились дополнительные комменты:
1. Я старой выучки и хочу проводной интерфейс.
2. Если это будет модуль или чип типа сконфигурировал / послал/принял данные по прерыванию - вообще замечательно!

Сообщение отредактировал C.S. - Jun 27 2010, 16:34

[aaarrr]

Из стандартных протоколов - MODBUS-RTU (правда не мультимастерный, а Вам оно (мультимастр) точно надо?)

Рекомендую посмотреть в сторону...

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

[Прохожий]

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

Не вижу никакой корявости.
Все достаточно логично и стройно.
Намного лучше того же PROFIBUS или PROFINET или всех этих канообразных CANOPEN и DeviceNet или всеми здесь любимого HART.
Я уже не говорю про Ethernet с его свалкой из протоколов на всех уровнях OSI.
А что касается 40 лет, так это лишь подтверждение применяемости, основанной на чем, спрашивается?
Тем более, дата на документе не 40-летней давности.
Да и документ не самый свежий.

[aaarrr]

Не вижу никакой корявости.
Все достаточно логично и стройно.

Никакой корявости, говорите?
А пляшущий эндианизм в Modbus-RTU?
А избыточные заголовки, с указанием длины в регистрах (которые всегда 2 байта) и байтах?

А что касается 40 лет, так это лишь подтверждение применяемости, основанной на чем, спрашивается?

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

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

ИМХО, это один из тех предметов, к которым очень подходит определение "забыли похоронить".

[Прохожий]

Никакой корявости, говорите?
А пляшущий эндианизм в Modbus-RTU?

Это вовсе не сложности.
Задачка для одной команды современного МК.
Кстати, почему эндианизм вместо чередования байт?

А избыточные заголовки, с указанием длины в регистрах (которые всегда 2 байта) и байтах?

А в стандарте расписано для чего.

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

[aaarrr]

Кстати, почему эндианизм вместо чередования байт?

Тогда уж порядок, а не чередование.

А в стандарте расписано для чего.

Для чего предназначены поля - расписано. А вот почему информация бездумно дублируется - нет.

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

И снова приходим к закономерному выводу: от протокола нам на самом деле нужна простота, открытость и "демократичность". То есть как таковой стандарт ценности не имеет, нужен "скелет", на базе которого будет построено что-то свое.

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

[Прохожий]

Для чего предназначены поля - расписано. А вот почему информация бездумно дублируется - нет.

[attachment=45432:0_10.PNG]

И снова приходим к закономерному выводу: от протокола нам на самом деле нужна простота, открытость и "демократичность". То есть как таковой стандарт ценности не имеет, нужен "скелет", на базе которого будет построено что-то свое.

Мне, как лицу, эксплуатирующему огромное количество электронных "покидух" в сфере промавтоматики хотелось бы, чтобы все придерживались стандартов как можно ближе.
К примеру, ПЛК "ОВЕН" не прошел проверку, поскольку его разработчики имели свое, отличное от стандарта представление именно о MODBUS/RTU.

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

Ой, неправда Ваша.
К примеру, частотные преобразователи CIMR-V7 от OMRON или VFD от DELTA вовсю используют именно MODBUS.
Да и вообще, в области частотных инверторов MODBUS/RTU де-факто стандарт.
Для PLC бюджетного ряда тоже. MODBUS/RTU включен в перечень поддержки удаленными модулями таких фирм, как Beckhoff и Wago Systems.
Что-то не похоже на умирающего.
А вот заумный PROFIBUS, похоже, скоро окончательно сдохнет. От него даже SIEMENS уходит, правда, в еще более заумные дебри в виде PROFINET.
Устройства на CAN-оподобных шинах, типа DeviceNet применяются крайне редко в виду плохого сочетания цена/скорость.
HART практически не применяется. Приборы КИПиА просто цепляются на токовую петлю. Каждый на свою.

[aaarrr]

[attachment=45432:0_10.PNG]

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

Мне, как лицу, эксплуатирующему огромное количество электронных "покидух" в сфере промавтоматики хотелось бы, чтобы все придерживались стандартов как можно ближе.

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

[Прохожий]

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

Не хуже, чем любая другая заумность из известных протоколов. По Вашему принудительная адресация поверх CAN в DeviceNet лучше?

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

Поймите правильно.
Не надо лучше.
Надо, чтобы всегда одинаково.
Поэтому - никаких "современных" стандартов.
И чем их меньше, тем лучше.
А свой протокол - даже не смешно.
Это будет никому ненужный мартышкин труд.

[aaarrr]

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

Если бы заумность, а то ведь глупость откровенная.

Поймите правильно.
Не надо лучше.
Надо, чтобы всегда одинаково.

Так оно не получается одинаково, что признают использующие Modbus - свои типы данных, свои команды и т.д.

А свой протокол - даже не смешно.
Это будет никому ненужный мартышкин труд.

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

[Прохожий]

Если бы заумность, а то ведь глупость откровенная.

А как Вам "засерание" шины совершенно излишней информацией, якобы увеличивающей целостность данных в том же Ethernet или Profibus?
Тоже очевидная глупость...
А про старые отработанные годами протоколы я бы осторожнее...
Любую несуразность в них надо воспринимать практически, как устав РККА или ПУЭ.
Наличие такой "глупости" говорит только о том, что кто-то здесь сломал себе шею...

Так оно не получается одинаково, что признают использующие Modbus - свои типы данных, свои команды и т.д.

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

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

Смысла делать свое даже в данном случае не вижу.
Лучше сделать то, что потом пригодится.
Не нравится Modbus - делайте что-то иное - DeviceNet или CanOpen, к примеру.
Потом хоть наработки останутся...
А в промавтоматике, где находится основная часть денег, которые можно заработать, свой протокол - признак элементарного дилетантизма.
Иными словами. В эту сферу со своими протоколами лучше вообще не соваться... Засмеют.

Сравните с:
А в 485-м интерфейсе багов нет и логов никаких не надо! И ловить нечего...

Не скажите.
Знаете, почему уважающие себя люди никогда не будут использовать нашу электронику в ответственных местах?
Потому, что в нашем воплощении RS485 логи, таки, нужны и ловить есть чего.
Даже простейший Modbus сообразно со стандартом сделать не можем...

[defunct]

Не скажите.
Знаете, почему уважающие себя люди никогда не будут использовать нашу электронику в ответственных местах?
Потому, что в нашем воплощении RS485 логи, таки, нужны и ловить есть чего.
Даже простейший Modbus сообразно со стандартом сделать не можем...

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

Так багов там немеряно. Вообще удивительно - как всё работает.

Потому что есть КЗ (код защиты). А сколько там пакетов теряется - то уже совсем не важно. Уважающий себя мастер в случае ответственного объекта всегда спросит дважды, и при несовпадении двух ответов спросит еще разок и так до тех пор пока не будет полного консенсуса между мастером и слейвом.

[galjoen]

485-й интерфейс "простой как ээээ Мир" © т.е. если и нужны логи, то это будут логи протокола, а не интерфейса. А там ведь товарищ логирует и ловит причуды интерфейса,

Не совсем понял, что тут называется интерфейсом, а что протоколом. Похоже под интерфейсом понимается физический уровень, т.е. драйверы. Если так, то у CAN (стандартного, 2-х проводного) драйвер проще и лучше, чем у 485. По крайней мере, там не может возникнуть случая, когда один драйвер тянет шину в 1, а другой в 0, и те девайсы, что ближе к первому, воспримут состояние на шине как 1, а ко второму - 0. Да и послушать шину чтобы сравнить, что там реально происходит с тем, что он отправил, девайс не может. Т.е. может, конечно, но толку нет - всё равно совпадёт. Да и проводов к драйверу меньше - при гальваноразвязке актуально.

А сколько там пакетов теряется - то уже совсем не важно.

Даже если теряется 100% пакетов?

[defunct]

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

Интерфейс включает также и формирование/декодирование фреймов которые по нему гуляют, определение ошибочных фреймов. CAN'овкие фреймы (те что Вы программно формируете) сложнее тех что ходят по 485-му. Фрейм в 485-м - включает Start ... данные ... Parity.. Stop, формируется/и декодируется железом UART'а.

[rezident]

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

Не совсем так. Имеет смысл говорить не про интерфейсы и протоколы, а про уровни согласно сетевой модели OSI. Тогда RS485 это физический уровень, а CAN это уже канальный уровень. Бо RS485 на аппаратном уровне не поддерживает детектирование коллизий и контроль целостности данных.

[defunct]

Имеет смысл говорить не про интерфейсы и протоколы, а про уровни согласно сетевой модели OSI. Тогда RS485 это физический уровень, а CAN это уже канальный уровень. Бо RS485 на аппаратном уровне не поддерживает детектирование коллизий и контроль целостности данных.

Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК. Разница между 485-м/CAN'ом/Ethernet'ом и т.п. только в размере фрейма и способе обнаружения ошибок. Канальный уровень заканчивается на фреймах. Следовательно 485-й интерфейс, как и CAN, включает и физику сигналов и канальный уровень.

Чтобы пресеч возможные дебаты по этому поводу, вот для Вас цитата взятая по Вашей же ссылке:

Канальный уровень (англ. Data Link layer)
Основная статья: Канальный уровень
Этот уровень предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные он упаковывает во фреймы, проверяет на целостность, если нужно, исправляет ошибки (посылает повторный запрос поврежденного кадра) и отправляет на сетевой уровень.

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

[rezident]

Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК.

Ну раз у вас такая аргументация, то давайте уж тогда основы рассматривать. Если вас это не очень затруднит, то найдите, пожалуйста, в стандарте TIA/EIA-485-A, который специфицирует интерфейс RS485, упоминание об UART, микроконтроллерах и фреймах или вообще что-либо отличное от электрических и частотных характеристик этого интерфейса.

[defunct]

Ну раз у вас такая аргументация, то давайте уж тогда основы рассматривать. Если вас это не очень затруднит, то найдите, пожалуйста, в стандарте TIA/EIA-485-A, который специфицирует интерфейс RS485, упоминание об UART, микроконтроллерах и фреймах или вообще что-либо отличное от электрических и частотных характеристик этого интерфейса.

Приведу полное название документа на который вы ссылаетесь - "Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems", чтобы было видно, что он описывает ну.. явно НЕ интерфейс. Иначе слово interface фигурировало бы в названии документа. Заодно можно на дату выхода стандарта посмотреть, - тогда и МК с UART'ом еще не существовали в природе, а если и был то один.

Спаведливости ради соглашусь, что по физике 485-го можно гнать что угодно, например HDLC фреймы.

Но реалии таковы, что дефакто RS-232/485 в отрыве от UART'а сейчас НИКТО мало кто рассматривает.

[=AK=]

Приведу полное название документа на который вы ссылаетесь - "Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems", чтобы было видно, что он описывает ну.. явно НЕ интерфейс.

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

Бесспорным фактом остается то, что RS485 специфицирован стандартом TIA/EIA-485-A (а до этого - стандартом RS-485), и что в этой спецификации нет и намека на свойства и характеристики, которые вы приписываете какому-то мифическому "интерфейсу RS485".

[defunct]

Бесспорным фактом остается то, что RS485 специфицирован стандартом TIA/EIA-485-A (а до этого - стандартом RS-485), и что в этой спецификации нет и намека на свойства и характеристики, которые вы приписываете какому-то мифическому "интерфейсу RS485".

Имею на то все основания - все кому не лень без задней мысли подключают драйвер RS485 к UART'овому RXD/TXD, RE/DE цепляют на UART'овый RTS. Производители МК для UART'а даже режим специальный придумали и так и назвали (UART MODE RS485). Ковертеры RS232<>RS485 впринципе не могут работать с данными отличными от UART фреймов, а здесь почему-то мы отвлеченно рассуждаем о том, что RS485 это строго физика. Нет не строго физика. И в контексте конкретно этой темы все кто предлагал пользовать RS485 - подразумевали эту связку UART<>RS485, как само собой разумеющееся явление. Связка UART<>RS485 PHY образует 485-й интерфейс, без этой связки RS485 - это непригодная к использованию фантазия расстояний, частот, напряжений, терминаторов и прочего хлама, такая же как Ethernet PHY в чистом виде.

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

Именно совокупность, т.е. не только как связать снаружи много 485-х драйверов (что и описывается в документе), но и как связать внутри, вчастности как МК подключить к RS485-й сети. Если вернуться к вышеупомянутой модели ОЗИ - интерфейс - это связь между уровнями (например интерфейс связи сетевого уровня с канальным), т.е. подразумевает стыковку с двух сторон, а протокол - связь множества элементов на одном уровне (например протокол сетевого уровня). Поэтому см. выше.

[galjoen]

Что то мы залезли в теорию, причём выясняется как теоретически правильно называется связка UART+драйвер RS485 (UART+485). Думаю, для практиков, а начинающие здесь это практики, это не представляет интереса. Поэтому предлагаю обсудить связку UART+драйвер CAN как базу для создания маленькой сети. Это будет гораздо интереснее. А уж как это будет называться - не так важно. Пусть будет UART+11898, если ни у кого нет возражений. На мой взгляд, именно такая связка наиболее оптимальна для создания маленькой сети т.к.её стоимость незначительно выше (драйвера одинаковой "брендовости" дороже на $0.3) чем UART+485, а по свойствам (мультимастерность, приоритеты, эхо-контроль и т.д.) она приближается к CAN. Я так вообще не могу найти ни одного недостатка у UART+11898 по сравнению с UART+485. Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало...

[MrYuran]

Если в том же модбасе заменить все драйвера RS485 на CAN-овские всё продолжит работать как ни в чём не бывало...

А как насчёт длины линии в 1..2 км?