Хорошая идея использовать UART в полудуплексном режиме при использовании приемопередатчика RS485?

Большинство 2-проводных реализаций RS485, которые я видел, используют как контакты UART RX, так и TX, что, конечно же, работает. И я сделал это.

Но мне было интересно, является ли использование UART в полудуплексном режиме хорошей альтернативой, которая, возможно (?) имеет преимущество в более чистом коде и уменьшении количества выводов.

Приложение представляет собой Modbus ASCII, а синхронизация настолько четкая (3,5 символа), что переключение (которое я все равно делаю для DataEnable) можно объединить с TransmitEnable.

(Некоторый контекст: у меня были передатчики RS485 с локальным эхом на линии UART RX)

Какой вопрос?
Рекомендуется использовать HDX для простоты управления и защиты от электромагнитных помех.
Вопрос: хорошая идея или нет. Уже обнаружил, что отлаживать сложнее

Ответы (3)

Это может быть хорошей идеей, если вы находитесь в ситуации, когда вам нужно сохранить булавки.

Но это также усложняет некоторые вещи.

Вам необходимо переключить один контакт MCU между режимами RX и TX для одного провода UART, в дополнение к управлению контактами включения передатчика/приемника.

Ему также может потребоваться подтягивание к линиям данных, чтобы он оставался в режиме ожидания между изменением направления вывода MCU — некоторые MCU имеют внутренние подтягивания, которые могут оставаться включенными все время, а не включаться только при вводе.

Это также делает невозможным считывание того, что передается MCU, поэтому обнаружение сбоев, коллизий или ошибок невозможно.

Собственно, последнее утверждение не совсем верно для всех микроконтроллеров. Например, в STM32 USART считывает свои собственные данные в полудуплексном режиме при условии, конечно, что RX включен. С другой стороны, в STM8 нет необходимости отключать RX при передаче в полудуплексном режиме, поскольку собственные данные не считываются автоматически.
@neoxic Вы неправильно поняли, что я написал. Вы говорите, что MCU будет получать именно то, что он передает, поэтому он не может обнаруживать сбои, коллизии или ошибки на шине RS-485. Я имел в виду, что MCU будет передавать на шину RS-485 и получать обратно то, что находится на шине RS-485, поэтому он может видеть, получает ли он обратно то же самое, что и отправил, или были ошибки, потому что два устройства хотят передавать одновременно по одному и тому же каналу. автобус. И поэтому эти ошибки не могут быть обнаружены с использованием одного вывода MCU только для RX и TX.
Нет, я не говорил, что MCU будет получать именно то, что он передает, поэтому он не сможет обнаруживать сбои. Я сказал, что от MCU зависит, получит ли он обратно то, что он передает, или нет в полудуплексном режиме. В первом случае он сможет проверить наличие ошибок на однопроводной шине. В последнем случае НЕ будет.
Итак, теперь вы говорите именно то, что я изначально сказал, что вы утверждали, что это неправда? Я не понимаю. Неважно, что MCU делает в полудуплексном режиме, принимает ли он собственные передачи или нет, потому что при использовании одного провода UART RX/TX сторона MCU все равно не знает, есть ли короткое замыкание на стороне RS485, т.к. он не может контролировать то, что находится на стороне RS485. Таким образом, используя один провод, ни в том, ни в другом случае MCU не сможет обнаружить ошибки, поскольку он не будет прослушивать фактические данные по RS485.
Возможность получать то, что отправляется, предназначена для того, чтобы MCU мог обнаруживать ошибки и коллизии на линии. Если есть коллизия (линия управляется другим TX) или ошибка (короткое замыкание, нестабильность), получатель, скорее всего, получит НЕ то, что только что отправил TX. Сравнивая последний отправленный байт с полученным, MCU может действовать соответствующим образом — прервать передачу, отключить звук приемника, дождаться случайного интервала и возобновить передачу. Но эта способность (получать то, что отправляется) зависит от MCU.
@neoxic Я думаю, что мы говорим здесь не об одном и том же, или есть какое-то другое недоразумение. Я понимаю и признаю, что вы имеете в виду в целом, но в данном случае возможности MCU не имеют значения. Если вы подключите только один полудуплексный провод данных RX / TX от MCU к микросхеме приемопередатчика RS-485, поскольку первоначальный вопрос был о том, каковы недостатки этого, вы просто не сможете получить обратную связь. Чтобы получить обратную связь от шины во время передачи, провода TX и RX MCU должны быть подключены к трансиверу RS-485.
Может быть. Дайте угадаю... Для меня 2-проводной RS485 - это именно то, что есть - физический полудуплексный уровень, где UART используется в качестве логического драйвера. Если вы говорите о схеме, где UART в MCU подключается к отдельному «передатчику RS485» (т.е. с собственным UART/драйвером), то вы, вероятно, говорите о связи между ними. Это соединение не имеет ничего общего с RS485, потому что оно логически соединяет два периферийных устройства. В этом случае полудуплексный режим, вероятно, ничего не даст.
Но если UART в MCU управляет двухпроводной линией RS485 напрямую, то в полудуплексном режиме он считывает то, что передает, и, следовательно, способен обнаруживать сбои и ошибки. Кстати, эта функция специально разработана для приложений RS485. Но, как я упоминал ранее, не все микроконтроллеры, а точнее не все периферийные устройства UART, имеют его.
Первоначальный вопрос был не о «микросхеме приемопередатчика RS-485». Речь шла о «двухпроводных реализациях RS485, которые используют оба контакта RX/TX UART». Например, см. ответ № 3, где ответчик называет его PHY (физическим) интерфейсом. 2-wire означает, что это полудуплекс.
Нет, вопрос не об этом, прочтите еще раз. OP использовал MCU с проводами RX и TX, подключенными к RS-485 PHY, и спрашивает, не стоит ли уменьшить количество контактов MCU и, возможно, переключиться на использование одного полудуплексного провода RX/TX между MCU и RS-485. PHY и определенно думаю об объединении контактов RE/TE. Недостатком использования полудуплекса между MCU и RS-485 PHY является то, что вы не можете получать/отслеживать/воспринимать от RS-485 PHY, что на самом деле происходит на шине RS-485 при передаче на шину с RS-485. физ.
Аааа, блин... :-) Теперь я вижу, где было недоразумение. Спасибо! Да, объединение выводов RE/DE в драйвере определенно снизит обратную связь.
Ради честности я также должен отказаться от своего первоначального комментария. Я тщательно протестировал UART в STM8, и оказалось, что он в равной степени способен принимать собственные данные в полудуплексном режиме. Фактически это тот же UART, что и в STM32.

RS485 уже является полудуплексным. Итак, почему бы не рассказать немного больше об интерфейсе PHY.
Это хорошая идея, если вы можете найти надежный метод арбитража RX и TX на локальных узлах и арбитража шины. Став еще более активным, вы можете ввести способ обнаружения конфликтов на шине. Что касается программного обеспечения, канальный уровень может с радостью потерять какую-то серьезную часть кода.
Когда я пишу это, это действительно кажется очень интересной идеей; что-то вроде Ethernet на RS485 PHY, или там уже должно быть что-то.

RS-485 НЕ является полудуплексным. Он может работать в полудуплексном (однонаправленном) или полном (двунаправленном) дуплексе по усмотрению проектировщика. На самом деле, одно из изменений, сделанных с '485 по сравнению с '422, заключается в том, что драйвер RS-485 может управлять дифференциальной парой с двойным окончанием, с резисторами 120 Ом на каждом конце линии.
Спасибо @SteveSh! Звучит как хороший аргумент, с которым я могу согласиться. Действительно, стандарт может указывать только электрические характеристики RS-485 и RS-422, я думаю, нет необходимости ограничивать дуплекс или протоколы.
Прослушивание собственного разговора — ненадежный способ обнаружения конкуренции на шине RS485.
Я согласен с @brhans. Обнаружение конфликтов не так просто.
@SteveSh, я имел в виду двухпроводной RS485 (упомянутый), поэтому полудуплексный контекст. другие: слушать собственный разговор в автобусе — это то, от чего я хотел полностью отказаться. Отсюда и идея использовать полный полудуплекс на UART (выполнит подтяжку, как уже упоминалось). Не уверен, что смогу просто так совместить RX/TX трансивера 485
@ JeromeBu1982 О том, что «просто объедините RX / TX» и «подтяните к линиям данных, чтобы он плавал в режиме ожидания»: если вывод UART TX не может быть настроен как открытый сток, тогда ему потребуется внешний буфер. Приемопередающее устройство потребует аналогичного рассмотрения. Первоначальная реализация не будет такой простой, как «просто собрать вместе», хотя, если концепция будет реализована в конструкции устройств, это будет привлекательный вариант, такой же простой, как RS485, и, я думаю, отвечает тем, что Ethernet не может.
Re: обнаружение конфликтов: я вспоминаю экскурсию, когда мы продавали оборудование Westermo. У них есть/было семейство последовательных преобразователей в оптоволоконные, которые могут/могут работать в резервном кольце на оптоволокне. А именно, это было старое поколение ЛД-64, как мне кажется. Протокол на месте был чем-то основан на полудуплексе RS485 с передачей маркера и быстрой коммутацией RX/TX. Во время запуска, по-видимому, шина полагалась на обнаружение коллизий (ошибки контрольной суммы), чтобы на некоторое время притормозить с передачей, чтобы «вставиться» без проблем. Узлы Westermo предотвратили искажение кадров и сбой при запуске...
(...продолжение) Я бы не назвал это ошибкой , скорее проблемой интеграции. Если я правильно помню, тонкие кольцевые узлы волокна Вестермо имели приоритет перед данными, поступающими от местного металлического узла. По кольцу данные будут перемещаться по кругу. Если локальный металлический «клиент» начал что-то передавать, узел оптоволоконного преобразователя блокировал все, что исходило с левой стороны кольца, и начинал повторять активность с локального металлического узла. Таким образом, нисходящие узлы (клиенты) справа не обязательно обнаружат ошибку контрольной суммы кадра и попытаются отследить ее напрямую.
(...продолжение) Вероятно, это привело к расщеплению/раздвоению/хаосу в последовательности передачи токенов, и аккуратный алгоритм быстрой передачи токенов рухнул. Был обходной путь, который действительно помог: обратить внимание на порядок адресов узлов в «клиентском» протоколе (болтовня ПЛК) и упорядочить адреса узлов ПЛК по кольцу в обратном направлении . Таким образом, соседним узлом, за которым нужно следить, будет тот, который находится слева от вас, и, если повезет, любой промежуточный узел (справа от вас), вероятно, не вмешается ... Задержки распространения вдоль оптоволоконного кольца были незначительными = нет проблема.
Хороший вопрос @frr! «Кольцевая топология» исключает «шинный» арбитраж.

Хм... стандартный Modbus/ASCII не использует тайм-аут прерывания кадра в 3,5 символа. Этот тайм-аут характерен для Modbus/RTU. Очевидно, что если вы владеете реализацией всех узлов, это мало что значит. Если ваша подпрограмма RX кадра может определить конец кадра на основе содержимого кадра (кадры переменной длины имеют длину, закодированную в начале кадра), вам, вероятно, даже не нужно соблюдать 3,5 символа ценности с точки зрения времени обработки RX/TX. ".

Когда-то я написал библиотеку Modbus для ПК, а также немного разбирался в 16C550A и совместимых UART, но эти знания устаревают. И я, конечно, ничего не знаю о UART, встречающемся в MCU. Будучи избалованным расточительным подходом к подсчету контактов в оборудовании ПК и имея лишь ржавую память о кодировании аппаратного обеспечения UART 16C550A, я не вижу, что «использование UART в полудуплексном режиме» может спасти меня с точки зрения размер или сложность кода.

Тем не менее, если я могу предложить что-то для облегчения полудуплексной работы RS485, это будет использование UART, который может автоматически управлять RX / TX , экспортируя внутренний флаг, называемый «Сдвиговый регистр передатчика пуст», в качестве внешнего дискретного сигнала, который может быть подключен непосредственно к преобразователю уровня RS485 (приемопередатчику).

Примечание: не путайте требуемый «Пустой регистр сдвига передатчика» с «Пустой регистр хранения передатчика» = другой флаг состояния в UART. Первое означает, что байт в данный момент побитно сдвигается в строку. Последнее относится к FIFO — и флаг THRE становится активным, как только FIFO пуст, т. е. пока сдвиговый регистр все еще занят смещением последнего байта, т. е. слишком рано, чтобы трансивер RS485 отключился в высокий Z/прослушивание. состояние.

Некоторые реализации UART могут отправлять этот сигнал в качестве альтернативной функции контактов RTS или DTR, другие имеют выделенные выходные контакты или могут отображать его на какой-либо GPIO. Стандартный 16C550A имеет только TSRE, также известный как TEMT, в качестве внутреннего флага состояния, но не имеет возможности экспортировать его на любой выходной контакт. То есть 16C550A не лучший выбор для RS485. В качестве блестящего примера правильно выполненной этой функции хотелось бы упомянуть покойный OX16C950 UART от Oxford Semiconductor, ныне уже не производимый (технический прогресс имеет свою оборотную сторону, и была череда приобретений, примерно OX Semi -> PLX - > Avago -> Broadcom). Если память не изменяет, современные UART от EXAR тоже могут это делать, и некоторые чипы LPC SuperIO также могут поддерживать это на некоторых или всех каналах UART (Fintek, SMSC, возможно, некоторые недавние ITE и Nuvoton, урожденная Winbond). я не

Кажется, я припоминаю некоторые UART, в которых эта функция несовершенна, а именно я вспоминаю дополнительную плату PCI для ПК с портами RS485 и аппаратным управлением, где UART переключал приемопередатчик в режим high-Z (RX) на один бит раньше, чем нужно. срезание стопового бита. Который, по-видимому, отлично работал против других UART ... Я не помню марку чипа UART на этой плате.

Я также видел ошибку проектирования на уровне платы (думаю) в некоторых азиатских промышленных ПК, где режим RS485 был реализован путем управления управляющим штифтом приемопередатчика RX / TX с помощью TTL Data TX UART, так что приемопередатчик переключался между лог. 1 и высокий Z...

Эта функция, т.е. "TSRE=TEMT для управления RX/TX RS485", может избавить вас от головной боли, связанной с точной синхронизацией в программном обеспечении. Это, безусловно, головная боль на ПК, особенно под некоторыми современными ОС ... независимо от того, является ли синхронизация головной болью или нет на вашем конкретном MCU, это, очевидно, ваше личное дело, YMMV.

Вы правы: РТУ
Хорошая идея использовать UART в полудуплексном режиме при использовании приемопередатчика RS485?
СпросиСетьПолитика конфиденциальности1y, 0v