Всем здравствуйте! Лето началось, снова я со скуки берусь за хобби. С диммером справился, пора для него разработать интерфейс
Приношу свои извинения, но кроме соединений типа точка-точка (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. Если это будет модуль или чип типа сконфигурировал / послал/принял данные по прерыванию - вообще замечательно!

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

Добавляю. Почитал про DMX-512. Там время обновления информации о каналах около 45 Гц. При этом, выходит, даже вполне себе нормальное плавное включение прожектора происходит (видел лично).
Может, мне имеет смысл тогда принять схему сетки в виде "Сервера"?
Фактически - контроллера с кучей памяти, который висит себе с одним адресом (пусть IP).
Каждому модулю там сопоставлена своя область памяти, типа "регистров". Например, регистр команд, данных и статуса.
Тогда Мастера могут писать/читать в регистры (и обновляют информацию скажем раз в 10-20мс), а Модули - лишь читают и исполняют команду, если она не ноль.

Такую схему реализации вообще делают?
И, если можно, подскажите ещё пожалуйста по модулям типа Wiznet вида RS-232 <> Ethernet. Я понимаю, что они открывают соединение по TCP/IP, и тупо передают/принимают всё, что заслато по RS-232? То-есть, его можно напрямую к USART той же меги сунуть?
Какой сейчас лучше взять для теста? Скатаюсь на днях в Терру например...


А вот здесь моя ламерская логическая затыка: я понимаю под панелью управления с дисплейчиком именно Мастера. Они мне будут заменять выключатели. Значит их будет несколько. Или не так?
Или можно такую панель тоже представить как устройство отображения информации (да фактически I/O) и сделать слэйвом? Тогда Мастер просто будет координировать работу всей системы, и будет один.
Как делают поддержку несокльких органов управления?

C.S., определитесь сначала с "физикой" линии. Много мастеров означает, что возможны коллизии при обращении к общей шине. RS485 не предполагает аппаратное разрешение коллизий. Для этого CAN более подходит. С другой стороны, коллизий можно избежать, если разделить работу мастеров во времени. Вы ведь не будете сразу на каждой панели кнопки нажимать? Панели должны уметь "слушать" линию и принимать те данные, которые непосредственно им нужны. Тогда в каждый конкретный момент времени мастером будет только та панель на которой пользователь кнопки тычет. А остальные будут пассивными приемниками информации, которую передают активному мастеру исполнительные устройства. Для актуализации информации можно разрешить панелям время-от-времени запрашивать состояние всех подчиненных устройств. Но не абы как, а по маркерному кольцу. Маркер передается поочередно от мастера к мастеру, позволяя ему становиться активным. Остальные панели-мастера опять же в пассивном режиме "слушают" линию и принимают данные, которые им могут быть нужны. То бишь я вам предлагаю "маркерное кольцо" для разрешения коллизий.

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

Так как мне хочется поиграться (и чтобы у меня чего-то получилось с первого-второго раза), я думал побаловаться с Wiznet'ами или их аналогами. Мне тяжело с физически уровнем разобраться - я страюсь, фактически, от него сбежать на уровень послал-принял байт(ы).
Мне показалось, что Ethernet проще всего (<> RS-232). До кучи, у меня дома есть мелкая сетка - было бы как раз удобно воткнуться туда.
Вижу я это, например как какой-то блок с адресом ну например 192.168.1.250. И панели и модули тупо стучатся к нему. Одни за "дай команду", другие за "новая команда".
Что с коллизиями - пока не понял сам. Вроде как от WizNet будет тупо идти поток байтов, адресованных ему? Или это уже UDP, а не TCP/IP?

P.S. Чувствую себя идиотом; с другой стороны - чем подробнее я пытаюсь сформулировать ответ, тем больше понимаю для себя.

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

Рекомендую посмотреть в сторону Нажмите для просмотра прикрепленного файла
На WizNet должно, по идее, все получиться.

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

Трафик? А TokenRing вроде тоже по сети гоняет данные постоянно?
Ну и ещё, из понятного мне более-менее - это DMX-512, где мы тупо повторяем последовательность уровней (читай байт), постоянно гоняя её по сети. Так я и дошёл до вышеописанного: что модули читают "откуда-то" информацию, а несколько панелей "туда" её записывают.

Хорошо. Положим, а если, сократив трафик, сделать вот как: есть эта "память", промежуточный "буфер". Панели могут туда писать/читать по принципу - кто первый записал, тот и успел. А сам буфер обслуживает модули: раздаёт им команды и получает ответы? Тогда трафик получается в двух частях: Панели<>Буфер и Буфер<>Конкретный модуль...
Все статусы выполнения команд хранятся в буфере, откуда их тоже может читать любой модуль (ну и они синхронизируются раз в полсекунды например).

З.Ы. Может, я в корне неверно мыслю? Мне б от шаблонов уйти. Ибо я не программировал ничего кроме точка-точка. Два устройства, соединённые кабелем.

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

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

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


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

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

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

Да - абсолютно никакой. Если не поддерживать заложенное туда г..но - регистры с их длиной и пляшущий эндианизм.
Эндианизм будет такой как проц с компилятором поддерживает, а регистры фтопку.
Оставить адрес устройства, функцию "как класс", длину данных, код ошибки и CRC, да и способ передачи пакетов. Вот и все...
Технически формат останется Modbus-RTU.
Практически - протокол подогнаный под конкретные требования - где для каждой функции сделать свой формат данных.


Хотите совместимость с другими вендорами и универсальность в телемеханике, берите линейку:
IEC 60870-5-xxx протоколов (101, 104 и т.п). Более красивого протокола позволяющего универсально (без введения каких-либо своих типов данных и обменов) описать любую систему в мельчайших деталях до каждого отдельно взятого битового сигнальчика и организовать учет с точностью до ms, трудно себе представить.

В системах телемеханики (собсно автор такую и задумал) модбас это нижний уровень и там все делают, что горазды. Формат данных там мало кого волнует.
Между модбасным железом и Хостом ставится железка которая всю модбасоподобную хрень преобразует во что-то более универсальное и объемистое - затем отдает на голову. Голову пусть даже самую совместимую со всем, тоже необходимо приготовить, потому как даже универсальные протоколы, сами по себе не позволят на пульте диспетчера вывести дружелюбную надпись "Рубильник освещения второго подъезда", а предоставят просто какой-то ТУ в базе... (и то далеко не факт что предоставят, обычно все сигналы вручную надо вбивать).

Если хотите просто и мультимастерно, то я рекомендовал бы сделать по стандарту J1708 (автомобильный). Там используются трансиверы RS485, но передача идёт по входу DI. Т.е. 0 на шине устанавливается передатчиком, а 1 за счёт резисторов. Для такого применения даже специальные RS485 трансиверы делаются (не нужен инвертор). Соединение - звезда. Общая длина до 50 метров (вроде). Из-за такого включения скорость всего 9600, но надёжность очень велика. Проверена временем в тяжёлых автомобильных условиях...
Ещё можно вместо RS485 трансиверов, в таком включении, CAN-овские использовать. Собственно CAN из J1708 то и вырос...

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

Эээ, ... я читаю всё, попутно просматриваю википедию, чтобы хоть понять про названия интерфейсов.
Повторю последний вопрос - а если таки оставить одного "мастера"? Только это будет не панель управления, а просто какая-то коробка с функцией "прочитать с панели, выдать на модули". Она и будет рулить сетью.

И ещё раз про LAN - это с физическим уровнем проще или нет, при условии что всё равно эту систему я буду тыкать в домашний код. В домашнюю сеть.

З.Ы. Всё равно хочу демоплатку, возможно, купить в Терре и поиграться с WizNet.

Ну и о протоколе. Если честно - я боюсь гемора на физическом уровне. Потому хочу подобрать чего-то простое. Так как это хобби - ну выкину я несколько тыр на LAN, если оно заработает - получу удовольствие.
Сам протокол, скорее всего будет передачей байт, что-то вида <адресМодуля><команда><параметр(ы)> и подтверждение/код ошибки в ответ.
Вот жду комментариев, и потом приму решение...

Боюсь что в этом случае в нагрузку к удовольствию пойдет еще гора сетевого оборудования. Громоздко слишком для "умного дома".

Простите за настырность, а какое ещё? Ну LAN модули. Витуха и свитч?
Есть, положим, UASRT у микроконтроллеров. И шо с ними делать? Читать про RS-485?.. И поверх вешать свой протокол?
С чего начать-то? Начать хочется... Физический интерфейс?

Свитчам нужны еще источники питания, получите в результате пионэрнет с ворохом проводов в отдельно взятой квартире - а оно надо?


Почитать про RS-485 в любом случае полезно. Заодно рекомендую почитать про CAN - в вашем случае он вполне подойдет.

Себе дома сделал на CAN. Контроллер сам по себе: управляет выходами, по информации со входов и другим признакам. Однако, есть возможность "кинуть в сеть" уникальный идентификатор события и принять событие из сети. Возможно передавать параметры в теле события.

По CAN прошивается логика, устанавливается время и т.п., а также гоняется аудио-трафик с нескольких переговорных блоков. Есть преобразователь CAN в Ethernet (UDP), для "общения по сеточке" с буком и внешним миром.

Скорость делал, вроде, 500 килобит, проверял на катушке CORE4, метров на 100 работает устойчиво (правда терминаторы подбирал щепетильно с осциллографом, но на мегабите).

Идентификаторы в контроллеры зашиваю железные. Раз в секунду все контроллеры грят "я жыф".

Сегодня в моде AIR
Проводки остались в прошлом веке.
Радиомодуль простенький стоит от 25р
Есть готовые интегрёные решения, типа CC430 у TI, нанонет (по-моему) у мелкочипа и у атмела тоже что-то завалялось.


А оно надо?
Пусть говорят, когда их спрашивают. Типа:
- 12-й, ответь 3-му...
-12-й на связи!

Радио не могу назвать надежным и безопасным.

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

Более того - логика в контроллерах сделана на графах. Графы работают параллельно и независимо. Даже при обновлении логики (расширение функционала) контроллер работает непрерывно по старым графам, мгновенно переключаясь на новые после обновления.

Я проектировал распределенную систему...

+ кста, насчет проводков: а питание?

Тшшш, ребят! Я только-только подбираюсь к теме, и вообще пока не ориентируюсь.

Почитал про RS-485 и DMX-512. Я правильно понимаю, что фактически 485й, это как бы паралельное включение всех приёмников и передатчиков? Ну то-есть, если я передаю - все принимают. Кто-то передаёт - все тоже принимают (в том числе и я). А уж чего с принятым делать - это задачи протокола?

И ещё вот какой вопрос: видел, что RS-485 можно гнать по двум витым парам: одна чисто для передачи, другая чисто для приёма.
Для начинающих проще, или нет с двумя витыми связываться? По одной тупо отправлять команды, по другой - получать от них ответ?

А как насчет LIN?

А почему не CAN?! Если нужно гонять данные до 8 байт, то самое простое решение (или нет?).
Мультимастер, неразрушающий арбитраж, приоритеты, аппаратный контроль целостности, настройка момента выборки, подстройка скорости, счетчики ошибок с автоотключением от шины...
Что касается витой пары, то дифференциальная пара, высокая скорость, не дорого и понятно.
Кодить тоже приятно и не сложно. По сути реализовать буфер приемника сообщений и буфер передатчика сообщений. Не сложно делать преобразователи CAN что в RS232, что в Ethernet.

Где минусы?! У меня восемь месяцев - полет нормальный; верните на грешную землю)

Эээ... так я же всех тут вопросами потом достану %)
LIN, вроде не совсем скоростной? Мой критерий скорости - чтобы было не хуже DMX-512 (примерно 10-20 мс на одну команду), так как я маньячу по управлению освещением. RS-485 всё равно основа основ?
2adnega А вот у меня есть штук 5 АТМег 8ых. Я ни одного примера ещё не видал - у меня получится CAN сваять так, чтобы не расстроиться сразу и не бросить? Я хотел начать с простых байт туда-сюда...

5 mega8 по CAN связать, не то чтобы не получится... проще сделать на контроллере где есть аппаратный CAN.
В avr-семействе есть такие, но я их не пробовал. Может, лучше махнуть сразу на C-M3?

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

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

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

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


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


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

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

Нажмите для просмотра прикрепленного файла

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

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

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


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

Есть несколько вариантов организации сети

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

2. Peer-to-peer.
Это усовершенствованный вариант мастер-слэйв. Мастер (теперь он называется координатор) опрашивает узлы, не хочет ли кто-нибудь "поболтать". Тому узлу, который изъявил желание пообщаться, мастер отдает сеть "во временное владение". Узел быстренько рассылает свое сообщение всем узлам, заинтересованным в его получении, по списку. По сравнению с п.1 надежность этого варианта можно резко повысить, если роль мастера (координатора) сможет брать на себя любой узел. Тогда, если текущий координатор помрет, остальные узлы, после короткого периода "неразберихи и разборок", решают, кто будет новым координатором. Тем не менее, этот вариант такой же медленный, как п.1.

3. Произвольный доступ - CSMA
Усовершенствование варианта п.2, координатора теперь вообще нет. Тот узел, которому надо что-то сказать, просто захватывает интерфейс и говорит. В случае, когда два узла хотят что-то сказать одновременно, между ними происходит "разборка" по одному из вариантов:
3а. CSMA/CD - произвольный доступ с обнаружением столкновений. Столкновение обнаруживается, например, на базе того факта, что на сообщение не приходит подтверждение о приеме.
3б. CSMA/CA - произвольный доступ с избеганием столкновений. Это изящно делается, например, на базе передатчиков с открытым коллектором. При передаче узел все время "слушает" шину. Если он сам передает '1', а на шине виден '0', значит, в это время кто-то еще передает, и узел, передававший '1' втихую отваливает, чтобы не мешать "более сильному" узлу, который передает '0'.
3в. Тупой повтор, несколько раз через псевдослучайные промежутки времени. Очень вероятно, что хоть одно сообщение "прорвется", ведь столкновения случаются редко.

4. Производитель-потребитель.
Вместо того, чтобы передавать одну и ту же инфу от источника всем приемникам, гораздо выгоднее настроить приемники так, чтобы они сами вылавливали интересующие их сообщения из общего трафика. Тогда источник может передать данные всего один раз. Однако - как убедиться, что сообщение дошло до всех? Для этого те, кто "не расслышал", посылают "негативное подтверждение", мол, "повторите, не слышу". Молчание - знак согласия.

Самые продвинутые используют 3б и 4. Это CAN, Clipsal C-Bus, и др.

aaarrr, MODBUS вы, очевидно, не любите. А что порекомендуете вместо него?

Есть еще варианты комбинировать приведенные 4 варианта.
Для домашней сети очень неплохо выглядило бы такое решение:

Внизу "1" (мастер-слейв) - ЦППУ (Центральное Приемо-Передающее Устройство) и много простеньких устройств - исполнительные блоки, интерфейс здесь например 485-й.
Вверху "3" (произвольный доступ) ЦППУ и множество управляющих клиентов - ethernet.

итого будет:
- одно устройство (ЦППУ) с двумя интерфейсами - 485/ethernet.
- много простых исполнительных устройств - с только 485-м интерфесом.
- и комп(ы) с управляющей программой для всей системы.

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

Чем ограничили бы выбор МК пригодных для примениня в 10 раз если не больше.

Ну так и замечательно! Меньше страдать муками выбора придется. И совсем не придется страдать изобретением мультимастерного обмена поверх RS-485.

Для контроллера светодиода (у исполнительных устройств будут как раз такие задачи) найти подходящий МК с CAN на борту, та еще задачка.
Меня бы жаба задавила ставить "100Mhz ARM" для управления одной релюшкой, даже для себя любимого.

Ну а в настенный выключатель Ethernet прикручивать не задушит?

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

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

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

C-bus он был реализован чуть ли не 20 лет назад на MC68HC05B5, т.е. в 4К ПЗУ и 170 байт ОЗУ. При этом C-bus не использовал ни стандартных драйверов, ни UART, весь физический уровень делался "врукопашную" при помощи bit-bang и таймера. Приемопередатчики были сделаны на рассыпухе, поскольку питание (36В) и сигнал передаются по одной витой паре.

Прокладку кабеля домашней сети имеет смысл вести дешевым кабелем Cat5 или Cat6, там 4 витых пары. В конце концов для С-bus тоже стали рекомендовать этот кабель. Это значит, что все усилия по созданию фантомной схемы питания в С-bus оказались по большому счету не нужны. Для питания в Cat5 можно использовать отдельные пары, а сигнал гонять по своей паре. В качестве приемопередатчиков можно использовать CAN-овские, их "доминантный" уровень при столкновениях является эквивалентом открытого коллектора и позволяет легко и просто обеспечить CSMA/CA.

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

Ну я вроде как обрисовал все выше... на мой взгляд самое адекватное решение - двухступенчатая сеть, 485-й внизу, 1 мастер он же 485<-> ethernet bridge, управление с компа через ethernet.. Использование RS485 внизу, позволит вчастности для выключателей применить IRDA, чтобы проводов меньше было. Без особых ухищрений воткнуть простенький прозрачный мост 485<>IRDA и не меняя протокола дублировть все, что идет по 485-шине в IR и наоборот. А общее центральное устройство с ethernet интерфейсом - обеспечит доступ к домашней сети через интернет.


Отчего же, если хорошо позаботиться о мастере - постоить на надежном железе и софте, предусмотреть watch dog, поставить UPS такой чтоб сутки-двое тянул при проблемах с питанием (для устройства на МК которое потребляет отсилы 100ma одной самой ширпотребной SLA батареи 12vx7A/ч хватит чтобы обеспечить ~140 часов, т.е. почти неделю, автономного питания). И не будет вопросов к надежности. В промышленности мастер-слейв сети прекрасно живут, надежность такая - что годами никто ничего не трогает, т.к. система просто работает и не нуждается во вмешательстве...

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

Кстати, про "жабу". Если душит STM32F103T за 80 рублей, то может и автоматизировать не надо. Рулить по-старинке, с выключателей. К сэкономленным деньгам добавить еще 4 раза по столько же и сидеть в Инете (на форуме) целый месяц)

И уж совсем офф. Блин, ye не можем найти путных разработчиков! Такое впечатление, что ARMы кодят в Ярославле всего три человека (и я их всех знаю). Призываю Вас - решайте задачи адекватно. Не надо "пыхтеть" на PICе, или ставить промышленный комп в задачу, в которую явно напрашивается иное.

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

По существу темы: интерфейсом для маленькой сети с несколькими мастерами может служить CAN - по-моему, оптимальное решение.

Эх! Уехать, что ли, в Ярославль?

С повышением в должности и понижением оклада?

По теме:
Можно организовать передачу "мастерства": например, текущий мастер, выполнив все нужные транзакции (например, выдав команду "лампочка, зажгись!") и находясь в IDLE, выдаёт по очереди всем временным слейвам запрос на передачу управления.
Широковещательный, наверно, не нужно, чтобы с коллизиями не бороться.
Тот, кому есть что сказать, отвечает и принимает управление на себя. И так по кругу. Наподобие токен ринг.
Никто не подскажет, как такой велосипед называется?


Зато изер - это больше, чем просто лампочки и выключатели.
Это универсальный канал, хоть видео по нему гонИте.
Кстати, даже телевизоры уже начали в интернет выходить.
Такшта...

А чем же J1708 не устраивает? Аналог CAN-а во всём кроме быстродействия (9600), а быстродействие там, как я понимаю, ни к чему.
Т.е. не во всём, конечно, сказывается ограничение UART-ов. Но эти ограничения в маленькой сети не проявятся. Ну не нужны там тысячи уровней приоритета и т.п. А вот быстродействие, кстати, поднять без проблем можно - просто CAN-овские драйвера поставить и будет мегабит.
А по реализации не сильно сложнее модбаса (которому давно на кладбище пора). Кстати, а не является ли модбас переложением J1708? Специфическим переложением, конечно, типа переложения фуги Баха для сольного исполнения на барабане.

Это Вам должно быть виднее, если курили оба



На одном камне все не заканчивается. Одно дело рисовать и изготавливать плату под STM32, совсем другое - совсем НЕ рисовать для Tiny13. А задачу выключателя с любым даже самым супер-пупер крутым диммером и будильником могут решить оба.

Надежность как известно растет с уменьшением сложности, а не с ее увеличением - и естессно будет выше на t13, т.к. чип в разы проще, да и просто лучше подходит под задачу. Например питать его можно через нехитрый БП - диод, резик и стабилитрон (или вообще простой делитель), непосредственно от 220, потому как чипу пофиг на Uпит, на практике живет от 1.3В до 6В. Непосредственно от GPIO t13 можно включать релюшку. А что Ваш STM? Для выключателя это просто быстый, ни на что не годный (даже реле напрямую дернуть не сможет) кусок г.вна калькулятор, который придется очень долго приспосабливать к конкретной задаче управления "ОДНИМ СВЕТОДИОДОМ" при помощи сторонних компонентов, потом еще думать как получившееся втиснуть в корпус от выключателя...

Что правда так делали?
Я бы на транзисторе не стал экономить.
Стрёмно это как-то...

Конечно курил оба, иначе бы не писал. От модбаса у меня впечатления какой то убогости осталось. Единственное его преимущество в простоте реализации - любой студент-двоечник осилит. Да ещё на 1816ве48 он запросто реализуется. Ну и если использовать его для соединения точка-точка, то недостатки не так заметны.
Но в наше время, делать на нём сеть, да ещё на АРМе - это из пушки по воробьям.

А чего ж нет, выводы у t13 сильные - DC Current per I/O Pin - 40.0 mA.