|
Интерфейс для маленькой "сети", где несколько Master'ов |
|
|
|
Jun 27 2010, 16:30
|

Участник

Группа: Участник
Сообщений: 52
Регистрация: 6-05-09
Из: Москва
Пользователь №: 48 733

|
Всем здравствуйте! Лето началось, снова я со скуки берусь за хобби. С диммером справился, пора для него разработать интерфейс  Приношу свои извинения, но кроме соединений типа точка-точка (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
|
|
|
|
|
 |
Ответов
(90 - 104)
|
Jul 4 2010, 15:20
|
Знающий
   
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640

|
Цитата(adnega @ Jul 4 2010, 18:57)  Длина зависит от скорости. 10кБ/с. В моей таблице (вроде как от CIA) так: 1 Мбод - 30 м 500 кбод - 100 м 125 кбод - 500 м 20 кбод - 2500 м 10 кбод - 5000 м Но реально не проверял. Из интереса попробовал 1 мбод на 100 м - работает без ошибок при 2-х устройствах. Если 3-е посередине с 50 см усами - пошли ошибки. Но это более, чем 3-х (!) кратное превышение.
|
|
|
|
|
Jul 4 2010, 15:43
|
Гуру
     
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882

|
2 defunct, насчет разницы терминов интерфейс и протокол. Пояснения на бытовых аналогиях. У человека есть органы, отвечающие за ввод и вывод информации: ввод - глаза, уши, нос, вкусовые и прочие рецепторы, вывод - речевой аппарат и мимическая жестикуляция. Согласитесь, что совершенно бесполезно общаться глухому со слепым, т.к. у них разные каналы ввода-вывода, не совместимые между собой. В то же время двум даже нормальным здоровым людям весьма сложно общаться, если они разговаривают с помощью речевого аппарата одной и той же конструкции, но на разных языках. Но если они знают несколько языков, среди которых найдется общий, то они могут договориться между собой, чтобы общаться именно на нем и общение приходит в норму. Тут уместно вспомнить как общаются разноязычные космонавты на МКС, англоязычные говорят по-русски, русскоязычные говорят по-английски потому, что даже искаженная родная речь понимается лучше. Немые общаются условными жестами, которые не каждый говорящий поймет. Хотя и немые и обычные люди передают друг другу практически одну и ту же информацию, но по разным каналам (интерфейсам). Так вот, если проводить "человеческую" аналогию, то интерфейс ("междумордие"  ) это согласованные по физическим параметрам каналы ввода-вывода информации, а протокол - это язык общения. В системах связи интерфейс это чаще всего "физика", которая согласует устройства электрически (параметрически), а протокол это система, использующая (заранее) определенный формат передачи данных/команд. На один и тот же интерфейс можно накрутить целый стек разных протоколов. А вот обратное не всегда возможно. Резюмируя. Интерфейс это физическое средство/способ связи, а протокол это система условностей/договоренностей.
|
|
|
|
|
Jul 4 2010, 18:15
|
Cундук
    
Группа: Участник
Сообщений: 1 478
Регистрация: 13-11-06
Из: Ростов-на-Дону
Пользователь №: 22 269

|
Цитата(MrYuran @ Jul 3 2010, 18:41)  Единственное, что бы добавить - автоматическую раздачу адресов А вот это не надо. Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи. Лично я, как потребитель , измученный различными сетями, такое бы брать не стал... В обслуживании будет гемор. Цитата(defunct @ Jul 3 2010, 03:32)  А там ведь товарищ логирует и ловит причуды интерфейса, затем и уже отдельно - наверняка приколы протокола уровнем повыше, и думает что это хорошо и так и надо... К стати, ПМСМ, CAN не совсем попадает под определение 1 уровня OSI. У него уже есть уровень 2 - разрешение конфликтов и некое поведенческое описание. У того же MODBUS второй уровень полностью отвязан от первого. Сейчас думаю реализовать его на оптике в качестве физ. уровня. Интересно было бы посмотреть на CAN-оводов в этой ситуации...
|
|
|
|
|
Jul 4 2010, 18:21
|
Гуру
     
Группа: Свой
Сообщений: 2 702
Регистрация: 14-07-06
Пользователь №: 18 823

|
Цитата(Прохожий @ Jul 4 2010, 21:08)  Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи. А многомастерность уже закрыли? Немного странно обсуждать протоколы, не видя перед глазами минимум требований: - количество устройств в сети - максимальное время передачи от одного устройства к другому - расстояние - топология сети - обстановка в части помех
--------------------
Уходя, оставьте свет...
|
|
|
|
|
Jul 4 2010, 18:59
|
Знающий
   
Группа: Свой
Сообщений: 841
Регистрация: 10-05-07
Из: Чебоксары (Россия)
Пользователь №: 27 640

|
Цитата(Прохожий @ Jul 4 2010, 22:49)  И тем самым разрушить уровень 1 по OSI? Там четко сказано - 2 открытых коллектора или стока. Это что за документ? CAN в т.ч. и беспроводной (радио) бывает... Офф. Только не подумайте, что я фанат CAN-а. Протокол как протокол. Но модбас с ним даже рядом не стоит.
|
|
|
|
|
Jul 4 2010, 19:32
|
Cундук
    
Группа: Участник
Сообщений: 1 478
Регистрация: 13-11-06
Из: Ростов-на-Дону
Пользователь №: 22 269

|
Цитата(galjoen @ Jul 4 2010, 22:59)  Но модбас с ним даже рядом не стоит. Правильно. MODBUS гораздо шире по возможностям, надежнее и более часто применим. При этом прост в реализации и более дешев. A CAN - жалкая медленная и короткая покидуха от BOSH с претензией на универсальность. Как Вам такой  ? Я тоже не фанат MODBUS. Просто уже наелся CAN-оводских решений до отвала в качестве потребителя.
|
|
|
|
|
Jul 4 2010, 21:20
|
Гуру
     
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882

|
Цитата(defunct @ Jul 5 2010, 03:02)  Почему другой? Потому, что в "физике" нет ни фреймов, ни битов, а есть только Вольты, Амперы, Омы и секунды. Цитата(defunct @ Jul 5 2010, 03:02)  Зачем мы тратим столько времени на очевидные вещи?... Потому, что путь к взаимопониманию начинается с базовых определений, которые, как оказывается, у вас свои собственные. Цитата(defunct @ Jul 5 2010, 03:02)  Или у вас есть опыт работы с RS485 сетями где используются фреймы отличные от UART'овских? Вам уже приводили пример с манчестером через RS485. Как еще один пример, SPI с частотой тактирования несколько МГц на сотню метров, также используя драйверы RS485. Вот и получается, что RS485 в применениях есть, а UART нету.
|
|
|
|
|
Jul 4 2010, 22:50
|

кекс
     
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326

|
Цитата(rezident @ Jul 5 2010, 00:20)  Потому, что в "физике" нет ни фреймов, ни битов, а есть только Вольты, Амперы, Омы и секунды. Стоп. Вы прикалываетесь или это троллинг такой мощный? ;> Цитата Цитата Хорошо, давайте уберем слово "физический", но тогда это уже будет другой уровень абстракции. Ровно один в один с абстракциями CAN и Ethernet интерфейсов. В которых внешняя часть оканчивается электрическими характеристиками, а внутренняя (со стороны программы на МК) - фреймами данных, правилами их формирования и декодирования. Убрали слово физический, получили, то что написано. Зачем опять туда слово "физический" подмешивать? Цитата Вам уже приводили пример с манчестером через RS485. Как еще один пример, SPI с частотой тактирования несколько МГц на сотню метров, также используя драйверы RS485. Вот и получается, что RS485 в применениях есть, а UART нету.  За примеры спасибо, правда не помню кто приводил пример с манчестером и в каком контексте, но я тоже могу таких примеров насочинять сколько угодно. Могу UART фреймы пустить по физике ethernet'а. Дурное дело - нехитрое, любые фреймы можно гнать по любой физике (не факт только что это будет эффективно, и востребовано). Но это явно не проблема. Вопрос был более конкретным: Цитата У вас есть опыт работы с RS485 сетями где используются фреймы отличные от UART'овских? Так есть или нет такой опыт? Допустим по рекламке вы покупаете конвертер RS485<>Ethernet, что вы ожидаете получить от этого конвертера? Манчестер с обеих сторон, HDLC, CAN фреймы, SPI на много мегагерц, или все-таки Ethernet фреймы на ethernet стороне, uart фреймы на RS485 стороне? Допустим Вы декларируете поддержку RS485 вашим устройством, вы уточняете какие фреймы бегают по этому интерфейсу в своей документации, это HDLC, CAN фреймы, Ethernet фреймы, или SPI на много мегагерц или все же UART фреймы? Если Вы хотите чтобы Ваши устройства кто-то купил, неужели будете ганять там ни с чем несовместимый SPI на "несколько мегагерц" как приводите в своем примере? За себя отвечу - у меня опыт такой: все сторонние (не сделанные мной) устройства, которые декларировались как совместимые с RS485 интерфейсом с которыми работал формировали UART фреймы. Цитата Потому, что путь к взаимопониманию начинается с базовых определений, которые, как оказывается, у вас свои собственные. Путь к взаимопониманию начинается с желания понять друг-друга. Как можно TIA/EIA-485-A стандарт перевести как "спецификация интерфейса", если в названии документа нет слова interface?  С таких веселых русских переводов и начинаются все преведы конфузы, искаженное предствление о действительности, а затем обвинения в "собственных представлениях базовых определений".
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|