Здравствуйте!
Мне нужно соединить два STM32F1 5-ти метровым кабелем. При этом один из МК будет подключен к USB, питаться тоже все будет от USB и предполагается гальваническая развязка по USB.
В итоге по 5-ти метровому проводу будут передаваться данные (скорость 1 Mbps) и питание.
Предполагается, что кабель должен быть максимально помехозащищен и желательно, чтобы под влиянием помех как минимум не вылетало USB.
Собственно предполагаю использовать RS-485 и исходя из этого есть вопросы:
1. Какой приемопередатчик RS-485 лучше выбрать? Видел много всяких типа MAX485, ST485, ADM485 и остальные
2. Нужна ли гальваническая развязка? При условии, что питание и земля все равно будут общими.
3. Во многих приемопередатчиков пишут, что есть встроенная защита, надо ли ставить дополнительно TVS-диоды?
4. Поскольку питание от USB, можно ли как то прикинуть ток потребляемый RS-485? Например так можно I=q/t=q*f=C*U*f ?
5. На что надо обратить внимание, какие есть тонкости при организации такой линии связи? Впервые сталкиваюсь с этим, поэтому извиняюсь за, может быть, глупые или детские вопросы.

При включении Теслы (примерно 2м от компа) мышь и клава отваливаются изредка, USB-осциллограф - сразу.

Это же зависит как то от длины кабеля USB?

При такой структуре:

длина USB соединения будет около 1 см - от процессора до разъема, USB процессор и трансивер разместятся в корпусе USB штекера.

От длины и качества кабеля, качества разводки, скорости работы порта (низкоскоростной/полноскоростной), чипов и пр.и пр.

По поводу помехозащищенности и развязок. Уже звучали намёки в вопросах к ТС, но всё же не было конкретизировано подключение земель и экранов.
Если датчики заземлены изначально вдали от развязки USB, это одно. Тут скорее всего понадобится дополнительная гальваническая развязка.
Если все компоненты системы изолированы и заземляются только в месте развязки, это вроде как другое.
Нет?

пытались таким смотреть сетевые блоки питания такими осциллографами (маленькие, модно в операционную, точнее в подсобку туда взять). Если не изолированный-- потеря USB после каждого второго (загнул конечно но очень регулярно, и смотря куда соваться), тыка щупом . Раз в полгода-- смерть USB. С питанием такого осциллографа изоляцией (через трансформатор) полегче но в принципе не спасает. --в зависимости от мощи.
Конечно коагулятор и рядом не лежал по мощности. Но все же я бы не рисковал. Тем более медицина. Прерывать операцию из-за временной потери USB как-то не очень. Доктора будут точно не довольны.

Напишу немного практических результатов. Применяем видеокамеры собственной разработки с питанием по USB. Используем USB High Speed, устоявшийся поток данных иногда 45Мбайт/сек. Часто используется внешний запуск камер или 2-4 синхронно работающие камеры. Для синхронизации применяю XR3178EID и ADM485AR. Также используем самодельные драйверы шаговых двигателей на токи до 2,5 А и фронтами длительностью порядка 50-100нсек. Часто все эти провода уложены вместе в общий кабель канал. Кабели USB паяем сами, провода к ШД обязательно в экране, всю установку обязательно заземляем. Только такой комплекс мер позволяет стабильно работать нашим установкам на производстве. Но всё же самым слабым местом по надежности это USB. Всё таки этот протокол не промышленный и не предназначен для работы в условиях сильных помех. Поэтому я бы на вашем месте для начала определился с надежностью работы USB. Ну там статикой пощелкал или рядом с устройством разместил более-менее мощный какой-нибудь генератор помех.

Датчики не заземлены, все изолировано. Заземление как таковое осуществляется только через USB.



К опытному образцу с точки зрения зависания USB претензий не было, хотя там конструкция: кабель USB 3 метра - прибор - кабель датчика 1 метр - датчик

Вы прошли сертификационные испытания? Или скорее всего предстоит.
Изучите импульсные помехи. Полезно будет.

Подскажите пожалуйста один момент при применении RS-485. Там надо переключать направление передачи данных.
У меня два МК, первый соединен с USB и по сути передает второму МК команды и принимает от него данные.
Я пока придумал такую логику, интересно насколько она верна.
После сброса, включения питания, USB-МК настроен как передатчик (в смысле, находящийся на его стороне ресивер настроен как передатчик), второй МК настроен как приемник, ждет команд.
USB-МК отправляет команду (или серию команд), направление передачи пока не переключаем, поскольку ответа не будет.
Когда все во втором МК настроено, USB-МК посылает первый запрос данных, в прерывании по окончанию передачи - переключается на прием.
Соответственно, второй МК после принятия такого запроса сразу же переключается на передачу, запускает таймер, который отсчитав 1 мс переключает МК на прием. Соответственно, время 1 мс выбрано потому что запросы данных будут приходить от USB-МК именно с такой частотой.

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

Atlantis, зачем все это? Не нужно еще один протокол изобретать, их есть уже готовых и проверенных временем и миллионами применений.
Берите любой протокол мастер-слейв, да хоть тот же дубовый Modbus и делайте общение на нем.
Или CANopen. да много их разных.
Огромный плюс использования стандартного протокола в слейве - возможность подключения устройства не только к Вашему мастеру, но и к любому другому с таким же протоколом, или к компьютеру (для тестирования и отладки, например). Если Вы не эксперт в написании протоколов, то плюсов в использовании готового будет гораздо больше.

Upd: непонятно, зачем вообще USB девайс в Вашей системе и почему не подключить RS-485 напрямую к компьютеру, но это уже другой вопрос.

Проблемы на ровном месте. 5 метров кабеля по операционной развешивать. Сделайте в вашем концентраторе датчиков сразу Wi-Fi. И скорости нормальные и гальваноразвязка и модулей встраиваемых сейчас развелось на все вкусы.

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

Зачем таймер? Отправил ответ и сразу переключился на прием.

Более того, то что касается инициализации нужно обязательно каждую команду сопровождать ответом, иначе где гарантия что она (инициализация) выполнена?

Тогда большой промежуток времени оба приемопередатчика будут в режиме "приемник", то есть будут ловить помехи


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

А нагрузочный резистор зачем же тогда, а резисторы смещения?

Не понимаю, ПК отправляет в USB команду инициализации и тут же получает ответ мол ОК, или не ОК. Это дает гибкость, ведь если управление с ПК, то и настроечные команды надо с ПК отправлять. Если контроллер инициализируется разово, тогда он это и сам может сделать (нет смысла посылать эти команды с другого контроллера).