Перейти к содержанию
    

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

Всем здравствуйте! Лето началось, снова я со скуки берусь за хобби. С диммером справился, пора для него разработать интерфейс ;)

Приношу свои извинения, но кроме соединений типа точка-точка (RS-232) я ничего не знаю; тема почти вольная и начнётся с тупых вопросов.

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

1. Есть n-ое количество модулей, которые вешаются на какую-то общую шину. Модуль - это например диммер, реле или датчики (ну вполне напоминает промышленные контроллеры, да).

2. Есть "панель управления" - девайс с кнопочками и дисплейчиком. Через меню мы можем управлять/считывать состояние навешанных на шину модулей.

3. Есть комп, который тоже подключён к этой шине (двоякое управление: автономное через (2) и через комп). Фактически комп выступает в роли такой же панели управления.

 

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

post-48733-1277656091_thumb.png

 

Ньюансы:

а) Панелей управления (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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Есть n-ое количество модулей, которые вешаются на какую-то общую шину.
Смотрите в сторону RS485 - просто, надёжно, дёшево и сердито...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Добавляю. Почитал про DMX-512. Там время обновления информации о каналах около 45 Гц. При этом, выходит, даже вполне себе нормальное плавное включение прожектора происходит (видел лично).

Может, мне имеет смысл тогда принять схему сетки в виде "Сервера"?

Фактически - контроллера с кучей памяти, который висит себе с одним адресом (пусть IP).

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

Тогда Мастера могут писать/читать в регистры (и обновляют информацию скажем раз в 10-20мс), а Модули - лишь читают и исполняют команду, если она не ноль.

 

Такую схему реализации вообще делают?

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

Какой сейчас лучше взять для теста? Скатаюсь на днях в Терру например...

 

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

А вот здесь моя ламерская логическая затыка: я понимаю под панелью управления с дисплейчиком именно Мастера. Они мне будут заменять выключатели. Значит их будет несколько. Или не так?

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

Как делают поддержку несокльких органов управления?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

То бишь я вам предлагаю "маркерное кольцо" для разрешения коллизий.

 

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

 

Так как мне хочется поиграться (и чтобы у меня чего-то получилось с первого-второго раза), я думал побаловаться с Wiznet'ами или их аналогами. Мне тяжело с физически уровнем разобраться - я страюсь, фактически, от него сбежать на уровень послал-принял байт(ы).

Мне показалось, что Ethernet проще всего (<> RS-232). До кучи, у меня дома есть мелкая сетка - было бы как раз удобно воткнуться туда.

Вижу я это, например как какой-то блок с адресом ну например 192.168.1.250. И панели и модули тупо стучатся к нему. Одни за "дай команду", другие за "новая команда".

Что с коллизиями - пока не понял сам. Вроде как от WizNet будет тупо идти поток байтов, адресованных ему? Или это уже UDP, а не TCP/IP?

 

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

Изменено пользователем rezident
Излишнее цитирование.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А что можно сказать о концепте одного Мастера? Пусть это будет разделяемая "память".
Память чего именно?

Панели - пишут, устройства - читают?
А зачем создавать лишний траффик-то? Раз устройства по событиям работают, то и траффик пропорциональный частоте возникновений событий вполне достаточен.

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Так как мне хочется поиграться (и чтобы у меня чего-то получилось с первого-второго раза), я думал побаловаться с Wiznet'ами или их аналогами. Мне тяжело с физически уровнем разобраться - я страюсь, фактически, от него сбежать на уровень послал-принял байт(ы).

Мне показалось, что Ethernet проще всего (<> RS-232). До кучи, у меня дома есть мелкая сетка - было бы как раз удобно воткнуться туда.

Вижу я это, например как какой-то блок с адресом ну например 192.168.1.250. И панели и модули тупо стучатся к нему. Одни за "дай команду", другие за "новая команда".

Что с коллизиями - пока не понял сам. Вроде как от WizNet будет тупо идти поток байтов, адресованных ему? Или это уже UDP, а не TCP/IP?

 

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

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

На WizNet должно, по идее, все получиться.

Изменено пользователем Прохожий

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Память чего именно?

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

 

Трафик? А TokenRing вроде тоже по сети гоняет данные постоянно?

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Не вижу никакой корявости.

Все достаточно логично и стройно.

Намного лучше того же PROFIBUS или PROFINET или всех этих канообразных CANOPEN и DeviceNet или всеми здесь любимого HART.

Я уже не говорю про Ethernet с его свалкой из протоколов на всех уровнях OSI.

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

Тем более, дата на документе не 40-летней давности.

Да и документ не самый свежий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не вижу никакой корявости.

Все достаточно логично и стройно.

Никакой корявости, говорите?

А пляшущий эндианизм в Modbus-RTU?

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Никакой корявости, говорите?

А пляшущий эндианизм в Modbus-RTU?

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

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

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

Оставить адрес устройства, функцию "как класс", длину данных, код ошибки и CRC, да и способ передачи пакетов. Вот и все...

Технически формат останется Modbus-RTU.

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

 

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

Хотите совместимость с другими вендорами и универсальность в телемеханике, берите линейку:

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

 

В системах телемеханики (собсно автор такую и задумал) модбас это нижний уровень и там все делают, что горазды. Формат данных там мало кого волнует.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ещё можно вместо RS485 трансиверов, в таком включении, CAN-овские использовать. Собственно CAN из J1708 то и вырос...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Оставить адрес устройства, функцию "как класс", длину данных, код ошибки и CRC, да и способ передачи пакетов. Вот и все...

Технически формат останется Modbus-RTU.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Эээ, ... я читаю всё, попутно просматриваю википедию, чтобы хоть понять про названия интерфейсов.

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

 

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

 

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

 

Ну и о протоколе. Если честно - я боюсь гемора на физическом уровне. Потому хочу подобрать чего-то простое. Так как это хобби - ну выкину я несколько тыр на LAN, если оно заработает - получу удовольствие.

Сам протокол, скорее всего будет передачей байт, что-то вида <адресМодуля><команда><параметр(ы)> и подтверждение/код ошибки в ответ.

Вот жду комментариев, и потом приму решение...

Изменено пользователем C.S.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...