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

[demiurg_spb]

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

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

[C.S.]

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

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

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

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

[rezident]

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

[C.S.]

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

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

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

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

Сообщение отредактировал rezident - Jun 27 2010, 20:41

Причина редактирования: Излишнее цитирование.

[rezident]

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

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

Панели - пишут, устройства - читают?

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

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

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

чем подробнее я пытаюсь сформулировать ответ, тем больше понимаю для себя.

Это-то как раз нормально. Правильно сформулированный вопрос содержит половину ответа

[Прохожий]

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

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

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

Рекомендую посмотреть в сторону [attachment=45344:Modbus_M...de_V1_0b.pdf]
На WizNet должно, по идее, все получиться.

Сообщение отредактировал Прохожий - Jun 27 2010, 21:01

[C.S.]

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

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

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

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

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

[aaarrr]

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

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

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

[Прохожий]

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

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

[aaarrr]

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

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

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

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

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

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

[defunct]

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

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

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

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

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

[galjoen]

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

[aaarrr]

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

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

[C.S.]

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

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

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

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

Сообщение отредактировал C.S. - Jun 28 2010, 10:35

[aaarrr]

Так как это хобби - ну выкину я несколько тыр на LAN, если оно заработает - получу удовольствие.

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

[C.S.]

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

Сообщение отредактировал C.S. - Jun 28 2010, 11:17

[aaarrr]

Простите за настырность, а какое ещё? Ну LAN модули. Витуха и свитч?

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

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

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

[adnega]

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

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

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

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

[MrYuran]

С чего начать-то? Начать хочется... Физический интерфейс?

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

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

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

[adnega]

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

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

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

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

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

Сообщение отредактировал adnega - Jun 29 2010, 09:31

[C.S.]

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

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

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

[ViKo]

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

[adnega]

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

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

[C.S.]

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

[adnega]

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

[Прохожий]

Никакой корявости, говорите?
А пляшущий эндианизм в 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]

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

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

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

[=AK=]

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

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, и др.

[AHTOXA]

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

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

[defunct]

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

1. Мастер-слэйв.
2. Peer-to-peer.
3. Произвольный доступ - CSMA
4. Производитель-потребитель.

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

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

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

[aaarrr]

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

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

[defunct]

(хотя я бы выбрал CAN)

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

[aaarrr]

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

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

[defunct]

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

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

[aaarrr]

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

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

[defunct]

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

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

[aaarrr]

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

[=AK=]

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

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

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

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

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

[defunct]

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

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

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

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

[adnega]

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

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

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

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

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

[aaarrr]

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

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

[MrYuran]

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

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

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

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

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

[galjoen]

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

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

[defunct]

Кстати, а не является ли модбас переложением J1708? Специфическим переложением, конечно, типа переложения фуги Баха для сольного исполнения на барабане.

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

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

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

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

[demiurg_spb]

Непосредственно от GPIO t13 можно включать релюшку.

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

[galjoen]

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

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

[defunct]

Что правда так делали?

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

[adnega]

Согласен что надежность и сложность находятся в определенной зависимости при определенных условиях...

1. Использовать сложный в аппаратном, но легкий в программном плане CAN _надежнее_ того же RS-485 с программными "ухищрениями" для получения соизмеримой вероятности необработанной ошибки. Ибо, программист грешен и допускает ошибки.

2. Защита от дурака усложняет, но надежность от этого увеличивается.

3. Распределенная система (CAN) по числу элементов может быть и меньше централизованной на RS-485... Если отказом считать невозможность нормально функционировать какому-то отдельно взятому узлу, то в случае CAN надежность равна надежности одного узла; в случае с RS-485 сумме всех узлов. Например, промышленный модуль I-7015 при "слете" прошивки на ногах проца имеет такой потенциал, что продолжает висеть на шине с _включенным_ передатчиком RS-485. Сеть при этом глючит - найти кто виноват в этом случае, на объекте, в условиях, за потолком или в теплоузле, мягко говоря... !

4. Если речь идет о "контроллере светодиода", то микросхемы тут не нужны - тупо включатель и провода (надежнее не придумаешь).

5. Контроллер для умного дома или _сети_ уже подразумевает под собой нечто сложное. Ресурса tn13 может не хватить (сейчас или в будущем). Прыгать по камушкам - затратно.

6. tn13 - шикарные микросхемы! ) Постоянно держу неснижаемый остаток штук 50. Пихаю везде, где только можно

[defunct]

1. Использовать сложный в аппаратном, но легкий в программном плане CAN _надежнее_ того же RS-485 с программными "ухищрениями" для получения соизмеримой вероятности необработанной ошибки. Ибо, программист грешен и допускает ошибки.

Не надо использовать RS-485 с ухищрениями, обычный мастер-слейв.

2. Защита от дурака усложняет, но надежность от этого увеличивается.

Недежность ПО падает, т.к. каждый "if" в программе это дополнительный риск возможного глюка.

3. Распределенная система (CAN) по числу элементов может быть и меньше централизованной на RS-485... Если отказом считать невозможность нормально функционировать какому-то отдельно взятому узлу, то в случае CAN надежность равна надежности одного узла; в случае с RS-485 сумме всех узлов.

Неправда, с RS-485 надежность определяется надежностью одного самого сложного устройства - Мастера.

Например, промышленный модуль I-7015 при "слете" прошивки на ногах проца имеет такой потенциал, что продолжает висеть на шине с _включенным_ передатчиком RS-485. Сеть при этом глючит - найти кто виноват в этом случае, на объекте, в условиях, за потолком или в теплоузле, мягко говоря... !

Пример мимо кассы, и CAN можно запороть неадекватным (несовместимым со стандартом) железом, шина общая ведь и там.

4. Если речь идет о "контроллере светодиода", то микросхемы тут не нужны - тупо включатель и провода (надежнее не придумаешь).

задача поставлена в контексте централизованного управления выключателями. В таком свете интеллектуальный выключатель позволит уменьшить число проводов. Почуствуйте разницу между 100 проводов для 100 выключателей и 2 провода на 100 выключателей. В контексте всей системы неизвестно где надежность будет выше, но определенно точно можно сказать что система из двух проводов будет проще при монтаже и безопаснее в эксплуатации.

5. Контроллер для умного дома или _сети_ уже подразумевает под собой нечто сложное. Ресурса tn13 может не хватить (сейчас или в будущем). Прыгать по камушкам - затратно.

Контроллер для умного дома - это несомненно сложная программа возможно на PC, или в центральном устройстве управления. А модуль на t13 это всего лишь исполнительный блок, выполняющий строго свою одну функцию - вкл./отлк свет и возможно менять яркость по команде от мастера. Даже если поменяется устройство управления в будущем, перекроить всю систему, то этот исполнительный блок на t13 все равно будет продолжать выполнять всё ту же функцию - вкл/откл свет и задать яркость. Ничего нового туда не добавится, ибо для управления освещением набор функций по определению ограничен только этими двумя действиями - вкл/откл и яркость.

6. tn13 - шикарные микросхемы! ) Постоянно держу неснижаемый остаток штук 50. Пихаю везде, где только можно

это да порой незаменимый кусочек железа ;>

[galjoen]

Пример мимо кассы, и CAN можно запороть неадекватным (несовместимым со стандартом) железом, шина общая ведь и там.

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

[adnega]

RS-485 без ухищрений - вещь, живущая до первого прецидента, на который разработчик, обычно разводит руками, мол "кто ж знал? помеха...". Не буду озвучивать имен, но не раз приходилось "солидным" конторам грозить пальчиком "ай-я-яй" - в погоне за простотой "обычного мастер-слейва" даже контрольную сумму не стремились использовать.

Не надо пытаться делать вещи проще, чем они того заслуживают. Табурет с 3 ногами устойчивее лишь в теории; 5 ног - явный перебор. "Битый жизнью" Мерфи утверждал, что если что-то негативное может случится, то оно случится обязательно с самым максимальным ущербом. Если под "защитой от дурака" понимать несложные программные или аппаратные проверки, уберегающие от явно деструктивного поведения системы при возможных (допустимых физически, реализуемых) входных условиях, то такая защита повышает надежность. Яркие примеры: проверка перед делением на ноль и плавкий предохранитель. Кстати, и прямовключенный диод во входной цепи питания много жизней спас.

Мастер, несмотря на всю свою активность, все же товарищ пассивный. Мониторят датчики и клацают релюхи слейвы. В контексте сети, для передачи сигнала о нажатии на кнопку на слейве_1 слейву_2 для управления реле, требуется, чтобы жили: слейв_1, слейв_2, мастер и не пакостничали все оставшиеся.

Яркий пример несовместимого по стандарту железа - топор - может запороть любую проводную шину. Пожалуй, поможет кольцевание и сегментация - и тут CANу легче. Разорвав сеть, в случае с CAN получите две маленькие работоспособные сеточки; у RS-485 одна сеть 100% мертвая, вторая - с простоями на шине из-за таймаутов на ответ "потеряных" узлов.

То, что есть защищенная от длительного удержания на линии доминантных бит физика - не секрет. Для надежности лучше использовать аппаратные CAN-модули, строго придерживающиеся стандарта.

А у меня есть опыт общения с Заказчиком, когда пытаешься объяснить почему не работают "100 выключателей" - а в глазах лишь скорбь... и оттенок зарождающегося сомнения: "может... 100 проводов было бы надежнее... чем 2, но увы - стены ужо стоять, а паркеты ужо лежать".

Многие разработчики - произошли от программистов, некоторые от радиофизиков. Статистическая радиофизика утверждает, что все работает с какой-то вероятностью (точнее, интересуется вероятностью "не работы") и учит методам снижения вероятности отказа. Программист всегда работает на исправном железе - "отказ? - перезагрузись!"

Не хотите наступать на грабли - используйте для умного дома распределенную сеть и ни когда, слышите, никогда не используйте ПК. CAN Вам в помощь )

...
+ купил когда-то ADM485 - так и лежат. Правда, уж второй год на московских АэроЭкспрессах бегает речевое оповещение с RS-485 - тьфу-тьфу... хотя и поезд)... хотя и не мультимастер)

Сообщение отредактировал adnega - Jul 1 2010, 16:32

[defunct]

Не надо пытаться делать вещи проще, чем они того заслуживают. Табурет с 3 ногами устойчивее лишь в теории; 5 ног - явный перебор.

Попытка оправдать применение дорогой автомобильной шины для дома? Вот 3 ноги из вашего примера - это отдельный провод каждому выключателю, 5 ног - это предложенный Вами STM32, а тиня там это как раз обычная четырех-ногая табуретка. Причем не особо важно будет то тиня13 или тиня2313 или PIC или еще чего такого же класса.

Мастер, несмотря на всю свою активность, все же товарищ пассивный. Мониторят датчики и клацают релюхи слейвы. В контексте сети, для передачи сигнала о нажатии на кнопку на слейве_1 слейву_2 для управления реле, требуется, чтобы жили: слейв_1, слейв_2, мастер и не пакостничали все оставшиеся.

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

А у меня есть опыт общения с Заказчиком, когда пытаешься объяснить почему не работают "100 выключателей" - а в глазах лишь скорбь... и оттенок зарождающегося сомнения: "может... 100 проводов было бы надежнее... чем 2, но увы - стены ужо стоять, а паркеты ужо лежать".

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

Не хотите наступать на грабли - используйте для умного дома распределенную сеть и ни когда, слышите, никогда не используйте ПК. CAN Вам в помощь )

Что за чушь, а если я с ПК хочу отключить свет в туалете, или запрограммировать чтобы кондиционер включился ровно в 8.00, тоже прикажете не использовать?
А CAN фтопку (вместе с Шао Каном, Лю Каном и Кано), не нужно оно для дома.

[adnega]

1. CAN совсем не дорого.
2. Насчет того что нужно мастеру, а что слейву - соглашусь, посмотреть можно и под Вашим ракурсом. Но типичный хомо-сапенс спроектирован для работы по принципу "причина-следствие". Заменив понятия, легко можно из Вашей концепции получить мою, где для актеров "выключатель" и "реле" система должна обеспечить некий сервис. В таком случае, "выключателю" и "реле" уже что-то надо - и с таким положением дел согласится 99% домохозяек. Применив, готовые микросхемы/интерфейсы с событийным характером работы, а не опросным, можно стать ближе к народу и Матушке-Природе, веками оттачивающей свое совершенство.
3. По поводу Заказчиков. Когда работаешь "на себя" - все запускается с первого раза, когда "работаешь на дядю" - как правило, Заказчика выбирает дядя. У них свои интересы, а делать из "г" конфетку за зарплату приходится разработчику. Эх... Заказчик с "100 выключателей" достался мне "по наследству". А с дядей я до сих пор работаю, и мысленно благодарю его за такой бесценный опыт.
4. ПК для конфигурирования и мониторинга очень удобен. Для управления в реальном времени... извиняйте.
5. Не изобретайте велосипед... возьмите готовый... интерфейс из транспорта )

[aaarrr]

Попытка оправдать применение дорогой автомобильной шины для дома?

А что, дом чем-то хуже автомобиля? Я бы думал, что наоборот.

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

[adnega]

Думаю будет интересно:
Имея неприятный опыт внедрения "чужих" умных домов, однако же не побоялся сделать себе свой. В спальне под кроватью расположен контроллер с SD-картой, длинным проводочком, релюшкой, полным мостом на 245 логике, и динамиком.
Контроллер постоянно измеряет емкость провода, аккуратно прикрепленного к краю одной из спинок кровати. Стоит поднести руку к проводу - загорится свет под кроватью (релюха + светодиоды). Аналогично свет выключается. Искать тапки зимой удобно.
В 11.00 с SD-карты играет колыбельная (44100Гц, 10 бит @ 2-ШИМ + полный мост + динамик). В 7.00 играет будильник (довольно спокойная композиция), в 7.30 - более настойчивый трек).

Второй контроллер расположен у письменного стола. Имеет аналогичный емкостной датчик, управляет двумя релюхами, имеет вход с ИК-приеника. Со всех пультов что были в доме, можно управлять настольной лампой (одна из релюх). Ей же можно управлять с емкостного сенсора. Вторая релюха пользуется как ШИМ включалка средства от комаров - два часа работает, два отдыхает (ночью).

Все это локально работает и удобно для меня и супруги. Но если добавить немножечко CANа, то:
- можно управлять настольной лампой с емкостного сенсора кровати (если удерживать 3 секунды). Фича появилась, когда лентяйки забывались на столе, а разработчик с супругой уже были в постели.
- можно управлять громкостью звука под кроватью с пульта. особенно удобно выключать будильники. Можно запускать другие треки.
- появилась возможность работы с напоминалками. С пульта нажимаешь кнопочку и голосом тебе сообщают об истечении времени по истечении времени. Нажатием кнопки по кругу выбирается "5 мин - 15 мин - 30 мин - выкл". Чайник на кухне стал реже подгорать).
- кроме того, есть возможность гонять живую речь между контроллерами у стола и кабинетом. Интерком поверх CAN: "женушка, принеси чай")

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

По CANу конфигурирую, круглосуточно мониторю - трафик ничтожный, задержек нет.

Как говорится "а Вам слабо, уважаемый RS-485"? Или умный дом это что-то другое? Может, это привычные выключатели и лампочки в альтернативной реализации? - тогда RS-485 рулит, и я сдаюсь)

[defunct]

А что, дом чем-то хуже автомобиля?

По требованиям к электронике - для разработчика как раз много лучше, это не industrial и даже не commercial, не то что automotive... Например можно поставить CAN, а можно - лапшу из проводов, можно поставить гальваноразвязку для каждого устройства, а можно и не ставить и т.д.. Тобиш выбор огромный, делай, что хочешь и как хочешь, принимай работу сам, и не бойся в тюрму не посадят из-за того что дом на кого-то упадет.. куда ж еще лучше требования то найти?

Я бы думал, что наоборот.

Ну а такие же требования как и для автомобиля могут появиться только если "дом" это одно из трех:
- избушка на курьих ножках;
- трейлер / вагон поезда;
- сарай у подножья действующего вулкана.

У вашей системы есть один большой недостаток: нельзя в произвольном месте подключить к шине кнопочку, которая будет управлять "во-он той лампочкой".

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

Или эти кнопочки должен будет постоянно опрашивать единственный мастер, что, по-моему, не является красивым решением.

Да он будет опрашивать все устройства ввода, которые нашел, это факт, тем самым заодно и контроллируя статус устойства - живой/не живой.

[ILYAUL]

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

Повлечёт, но не очень сильное. Его адрес + кто он такой.

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

Можно попробывать пойти по другому. На момент инит в систему он мастер, сообщает о себе , становится slave.

[adnega]

Уж если RS-485, то могу посоветовать две фишечки:
1. Использовать схему приоритетного опроса. Реализуется не сложно,принцип такой:
- у каждого узла на шине есть приоритет.
- мастер за один цикл опрашивает все узлы с наивысшим приоритетом и одно устройство с приоритетом на единицу ниже (окно). От цикла к циклу в окно последовательно попадают все устройства с приоритетом на единицу ниже и одно на две единицы ниже. Далее рекурсивно. Пример, A, B - наивысшиq приоритет, C, D - чуть ниже, E - низший приоритет. Опрос будет выглядеть так: A B C A B D A B E и т.д. Если какой-то узел не ответил N раз - считаем его потерявшим связь с шиной и устанавливаем низший приоритет. При восстановлении связи с этим узлом - восстанавливаем исходные приоритет.
Плюсы: гарантированный период опроса (ограничен сверху), минимизация простоев на шине.
Минусы: пока не придумал)

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

3. Недавно всплывала задачка автоматического поиска устройств на шине RS-485 (охранно-пожарная сигнализация с нестабильно конфигурацией - например, поезд с перецепкой вагонов). Готовые контроллеры имеют 24 битный адрес (8 под тип устройства; 16 под идентификатор, прошиваемый на заводе) - тупой перебор займет мнооого времени (скорость 9600, минимальный пакет слейву 7 байт + таймаут неответа), или я не правильно считаю?

[defunct]

Уж если RS-485, то могу посоветовать две фишечки:

Раз уже пошли советы по теме
Могу тоже поделиться hint'ом:
Если использовать хороший помехоустойчивый протокол и не требовательный к таймаутам между пакетами, например модбас over hdlc. Тогда в одной сети можно размещать устройства с разными скоростями обмена. Устройства с ИК портом на 2400-9600, остальные на 115200, а там где много данных например на 1Mbps. В этом случае у мастера появляется возможность адресовать устройства не только адресным байтом, но и признаком скорости. Например в системе может быть 3 устройства с одинаковым адресом "1", но работающих на разных скоростях.

[aaarrr]

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

Вот только не надо переворачивать все с ног на голову: сами же писали, что CAN - это слишком дорого.

[ILYAUL]

...не только адресным байтом, но и признаком скорости. Например в системе может быть 3 устройства с одинаковым адресом "1", но работающих на разных скоростях.

Может всё таки 2

[defunct]

Вот только не надо переворачивать все с ног на голову: сами же писали, что CAN - это слишком дорого.

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

Может всё таки 2

Сколько скоростей будет обслуживать мастер столько и устройств с одинаковым адресом.

[aaarrr]

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

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

[=AK=]

Oтчего же, если хорошо позаботиться о мастере - постоить на надежном железе и софте

Построить надежное устройство - само по себе задача не тривиальная. А написать для него надежный софт - задача просто сложная, занимает много времени (с доводкой - растягивается нa годы) и получается отнюдь не у всех. Поэтому использование CAN является более чем оправданным. И разбиение задачи на маленькие кусочки - тоже оправданно. Ведь с ростом сложности ненадежность софта увеличивается не линейно, а как-то типа в геометрической прогрессии.

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

[ILYAUL]

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

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

[galjoen]

Напомню, что до сих пор ваш основной аргумент против CAN был - дорогие контроллеры/дорогая автомобильная шина.

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

[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 .

[Прохожий]

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

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

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

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

[aaarrr]

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

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

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

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

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

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

[defunct]

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

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

[Прохожий]

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

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

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

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

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

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

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

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

[galjoen]

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

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

[defunct]

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

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

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

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

[demiurg_spb]

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

Не знал, т.к. моя рабочая лошадка mega8(88,48).

[MrYuran]

Лучше потратить пару часов на изобретение своего, с учетом своих потребностей, а не брать Modbus и "расширять" его потом.

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

[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-й сети. Если вернуться к вышеупомянутой модели ОЗИ - интерфейс - это связь между уровнями (например интерфейс связи сетевого уровня с канальным), т.е. подразумевает стыковку с двух сторон, а протокол - связь множества элементов на одном уровне (например протокол сетевого уровня). Поэтому см. выше.

[Guest_@Ark_*]

Ковертеры RS232<>RS485 впринципе не могут работать с данными отличными от UART фреймов, а здесь почему-то мы отвлеченно рассуждаем о том, что RS485 это строго физика.

В принципе, это, как раз, не так. Конвертор RS232-RS485 в строгом смысле - это только преобразователь уровней сигналов, т.е. физических интерфейсов в чистом виде, и не более того. Никакого UART-та внутри там, как правило, нет. А снаружи - он только подразумевается. Другое дело, что подразумевается - практически всегда. Однако, ни что не мешает, вместо UART, прицепить к драйверу RS485 (или к RS422, или к RS232) модуль который будет использовать, например, манчестерскую кодировку. Если такое решение будет использоваться согласованно, для всех устройств на линии - все будет работать, никуда не денется.

[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 км?

[adnega]

Длина зависит от скорости. 10кБ/с.

[galjoen]

Длина зависит от скорости. 10кБ/с.

В моей таблице (вроде как от CIA) так:
1 Мбод - 30 м
500 кбод - 100 м
125 кбод - 500 м
20 кбод - 2500 м
10 кбод - 5000 м
Но реально не проверял.
Из интереса попробовал 1 мбод на 100 м - работает без ошибок при 2-х устройствах. Если 3-е посередине с 50 см усами - пошли ошибки. Но это более, чем 3-х (!) кратное превышение.

[rezident]

2 defunct, насчет разницы терминов интерфейс и протокол. Пояснения на бытовых аналогиях.
У человека есть органы, отвечающие за ввод и вывод информации: ввод - глаза, уши, нос, вкусовые и прочие рецепторы, вывод - речевой аппарат и мимическая жестикуляция. Согласитесь, что совершенно бесполезно общаться глухому со слепым, т.к. у них разные каналы ввода-вывода, не совместимые между собой. В то же время двум даже нормальным здоровым людям весьма сложно общаться, если они разговаривают с помощью речевого аппарата одной и той же конструкции, но на разных языках. Но если они знают несколько языков, среди которых найдется общий, то они могут договориться между собой, чтобы общаться именно на нем и общение приходит в норму. Тут уместно вспомнить как общаются разноязычные космонавты на МКС, англоязычные говорят по-русски, русскоязычные говорят по-английски потому, что даже искаженная родная речь понимается лучше. Немые общаются условными жестами, которые не каждый говорящий поймет. Хотя и немые и обычные люди передают друг другу практически одну и ту же информацию, но по разным каналам (интерфейсам). Так вот, если проводить "человеческую" аналогию, то интерфейс ("междумордие" ) это согласованные по физическим параметрам каналы ввода-вывода информации, а протокол - это язык общения.
В системах связи интерфейс это чаще всего "физика", которая согласует устройства электрически (параметрически), а протокол это система, использующая (заранее) определенный формат передачи данных/команд. На один и тот же интерфейс можно накрутить целый стек разных протоколов. А вот обратное не всегда возможно.
Резюмируя. Интерфейс это физическое средство/способ связи, а протокол это система условностей/договоренностей.

[defunct]

Резюмируя. Интерфейс это физическое средство/способ связи, а протокол это система условностей/договоренностей.

С примером все ОК, а вот с выводом - не согласен.
Интерфейсы в ВТ это способы взаимодействия разных уровней ОЗИ ;> между собой. Например интерфейс OpenGL позволяет app программисту общаться с разным железом видео карт разных производителей одинаково, но OpenGL сам при этом не является физическим средством, а всего лишь фантазия договоренностей функций и типов данных.

[Прохожий]

Единственное, что бы добавить - автоматическую раздачу адресов

А вот это не надо.
Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи.
Лично я, как потребитель , измученный различными сетями, такое бы брать не стал...
В обслуживании будет гемор.

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

К стати, ПМСМ, CAN не совсем попадает под определение 1 уровня OSI.
У него уже есть уровень 2 - разрешение конфликтов и некое поведенческое описание.
У того же MODBUS второй уровень полностью отвязан от первого.
Сейчас думаю реализовать его на оптике в качестве физ. уровня.
Интересно было бы посмотреть на CAN-оводов в этой ситуации...

[rezident]

С примером все ОК, а вот с выводом - не согласен.

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

[Dog Pawlowa]

Точно так же, как не надо и очереди сообщений и много другой чисто программистской чепухи.

А многомастерность уже закрыли?

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

[galjoen]

Сейчас думаю реализовать его на оптике в качестве физ. уровня.
Интересно было бы посмотреть на CAN-оводов в этой ситуации...

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

[Прохожий]

Живет CAN на оптике. Какие там проблемы то? Элемент 2-И добавить?

И тем самым разрушить уровень 1 по OSI?
Там четко сказано - 2 открытых коллектора или стока.

[adnega]

Вроде, CANу от среды нужно немного:
- наличие двух состояний среды "доминантное" и "рецессивное";
- при выводе сколь угодно многих "рецессивных" состояний, одно "доминантное" при считывании должно давать "доминантное" в сумме.

Оптика: есть/нет света.
Радио: есть/нет модулированный сигнал
Витая пара: есть/нет разность напряжений.
Открытый коллектор, в конце концов.