Добрый день.
Суть вопроса в следующем. Работаю с 485 интерфейсом. Линии RE#, DE соединены вместе, контроллер управляет этой парой ножек. Когда я перевожу ножку контроллера из 0 в 1 (т.е. перевожу ADM485 из приемника в передатчик), то по УАРТу получаю прерывание по приходу символа (обычно это 0). Обойти решил изуверским способом. Перед переключением ПРМ->ПРД запретить приемник (RXEN = 0). Но чую, что что-то неправильно. Кто-нибудь сталкивался с подобным? Подскажите, как бороться с проблемой?

P.S. Еще слышал решение (в документации на FTDI232BL), что можно линию DE устанавливать в 1 на время передачи, после чего снимать, а линию RE# держать все время в нуле. При это на линию RxD контроллера заводить логическое ИЛИ от сигнала RO и DE. Практикуется ли подобное и является ли такое решение более правильным?

Повесьте pull-up резистор на RXD - линия повисает в воздухе, если nRE = 1.


Правильное решение...


...а вот это лишнее: тогда лучше или pull-up, или фильтровать прием. Заодно можно и детектор конфликтов сделать.

Я правильно понимаю, что если включен UART, то команда PORTE |= _BV(PE0) для включения подтяжки не будет работать? Т.е. нужен внешний pull-up?


Об этом даже не думал. Спасибо. Действительно ценная идея

я работаю без подтяжек...нареканий не было...с переключением тоже

Работать будет, но я бы в любом случае рекомендовал внешний резистор.


Вам просто повезло.

Будет. Только порт на ввод должен быть настроен. Продано несколько тысяч приборов - нареканий нет.

да будет так !

Насколько я знаю, при включенном УАРТе ножка RxD автоматически настраивается на вход

А когда отключаете приёмник, что там будет Вы задумывлись?
Я думал что уарт состоит как-бы из двух частей, управляемых независимо через TXEN и RXEN...

Да, но управление pull-up'ом это не отменяет.

Я имел ввиду, что при включении функции УАРТ управление ножками контроллера (включая возможность управления подтяжками) полностью переходит к модулю УАРТ и он блокирует мои выбрыки вроде PORTE |= _BV(PE0); и делает с подтяжками так, как ему это удобно. Надо, блин, покурить мануал

Нет, управление pull-up'ами остается. Курите мануал.

Правильно.

Я бы так не стал делать - лишняя зависимость от некой сущности "логического ИЛИ".

Поступаю как и Вы - соединяю RE/DE вместе и управляю одной ногой контроллера. Мусор в момент переключения приемника/передатчика меня не особо беспокоит в силу защищенности протокола, хотя также отмечу, что ни разу с такой проблемой как у вас не столкнулся... Всмысле лишнего "0" после переключения ни разу не словил. И с пул-апом и без оного.

Может у Вас что-то фонит на плате излишне? Или с линией что-то не так (проверьте появляется ли этот "0" если поставить терминатор 120om между A и B )?


Можно-то можно. Вопрос зачем? При идеологии шины "1" мастер "много" слейвов. Конфликт ловить бесполезно - т.к. слейв все равно не может делать перепосылку "по собственному хотению", а мастер и так всегда прав.

Как по мне, с позиции Rs485 мастера - удобно делать так:
- очистить приемный буфер
- послать запрос
- спать
- проверить приемный буфер (и вот чего в этом месте точно не нужно, так это получить собственный же запрос в начале буфера)

слейву как бы тоже все ясно:
- спать
- проверить приемный буфер
- ответить.

В обоих случаях RX спам своми же сообщениями бесполезен и только будет мешать.

Хм, а откуда это вдруг взялась идеология "один мастер много слейвов"? Или уже по умолчанию считается, что RS-485 == modbus? Тут пока ни слова об этом не было.

Одномастерная идеология самая массовая для RS485.
Я тут немножко сопровождаю три десятка последовательных протоколов, две трети из них на RS485/RS422.
Статистика такова - все одномастерные, ни одного modbus.

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

Весьма далеко идущее предположение. Ведаю. и вопросов про пропадание и мусор не будет.
И вопрос был не по задержкам - проблема была в переходе из Rх в Tx и последующим за этим приходом левого символа. Эта проблема была решена именно задержками и отключением приемника в момент перевода из ПРМ в ПРД. Просто было интересно узнать как подобная проблема решается "по-правильному".

Я думаю, что на самом деле вы не проверяли, ловите вы лишние нули при переключении RO в высокоимпедансное состояние или нет
Без подтяжки (внешней или внутренней в МК) все зависит только от наводок на эту линию.
Я вот тоже никогда этим вопросом не "заморачивался" по двум причинам, о которых уже было сказано:
- наличием подтяжек (если позволяет МК, то только внутренних - зачем лишняя детать);
- "правильным" софтом. Ну, словит обработчик приемника лишний байт - "понюхает его, пожует и выплюнет" - есть же протокол передачи данных, есть защитные таймауты. Я про это событие даже и не узнаю

Если связь рушиться из-за парочки паразитных переходов на RxD, то нужно что-то в обработчике менять...

А откуда вдруг взялась идеология точка-точка при использовании RS-232?
Очевидно из природы интерфейса.

RS-485 — полудуплексный многоточечный последовательный интерфейс передачи данных. RS-485 не предоставляет возможности для своевременного обнаружения и предотвращения конфликта.

Этим и обусловлена его область применения.
Допускаю, что в качестве контр агрумента можно привести Profibus использующую маркерный метод доступа для организации multimaster через RS-485. Но это IMHO уже костыль.


есть еще много всяких xxx-bus, идеология которых - "1 мастер много слейвов", и они прекрасно ложаться на RS485.



Я понимаю, что это никак недоказуемо, до тех пор пока не показать в живую... Но все-таки как говорится "зуб даю" - проверил!

При работе в Modbus-ASCII - алгоритм у меня используется такой как привел выше:
1. Мастер очищает приемный буфер,
2. шлет запрос слейву,
3. спит некоторое время,
4. вытаскивает ответ из приемного буфера.

Мастер не ищет начала пакета каким-то специальным образом, он предполагает, что ответ слейва начинается с [0]-го символа приемного буфера. Если бы при переключении постоянно выскакивал лишний "0" оно б у меня браковало бы все ответы т.к. данные были бы сдвинуты!! А я вижу адекватные респонзы от слейвов. Буквально сегодня специально проделал этот экперимент.

Помониторил линию RxD, как и ожидал - наблюдал на ней уровень VCC, каких либо всплесков при переключении драйвера не обнаружил.
(подтяжки внешней нет, внутренняя специально отключена, RXEN включен). Подопытные МК - m128, m162 (оба тестировал с UART0), подопытный драйвер - adm485arz

Усложнил задачку - сделал так, что драйвер переключается после отправки каждого! символа на прием, и обратно на передачу (если есть что слать) - полет нормальный! Так что остаюсь пока при своем мнении - у автора проблемы не с подтяжкой. Или фонит что-то ооочень сильно, или снаружи A и B попутаны.


А в остальном Вас поддерживаю

Была у меня абсолютно такая же проблема. При выходе из режима передачи приемник ловил ложный стартовый бит и вся посылка ни к черту... У меня просто не стояло подтягивающих резисторов на +5 и землю (на самой линии). А в реализации для adm485 рекомендуют... избавился заменой на adm4853