умный дом [выбор интерфейса] Опции

[qnx]

начал подумывать о автоматизации процессов в доме, в частности управлении и контроле.
структуру думаю примерно следующую.

ПК (веб сервер, умеющий работать с железкой с портами ВВ, шим, аналоговыми (на которые в дальнейшем навешиваются объекты контроля и управления))

ПК соединен с вайфай роутером, для видения его внутри и по интернету.

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

на сколько понимаю много оборудования сейчас делается так: ПК->USB->COM->uart-переферия

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

[=AK=]

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

Zigbee, Bluethooth LE, DASH-7

[пай-мальчик]

"usb плату, умеющую работать с портами" - это банальный FT232 или новые ревизии pl2303. И то и другое умеет делать bitbang.

Хотя и совершенно непонятно зачем серверу GPIO. Они должны быть на исполнительных устройствах. Если денег много, то raspberry и подобное. Если денег мало, AVR/PIC.

[qnx]

тобишь на подобие "Переходник USB A - COM (RS232) 45cm" переходников, а дальше уже com-uart переходник.

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

[kolobok0]

...на подобие "Переходник USB A - COM...какой-то "шифратор"...по интерфейсу com
(uart) ?...плата для контроля и управления портами вв дискретными, для начала...

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

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

как альтернатива...
есть готовые, либо полуготовые решения на МК. Есть даже с осями типа андроидов и иже. И задача железок - именно управление
переферией. И связь какая нить стандартная, модбас поверх изернета типа. такие решения сразу затмевают решения на писюках и иже,
если выбирать придётся. Да и на рынок посмотрите - ценники на спецов мобильной техники
(андроиды, кастрированные форточки, иосы и прочяя "нечесть")

[Ruslan1]

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

Есть еще вариант: вдруг его никнейм не просто так выбран и ТС именно под ним и программит...
уж не знаю как сейчас, но 15 лет назад QNX был не самым плохим выбором для промавтоматики (хотя и недешевым)

[iosifk]

на сколько понимаю много оборудования сейчас делается так: ПК->USB->COM->uart-переферия

Это только "настольное" и "игровое" делается под USB... А промышленное и длительно-работающее - никогда.. Вот подвиснет ночью у Вам USB и что будете делать? Вручную кабель передергивать?

[qnx]

Есть еще вариант: вдруг его никнейм не просто так выбран и ТС именно под ним и программит...
уж не знаю как сейчас, но 15 лет назад QNX был не самым плохим выбором для промавтоматики (хотя и недешевым)

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

п.с. а под QNX написал лишь "hello world", не более)

to iosifk
Watchdog timer передергивающий)
шучу, именно потому и спрашиваю что объективно и почему подойдет/не подойдет.

kolobok0, таки Вы правы, в виду того, что под ПК чего-то пишу, такую архитектуру и продумывал, и поскольку сомневался в правильности и спрашиваю советы))

[Alex11]

Даже если нет серьезного реалтайма, iosifk Вам правильно подсказывает про USB. Вот включили Вы печку, а USB и отвалилось. При плохом стечении обстоятельств все сгорело. Оно Вам надо? Используйте Ethernet или RS-422 или 485. Они по крайней мере не виснут после включения рядом холодильника.

[qnx]

Alex11, спасибо большое, взгляну в сторону Ethernet (ENC28J60).
Может еще есть что-то поинтересней по доступной цене

[EvilWrecker]

Готовых индустриальных материнок на цену которая вас устроит не существует, и насчет усб отписавшиеся сказали правильно- на вашем месте я бы взял мк от стм, подойдет сотка, купил микросхемы RS485 штуки 4(на mouser-е предостаточно и дешевая доставка), и физик эзернета- пинов на мк хватит чтобы прокинуть физик через RMII, включить 4 трансивера на 485й, и останется еще предостаточно гпио чтобы вывести как входы/выходы оптопарами, реле и пр.Как ос вам с головой хватит FreeRTOS™.

[kolobok0]

...под ПК чего-то пишу, такую архитектуру и продумывал..

я не давал конкретики - дабы не рубить Вашу хфантазию. Вдруг Вы и в правду qnx не просто так написали ))
есть один из подходов, вроде как тут ышо не прозвучал...
берёте готовый девайс. ну типа роутера с вайфаем. смотрите в инете как народ на него компилит и заливает какую нить ось типа льюниксов.
дальше надеюсь мысль понятна ограничение тока - схемотехникой девайса.
Но с точки зрения электроники - проблем вывести любой объём инфы по одному пину собственно и нет.
если это не ваш путь - то тогда либо полуфабрикаты с ебеней тянуть, либо пром контроллер, либо что нить аля карманное
(но опять доделка по пинам и выхода-входам) или что то своё(но тут для быстрого старта лучше опять жешь прикупиться готовой схемотехникой
с софтом, чтоб не гиморничать. если тема в добавок вам не совсем понятна - то алгоритм следующий. заказываете, приходит, компилируете,
заливаете, работает = срисовываете схему, разбираетесь с прошивкой. Для первого подхода к снаряду - вполне. Правда упускаются нюансы -
бывает и оригинал кривоватенько сделан, но вам же форсаж к цели а не вылизывание скромных уголков для профита в 10%?).
Если последнее - то сейчас набирают обороты по цене-фичам-удобствам-спросу всякие ARMы. Одни из популярных от ST. примеров и опытных
людей уже достаточно чтоб смело смотреть на это, даже в первый раз. Если не боитесь и есть запал - справитесь. Дорогу осилит идущий.

удачи вам!

[Plain]

Главный ум в таких зданиях — разводка звездой, т.е. как минимум по одному отдельному проводу от каждой точки до кросса в щитке, а уж какой протокол по ним запустить — дело десятое, т.е. всё сводится к соответствующего бюджета ремонту или первоначальному проекту. Типичный кабель для таких случаев — EIB Combi, три жилы 1,5 мм² и две слаботочных пары для данных и питания мозгов и интерфейса.

[=AK=]

Это только "настольное" и "игровое" делается под USB... А промышленное и длительно-работающее - никогда.. Вот подвиснет ночью у Вам USB и что будете делать? Вручную кабель передергивать?

Для конфигурирования оборудования USB применяется сплошь и рядом. Для управления оборудованием - нет. Собственно, точно то же самое было и с RS-232, для управления оборудованием его применяли разве что по недоумию. Впрочем, в таком случае и RS-485 был не впрок, чему есть масса примеров.

[A. Fig Lee]

Для конфигурирования оборудования USB применяется сплошь и рядом. Для управления оборудованием - нет. Собственно, точно то же самое было и с RS-232, для управления оборудованием его применяли разве что по недоумию. Впрочем, в таком случае и RS-485 был не впрок, чему есть масса примеров.

а что не так с 485?

[Xenia]

А чего не Wi-Fi?
Когда-то то действительно это было черезчур дорогим решением, но с тех пор WiFi-модули подешевели, сократившись в размерах. К тому же WiFi-роутер есть почти в каждом доме, а WiFi-точка в каждом ноутбуке. Опять же провода не надо тянуть, а радиус действия квартиру захватывает.

[=AK=]

а что не так с 485?

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

[kolobok0]

А чего не Wi-Fi?..это было черезчур дорогим...провода не надо тянуть, а радиус действия..

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

Сообщение отредактировал kolobok0 - Dec 9 2013, 22:44

[Plain]

Главный ум в таких зданиях — разводка звездой, т.е. как минимум по одному отдельному проводу от каждой точки до кросса в щитке, а уж какой протокол по ним запустить — дело десятое, т.е. всё сводится к соответствующего бюджета ремонту или первоначальному проекту. Типичный кабель для таких случаев — EIB Combi, три жилы 1,5 мм² и две слаботочных пары для данных и питания мозгов и интерфейса.

На фото — потолок и пол подводки к щитку обыкновенной квартиры 60 м², зелёненькие — как раз упомянутые умнодомные кабели EIB:

[A. Fig Lee]

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

И че делать? CAN?

[Xenia]

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

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

На фото — потолок и пол подводки к щитку обыкновенной квартиры 60 м², зелёненькие — как раз упомянутые умнодомные кабели EIB

Что же это такое? Неужели в умном доме можно (хотя бы теоретически) найти так много электрических приборов, чтобы для управления ими потребовалась такая уйма проводов?!

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

[Plain]

Неужели в умном доме можно (хотя бы теоретически) найти так много электрических приборов, чтобы для управления ими потребовалась такая уйма проводов?!

Приборы здесь не при чём, по-минимуму считаются только углы и свет — две комнаты, кухня, туалет, ванная, коридор — 24 угла и 6 светильников, по кабелю на каждую позицию. Ну и на кухне ещё надо дополнительных кабелей. Плюс по кабелю на каждый выключатель света.

В свою очередь, каждый угол — это т.н. гнездо, т.е. 6...10 силовых розеток, коаксиал, пара локалок и звук. А в данном проекте в каждой комнате ещё пара гнёзд шла по верху, плюс скрытых в потолке пара резервных кабелей. Силовая разводка в гнезде — это чередующиеся розетки от пары кабелей с разных УЗО и автоматов.

[andrewlekar]

Щас процентов 50 охранно-пожарной сигнализации ставится беспроводной. За рубежом так и все 80, пожалуй. Так что смело закладывайте для умного дома беспроводку: WiFi или RF 433 с WiFi шлюзом.

[=AK=]

И че делать? CAN?

Modbus RTU, Bitbus и т.п.

[ILYAUL]

Нет , коллеги , давайте разделим . Протокол или железо, что ТС нуно?
Если железо , то провода или радиомодули.
А уж из выбранного протокол.

[A. Fig Lee]

Modbus RTU, Bitbus и т.п.

Modbus RTU - это физический интерфейс?

[ILYAUL]

Modbus RTU - это физический интерфейс?

Это протокол.

[A. Fig Lee]

Это протокол.

И каким образом он может заменить RS-485?

Изначально я спрашивал, что если не RS-485?

[=AK=]

Изначально я спрашивал, что если не RS-485?

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

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

[NicSm]

=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.

[A. Fig Lee]

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

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

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

2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

[=AK=]

=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.

Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.

2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

[A. Fig Lee]

Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.


RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus?

[=AK=]

То бишь RS-422 самый стойкий к помехам?

RS-485 с правильным протоколом ничуть не хуже.

А CAN bus?

Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

[A. Fig Lee]

RS-485 с правильным протоколом ничуть не хуже.


Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

И при чем тут "правильный протокол"?

[=AK=]

И при чем тут "правильный протокол"?

При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка...

[Xenia]

Cкажите, кто знает, на какую длину можно тянуть UART? Не преобразовывая его в RS-232, а прямо так, сырой, между двумя МК на разных платах. Вопрос помехоустойчивости даже не поднимаю.

[Harbinger]

При скорости до 230400 - метр наверняка. Приблизительно такая длина была у дата-кабелей старых сотовых телефонов с преобразователем USB/UART в оболочке USB разъёма.

[blackfin]

При скорости до 230400 - метр наверняка.

Похоже на правду, учитывая что для старых жестких дисков стандарт PATA устанавливал максимальную длину кабеля равной 46 см и при этом рабочая частота интерфейса в режиме передачи Ultra DMA 100 равнялась 100/16 = 6,25 МГц.


И, кстати, обычный SCSI (то есть, single-ended) работал на частоте 5 МГц до шести метров.

[_4afc_]

Cкажите, кто знает, на какую длину можно тянуть UART? Не преобразовывая его в RS-232, а прямо так, сырой, между двумя МК на разных платах. Вопрос помехоустойчивости даже не поднимаю.

Дальность зависит ещё от выходных драйверов ваших МК.
В этом случае её можно увеличить поставив буфер, особенно при уровнях 1.8В.

[Xenia]

При скорости до 230400 - метр наверняка. Приблизительно такая длина была у дата-кабелей старых сотовых телефонов с преобразователем USB/UART в оболочке USB разъёма.

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

Ну, и раз уж про USART спросила, то спрошу уж и про SPI. Что мешает передавать далеко с его помощью? При этом клок SCK можно генерить даже не аппаратно, а ногодрыгом, чтобы более продолжительным получился. Т.е. замедлить скорость передачи на столько, на сколько потребуется.

Ведь в "умном доме" обычно не объемные дампы с АЦП передавать приходится, а какие-то простенькие короткие команды, типа "горшочек вари" или "горшочек не вари" . А если на линии напряжение садится, то ведь всегда можно сделать выход более мощным, продублировав более мощным ключом (повторителем).

[_Pasha]

Ну, и раз уж про USART спросила, то спрошу уж и про SPI. Что мешает передавать далеко с его помощью? При этом клок SCK можно генерить даже не аппаратно, а ногодрыгом, чтобы более продолжительным получился. Т.е. замедлить скорость передачи на столько, на сколько потребуется.

Да те же дифференциальные приемники и передатчики - и насколько угодно, хоть на 1 км. Только предварительно spi заменить на usart.

[Lagman]

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

Закон Ома существует или ...? Кто сказал что с увеличением длинны проводника не будет падать амплитуда (напряжение).

[A. Fig Lee]

При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка...

Не хамить воспитание не позволяет?

[kolobok0]

..велик соблазн..вашему пылесосу..за вашим котом ....по силовой сети сообщения..

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

по сетевой сети - стандарт вроде как X10 был. Но скорости оставляют желать лучшего. Да и не всегда есть эти 220. Например частенько
по правилам пожарной безопасности, при сработки сигнала "ОГОНЬ" - идёт отключение и 220 так-же.

...Не хамить воспитание не позволяет?

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

зы
обычно кто имеет хотя-бы немного опыты в пром. реализации RS485 - тот так и делает...

[Ruslan1]

Не хамить воспитание не позволяет?

перевожу на русский:
RS-485 имеет неопределенное состояние в случае, когда никто не передает. То есть состояние линии может быть любое и меняться с любой скоростью.
=AK= использует протоколы, которые чувствительны к этому, то есть они не имеют эффективной защиты от этого "горя".
Некоторые (условно назовем их "остальные") использует протоколы, которым все равно что происходит на линии в то время, когда данные по ней не передаются. Как результат- эти некоторые (и разработанные ими устройства) не видят разницу между "линией, в которой есть неопределенность при отсутствии передачи" и "линией состояние которой между передачами детерменировано"
Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:
1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.

[=AK=]

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

Уж не знаю, кто это имел ввиду, однако из этого сбивчивого описания я лично не выудил ровно никакого смысла. Паузу после передачи информации выдерживать бесполезно, поскольку все проблемы возникают до начала передачи или в самом начале передачи пакета, а приводят они к порче пакета.

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

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

Некоторые (условно назовем их "остальные") использует протоколы....

Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.

Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:
1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.

Хоть кол на голове теши. Я уже много раз повторил, что этот подход обеспечивает невысокую помехоустойчивость, которая в десятки-сотни раз уступает помехоустойчивости RS-485 с правильным протоколом, или помехоустойчивости RS-422. Я за свою жизнь вдоволь насмотрелся на поделки таких "гурманов", они хорошо работают на столе в лаборатории, однако бездарно глючат в полевых условиях.

[Ruslan1]

Хоть кол на голове теши.

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

Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.

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

Upd: Хм. перечитал себя. При некотором извращизме (ну, как минимум один так уже прочитал) действительно можно подумать, что я ратую заменить соответствующий среде передачи протокол на подтяжки. Никогда! Для меня наличие нормального протокола настолько очевидно, что я как-то и не подумал, что могут найтись люди, которые этого не понимают.
Пора начинать писать "комментарии" к себе, уж больно витиевато я выражаюсь.

[=AK=]

Какие сказки про белого бычка? Че за знаки "ты идиот"?

- а что не так с 485? -
- Объяснил первый раз
- И че делать? CAN?
- Ответил
- Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?
- Обьяснил второй раз.
- какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом? В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?
- Обьяснил третий раз.
- Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем
- Ответил
- И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.
- Обьяснил еще раз, однако отметил нарочитую тупость.
- Не хамить воспитание не позволяет? - ну точно, тролль, вишь как обрадовался кормежке
- совок он и есть совок, хоть куда переедь, из души не вытравить. - однозначно тролль, жирный и нахрапистый

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

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

[msalov]

То бишь RS-422 самый стойкий к помехам?

RS-485 с правильным протоколом ничуть не хуже.

А CAN bus?

Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом? Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры, а сравнение может быть только в конкретной ситуации.

[Dog Pawlowa]

вишь как обрадовался кормежке

Но может всё-таки не понимает?

Хотел бы уточнить насчёт CAN. ... Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры....

Если Вы нашли какое-то противоречие в словах, то лучше его указать. Вон как =АК= успешно отбивается, он несомненно объяснит.
А так получилась общая фраза. Разумеется Вы правы, в случае с CAN меньше места для творчества, но "всегда есть место подвигу".
Например, при распределении идентификаторов использовать нули там, где есть избыток битов. По идее это повысит надежность связи.

[msalov]

Если Вы нашли какое-то противоречие в словах, то лучше его указать.

Так и указал. Более слабая физика RS485 (из-за отключения передачика) + хороший протокол вкупе дают хороший результат сравнимый с RS422, а вот CAN с ещё более слабой физикой но с на порядок более надёжным протоколом (уже готовым, причём) почему то сравнили с аутсайдером обсуждения - RS485 + плохой протокол, без вариантов.

[=AK=]

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом?

Я говорил, что CAN, в силу своего слабоватого физического уровня, по помехоустойчивости не может тягаться с RS-485 c качественным протоколом. Его помехоустойчивость сравнима с помехоустойчивостью интерфейса на базе RS-485, где есть резисторы растяжки, но используется плохой протокол. "Жесткость" протокола, использование CRC и т.п. отнюдь не делают протокол автоматически "хорошим", а плохой физический уровень погубит любой протокол, как бы он ни был хорош.

Когда-то давным-давно я лично наблюдал за мытарствами неких изобретателей самопальных протоколов, которые свято верили в силу резисторов растяжки на RS-485. Программист незнамо зачем (сам он не мог объяснить своих мотивов) переводил трансивер в 3-е состояние после каждого переданного байта, то есть, делал нечто напоминающее физический уровень CAN. На объекте система дико и регулярно глючила, надолго теряя связь, что по условиям задачи было недопустимо. Туда в командировку несколько раз посылали электронщика. Его действия сводились к уменьшению сопротивления резисторов растяжки и замене кабелей на все более дорогие экранированные витые пары. Частота глюков немного снижалась, однако оставалась заметной, система работала ненадежно.

В случае CAN тишина до и после пакета позволяет уменьшить количество коллизий, однако никак не спасает от помех.

[Herz]

Господа! Воздержитесь от наездов! Не хватает терпения объяснять спокойно - никто не принуждает участвовать. Тему частично почистил.

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

Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

[ZASADA]

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

[=AK=]

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

Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

[Dog Pawlowa]

на порядок более надёжным протоколом

Это смотря в каких попугаях считать надежность. Если в попугаях достоверности контрольной суммы - да, CAN более надежен, чем какой-нибудь самопал на RS485.
Если в вероятности безошибочной доставки сообщения одинаковой длины в одинаковых условиях помех - тут уж извините, я согласен с =AK=.

[ZASADA]

Буржуи в курсе, поэтому ничего "жизненно-критического" на него не возлагают и за панацею не держат. Для fly-by-wire используют более надежный MIL-SDT-1553 и иже с ним. Для drive-by-wire предназначены flex-ray и TTP, и т.п. Для таких ответственных применений CAN не прокатывает. Вот домашнюю автоматику на нем собрать - самое оно, для этого почти чего угодно сойдет.

а какже самый надежный RS-422?

[AlexandrY]

Это смотря в каких попугаях считать надежность. Если в попугаях достоверности контрольной суммы - да, CAN более надежен, чем какой-нибудь самопал на RS485.
Если в вероятности безошибочной доставки сообщения одинаковой длины в одинаковых условиях помех - тут уж извините, я согласен с =AK=.

CAN - сетевой интерфейс. Надо рассматривать его надежность, дальнобойность и скорострельность в контексте сети.
Насколько жизнеспособна сеть с CAN, насколько CAN загружает узлы, как быстро сеть восстанавливается после нарушения физической целостности.
RS485 оcтается где-то жить только из-за MODBUS. Но cам MODBUS морально устаревший протокол. Нигде в нем каких-то особых средств поддержания жизнеспособности сети нет.

В условиях тяжелейших помех, отказа узлов , наличии приоритетных критических задач и сообщений CAN явный лидер.
Имею опыт применения CAN и на военных полигонах протяженностью в километры и в управлении локальными устройствами и в лифтах.
С успехом конкурировал и вытеснял решения предлагавшие RS485.
"Хороший" протокол на RS485 это такой "неуловимый Джо". А в реале съедает все силы разработчиков.

[Plain]

CAN - сетевой интерфейс.

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

[AlexandrY]

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

Хорошая тема для нового флейма - "отвественная задача". Странно, но википедия такого термина не знает.

[Plain]

В моём понимании, управление стеклоподъёмниками безусловно ответственная задача, чреватая увечьями и летальными случаями, а ведь именно для этого и была создана данная шина.

И я разрешаю воспроизведенние данного высказывания в упомянутой базе.

[Dog Pawlowa]

управление стеклоподъёмниками безусловно ответственная задача

Безопасность управления стеклоподъемниками обеспечивается на уровне драйвера, интерфейс связи (любой) в эту цепочку не входит вообще.
Я даже слышал байку о том, что ставят DSP, чтобы распознать коллизии наиболее достоверно.

[AlexandrY]

В моём понимании, управление стеклоподъёмниками безусловно ответственная задача, чреватая увечьями и летальными случаями, а ведь именно для этого и была создана данная шина.

CAN не мог быть создан для стеклоподъемников и даже для тысячи стеклоподъемников.
Он был создан для сети исключительно разнородных устройств разных по важности выполняемых функций.
И в этом его сила.
В современной машине применяют что-то около 200 микроконтроллерных узлов, если память не изменяет.
Даже если на всех одинаково "хороший протокол", то все равно у них не одинаково хорошие приложения.
И вот CAN с таким зверинцем идеально справляется. Забивает флудеров, приоретизирует сообщения, не требует квитанций, мапирует прямые передачи и проч.

[adnega]

По поводу помехоустойчивости. Диф.линия очень хорошо давит синфозную помеху. А в этом плане у CAN допустмо аж 80В на входе, вместо 12В для RS485. Хотелось бы увидеть макет, где в диф.линии появляется значительная по масштабу помеха (ну, вольт 10 хотя бы). И поместится ли такой макет
в квартире/доме?

[Ruslan1]

Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

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

[A. Fig Lee]

По поводу помехоустойчивости. Диф.линия очень хорошо давит синфозную помеху. А в этом плане у CAN допустмо аж 80В на входе, вместо 12В для RS485. Хотелось бы увидеть макет, где в диф.линии появляется значительная по масштабу помеха (ну, вольт 10 хотя бы). И поместится ли такой макет
в квартире/доме?

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

[AlexandrY]

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

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

[garlands]

вариантов два:
1) в процесс ремонта имеет смысл заложить провода
2) если ремонт уже есть и чтобы его не ломать - имеет смысл посмотреть в сторону радио. например, я себе делал подобное на NRF24L01/LE1.

[Harbinger]

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

десятки вольт наводки возможны

Трансилами срезать.

имеет смысл посмотреть в сторону радио. например, я себе делал подобное на NRF24L01/LE1.

Глушится на раз.

[garlands]

Глушится на раз.

Целенаправленно - да, как и вообще любое радио. А от всяких WiFi, BT и что там еще у нас на этой частоте вполне можно и отстроиться.

но

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

[=AK=]

а какже самый надежный RS-422?

На современном этапе вытесняется еще более помехоустойчивым интерфейсом точка-точка - оптоволокном.

[_Pasha]

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

Ну, микроволновки созданы специально для вайфая
Почему-то все дружно забыли про PLC... да не тот, что ПЛК!!- Power Line Communications

[=AK=]

Почему-то все дружно забыли про PLC... да не тот, что ПЛК!!- Power Line Communications

А про него все забыли. Поигрались и забыли. Ущемленный всякими ЭМС стандартами до полной убогости, и в результате дорогой, медленный, глюкавый. Всеобщий бардак в электропроводке делает результаты его применения плохо предсказуемыми: в одном доме работает, в другом нет, а в третьем работает, пока юзер не воткнет в розетку какую-то новую приблуду. Он вытеснен всякими RF, основные из которых я перечислил в начале треда.

[Herz]

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

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

[ZASADA]

а какже самый надежный RS-422?

На современном этапе вытесняется еще более помехоустойчивым интерфейсом точка-точка - оптоволокном.

вам осталось только назвать автомобиль с очень надежным RS-422 и без очень ненадежного CANа.

[=AK=]

вам осталось только назвать автомобиль с очень надежным RS-422 и без очень ненадежного CANа.

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

При том, что CAN не очень помехоустойчив, он довольно надежен. Кроме того, он дешев в реализации. Построение аналогичной системы на RS-422 или оптоволокне обойдется дороже. А в автомобилестроении каждая копейка на счету, вот его и применяют.

[Ruslan1]

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

Тут есть разночтение определения "все равно". Я имею в виду, что не-данные не приводят к каким-либо действиям приемника, индентичным реакции на прием настоящих данных. Приемник, конечно, слушает линию и может делать какие-то проверки, но это внутренние действия.
Причем "слушает" и "делает проверки" - это не обязательно только микроконтроллер. Например, компаратор приемника драйвера RS485 тоже слушает линию и переключает логический выход приемника при выполнении некоторых условий. Уровней может быть множество, и каждый следующий подключается к обработке только когда предыдущий отработал верно и передал что-то "выше".

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

[Dog Pawlowa]

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

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

И вряд ли опровержение этого банального факта может лечь в основу Вашей диссертации по философии

[Herz]

Тут есть разночтение определения "все равно". Я имею в виду, что не-данные не приводят к каким-либо действиям приемника, индентичным реакции на прием настоящих данных. Приемник, конечно, слушает линию и может делать какие-то проверки, но это внутренние действия.
Причем "слушает" и "делает проверки" - это не обязательно только микроконтроллер. Например, компаратор приемника драйвера RS485 тоже слушает линию и переключает логический выход приемника при выполнении некоторых условий. Уровней может быть множество, и каждый следующий подключается к обработке только когда предыдущий отработал верно и передал что-то "выше".

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

ОК, я бы назвал это просто: помехоустойчивым алгоритмом. Приёмник по определению не может быть безразличен к тому, что происходит на линии. Он вынужден реагировать на все изменения и анализировать их. Центральный контроллер, которому, в конечном итоге, предназначены данные, может не заниматься этой рутиной: функции распознавания и фильтрации помех просто выносятся на периферию. Но никаких чудес, конечно, не происходит: шина остаётся шиной со всеми её проблемами. И объём вычислений остаётся тем же.
Определяемый протоколом. Так?

[Ruslan1]

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

Я не вижу что тут опровергать и зачем. Вы ни коим образом не опровергаете мои слова.
То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

А философии действительно не хватает в приборостроении. Может, замутить новое течение... Философия переходов... Полупроводниковая диалектика.... Хм. Надо подумать.....

P.S.
топикстартеру, по существу: не бойтесь Вы CAN или RS485.
CAN сильно серьезней и лучше в подобных задачах с разношерстной аппаратурой . больше уровней ISO включает прямо в спецификацию и больше чего решает аппаратно внутри, до доставки дейтаграммы на программый уровень. CAN любит хорошие провода и правильное терминирование. Ну и меньше придумывать нужно, все уже придумано и стандартизировано, от Heartbeat до LSS (CANopen).

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

если CAN- то CANopen (все основное открыто или открывают после звонка/письма в головной офис, что закрыто- то доставабельно в интернете). Но CAN-приборы обычно дороже чем RS-485.
если RS485- то MODBUS RTU или ASCII (все открыто). Я только RTU пользую, но уже лет пять как к ASCII приглядываюсь- при приеме в компьютер с ним сильно проще.

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

ОК, я бы назвал это просто: помехоустойчивым алгоритмом. Приёмник по определению не может быть безразличен к тому, что происходит на линии. Он вынужден реагировать на все изменения и анализировать их. Центральный контроллер, которому, в конечном итоге, предназначены данные, может не заниматься этой рутиной: функции распознавания и фильтрации помех просто выносятся на периферию. Но никаких чудес, конечно, не происходит: шина остаётся шиной со всеми её проблемами. И объём вычислений остаётся тем же.
Определяемый протоколом. Так?

Так. Объем "вычислений" определяется физической шиной и применяемым протоколом. Примеры "вычислителей":
1) Компаратор с гистерезисом, определяющий переход больше 120 мВ
2)логический автомат приема бита, работающий по принципу совпадения 3 из 5
3) CAN: прием дейтаграммы ведется контроллером CAN, и какая его часть сделана аппаратной логикой а какая вшитой микропрограммой- это внутреннее дело разработчика МК.
4) уже пользовательское: разборка содержимого, счет CRC(тоже бывает вшитая микропрограмма), реакция.

[=AK=]

То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

А вы никогда не задумывались, что будет происходить при использовании ваших протоколов, если помех много и они приходят часто?

[qnx]

http://www.kernelchip.ru/Laurent.php
на сколько потенциально могло бы подойти найденное решение посредствам Ethernet?
п.с. если есть аналоги более дешевые предлагайте
данный протокол кажется удобным за счет разных возможностей коммутации, либо витой парой, либо дешевыми вайфай роутерами, на худой конец
какое-то устройство с разработкой и дебагом плат, даже для собственного применения трудоемкое, потому и хочу то, что под силу будет, не вникая в низкоуровневые протоклы смастерить.

[Ruslan1]

А вы никогда не задумывались, что будет происходить при использовании ваших протоколов, если помех много и они приходят часто?

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

Мне кажется, что это очевидно. Что именно Вас смущает?

Кстати, лет 17 назад сталкивался с таким: стояла в одной организации система сбора данных (ЦТ-5000), по республике у них было расставлено полтора десятка точек сбора. Там сложная каналообразующая аппаратура, передача по ЛЭП с переприемами, что-то поменять в канале связи практически невозможно. Так у них была одна точка, которая за много лет работы ни разу не смогла нормально завершить обмен данными с сервером. НИ РАЗУ. Ну, такой разработчики протокол применили, им же виднее было. Там помеха валила примерно каждый 15й байт (скорость выделенного канала была 100 бод). Мы в своем нижнем уровне тогда применили доморощенный протокол с длиной 11 байт, проработало много лет успешно.

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

Если "не мастерить и быстро-стандартно" - то Ethernet это идеальный вариант. В сочетании с технологией PoE вообще крастота. но проводами, wifi применим только как временное решение и для некоторых узлов.

Насчет конкретного линка- тут от метода покупки зависит, я бы начал с ебея-алиэкспресса,
Например, у этого болгарина целый склад вкусностей на эту тему (галантерейщики и кардинал, тьфу, телемеханика и езернет)
http://stores.ebay.com/DAEStore?_trksid=p2047675.l2563

[=AK=]

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

Вы ошибаетесь. Данные в этом случае не будут переданы никогда только в случае использования второсортных протоколов, которые вы ранее обозначили словом "остальные". А в случае использования протоколов, которые вкратце были описаны мною ранее, они будут успешно доставлены по назначению.

Не все так очевидно, как вам кажется.

Кстати, лет 17 назад сталкивался с таким: стояла в одной организации система сбора данных (ЦТ-5000), по республике у них было расставлено полтора десятка точек сбора. Там сложная каналообразующая аппаратура, передача по ЛЭП с переприемами, что-то поменять в канале связи практически невозможно. Так у них была одна точка, которая за много лет работы ни разу не смогла нормально завершить обмен данными с сервером. НИ РАЗУ. Ну, такой разработчики протокол применили, им же виднее было. Там помеха валила примерно каждый 15й байт (скорость выделенного канала была 100 бод). Мы в своем нижнем уровне тогда применили доморощенный протокол с длиной 11 байт, проработало много лет успешно.

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

[ZASADA]

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

При том, что CAN не очень помехоустойчив, он довольно надежен. Кроме того, он дешев в реализации. Построение аналогичной системы на RS-422 или оптоволокне обойдется дороже. А в автомобилестроении каждая копейка на счету, вот его и применяют.

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

[=AK=]

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

Судя по этой реплике, вам померещилось будто бы кто-то предлагает RS-422 как панацею для любых применений, включая "умный дом"? Раз с первого раза до вас не дошло, повторяю: для "умного дома" подходит почти что угодно, в том числе и CAN. Коммерческие EIB и С-Bus используют простейшие передатчики с открытым коллектором, и ничего, успешно работают в тысячах зданий.

[Plain]

http://www.kernelchip.ru/Laurent.php
на сколько потенциально могло бы подойти найденное решение посредствам Ethernet?

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

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

Например:

http://www.ebay.com/sch/i.html?_sacat=0&am...+spi&_frs=1

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

[A. Fig Lee]

Кроме того, сперва Вам надо найти под него соответствующий подрозетник, иначе все стены будут утыканы внушительными коробками.

http://www.leviton.com/OA_HTML/SectionDisp...;minisite=10251

http://www.kernelchip.ru/Laurent.php
на сколько потенциально могло бы подойти найденное решение посредствам Ethernet?
п.с. если есть аналоги более дешевые предлагайте
данный протокол кажется удобным за счет разных возможностей коммутации, либо витой парой, либо дешевыми вайфай роутерами, на худой конец
какое-то устройство с разработкой и дебагом плат, даже для собственного применения трудоемкое, потому и хочу то, что под силу будет, не вникая в низкоуровневые протоклы смастерить.

Во первых дорого. Во вторых, если надо чтото сложнее чем кликнуть реле придется более мощный контроллер брать, да и граблей там может быть больше.
Гладко только на бумаге. Проще всего RS-485 и не болит голова у дятла.
Ну или CAN, но уже думать придется.

[Plain]

A. Fig Lee, это у Вас всё разные розетки, а подрозетник — это коробка в стене, и соответствующая дыра под неё.

Плата, которыми автор собирается набить все стены, имеет размеры 100х135 — накиньте ещё 20% и больше, и ищите соответствующих размеров установочную коробку.

[Ruslan1]

Вы ошибаетесь. Данные в этом случае не будут переданы никогда только в случае использования второсортных протоколов, которые вы ранее обозначили словом "остальные". А в случае использования протоколов, которые вкратце были описаны мною ранее, они будут успешно доставлены по назначению.

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

[=AK=]

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

Я уже много раз ссылался на Modbus RTU. Если вы не понимаете, как он работает в условиях частых помех, поясню:
- в начале фрейма, еще до начала пакета данных, передатчик включает свой трансивер на передачу и выдерживает паузу в 3.5 байт-интервала, не передавая никаких байтов
- поскольку максимально допустимая пауза между байтами внутри пакета данных не может превышать 1.5 байт-интервала, все приемники успевают закончить прием ложных байтов, после чего, обнаружив длинную паузу на линии, очищают свои буфера приема от мусора, нанесенного помехами во время пассивного периода между фреймами
- после этого все приемники, без какой-либо коррекции ошибок, благополучно принимают неиспорченный пакет данных (передатчик, конечно же, гонит весь фрейм как одно целое, ни в коем случае не переводя трансивер в третье состояние во время фрейма).

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

[Herz]

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

Хорошее уточнение. По сути означающее то, что к хорошему протоколу нужна и хорошая линия связи. Ибо источник помех - это не только наводки на низкоомную цепь ЭМ излучения, но и плохие контакты, например. Нет?

[Ruslan1]

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

Вы издеваетесь? Сначала написали одно, потом "уточнением" изменили свою точку зрения на противоположную.

Я прекращаю реагировать на Ваши посты. Либо Вы действительно троль, либо неумный человек, и с тем и с другим разговаривать не о чем.

Хорошее уточнение. По сути означающее то, что к хорошему протоколу нужна и хорошая линия связи. Ибо источник помех - это не только наводки на низкоомную цепь ЭМ излучения, но и плохие контакты, например. Нет?

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


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

А помеха, которая глушается активным передатчиком- это классика, MODBUS RTU на это заточен. Это "хороший" протокол для линий, в которых помеха заглушается активным передатчиком. Если Вы попробуете необдуманно применить MBRTU на линиях, в которых помехи сильнее передатчика- он не справится, и, соответственно, перейдет в разряд "плохих" протоколов.

[=AK=]

Вы издеваетесь? Сначала написали одно, потом "уточнением" изменили свою точку зрения на противоположную.

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

Я прекращаю реагировать на Ваши посты. Либо Вы действительно троль, либо неумный человек, и с тем и с другим разговаривать не о чем.

Слив засчитан. Однако в вашем положении обтекать более пристало молча.

А помеха, которая глушается активным передатчиком- это классика, MODBUS RTU на это заточен. Это "хороший" протокол для линий, в которых помеха заглушается активным передатчиком.

Не переливайте из пустого в порожнее, речь все время шла о RS-485, для которого это всегда имеет место.

Вот здесь вы несли глупости на тему RS-485, a вот это объяснение - проигнорировали, очевидно, вcледствие непонимания. В этом диалоге o RS-485: 1 - 2 - 3 - вас практически прямым текстом спросили, как обеспечить помехоустойчивость, когда незадолго до начала пакета помеха навела ла линию ложный символ; из диалога видно, что в тот момент ответа вы не знали. И вот теперь, когда вам разжевали и в рот положили, и до вас, наконец-то, дошло, вы делаете поворот оверкиль и вместo "это невозможно" начинаете говорить "это очевидно" и обвиняете меня в "непоследовательности". Смешно.

[Dog Pawlowa]

Если возвращаться к теме, то я бы делал или на Ethernet или на Lonworks.
Для себя выбрал Ethernet, т.к. более универсальный, уже развел по 1-2 кабеля в каждое помещение, получилось как раз 16 - свич занят полностью.
Пока подключены интернет и прочее телевидение.
Единственно, что непонятно - нужен ли вообще "умный дом". Термоголовка надежнее привода клапана.
В планах только автоматический полив.

[ZASADA]

Ethernet хорошо, но пока дороже прочих решений и зачастую избыточен.

[Dog Pawlowa]

Да, это как дорогое бухло - дорого и избыточно

[fiim]

Ну как сюда не предложить такой вариант:Основная идея, И еще ссылочка:Ссыль

[psL]

Ну как сюда не предложить такой вариант...

еще немного и убийцо MODBUS будет готов...