Конфликт SN65176 RS485

Я передаю RS485 через:

Моно-приложение -> Устройство Linux USBTTY -> Адаптер RS485 с добавленным терминатором 100R -> CATV ~1 м -> SN65176 с добавленным терминатором 100R -> PIC.

С помощью отладки я вижу, что передача из приложения на PIC прошла успешно, и передача PIC из последовательного порта также в порядке. Однако, когда SN65176 переключается из режима приема в режим привода, низкий уровень выходного сигнала очень шумный (см. захват):

Изображение осциллографа сигналов RS482

В этом захвате осциллографа канал 1 (синий) — это сторона данных (R/D) SN65176, а канал 2 (желтый) — на разъеме RS485 рядом с ПК.

В этом конкретном случае первый байт был от ПК (00001101), а второй байт был от PIC. Он должен был быть 00011101, но был получен как 00000100.

Вот соответствующий код порта Mono/C#:

        port = new SerialPort(
            portName: portName,
            baudRate: 115200,
            parity: Parity.None,
            dataBits: 8,
            stopBits: StopBits.One)
        {
            Encoding = ASCIIEncoding.ASCII,
            Handshake = Handshake.RequestToSend,
            DtrEnable = false,
            RtsEnable = false,
            WriteTimeout = 1000 // ms
        };
        port.Open();
// ...
        Port.ReadByte()

Адаптер RS232-to-485 представляет собой XS201A . Он утверждает, что имеет отказоустойчивое смещение; однако прямые измерения не подтверждают это утверждение. Возможно, это связано с тем, что смещение включается только тогда, когда на устройство подается питание, но я не считаю это особенно безопасным. В нем нет схемы, и это запечатанный блок, поэтому его сложнее реконструировать; однако при работе с внешней нагрузкой 100 Ом на обоих концах я вижу следующие напряжения:

Va-Vb = 44mV
Va-gnd = 311mV
Vb-gnd = 267mV

XS201A также утверждает, что использует «Автоматическое управление отправкой данных», питание от порта RTS / DTR / TXD и короткие RTS + CTS и DTR + DSR + CT.

С отключенным SN65176 и немного другим смещением кажется, что XS201A имеет недокументированный 4-битный линейный привод, после чего драйвер отключается:

тайм-аут привода

Это показывает два последовательных 0x33 от ПК. Оба байта окружены одним стоповым и стартовым битами, а также конечным тайм-аутом диска.

Мне это кажется спором. Вы уверены, что передатчик на стороне ПК отключен до того, как PIC начнет передачу? Как управляется сигнал включения передатчика ПК? Вы смотрели на + и - сторону шины, и они обе показывают проблему?
Я вполне уверен, что Z-состояния на стороне PIC реализованы правильно, но не так уверен на стороне ПК. Это адаптер USB-UART, а затем адаптер UART-RS485. Я опубликую свой код.
Похоже, что скорость передачи составляет около 125 КБ, но я не вижу стоп-бита при передаче с ПК. Похоже, что PIC передает раньше, чем ПК. Из вашего кода видно, что включение передачи на ПК контролируется RTS, но я понимаю, что может быть задержка перед падением RTS, особенно через USB.
Одна вещь, которая может помочь: я обычно устанавливаю на шину смещающие резисторы, чтобы на шине с тремя состояниями было напряжение примерно на 300 милливольт ниже центральной линии (около 2,2 В для шины 5 В). Таким образом, это очевидно на осциллографе, когда автобус не движется. Похоже, ваш автобус всегда едет, поэтому я подозреваю, что два передатчика перекрываются.
@Reinderien - я согласен с Марком (+1), из этих сигналов ваша проблема является разногласием. Существуют различные адаптеры RS-485, которые соответствуют описанию, которое вы написали, но не все они работают одинаково, например, некоторые утверждают, что имеют «автоматическое включение» стороны RS-485. Им требуется время после завершения передачи, чтобы перестать управлять шиной RS-485. Я предлагаю сосредоточиться только на передаче ПК (передача 1 байт, затем 5-секундная пауза, повторение) и контролировать шину во время этих пауз. Я подозреваю, что вы обнаружите, что шина RS-485 активно управляется в течение дополнительного символьного времени, превышающего сам передаваемый байт.
Сэм делает хорошее замечание: некоторые RS-232->RS-485 ждут, пока передатчик не будет бездействовать, прежде чем отключить драйвер. Для обнаружения холостого хода требуется некоторое время. Какой адаптер RS-485 вы используете? (@СэмГибсон)
Конвертер, который я использую, это. usconverters.com/rs232-rs485-конвертер-xs201a
@Mark, сеть смещения - хорошая идея, но на практике это сложно. Это дифференциальная пара, для которой требуется определенный согласующий импеданс, поэтому топология смещения не будет состоять из одного согласующего резистора.
Возможно, предвзятость тевенина показана на goo.gl/images/yY5BjW .
В качестве примера того, как я завершаю работу, взгляните на рисунок 10 на последней странице этого документа: usconverters.com/downloads/support/10waysrs485.pdf
@Reinderien - Марк уже дал много хороших советов. Я просто добавлю свои 0,02 доллара в отношении: «сеть смещения [...] сложна на практике. Это дифференциальная пара, для которой требуется определенный импеданс завершения [...]» имхо для временных целей тестирования, вам все равно о прекращении так много. Вам просто нужно сместить линии +/-, чтобы вы могли видеть на прицеле, когда они активно управляются ПК, или просто напряжение смещения от резисторов. Затем запустите тест только для ПК, который я предложил, чтобы увидеть, как быстро ПК перестанет активно управлять шиной, чтобы подтвердить фокус на аппаратном обеспечении ПК.
Глядя на вашу ссылку на преобразователь RS232-RS485, выделяются два момента (хотя схема не приводится для дальнейшего анализа). Они говорят, что у него есть «отказоустойчивые резисторы смещения», так что это может повлиять на решения о напряжении смещения и сделать его очевидным для прицела. Что еще более важно, они подтверждают мое подозрение - у него есть "Автоматический контроль отправки данных" - бинго! В техническом описании показано, что сигнал RTS не используется для управления направлением, а только для паразитного питания от порта RS232. Пожалуйста, добавьте 1-секундную задержку после Tx от ПК, прежде чем PIC попытается передать Tx, повторите свой первоначальный тест и отчитайтесь.
@Марк, эта статья «10 баллов» действительно великолепна. В свою очередь, это относится к АН-847 именно о дифференциальном смещении, которое я сейчас читаю.
@Reinderien - Спасибо за результаты тестов в ваших последних обновлениях. Это подтверждает непреднамеренную конкуренцию в автобусе. Я написал ответ, чтобы обобщить свои взгляды, и сослался на другую тему EE.SE, которая очень актуальна. Спасибо Марку за его предыдущие комментарии :-)
Мои новые проблемы с RS485 здесь: electronics.stackexchange.com/questions/246097/…

Ответы (1)

Подведем итоги обсуждения и ответим на результаты теста:

похоже, что у XS201A есть недокументированные 4 бита линейного привода, после чего драйвер отключается

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

Скорее всего, это будет относительно фиксированное время , в течение которого линия активно управляется после передачи этим преобразователем RS232-RS485, а не постоянное количество битов, независимо от скорости передачи. Вы можете значительно изменить битрейт и повторно протестировать, чтобы убедиться, что «время работы линии после отправки» по-прежнему остается близким к текущему ~ 35 мкс. Вы также можете обнаружить, что существует вариация в этом «времени работы линии после отправки» в зависимости от отправляемого байта данных, поэтому я предлагаю больше тестов с разными байтами, чтобы проверить это.

Это была еще одна недавняя тема здесь, на EE.SE (Как работает этот модуль RS485?) , где частичная схема показывает тип схемы, которая может использоваться для обеспечения «автоматического» переключения между отправкой и получением по RS-485. Однако они не переключаются сразу после завершения передачи, что приводит к поведению, которое вы наблюдали.

Как я вижу, некоторые варианты включают в себя:

  • Добавьте задержку (задержки) там, где это необходимо в вашем коде, чтобы учесть поведение этого преобразователя (но вам нужно сначала протестировать и попытаться найти максимальное «время работы линии после отправки») или ;
  • Используйте другой преобразователь RS232-RS485, который использует линию RTS для фактического переключения между Tx и Rx. Однако вам необходимо убедиться, что сигнал RTS изменяется в нужное время, а не раньше (что может прервать отправку). Небольшая «задержка переключения» все же может понадобиться, особенно если расстояние (т. е. емкость кабеля) между устройствами велико.

Вы можете изучить такие термины, как «задержка переключения RS-485» или «автоматическое переключение RS-485», чтобы получить дополнительную информацию и опыт при временном мультиплексировании нескольких передатчиков на полудуплексных шинах RS-485.

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