[alex2k3 0]

Здравствуйте.

Подскажите как можно гальванически развязать линию связи и трансивер RS 485 или развязкулучше делать через оптопару после трансивера? Нашел такую микросхему MAX3535EEWI (даташит). В рознице порядка 200 рублей, не считая обвязки. Можноли достичь того же результата за меньшие деньги?

Спасибо всем откликнувшимся.

[man with no name 0]

Можно использовать MAX1480 - не дешевле, но отпадает необходимость в трансформаторе.

 

Дешевле наверно может получиться лишь с простеньким DC-DC преобразователем и ADUM1301 (кажется, она с 2 tx, 1 rx?). Но это надо считать :)

[rezident 0]

Ну MAX1480 это классическое и многократно проверенное временем решение. Но не самое дешевое. Если предполагается "обычный" коммуникационный RS-485 со скоростями до 115200 (а не какой-то монстроидально-специфический на десяток МГц) и с изоляцией до 500В, то у нас самый дешевый вариант получается с использованием нерегулируемого 1Вт DC/DC (типа RE-0505S, AM1S-0505S и подобных) + 3 шт. H11L1(S) для гальваноразвязки какого-нибудь драйвера типа ADM485. С применением ADUM1301 получается подороже, т.к. ADUM1301 дороже 3 шт. H11L1 да еще для него уже нужен DC/DC с нормальной стабилизацией выходного напряжения. Есть еще варианты гальваноразвязанного RS485 типа ADM2482E, требующий лишь внешнего трансформатора.

[alex2k3 0]

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

[MrYuran 16]

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

У макса в даташитах есть схемы с автоопределением направления. Там по-моему нога направления тупо садится на DO, но это наверно не все драйвера поддерживают.

Вот, например

[jasper 0]

Есть еще хорошие штуки у Texas Instruments iso3080, iso3082, iso3086, iso3088.

Стоят дешевле, чем алогичные изделия Analog Devices серии ADUM, только жрут поболее.

 

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

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

[rezident 0]

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

Да, верно. MAX1480 это интегральная схема, содержащая внутри как (опто)изоляцию, так и питание изолированной части (драйвера).

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

Самый простой способ это перезапускаемый одновибратор, (пере)запускаемый по перепаду 1->0 сигнала передатчика. Длительность импульса одновибратора настраивается на время передачи одного символа. Но время передачи символа зависит от скорости передачи, в этом основной недостаток данного способа. Другие способы используют буферизацию с вычислением скорости передачи и/или "заточены" на конкретные протоколы связи.

[Uladzimir 60]

Можно использовать MAX1480 - не дешевле, но отпадает необходимость в трансформаторе.

 

Дешевле наверно может получиться лишь с простеньким DC-DC преобразователем и ADUM1301 (кажется, она с 2 tx, 1 rx?). Но это надо считать :)

 

A вот пример из схемы :beer:

[alex2k3 0]

Спасибо всем ответившим!

Скорее всегу буду применять

"с использованием нерегулируемого 1Вт DC/DC (типа RE-0505S, AM1S-0505S и подобных) + 3 шт. H11L1(S) для гальваноразвязки какого-нибудь драйвера типа ADM485"

Это самый дешевый способ из всех предложеных.

Над направлением передачи еще подумаю

[man with no name 0]

Если завести сигнал ~drive enable (~DE) на data input (DI), притом сделать так на всех устройствах сети, то вы теряете в помехозащищённости (т.к. уровень логической единицы формируется подтягивающими резисторами) и скорости (изза ёмкостей входов), зато получаете защиту передатчиков от случайной встречной передачи (одновременной передачи разных сигналов несколькими передатчиками).

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

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

 

UPD: да, но это всё касается только варианта с наличием RTS. Если его нет, то, пожалуй, варианта для управления передачей, прощё, чем завести ~DI на DE мне в голову не приходит.

[Mike18 0]

Самый простой способ это перезапускаемый одновибратор, (пере)запускаемый по перепаду 1->0 сигнала передатчика. Длительность импульса одновибратора настраивается на время передачи одного символа. Но время передачи символа зависит от скорости передачи, в этом основной недостаток данного способа. Другие способы используют буферизацию с вычислением скорости передачи и/или "заточены" на конкретные протоколы связи.

Попадался не совсем "честный" :) , но вполне работоспособный способ с "автопереключением". Линия "DE" удерживается в состоянии "1" во время формирования "0" передатчиком, перепад "0->1" запускает одновибратор, который задерживает перевод драйвера в режим приёма на время, достаточное для формирования в кабельной части динамического перехода "0->1". Это время определяется "шириной" одного информационного бита на максимальной используемой скорости.

 

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

Изменено 26 июля, 2008 пользователем Mike18

[Uladzimir 60]

Попадался не совсем "честный" :) , но вполне работоспособный способ с "автопереключением". Линия "DE" удерживается в состоянии "1" во время формирования "0" передатчиком, перепад "0->1" запускает одновибратор, который задерживает перевод драйвера в режим приёма на время, достаточное для формирования в кабельной части динамического перехода "0->1". Это время определяется "шириной" одного информационного бита на максимальной используемой скорости.

 

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

 

Вот только задержка не на бит а на байт

[_Pasha 0]

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

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

[rezident 0]

Попадался не совсем "честный" :) , но вполне работоспособный способ с "автопереключением". Линия "DE" удерживается в состоянии "1" во время формирования "0" передатчиком, перепад "0->1" запускает одновибратор, который задерживает перевод драйвера в режим приёма на время, достаточное для формирования в кабельной части динамического перехода "0->1". Это время определяется "шириной" одного информационного бита на максимальной используемой скорости.

 

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

ИМХО это шаманство для настольного варианта. Я когда разрабатывал свой конвертор-репитер, то вводил еще и обязательную задержку битового потока во время переключения драйвера на передачу. Т.е. битовый поток с полезным сигналом на выход драйвера поступал к тому моменту, когда в линии уже все переходные процессы "устаканились". И выключался передатчик драйвера также с небольшой задержкой. Это нужно было для RTU-ных протоколов, где начало/конец пакета определяется "паузой тишины". Работает даже и без подтяжек.

[Mike18 0]

Вот только задержка не на бит а на байт

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

ИМХО это шаманство для настольного варианта.

Согласен.

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

И это правильно! Вот только работа без подтяжек, IMHO, это тоже шаманство :) , предполагающее, что к сети будут подключаться только такие драйверы, которые это отсутствие допускают.