AVR и ADM485, правильное использование линий RE#, DE Опции

[korobov_michael]

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

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

[defunct]

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

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

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

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

Заодно можно и детектор конфликтов сделать.

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

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

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

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

[aaarrr]

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

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

[defunct]

Хм, а откуда это вдруг взялась идеология "один мастер много слейвов"?

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

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

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

Или уже по умолчанию считается, что RS-485 == modbus? Тут пока ни слова об этом не было.

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

Я думаю, что на самом деле вы не проверяли, ловите вы лишние нули при переключении RO в высокоимпедансное состояние или нет

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

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

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

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

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


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