Нуу во-первых, нужно сначала разобраться с тем, что и как посылается. Это важно. Без этого как бы и бессмысленно пытаться наладить связь - будут затыки.
От главного МК к подчиненному запрос (команда) сейчас в проекте автора посылается беспрерывно, и не останавливается даже тогда, когда пошел ответ от подчиненного МК. Отсюда и конфликт на линии выходит, когда два трансивера (MAX487) в один момент времени оказываются оба в передаче.
Поэтому, вначале желательно отладить протокол обмена без трансиверов RS485 (чтобы не париться), ориентируясь по графикам в симуляции, таким образом, чтобы не было одновременной передачи с обеих МК. Одновременная передача может здорово нагружать в железе трансиверы по току драйверов, а МК не распознает, что идет одновременная передача, а не обрыв линии и будет дальше пытаться передавать. Сейчас в проекте главный МК вообще зависает, если нет ответа.
Протокол обмена в простейшем случае можно придумать самому. Допустим, на линии есть всего два устройства - главный МК пульта и подчиненный МК датчиков (или че там такое).
Определяемся, сколько байт нужно для передачи запроса (команды) от главного МК к подчиненному. Допустим, 1 байт, в него заложено всего несколько вариантов команд. Вот его то и будем передавать в запросе всего
один раз. Не надо его постоянно слать до посинения, а то не сможем обратно принять. Один раз отправили - и ждем ответа от подчиненного МК в течение некоторого интервала времени, переключившись на прием и не пытаясь ничего передавать. Этот интервал должен быть таким, чтобы при самых худших условиях по загрузке, подчиненный МК успел сформировать байты ответа и начать передачу. Как только пришел ответ в заданный интервал времени, получаем ответ и обрабатываем его.
Если ответ не пришел в интервале времени, только тогда можно попробовать повторную передачу запроса. Допустим, будет всего три попытки добиться ответа от подчиненного МК. Если ответа так и нет - пишем на дисплее, что связь оборвалась или подчиненный МК завис (выключился).
Теперь определяемся с тем, сколько байт нужно получить в ответе от подчиненного МК. Например, пакет в 4 байта - 3 байта информации и 1 байт контрольной суммы (типа защищаемся от помех, для разнообразия кодописательства). И пока главный МК не примет все 4 байта, он не должен начинать передачу сам. Опять же, эти байты ответа должны прийти в течение некоторого интервала времени, определяемого наихудшими условиями по длительности формирования ответа подчиненным МК. Если этот интервал времени истек, а все 4 байта не приняты, значит, что-то случилось на линии или с МК.
Вооот, это будет основной обмен информацией.
Теперь, для разнообразия придумываем контроль исправности линии RS485 в простое и вообще, контроль исправности (нормальной работы) подчиненного МК.
Для этого, периодически, например, каждые 2-5 секунд посылаем от главного МК специальный байт контроля. Он должен быть уникальным, то есть, не использоваться в командах и однозначно распознаваться как контрольный. Например, 0х55 (0101 0101) - чередующаяся последовательность 0 и 1. Подчиненный МК должен ответить либо таким же байтом 0х55, либо прислать обычный многобайтный ответ с информацией о состоянии устройства.
Далее, что касается физической части RS485.
Если на концах линии не используются согласующие резисторы (на низкой скорости и на маленьком расстоянии можно и без них - работает, проверял), то при разомкнутой линии на выходе RO будет 1. А вот в Протеусе - наоборот, 0 будет, а это помешает нормальной работе UART. Чтобы заработало в Протеусе, надо пойти на небольшую хитрость, вот так:
В железе работает почти такая же схема, только вместо отрицательного -5V подсоединяем к общему GND. Да, Протеус малость своеобразен.
Если в железе поставить согласующий резистор, но не подтянуть линии к + и общ, то получим тоже ерунду, поскольку на линии будет неопределенность и ложные срабатывания.
----
А что касается того, откуда брать инфу для выключения направления передачи, то сигналом для нее может быть бит TRMT в регистре TXSTA. Он сигнализирует о том, что буфер передачи пуст после передачи последнего байта в посылке:
Выждав после него еще чуть-чуть, чтобы сформировался стоп-бит, можно отключить направление передачи.
Но для того, чтобы использовать этот бит, нужно прекратить загружать буфер передачи.
Короче говоря, до тех пор, пока не будет нормально сделан протокол обмена, нифига с полудуплексным RS485 не получится. Либо уж тогда делать в полном дуплексе с двумя сигнальными витыми парами.
Re: Неправильная работа Proton с RS485
Я ж показал, как надо сделать, чтоб в протеусе появилась связь
