Помехозащищенный RS-485 Опции

[Atlantis-]

Здравствуйте!
Мне нужно соединить два 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. На что надо обратить внимание, какие есть тонкости при организации такой линии связи? Впервые сталкиваюсь с этим, поэтому извиняюсь за, может быть, глупые или детские вопросы.

[Сергей Борщ]

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

[Ruslan1]

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

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

[zltigo]

Абсолютного равенства сигналов не бывает.

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

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

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

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

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

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

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

А насколько коротким? Что произойдет за время, пока оба передатчика выключены?

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

Резисторы подтяжки удерживают линию связи в пассивном состоянии

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

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

[=AK=]

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

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

Как человек почти вся жизнь занимающийся всевозможными связными потоколами могу точно сказать, что Modbus RTU есть натуральное дерьмо.

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

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

[Сергей Борщ]

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

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