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? Тут пока ни слова об этом не было.

[Dog Pawlowa]

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

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

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

[korobov_michael]

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

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