Для требуемых 5 метров это разумное решение. Но только несколько наcтораживает слово "помехозащищеный" в названии темы, хотя автор никак не конкретизровал это требование. Но вообще кроме LVDS вариантов дифференциальных приемопередатчиков еще немало есть.




Согласен.

Мне не хотелось бы здесь устраивать "разбор полётов". Не в тему.
Надеюсь, Вы сами, спокойно перечитав ветку, обнаружите, что дискутировали слишком эмоционально.

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

По случаю, выскажусь ещё раз в осуждение жаргона. Как Вы сами замечаете, "проще" и "короче" - не всегда значит "лучше" и понятнее".
Создание "гнилых" протоколов - лишь частный случай небрежности в исполнении, связанной с небрежностью в рассуждениях и формулировках.
Склонность к жаргону, ИМХО, - вид распущенности, мешающий действовать аккуратно как в общении, так и в работе.
Но в разделе для начинающих, где не все - люди взрослые и ответственные, на жаргон ещё смотрю сквозь пальцы. Хотя, желал бы, чтобы мэтры подавали хороший пример для подражания. Ибо убеждён: схема, "сколхоженная" из резюков и кондюков со "вкряченными" туда микрухами и работать обречена соответственно. А автору, тачающему такую "электронику" - никогда не стать грамотным инженером.

Предполагается эксплуатация прибора в операционной при работающем рядом электрокоагуляторе - главном источнике помех.

RS-485 очень устойчивый. Сделать линию связи более устойчивой тоже просто- применить Ethernet кабель с двойным экраном и грамотно соединить земли и экраны.
Говорю про RS485 потому что его знаю. Возможно, другие синфазные интерфейсы тоже не хуже, у меня нет опыта их использования.

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

Структура такая: короткий кабель USB воткнут в ПК и соединен с промежуточным блоком (в этом блоке есть развязка по USB и питанию), далее кабель 5 метров (предполагаемый RS-485), на другом конце которого интерфейсный блок к которому присоединяются датчики.
Я тут подумал - самым слабым звеном кажется даже не 5-метровый кабель, а провод от датчика до интерфейсного блока. Там просто UART, а не дифф. пара.

Для перестраховки там тоже можете поставить шинники RS-422.

Самым слабым звеном будет USB. Вместо него лучше всего было бы использовать Эзернет.

Там кабель надо тонкий, гибкий. Я нашел только экранированный трехпроводной. Ну и размер датчика ограничен.

USB это очень тоскливо, тем более, когда о помехах речь идет. Что там такое "промежуточный блок" делает между UART и USB, что PC сделать не может? Убрать его, в PC сразу RS422/485 гальванически развязанный порт в вперед...



Да 5 метров можно хоть руками сделать, тем более, что изделие, похоже, штучное.

все так, но у меня задание сделать именно USB устройство

можно, если без экрана
самодельный экранированный провод не гибкий, заводские тоже трудно найти тонкие и гибкие


какие например?

Панельный компьютер, у которого наружу выведены только USB?
Обычно внутри всегда есть и COM порты.

Если не забанили в интернете, то найдете - начиная с LVPECL, VML, CML, MLVDS, BLVDS, LVDM...




Сильное заявление . Самодельный на то и самодельный, что может быть ЛЮБЫМ!



Вам шашечки, или ехать? На худой конец, тот-же USB-RSxxx гальванически развязаный.

А вообще еще есть массовая дешовая оптика.

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

у нас такой сделать не получилось
без экрана нормальный, а экранированный получился дубовый)


В смысле вместо МК поставить преобразователь USB-RSxxx ? А в чем преимущество будет? Гальваническая развязка у меня тоже есть (правда USB). И если не ошибаюсь преобразователь USB-RSxxx определится как виртуальный COM-порт, а мне надо изохронный канал.

Вы в этом ТОЧНО уверены???

Ошибаетесь. Это только один вариант использования.

Ни одно из понятий определяемых помянутым Вами термином "изохронный" у меня лично НИКАК не вяжется с "Структура такая: короткий кабель USB воткнут в ПК .... которому присоединяются датчики ... просто UART"
Что сказать-то хотели???

да, ADUM4160 по линиям данных USB и трансформатор по питанию

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

Давайте все-же ответите на вопрос, что Вы хотели сказать термином "изохронный", поскольку "время доставки" никак его не обяснило .
Ну а вообще USB интерфейс весьма и весьма нестабильный по разбросам времени доставки пакетов интерфейс. Можно сказать, что в этом смысле он АНТИизохроный.

я имел ввиду, что нужен изохронный канал USB

В общем пока вижу совершенно непродуманую систему куда, очевидно, для большего барадака еще и USB приянули.
Если Вам нужно "реальное время", то оно должно обеспечиваться контроллером, а не какой-то PC с неведомой операционкой подключенной по USB.
Пакеты с информацией от датчиков должны приходить в PC уже с ОТМЕТКАМИ времени сделаными контроллером датчиков.

Такое жесткое "реальное время" не требуется, просто нужно увидеть на экране воздействие на датчик не через 3 секунды, как это возможно в Bulk-канале.
От датчиков приходят данные с заданной частотой и пока, на макете, все устраивает. Просто нужно удлиннить кабель до ПК.

А нужен ли?

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

Однако если вы поставите свою собственную USB карту, к которой ничего, кроме своего устройства, подключать не будете, то все, на что способен этот хост, вся пропускная способность интерфейса все равно будет ваша: хоть в виде балка будете ее использовать, хоть в виде изохронного. А балк при этом еще автоматически обеспечит гарантированную доставку.

да, так и будет

Сейчас появилась идея делать USB без развязки, а развязку сделать на другом конце RS-485. То есть будет так: USB-USB процессор-трансивер-кабель RS-485-трансивер-гальваническая развязка-процессор-датчики
В такой конфигурации есть какой то изъян?

Если выбирать из многих зол меньшее, то нет .

У Вас что, никогда мышь "не отваливалась"?!
Ну люди падают с луны и прямо сюда! ;)

Честно - никогда) а Вы это к чему?
принтер подвисает иногда, там кабель 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 команду инициализации и тут же получает ответ мол ОК, или не ОК. Это дает гибкость, ведь если управление с ПК, то и настроечные команды надо с ПК отправлять. Если контроллер инициализируется разово, тогда он это и сам может сделать (нет смысла посылать эти команды с другого контроллера).

Все так, но все равно при включенном передатчике помехе труднее пробиться. На линии будет 5 вольт, а нагрузочные резисторы смещают только на 0,2 вольта.


USB-МК принимает команды от ПК и передает их по RS-485, а тот уже настраивает у себя что надо. Я имел ввиду, что не прокатит USB-запрос с передачей данных, потому что надо успеть команду передать по RS-485 и ответ принять и процесс "переваривания" команды бывает долгим.

У меня висит датчик ускорения, ему для инициализации надо прописать 6 регистров. Я их прописываю не из ПК, а из ПК просто идет команда "настроить" и контроллер прописывает нужные регистры. Вы это имели ввиду?

Ну тут вариантов реализации несколько, например сделать отдельно команду записи параметров, команду чтения их из акселерометра в буфер и команду передачи собственно буфера в ПК. Т.е. посылается к примеру команда конфигурации МСУ: "1000, 100, 200, 50", что означает установить чувствительность каналов 1-4 соответственно этим значениям. Приходит ответ: "команду отправил", это значит USB отправил команду подопечному МСУ и получил подтверждение (получения). Далее через какое-то время (скажем 100мсек) посылается новая команда "чтение конфигурации", снова получаем ответ:"команду отправил", в это время МСУ начинает вычитывать значение из акселерометра...Через фиксированное время посылаем теперь уже команду чтения буфера (они уже прочитаны и сидят в ОЗУ), на что теперь уже получаем данные: "1000, 100, 200, 50". Может это несколько сложновато, зато всё контролируется с ПК и протокол получается универсальным как для передачи команд, так и запроса данных. Контроллер USB при этом не выполняет никаких самостоятельных действий (чего он и не должен делать), а лишь функцию ретранслятора пакетов.
Как вариант вместо вставки фиксированного интервала ожидания можно использовать специальный код в ответном сообщении, который говорит о том, что данные еще не готовы. В этом случае ПК повторяет свой запрос периодически, пока не получит требуемые данные. Тогда чтобы сконфигурировать и получить информацию об установках достаточно одной команды -установки параметров, ответом на которую будет являться сообщение с реально установленными параметрами.

Если значения регистров не предполагается менять время от времени, тогда регистры можно прописать сразу при старте МСУ, не понятно зачем для этого нужно посылать специальную команду.

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

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

2. Если длительность "опасного" интервала очень мала, то приемник может "ничего не заметить" даже если помеха навелась прямо на этот интервал. Это зависит от того, как устроен приемник UART-а. Приемники "для оффисных применений" детектируют старт-бит по фронту, а сэмплируют принимаемые биты один раз ровно в середине бит-интервала. Совсем хреновые воплощения могут запустить прием по короткому фронту (помехового)сигнала, после чего даже не проверять уровень старт-бита в середине стартового бит-интервала. Приемники для индустриальных применений трижды сэмплируют данные в середине каждого бит-интервала, включая старт-бит. Можно надеяться, что и фронт сигнала они определяют по трем выборкам, хотя в даташитах подробности реализации как правило не раскрываются.

При бодовой скорости 1 Mbps длительность помехи, которая может быть отсеяна "хорошей" реализацией UART-а, составляет малую долю микросекунды. Имеет ли смысл закладываться на этот механизм? Можно ли программно обеспечить "опасное" время, когда оба передатчика выключены, порядка 0.2-0.3 мкс? Нет, конечно.

3. Если длительность "опасного" интервала больше, чем в п.2, то в момент переключения коварная помеха может создать как минимум ложный старт-бит. Конечно, чем длиннее интервал переключения, тем больше вероятность, что это произойдет. Тем не менее, ложный старт-бит может появится, а значит, UART может принять ложный байт. Что с ним делать? Протоколы типа Modbus RTU устроены так, что ложно принятый в это время байт будет гарантированно отброшен. Самопальные протоколы такого как правило не умеют, они надеются на резисторы подтяжки, плюс, иногда (как в вашем случае) надеются на то, что вероятность этого события мала, поскольку длительность "опасного" интервала мала.

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

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

Нет, это потенциально опасный подход.
Абсолютного равенства сигналов не бывает. Причин много, например- разное питание(пусть даже в пределах отклонения стабилизаторов на одинаковое напряжение, а ведь может быть и связка 3.3В-5В), разные типы драйверов, разная температура. Так что переток будет всегда. А переток-это плохо (и КПД падает, и перекос линии по напряжению возрастает).
Поэтому ситуации "оба передатчика работают одновременно" пытаются избегать, увеличивая вероятность более безопасной ситуацией "оба передатчика выключены". Это решаемо на протокольном уровне.

А они ни нафиг и не нужны - посмотрите хоть как выглядят выходы драйверов. Даже конфликты не проблема. Для особых параноиков есть CAN драйвера.



Если головы не плечах нет, то да.

Не криминал. Максимум неопределенность состояния линии.

Он может быть любым.

А все равно, что произойдет. Как максимум произойдет то же самое, что и обрыв линии, который есть совершенно реальная ситуаци от которой тоже надо ПРОТОКОЛЬНО защищаться.

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

Все "проблемы" решаются включеним передатчика ДО начала передачи за время большее передачи одного байта.

О чём здесь всё ещё спор? Два МК, линия связи с парой терминаторов и куча датчиков, и на всё в сумме — лишь 2 Вт с USB? Ясно же, что здесь только LVDS реален, да ещё, чтобы протащить, а не растерять по дороге неназванные ватты до системы сбора через терминаторы и по неназванному сопротивлению кабеля, из него требуется делать ЛЭП, т.е. соответственно повышать и понижать напряжение.

Так сделано в Модбас RTU, который вы еще недавно обсдавали пометом



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

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

Достаточно просто проверить, что принятый мусор не совпадает с признаком начала пакета. Соответственно весь геморрой с отслеживанием времени и обеспечением непрерывности пакета становится не нужен и ModbusRTU идет лесом из любой проектируемой конструкции, где не требуется стыковка с другими устройствами, которые ничего кроме ModbusRTU не умеют.

Ну а если совпадает? Одного "признака начала" недостаточно. "Байт-стаффинг" - это более точное указание на то, что требуется. Я уже писАл, что байт-стаффинг проще, чем Модбас. Более того, предлагал ТС использовать COBS.

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