Нужно сделать сеть 1 Мбит, до 20-30 устройств. Топология шина, длинна не более 15м.
Думал сначала почти однозначно RS485, но есть и другие идеи =)

Т.к. сеть не большая, хотелось бы обойтись без драйвера одной токовой петлей и, предположим, АТмегой на внутреннем РЦ генераторе 8 МГц. В связи с этим есть идея сделать нечто на СИНХРОННОМ уарте. Использовать шлейф IDC с разьемами в нужных местах, , типа как в ПК шлейф IDE, питание тоже по нему на слейвы подавать.
Теперь вопрос =)
Нужно ли оно? Какие могут быть проблемы-сложности?
Может лучше сделать стандартный рс 485 с витой парой и драйверами и кварцами на слейвах?

Вроде все. Спасибо за внимание )

А где сетка будет эксплуатироваться? В каких условиях? Если для промышленного применения (где-нибудь в цеху), то IMHO "другие идеи" лучше сразу отбросить. Сделать на RS485, желательно с гальванической развязкой.

В жилых/нежилых помещениях. Впринципе могут поблизости быть эл. двигатели до пары кВт =)

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

Можно еще CAN сделать, на такой длинне.

Можно. А какие преимущества?
Вообще программная реализация будет не стандартная. Поэтому вопрос чисто по физическому уровню..
ОЧЕНЬ хотелось бы использовать вместо витой пары шлейф, даже если рс 485. Опять-же хотелось бы обойтись без драйверов на слейвах или вообще синхронным уартом.
И интересует чем это может быть плохо) Или хорошо. А то что можно много всего сделать это понятно конечно =)

Резкое уменьшение трафика из-за отсутствия ведущего. Т.е. все будут посылать сообщения только если у них произошло к.л. событие. В RS485 обычно 90% сообщений типа таких: Ведущий: Ведомый N17, у тебя что-нибудь случилось? Ведомый N17: У меня всё в поряде.

Тогда сделайте USART с драйверами от CAN. Недостатков, в вашем случае, по сравнению с RS485 нет (кроме цены драйверов), а преимущества есть, и немалые. Поищите по форуму - такой вариан рассматривался.

Не понял. Мегабит без драйверов на 15 метров?

Ну это мне не актуально т.к. опрос будет идти постоянно и чем чаще тем лучше.
Считаем что данные меняются постоянно.



Да =) Считаете, что не выйдет? С синхронной передачей?
Хотя поставить 485й драйвер я уже пожалуй не против.

А скажите плз насколько в моем случае принципиально использовать витую пару
по сравнению с шлейфом под IDC(шаг 1.27мм)?(Если таки окончательно решусь делать РС485)

И совсем не обязательно организовывать обмен именно таким образом. Можно, например, так: свободна линия и есть, что передавать - передаем, занята - ждем. В посылке можно указывать адрес получателя. Физический уровень RS485 это, вполне, позволяет. В отличие, например, от сдвоенных линий RS422 или прямых соединений UART. И физический конфликт на шине (одновременная передача многими) для RS485, как правило, не приводит к катастрофическим последствиям - выходу из строя драйверов. А вот в случае прямого объединения UART - это не гарантировано.
Потом, все таки, RS-485 - стандартное решение, есть готовые драверы... А вот способен ли UART МК "прокачать" 15-ти метровую линию на 1МГц - большой вопрос. И не "собрать" при этом все возможные помехи и наводки.... В общем, на физическом уровне, я бы выбрал RS485, как оптимальный вариант для небольших скоростей обмена по соотношению цена/качество. Конечно, я не совсем объективен, так как, в основном, занимаюсь промэлектроникой.
А на программном уровне - останется полная свобода действий. Почему обязательно асинхронный обмен? Можно и синхронный, если есть такое желание. Единственное ограничение - полудуплексный режим обмена...

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

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

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

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

Конечно, такая система сложнее в реализации, но имеет полное право на существование.

PS Наглядный пример - пожарная сигнализация, соответствующая стандарту EN54. Время реакции на сигнал "Пожар" не должно превышать 10 секунд, на неисправность - 100. Как раз идеальный случай для приоритетных событий, передаваемых инициативно. С другой стороны, если из девайсов постоянно выгребаются какие-то данные типа уровней постоянно меняющегося аналогового сигнала, инициативная передача особого выигрыша не даст, проще выполнять банальный циклический опрос. Кстати, именно по этому надо стараться переносить обработку в девайсы, и гонять по каналам связи как можно меньше информации

Можно добавить в систему аварийное сообщение от "слейва" мастеру. Начало - более 9 нулей. CAN (под uart) в этом случае весьма полезен - все передатчики слушают эхо и в случае чего затыкаются.
В общем, если нет проблем с ценой драйверов и длинна 15 метров - CAN (полный или только физически) лучше. В остальных случаях я (бы) выбрал RS422 и объединение всех концов в хабе. Для исходных параметров драйвер обязан быть, витая пара весьма желательна, терминировать концы (485/422) необязательно.

У меня всегда одно из событии, случившихса у ведомого, называется "я жив" - подаётся например каждую секунду или так "я жив уже 156.6 секунд". Я как-то забыл об этом написать. Но когда у ведомого случаются более приоритетные события он говорит о них, и при этом считается, что он жив (ватчдог его жизни взводится). В случае CAN - сообщение "я жив" обладает низким приоритетом и совершенно не мешает другим сообщениям. При скорости 125 кбод (а не 1 мбод, как у топикстартера) 64 девайса посылающие сообщения "я жив" каждые 100 милисекунд совершенно не мешают друг-другу. Вообще-то они самоограничивают частоту своих событий, т.е. говорят о них не чаще, чем раз в 20 милисекунд (кроме редких сверхприоритетных). Но такое самоограничение всегда полезно.
К тому-же если в данный момент в сети только 3 устройства, ведущий не будет тратить время на опрос остальных 60-ти. И в сети ОДНОВРЕМЕННО могут находится 64 девайса, а всего их м.б. много больше. Да и за счёт отсутствия собственно пакетов запроса и ожидания (безрезультатного) ответа на них (а м.б. пакет от ведущего был просто повреждён и нужно повторить запрос) ещё трафик уменьшается. Т.е. кругом сплошные преимущества.
Кстати мне кажется, что у топикстартера 1 мбод - это многовато. Возможно это как-раз из-за опроса?

Для USART с драйверами CAN длина будет побольше, т.к. там поменьше требования к самоприёму. Практически можно использовать те-же значения, что и у RS485.

2 @Ark
А вот с драйверами RS485 мультимастерность крайне ограничена (из-за неинформативности самоприёма). Я бы даже сказал губительна для реалтайма, т.к. пока девайс не выдаст ВЕСЬ свой пакет он не узнает, что была коллизия. Да и восстановление после коллизий может затянуться. Пример - эзернет.

Подредактировал. Извините за повторы. Около 0.00 всегда интернет затыкается.

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

Кроме того, эзернет на общей шине давно мертв.

На этом наверное и остановлюсь. Под синхронным я имел ввиду не обмен, а сам физ уровень тоесть клок+дата =) Но уже от этого отказался.



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

Кстати спасибо всем ответившим =)



Можно поподробнее про конци и хаб? ) Зачем это нужно и что куда обьединять?

Согласен. Я плохо знаю эзернет. Давным-давно попробовал и понял, что реалтайма от эзернета добится не получится, с тех пор и забросил т.к. все задачи у меня с жёстким реалтаймом связаны. А вот насчёт общей шины я не знал... Я считал, что до сих пор хабы пакеты во все стороны передают. Раньше ведь так было? Т.е. хоть шина и не общая, но везде кол-во пакетов одинаковое. Разве не так? Кстати не подскажете где бы про нынешнее состояние эзернета почитать?
Простите за оффтоп.
Но вот в случае мультимастерности на RS485 смысла в преамбулах я не вижу. Т.е. я имел ввиду, что сам пакет (он д.б. достаточно коротким) будет играть роль преамбулы.

"Ожидания не будет т.к. ждётся следующий" - несколько противоречиво...
1. Что будет делать ведущий RS485 после того, как он отправил ведомому пакет?
2. По каким признакам ведущий сможет узнать был-ли пакет отброшен ведомым т.к. CRC не совпало или ведомый просто сдох?
3. Если один из ведомых на некоторое время сдох, а потом опять заработал (например ватчдог перезапустил его процессор) восстановится ли связь с ним в вашем случае?

Давно не так. Свичи коммутируют пакеты только туда, куда надо. Если это конечно не широковещательные пакеты.



Дык хоть в закромах, хоть в инете берете комплект стандартов IEEE802.3 и курите до состояния дзен

Это для начала.

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

2. Ну просто сдох это как-то не тривиально =) Но вообще в каждом ведомом будет структура типа отладочная, отдельно запрашиваемая, в которую каждый ведомый заносит свое кол-во ошибок црц, оверфлов, может что-то еще.. И сдохший находится т.к. он ее вообще не выдаст) Как также находится и например плохо обжатый провод по большому кол-у ошибок относительно первых ведомых в сети.
Да, это в компутер выводится.. Как собственно и данные в\из сети.

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

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



Топология - звезда на RS422, один конец от каждого девайса заводится на хаб, где они и объединяются в общую шину. Другой вариант - объединяются все TX слейвов на RX мастера и RX слейвов на TX мастера.



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


Хабы передают. Свитчи - не передают.

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

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

Вот проблема, для электронщика.



Вы, видимо, совсем неправильно поняли. Соединение точка-точка, поэтому я пишу RS422, а не RS485, все передатчики всегда включены, а общая шина получается внутри хаба, за трансиверами. Второй вариант - трансивер мастера подключается наоборот. Аплинк, если хотите.

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

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


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


Что вы, в самом деле, на четыре провода еще поискать придется. Проще найти на восемь. А на два - так вообще экзотика. Если только не гоните сотню-другую пар одновременно. Но это совсем другая история.

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

А вообще драйвер CAN стоит одинаково с драйвером RS422. Так что никаких преимуществ. А вот почему USART с драйверами CAN широкого распостранения не получил лично я не понимаю. М.б. это из-за отсутствия стандарта? Так давайте подумаем о стандарте. Или это лучше в оффтопе делать?

Шутите? Витуху на резисторном мосту соединять? Смысл??? 8мипортовый свич стоит менее $10 в любом ларьке.

Совсем не так. Несклько чипов, трансов, разъемов, блок питания...



Разница в цене с RS422 в два-четыре раза.
А если делать дуплексную передачу, то потребуется два драйвера CAN. Так тоже делал. После непродолжительного рассмотрения собранной платы пришел к выводу, что это как минимум неэстетично. Извращение, короче.



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

Найдите сейчас ядра хабов в виде Ваших "нескольких чипов".

Забудьте уже про хабы. Считайте, что их нет.



Ну, во-первых есть X-Port. Правда, это не очень бюджетно.
Во-вторых - есть WizNet. Дешевле. Стек реализован прямо в нем.
В-третьмх - есть всякие чипы аля ENC28J60 (или новые Micrel'овские). Тут уже стек внутри проца надо делать. Но цена еще ниже.
В-четвертых, на форуме я выкладывал дешевое решение озернечивания устройства. Там разговор идет о единицах долларов на все - т.е. сравнимо по цене с RS485.

Почему же ? Есть объективные причины считать, что они есть. Детерминированный реалтайм, например.


По таким ценам можно считать, что их и нет. Не нужно, как минимум.


Вкратце ?

Да сколько уже можно носиться с этим жупелом под названием "реалтайм". Допустим, пакет будет битый. Че делать-то? Время подошло, а данных нет. Какой же тут реалтайм?



http://electronix.ru/forum/index.php?showtopic=44276

Не вижу тут разницы между уарт и эзернет.

Объясните мне тогда, какой такой сакральный смысл вкладывается в понятие "realtime"?

Да, неплохо, уже тем, что работает. Я подобное пытался сделать еще в пору 90s2313 (без PHY) Но толи кварц был кривой, толи руки с головой, так и не смог завести. Сейчас можно помучать иксмегу на туже тему - весьма располагает. Возможно, атмелы ее под это и затачивали в т.ч.



Спор не о реалтайм, а о свитч вс хаб. Так вот, свитч - вещь в себе, а хаб - прозрачен по сути своей работы. В остальном свитч лучше.

Я Вам больше скажу. Я на основе этого дела серийные устройства выпускаю

Щас неспеша думаю над следующей стадией. Еще дешевле

Готовый девайс с коробкой и документацией за $30 в розницу ? Или только модуль эзернет ? )

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

Потом, конечно, и удешевление девайсов на основе этого дела.

Да и смотря какой девайс. Такой - http://shop.wild-mix.com/product_info.php?...;products_id=32 - $25 в розницу.

Хотелось бы пару гигагерц, да пару гигабайт...


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


зы:

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

У вас старые данные - драйвера CAN сильно подешевели. На прошлой неделе купили 100 шт. MCP2551 по 37 руб. (осенью около 27 руб. стоили). А там ведь даже защита от подвешивания сети доминантой есть (ограничение длительности)! А по прайсу ADM4857AR стоит $1,2. Т.е. даже дороже! Хотя я понимаю, что скачки курса, старые запасы и т.д. Но тенденция однако...
Дуплекс на CAN драйверах это конечно будет неэстетично. Я даже сказал бы, что это изврат. Все преимущества теряются + куча лишних проводков. Зачем???


1. Гарантированное время восстановления после сбоев.
2. Отсутствие таких ситуаций, когда различные узлы расходятся во мнении о том, что происходит в сети. В т.ч. и по поводу того, битый этот пакет или нет.

Прекрасный пример реалтайма - CAN.

Мне нужна была скорость передачи и возможность мультиплексировать линию TX мастера. Ждать на симплексной шине пока слейв отключиться (и тем более таймаута) очень и очень долго.
зы: Rs422 брал где-то по 7 рублей, CAN - по 30.

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

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

Причем тут приставка "гига"?



Смысл Вашей фразы ускользает от меня напрочь. И логическую цепь xmega - ethernet построить никак не получается.



Нормальная цена. Оптом (от ста штук) девайс, ссылку на который я дал, стоит $21.



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

Затем, что выходы CAN можно объединять на шине, а выходы RS422 только в хабе. Есть, конечно, и безхабный вариант, но он несовсем правильный.


Зачем, какая разница ? Это же вещи с минимальным уровнем сложности.



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


Нужно построить ethernet на xmega only. Тогда девайс имеет право остаться в нижнем сегменте, с экономией пяти-десяти баксов.


А калькуляцию можно увидеть ?


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

Это как самоцель? ATMega168 уже не рулит? Или Вы хотите воткнуть 2 пары прямо на камень ATXMega без всяких посторонних привесов рядом (например, у меня функцию этого привеса выполняет RTL8201 за $1...1.2)? Если второе - то удачи



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



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

Да. Без всяких (кроме транса и около него) посторонних привесов. На 2313 мог быть собран передатчик, а а иксмеги может хватит и на прием.


Не совсем. Хочу знать, что сколько стоит в ваших краях, чтобы знать потенциальные резервы. На вскидку, тот девайс я бы и по себестоимости в $25 не вошел.


А как вы понимаете реалтайм ? Это ведь не "послали пакет - 100% приняли пакет", а "послали пакет - 100% приняли пакет за заранее оговоренный промежуток времени". Поэтому и 1s и 1us могут считаться реалтаймом если такое время принято и пакет за него доставлен.



Хм, задумался...

Допустим мы решили, что 3 ошибки из-за помехи подряд возникнуть не могут. Постановили, что вероятность такого события в нормальных условиях равна нулю. Подобно тому, как считается, что вероятность совпадения CRC у пакета, разрушенного помехой, равна 0. А если таких допущщений не делать, то получается, что вообще передавать ничего нельзя (чёрная дыра нам). Тогда получается, что данные гарантированно передадутся за тройное время передачи пакета. Это справедливо в случае CAN (конечно там для этого нужно с приоритетами поработать, но они для этого и предназначены). А вот в эзернете (каким я его знаю) не так. Там в момент исправления ошибки передачи вполне может ещё к.л. влезть и ещё коллизию создать. Там ведь арбитраж тормозит передачу пакета у обоих девайсов в отличие от CAN, где девайс с высшим приоритетом даже не заметит, что была коллизия. А т.к. сеть в это время перестала передавать, то это даже весьма вероятным становится. А там ещё кому-нибудь передать что-то захочется - опять коллизии. Т.е. сбой нарастает как снежный ком. Можно ещё рассмотреть случай когда связь пропадала, а потом восстановилась и все дружно друг-другу мешать начали. Но и без этого всё ясно.
А в том посте я забыл добавить 3-м пунктом неразрушающий арбитраж.

Так там просто нужно было поставить RS485 драйвер и всё. Зачем там CAN драйвер?
А если уж вам так хочется съэкономить 20 руб. на драйвере, и вы даже готовы из-за этого ставить всякое барахло, рискуя, что оно своим отказом повесит всю сеть. То почему бы не использовать самый китайский драйвер RS485 в режиме CAN. Вообще-то название "режим CAN" я изобрёл только-что. Не знаю как это правильно называется.

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

Я-то как раз всё понимаю. А вот вы - нет. Когда я пишу "драйвер RS485" или "драйвер CAN" это значит, что используется такая микросхема, а не протокол. Неужели не понятно?
А в том, что увеличив кол-во проводов и драйверов линии в 2 раза и добавив ещё кое что, можно несколько (меньше, чем в 2 раза) повысить скорость у меня никаких сомнений нет. Только тогда об экономии говорить уже не приходится.

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


В моих кабелях идет по 4 пары. То, что вы 3 из 4 не используете, цену кабеля не уменьшает. И даже два драйвера RS422 стоят в два раза дешевле, чем один драйвер CAN. Впрочем, это уже неоднократный байан.

Вот именно. А вы в том случае, когда нужна одна поставили 2 других.

Я использую USB-шный кабель. Там всего 2 пары. Одна витая пара (провод потоньше) используется для передачи данных и одна невитая пара (провода потолще) используется для питания устройств.

Но даже один драйвер RS422 стоит дороже, чем один драйвер RS485, не говоря уже о соотношении цен у 2-х 422-х к одному 485-му. А то, что он будет использоваться в режиме CAN, его цену не увеличивает. Вот раньше не было драйверов CAN стойких к радиации, а драйвера RS485 такие были. И в сетях, работающих по протоколу CAN, (там где по ТУ радиация) использовали драйвера линии RS485. Что мешает использовать их так сейчас? Но уже не из-за радиации, а из-за цены. Хотя я лично бы не стал так делать из-за копеечной экономии.

Я уже задавал вопрос (в другой ветке) - поделитесь, зды, схемой. Только не драйвера, а ресивера физики CAN на трансивере RS485. То что я видел - не впечатлило. Хотя один из таких вариантов на печатке у меня потенциально заложен.



А я знаю, почему я так сделал. И совсем не потому, о чем вы пишете.


Так он же короткий. А паять его произвольной длинны - не подарок.


Нет, для меня RS485 - $0.5, RS422 - $0.3

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