[ZASADA 0]

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

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

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

[=AK= 18]

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

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

 

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

[Ruslan1 17]

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

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

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

 

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

[DogPawlowa 0]

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

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

 

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

[Herz 6]

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

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

 

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

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

Определяемый протоколом. Так?

[Ruslan1 17]

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

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

То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят 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= 18]

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

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

[qnx 0]

http://www.kernelchip.ru/Laurent.php

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

п.с. если есть аналоги более дешевые предлагайте

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

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

[Ruslan1 17]

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

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

Это классическая ситуация, когда среда передачи и протокол не соответствуют друг другу (неправильный выбор).

 

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

 

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

 

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

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

 

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

Например, у этого болгарина целый склад вкусностей на эту тему (галантерейщики и кардинал, тьфу, телемеханика и езернет)

http://stores.ebay.com/DAEStore?_trksid=p2047675.l2563

[=AK= 18]

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

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

 

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

 

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

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

[ZASADA 0]

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

 

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

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

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

 

[=AK= 18]

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

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

[Plain 228]

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 0]

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

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

 

 

http://www.kernelchip.ru/Laurent.php

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

п.с. если есть аналоги более дешевые предлагайте

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

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

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

Гладко только на бумаге. Проще всего RS-485 и не болит голова у дятла.

Ну или CAN, но уже думать придется.

 

[Plain 228]

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

 

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