Интерфейс для маленькой "сети", где несколько 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

[ILYAUL]

признаком скорости

Что Вы под этим понимаете

[defunct]

Что Вы под этим понимаете

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

Код

for( speed = LOW_SPEED; speed <= HIGH_SPEED; speed++)
{
       uart_SetBaudRate( speed );

       for( addr = 1; addr <= MAX_ADDR; addr++)
       {
             query_slave( addr, ....);
       }
}

У меня софтовый CAN до 500 килобод живёт на ATmega48 за $1. Для выключателя/лампочки ничего больше и не надо. Неужели $2 ($1 контроллер + $1 драйвер) дорого?

Это решение ненадежно, настолько же насколько и недорого. Софтовая реализация довольно сложного интерфейса это не просто потенциальный баг, а мина замедленного действия. Сочетание той же m48 с аппартным UART'ом и rs485 драйвером, будет куда проще и надежней, заметьте - по той же цене.

Построить надежное устройство - само по себе задача не тривиальная. А написать для него надежный софт - задача просто сложная, занимает много времени

Эта задача все равно много проще multimaster системы. Суммарно если сравнить две системы:
- систему 1 мастер + тривиальные слейвы,
- систему мультимастер где много устройств средней сложности.

Первая будет проще.

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

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

[galjoen]

Это решение ненадежно, настолько же насколько и недорого. Софтовая реализация довольно сложного интерфейса это не просто потенциальный баг, а мина замедленного действия.

Чем же это железная реализация надёжнее софтовой? На мой взгляд, как раз наоборот. И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле.
А для гарантии, при использовании с софтового CAN-а, можно использовать драйвер с ограничением времени доминанты и всё. Поэтому я и написал про его стоимость $1 .

[defunct]

И периодически вылавливаемые в CAN-овском железе баги это подтверждают. И не известно есть они там или нет. А в софтовой можно все ошибки выгрести - запись логов при работе достаточно сделать. Кстати, для софтового CAN-а можно и ATtiny2313 использовать - ещё дешевле.

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

[galjoen]

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

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