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

[Atlantis-]

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

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

[=AK=]

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

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

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

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

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

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

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