Гальваническая развязка САN шины Опции

[Alb]

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

[spf]

Возникла такая задача - нужно гальванически развязать CAN шину (т.е не между контроллером и трансивером, а между трансиверами).

И в чем же великая необходимость такого изврата?

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

Может просто не ставить "недополнительный контроллер"

PS:
Если нужен хороший ответ, потрудитесь задать хороший и полный вопрос... телепатов тут нет

[cebotor]

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

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

[Shandy]

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

[Shandy]

Упустил из виду - между U17 и микроконтроллером должен стоять еще один CAN-драйвер, общий для всех каналов. Он у меня на другом листе нарисован.

[spf]

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

ИМХО: Вместо того, чтобы городить подобный огород, лучше развязать всю CAN-шину и вообще забыть про общую "землю".

[Buravtsev]

ИМХО: Вместо того, чтобы городить подобный огород, лучше развязать всю CAN-шину и вообще забыть про общую "землю".

Правильно! Профессионалы так и поступают.
Вместе с сигнальными линиями идут два провода питания шины, развязанные от всего через DC/DC конвертор с гальванической изоляций. Это питание применяется только для CAN-трансиверов в каждом устройстве, поэтому и мощность источника питания весьма невелика.
Если надо, могу дать примерную схемку.

Сообщение отредактировал Buravtsev - Apr 30 2007, 12:43

[Shandy]

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

[Buravtsev]

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

В там случае надо знать следующее:
1. Параметры портов "черных ящиков"
2. Параметры ЭМС "черных ящиков"
3. Требования к ЭМС всей системы.

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

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

[spf]

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

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

На роль моста подойдет любой контроллер с двумя CAN-овскими модулями (PIC, или что-то на базе ARM7, например от Atmel или Philips).

У Fujitsu тоже имеются такие МК

[Shandy]

Хочу или не хочу я что-то подключать, никого особенно не интересует. Это моя работа, за которую платят деньги.
Я не совсем точно выразился, ящики не "черные", протокол и все прочее известны. Заставить производителя переделать аппаратную часть интерфейса "под себя" практически нереально.
Проблема в том, что кроме CAN из них выходят также аналоговые сигналы, и работать это будет в промышленных условиях, поэтому соединять земли крайне нежелательно.
На мой взгляд, пассивное развязывающее устройство сделать проще и дешевле - спаяли плату и все сразу работает + не надо писать и отлаживать доп. программы для хаба, там и без этого проблем хватит.
Время - деньги ©

[Buravtsev]

У Analog Devices есть цифровые изоляторы iCoupler типа ADuM1400 и т.п.
Вот их сводная таблица:
http://www.analog.com/Analog_Root/static/p...alIsolators.pdf

Или запустите по сайту поиск по iCoupler. Еще где-то попадалась статья про них на русском языке.

Кстати, удовлетворите мое любопытство - нахрена с CAN-овскими сигналами пускать аналоговые? И как это выглядит?

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

Так что еще раз повторюсь, все должно вытекать из требований, предъявлемых к устройтству по ЭМС. Может, вполне достаточно фильтры по цепям питания поставить и смело объединять земли.

[Shandy]

Если вернуться к первоначальному вопросу, то он звучал так: "Как гальванически развязать шину ?".

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

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

[d'Bill]

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

[KRS]

А мы ставили IL711 от NVE
а теперь начинаем SI8421 от silabs они в разы дешевле, а по корпусу и ногам совместимы

[Седой]

Репитер, созданный по схеме, работать не будет.

[Denisvak]

Как-то делали оптическую вставку в CAN. Что-то типа оптических модемов если грубо. Думаю можно приспособить как-нить

Код

CAN        modem      оптика        modem      CAN
====<>|         |-------RX--------|          |<>=====
      |         |-------TX--------|          |

Сообщение отредактировал Denisvak - Jul 5 2007, 18:12

[Mos]

Репитер, созданный по схеме, работать не будет.

Я так тоже дмаю

[Hardman]

Это не репитер, это триггер (не)работающий на CAN.

[syoma]

Кстати имеет ли значение отдельные линии питания CAN трансиверов и контроллеров. Т.е. что лучше - вести везде четыре провода - Земля +Питание, CANH СANL, а затем с помощью DC/DC получать питание от этих линий для удаленных устройств?
Или можно вести 6 проводов Земля+питание для CANа, Земля+питание для схем и CANH и CANL. Но в таком случае я как понимаю гальванической развязки между устройствами не будет, хотя передаваться будет только питание.
Или вообще не заниматься ерундой, если расстояние менее 200м?
Может кинете ссылкой, как лучше сделать развязки?

[Mos]

Кстати имеет ли значение отдельные линии питания CAN трансиверов и контроллеров. Т.е. что лучше - вести везде четыре провода - Земля +Питание, CANH СANL, а затем с помощью DC/DC получать питание от этих линий для удаленных устройств...
...вести 6 проводов Земля+питание для CANа, Земля+питание для схем и CANH и CANL. Но в таком случае я как понимаю гальванической развязки между устройствами не будет, хотя передаваться будет только питание.

Развязки не будет. Не забывайте о том, что по проводам питания иногда протекают токи Которые могут создавать наводки на КЭН. Поэтому, задачи объединения узлов в сети КЭН и питания узлов лучше не смешивать. Ведь не обязательно, чтобы сеть питания повторяла топологию илний связи. Короче, питайте Ваши узлы каждый посвоему (где-то 220 с 2-мя втор. обмотками - одна для схем, одна для КЭНа, гдето один блок на все схемы и при этом каждый КЭН - через свой отдельный ДСи/ДСи от питания соответствующей схемы и т.д.).

Может кинете ссылкой, как лучше сделать развязки?

Реализовать развязку КЭНа красиво и дёшево НЕ возможно. Например, потому, что:
-для развязки потребуется дополнительное преобразование КЭН-ТТЛ, и ТТЛ-КЭН. Это осуществляет КЭН-трансивер и делает он это достаточно медленно (даже тот, который 2МБпс) -> Вам нужно будет либо сильно увеличивать Prop_Seg, что повредить Phase_Seg* либо сильно снижать скорость (примерно в 2 раза). А это значит, что можно просто поставить активный повторитель (он решит проблему, но сам, по своей идеологии является устройством, морально мёртвым, ещё даже не родившись см. book.itep.ru, раздел про повторители Изернет). Построить пассивный быстродействующий повторитель невозможно из-за медленных трансиверов (никто их не делает, хотя могут, быстрыми т.к. "стандарт не требует");
-если забить на скорость то сразу же встаёт другая проблема: повторитель должен принемать сигнал, преобразовывать его в своё внутреннее состояние и выдавать на остальные порты. Если кабельные сегменты, подключённые к повторителю, будут разной длинны (а иначе никому и не надо), они будут обладать разной ёмкостью, и в то время, когда все сегменты передут в рецессивное состояние после доминантного, самый высокоёмкостной ещё будет в доминантном и выставит ЛОЖНЫЙ доминантный импульс в состоянии повторителя. Вот.

[Sergey Makarov]

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

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

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

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

[galjoen]

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

Чтобы заработала развязка - логика, управляющая ей, должна знать скорость передачи и понимать CAN протокол. Иначе конфликтов не избежать. Придётся смотреть откуда SOF пришёл и кто арбитраж выиграл... Поэтому на рассыпухе это сделать невозможно. И в любом случае - будет вносится задержка. Причём не только драйверами и развязкой, но и самой логикой.
А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

[Sergey Makarov]

Чтобы заработала развязка - логика, управляющая ей, должна знать скорость передачи и понимать CAN протокол. Иначе конфликтов не избежать. Придётся смотреть откуда SOF пришёл и кто арбитраж выиграл... Поэтому на рассыпухе это сделать невозможно. И в любом случае - будет вносится задержка. Причём не только драйверами и развязкой, но и самой логикой.
А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

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

А мы ставили IL711 от NVE
а теперь начинаем SI8421 от silabs они в разы дешевле, а по корпусу и ногам совместимы

А вы их ставили на CAN шине? В документации про CAN ни слова

Сообщение отредактировал Sergey Makarov - Nov 13 2009, 06:24

[Седой]

Чтобы заработала развязка - логика, управляющая ей, должна знать скорость передачи и понимать CAN протокол. Иначе конфликтов не избежать. Придётся смотреть откуда SOF пришёл и кто арбитраж выиграл... Поэтому на рассыпухе это сделать невозможно. И в любом случае - будет вносится задержка. Причём не только драйверами и развязкой, но и самой логикой.
А вообще, это на каком-нибудь самом дешёвом AVR с тактовой 20 мГц можно сделать. Например, ATtiny2313 или ATmega48 подойдут. Но до скорости не более 500 кбод.

На рассыпухе все прекрасно делается. (Скорость передачи и протокол не играет роли)
Но чтобы с ней не маятся, используем PLD.
PS. Логическая схема репитера изложена в каком-то из документов Cia.
PS2.Проблемы, указанные Mos, могут наблюдаться.

[galjoen]

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

Да, конечно. Я такую реализацию видел. См. в интернете сканматик. Так там используется ATtiny2313, и ничего, с J1939 нормально работает. Да и ничего особо сложного там нет. Возможно я как раз чем-то подобным и займусь в недалёком будущем...

А вы их ставили на CAN шине? В документации про CAN ни слова

Это гальваническая развязка, при чём здесь CAN документация?

На рассыпухе все прекрасно делается. (Скорость передачи и протокол не играет роли)
Но чтобы с ней не маятся, используем PLD.
PS. Логическая схема репитера изложена в каком-то из документов Cia.
PS2.Проблемы, указанные Mos, могут наблюдаться.

Да, я тоже подумал, что на самом деле это гораздо проще, чем мне сначала показалось.
У меня получилось, что всего один триггер, который управляет направлением передачи, нужен, и несколько логических элементов. Когда в обоих подсетях рецессивный уровень, триггер имеет возможность переключится от любой из подсетей. Т.е. он следит за тем, в какой части доминанта первой появилась. Например, она первой появилась в части N1. Тогда триггер направление передачи на "из подсети N1 в подсеть N2" переключает, а сам, до тех пор пока в подсети N1 рецессивный уровень не появится, переключатся не может. Когда в подсети N1 рецессивный уровень появится - триггер получает возможность переключаться. И если в этот момент в подсети N2 доминанта, он переключится на направление N2 -> N1. Если в N2 рецессивный уровень, то опять будет следить за тем, где доминанта первой появилась (в это время направление передачи не имеет значения). А если подсетей больше 2, то просто переключается передача от подсети Nx ко всем остальным.

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

[Itch]

Весь хаб:


Отдельный его элемент:


P.S. На здоровье

[Mos]

Лично я с большим недоверием отношусь к решениям типа КЭНовского хаба, приведённого выше. Сама идеология КЭНа, равно как и TIA/EIA-485 изначально не предусматривала повторителей физического уровня (а хаб - это частный случай такого повторителя; не важно, что он служит только для развязки). Хотя маститые конторы (типа TI, MAX и т.д.) предлагают решения данных задач, всё равно возникает куча оговорок и выглядит это всё как-то слегка СР@НО.
Приведённый выше хаб - решение для КЭНа (данное решение уже не раз мелькало на форуме, но у Cia я его не встречал (но особо и не искал)).
Для 485-ого предлагается решение на основе некоторых драйверов (не помню каких). Идея такая: если драйвер хочет выставить лог. "0", то выставляет и всё. Если лог. "1", то он выставляет этот уровень и через малый промежуток времени (типа четверти битового интервала) переходит в "Z" (это можно былобы и на контроллере сделать, при программном USARTе, путём упр. ногой DE, исп. любой драйвер, а не наворочаный).
А КЭНовский хаб должен защёлкнутся (до снятия питания)!
(тынц)

2 Shandy:
насчёт необходимости развязки CAN-bus:
может быть следует уточнить, действительно ли нужно отвязывать КЭН ТРАНСИВЕР одного сегмента сети от ТРАНСИВЕРА другого сегмента сети? или нужно отвязать ТРАНСИВЕР от остальной схемы, а трансиверы между собой пусть будут соединены?

если первый случай, то както очень смутно могу себе представить, чтобы разработчики этих девайсов изначально планировали, что их девайсы будут работать в таком режиме - очень врядли! В этом случае - применение КЭНа было бы ошибочным.
если второй - всё просто - ставится опторазвязка (типовое решение). А ставится она либо между формирователем КЭН протокола и ДРАЙВЕРОМ ФИЗ. УРОВНЯ либо между контроллером и объектом управления (ведь не просто же контроллер в сетке висит) (можно и так и так, но дорого по питанию

Совсем крайний случай описан в литературе: "CAN application in avionics" (см. прил, рис. 17 - схема с трансом)

Прикрепленные файлы

 CAN_In_Avionics__comp_a_99_A93_.pdf ( 792.5 килобайт ) Кол-во скачиваний: 558

 

[Itch]

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

[Aner]

если на MCU то имейте ввиду проблему зависания ( причин много), логика все же не виснет.

[Juray]

Если тема еще актуальна, могу подкинуть еще одну схему развязки CAN (реально применяемую):

(источник: презентация "Аппаратные решения и разработки для шины CAN". Чепурнов А.С. http://www.can-expo.ru/files/apparat.pdf )

[syoma]

Если тема еще актуальна, могу подкинуть еще одну схему развязки CAN (реально применяемую):

Конечно, этот вариант, наверное, еще с изобретения CANа появился. (Ну, или немножечко позже)

[Linker]

Если тема еще актуальна, могу подкинуть еще одну схему развязки CAN (реально применяемую):

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

[adnega]

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

Хотелось бы узнать названия.... чтоб "реально не городить"

[Forger]

Хотелось бы узнать названия.... чтоб "реально не городить"

Например, этот: ISO1050
http://www.ti.com/ww/ru/analog/iso1050/index.shtml
http://www.compeljournal.ru/enews/2010/8/3

[syoma]

Неужто и вправду кто-то такое реально городит?

Вы не путайте оптическую развязку с защитой самого драйвера. Элементы L1, D1, D2 D3 - служат только для защиты при работе CAN драйвера на длинных линиях. Пока вы работаете в условиях, где нет помех, вам ничего такого не потребуется, поэтому многие и думают, что это не нужно. Но на длинных линиях - это необходисость. И пока ничего такого в одном корпусе я не встречал. Единственное, вместо D1,D2,D3 ставят что-то типа NUP2105L или PSM712. А тот самый ISO1050 защиты никакой не имеет и выгорит на длинной линии при помехе только так.
По цене он дороже обычного драйвера + пара оптронов. Все равно к нему DC/DC преобразователь нужен.

Тем более что давно уже есть драйверы со встроенной оптоизоляцией и защитой.

Менее года даташиту - это давно? Да он еще не продается толком.

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

[galjoen]

Элементы L1, D1, D2 D3 - служат только для защиты при работе CAN драйвера на длинных линиях.

L1 это продольный трансформатор, он более, чем драйвер от выгорания, процессор от сбоя защищает.

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

Смысла нет в применении всего этого в одном корпусе - паразитная ёмкость будет больше, чем в нескольких. И разводкой её не уменьшишь и резисторы, для её уменьшения, внутрь добавить невозможно.
В схеме, кстати, такие резисторы включены правильно. Только они должны выводными быть - проходная ёмкость меньше. И ещё нужно поставить выводной резистор номиналом в районе 1 кОм между RX_CAN и 6-й ногой U1. Иначе прямо на ногу проца помеха попадает.

[syoma]

1.9пФ - это разве большая проходная емкость?

[galjoen]

1.9пФ - это разве большая проходная емкость?

Небольшая, но у обычных smd резисторов, вместе с печатными дорожками, получается около 5 пФ.
Но самое главное не в величине ёмкости, а в том, что при использовании smd невозможно защитные земли как следует развести - места не хватает.
Ну и ещё у выводных металлоплёночных резисторов номиналом более 500 ом, как правило, спиралькой резистивный слой нарезан. А это увеличивает паразитную индуктивность. Но она, в этом случае, полезна.
Да и вообще, ИМХО на защите от помех экономить не стоит.

[syoma]

Вот еще в семействе изолированных CAN драйверов прибавилось - ADM3053 уже с DC/DC конвертером внутри. И корпус еще меньше - SOIC20 13x17мм.

[bookevg]

Вот еще в семействе изолированных CAN драйверов прибавилось - ADM3053 уже с DC/DC конвертером внутри. И корпус еще меньше - SOIC20 13x17мм.

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

[ukpyr]

паразитная ёмкость будет больше

на скоростях CAN она вряд-ли помешает.

[syoma]

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

А что у Максима есть изолированое для CANа?

[bookevg]

А что у Максима есть изолированое для CANа?

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

[AndreyKar]

Подниму тему
Кто что думает про оптоволокно в КЭНе?
Вот думаю HFBR-0400 применить. На вскидку, управлять ими прямо с КЭН ножек контроллера, только пока не соображу как их подключить, если в цепи больше 2х устройств.

Сообщение отредактировал AndreyKar - Feb 21 2011, 07:50

[syoma]

На Avago вроде были примеры применения ихних оптокомпонентов для CANа. Но я не сильно разбирался.

[AndreyKar]

На Avago не чего не нашел

[syoma]

http://www.avagotech.com/docs/AV02-0784EN
Они предлагают использовать оптические пассивные сплиттеры - недешевое удовольствие, насколько я знаю.

[Doka]

Этот ADM3053 стоит 710р в рознице.

дискретное решение:
изолятор Si8421 240p
DC/DC ROE-0505S 320p
CAN драйвер MCP2551 80p
итого 640р (+ место на PCB, + обвязка керамика)

примерно тож на тож.

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

PS: есть еще ISO1050 (CAN+изолятор) за 290р + DC/DC = 610p

[syoma]

Я пока ставлю ISO1050 и не парюсь. Единственное по обвязке к нему надо еще дроссель + TVS на шину типа NUP2105L или аналогичное, бо по защите он хуже MCP2551, насколько я помню даташит.

[x893]

Я ставлю ADM3053 и не парюсь ещё и с развязкой по питанию

[Myron]

Я ставлю ADM3053 и не парюсь ещё и с развязкой по питанию

Конечно, для двунаправленного САН надо использовать не только изолированные сигналы, но и питание, Для снифферов (правильно построенных) можно изолировать только сигналы. Вот отсюда и идет недопонимание в использовании тех или иных решений.

[novikovfb]

Я ставлю ADM3053 и не парюсь ещё и с развязкой по питанию

помехи в шину при выключении ADM3053 не мешают? У нас почему-то выдает импульсы лог. "0" порядка 10 мкс после выключения первичного питания.

[syoma]

Конечно, для двунаправленного САН надо использовать не только изолированные сигналы, но и питание, Для снифферов (правильно построенных) можно изолировать только сигналы. Вот отсюда и идет недопонимание в использовании тех или иных решений.

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

[Myron]

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

Поэтому я и использую ADM3053 уже лет так 7.

[Doka]

Конечно, для двунаправленного САН надо использовать не только изолированные сигналы, но и питание, Для снифферов (правильно построенных) можно изолировать только сигналы. Вот отсюда и идет недопонимание в использовании тех или иных решений.

не могли бы пояснить мысль?

[Vasily_]

не могли бы пояснить мысль?

Через 3 года, думаю вряд ли.