Xon xoff что это

knigechka

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

Для управления потоком данных (Flow Control) могут использоваться два вари­анта протокола — аппаратный и программный. Иногда управление потоком пута­ют с квитированием. Квитирование (handshaking) подразумевает посылку уведомления о получении элемента, в то время как управление потоком предполагает посылку уведомления о возможности или невозможности последующего приема данных. Зачастую управление потоком основано на механизме квитирования.

Аппаратный протокол управления потоком RTS/CTS (hardware flow control) ис­пользует сигнал CIS, который позволяет остановить передачу данных, если при­емник не готов к их приему (рис. 2.13). Передатчик «выпускает» очередной байт только при включенной линии CTS. Байт, который уже начал передаваться, задер­жать сигналом CTS невозможно (это гарантирует целостность посылки). Аппарат­ный протокол обеспечивает самую быструю реакцию передатчика на состояние приемника. Микросхемы асинхронных приемопередатчиков имеют не менее двух регистров в приемной части — сдвигающий, для приема очередной посылки, и хра­нящий, из которого считывается принятый байт. Это позволяет реализовать обмен по аппаратному протоколу без потери данных.

Рис. 2.13. Аппаратное управление потоком

Аппаратный протокол удобно использовать при подключении принтеров и плот­теров, если они его поддерживают. При непосредственном (без модемов) соеди­нении двух компьютеров аппаратный протокол требует перекрестного соедине­ния линий RTS — CTS.

При непосредственном соединении у передающего терминала должно быть обес­печено состояние «включено» на линии CTS (соединением собственных линий RTS — CTS), в противном случае передатчик будет «молчать».

Применяемые в IBM PC приемопередатчики 8250/16450/16550 сигнал CTS аппарат-но не отрабатывают, а только показывают его состояние в регистре MSR (см. п. 2.5). Реализация протокола RTS/CTS возлагается на драйвер BIOS Int 14h, и назы­вать его «аппаратным» не совсем корректно. Если же программа, пользующаяся СОМ-портом, взаимодействует с UART на уровне регистров (а не через BIOS), то обработкой сигнала CTS для поддержки данного протокола она занимается сама. Ряд коммуникационных программ позволяет игнорировать сигнал CTS (если не используется модем), и для них не требуется соединение входа CTS с выходом даже своего сигнала RTS. Однако существуют и иные приемопередатчики (например, 8251), в которых сигнал CTS отрабатывается аппаратно. Для них, а также для «чест­ных» программ, использование сигнала CTS на разъемах (а то и на кабелях) обя­зательно. Преимущество протокола RTS/CTS во времени реакции (по сравне­нию с программным методом XON/XOFF) остается лишь для буферированной (в режиме FIFO) передачи.

Программный протокол управления потоком XON/XOFF предполагает наличие двунаправленного канала передачи данных. Работает протокол следующим обра­зом: если устройство, принимающее данные, обнаруживает причины, по которым оно не может их дальше принимать, оно по обратному последовательному каналу посылает байт-символ XOFF (13h). Противоположное устройство, приняв этот символ, приостанавливает передачу. Когда принимающее устройство снова стано­вится готовым к приему данных, оно посылает символ XON (llh), приняв который противоположное устройство возобновляет передачу. Время реакции передатчи­ка на изменение состояния приемника по сравнению с аппаратным протоколом увеличивается, по крайней мере, на время передачи символа (XON или XOFF) плюс время реакции программы передатчика на прием символа (рис. 2.14). Из этого следует, что данные без потерь могут приниматься только приемником, имеющим дополнительный буфер принимаемых данных и сигнализирующим о неготовно­сти заблаговременно (имея в буфере свободное место).

Рис. 2.14. Программное управление потоком XON/XOFF

Преимущество программного протокола заключается в отсутствии необходимо­сти передачи управляющих сигналов интерфейса — минимальный кабель для дву­стороннего обмена может иметь только 3 провода (см. рис. 2.5, а). Недостатком, помимо обязательного наличия буфера и большего времени реакции (снижающе­го общую производительность канала из-за ожидания сигнала XON), является сложность реализации полнодуплексного режима обмена. В этом случае из пото­ка принимаемых данных должны выделяться (и обрабатываться) символы управ­ления потоком, что ограничивает набор передаваемых символов.

Кроме этих двух распространенных стандартных протоколов, поддерживаемых и ПУ, и ОС, существуют и другие.

Литература:
ГукМ., Г93 Аппаратные интерфейсы ПК. Энциклопедия. — СПб.: Питер, 2002. — 528 с.: ил.

Источник

Xon xoff что это

Имеются 2 типа управления потоком данных: аппаратное и программное (Xon/Xoff).

Аппаратное управление потоком данных использует специальный сигнальный провод, в то время как программное управление потоком данных сигнализирует, посылкой служебных байтов Xon или Xoff по обычному проводу данных. Для аппаратного управления потоком данных, кабель должен быть правильно распаян.

Поток байтов данных в кабеле между 2 последовательными портами двунаправлен так что имеются 2 различных потока:

Можно было удивиться, почему возможно переполнение последовательного порта, так как скорости и передачи, и приема байтов данных последовательных портов, установлены равными (в бит/сек) типа 19,200.

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

Когда содержимое этого маленького аппаратного буфера достигает определенного ограничения (один байт для старого UART’S) генерируется прерывание. Затем компьютерные прерывания, которые были вызваны и программное обеспечение выясняют что случалось. В конце концов они определяют, что требуется извлечь байт (или больше) из буфера последовательного порта. Они берут этот байт(ы) и помещают их в больший буфер (также буфер последовательных портов), который ядро поддерживает в оперативной памяти.

Терминалы также имеют последовательные порты и буфера подобно компьютеру.

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

Конечно, если вы используете компьютер как терминал (эмуляцией), тогда он аналогично подвержен переполнению.

Опасные ситуации, когда переполнение наиболее вероятно: 1. Когда другой процесс отключил прерывания (для компьютера). 2. Когда буфер последовательных портов в главной (или терминальной) памяти собирается переполняться.

Когда обнаруживается, что приемник почти переполнен входящими байтами, то отправителю посылается сигнал прекращения передачи. Это называется управлением потоком данных, и сигналы управления потоком данных всегда направлены против потока данных, которыми они управляют (хотя не в том же самом канале или проводе). Этот сигнал может быть или управляющим символом (^S = DC3 = Xoff), посланный как обычный байт данных по проводу данных («внутрипотоковая» сигнализация), или переходом напряжения с положительного на отрицательный урвень по rts-cts (или другим) сигнальным проводам(внепотоковая сигнализация

Использование Xoff называется «программное управление потоком данных», а использование перехода напряжения в специальном сигнальном проводе (внутри кабеля) называется «аппаратное управление потоком данных».

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

Когда приемник обработал данные и готов получать остальные байты данных, он сообщает об этом отправителю. Для программного управления потоком данных этим сигналом является управляющий символ ^Q = DC1 = Xon, который пересылается как обычная строка данных. Для аппаратного управления потоком данных напряжение в сигнальном проводе переходит из отрицательного (инвертированного) уровня в положительный (установленному).

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

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

Управление потоком данных RTS/CTS и DTR

Linux PC использует RTS/CTS, но управление потоком данных с помощью DTR (используемое многими терминалами) ведет себя аналогично (за исключением то, что оно однонаправленное). RTS/CTS использует выводы RTS и CTS на последовательном разъеме (EIA-232). RTS означает «Запрос передачи (Request To Send)».

Связь с помощью интерфейса DTR с RTS/CTS управлением потоком данных

Многие терминалы используют DTR управление потоком данных. Это исключительно одностороннее управление потоком данных для предохранения терминала от переполнения. Это не защищает компьютер от кого-то, печатающего слишком быстро для компьютера. Как можно использовать это с Linux, который использует управление потоком данных RTS/CTS?

Так как вывод DTR ведет себя подобно выводу RTS, то на терминале обрабатывают только вывод DTR, как будто это вывод RTS, присоединенный к выводу CTS на компьютере. Для этого вам вероятно потребуется сделать специальный кабель (или перепаять разъем). Таким образом можно использовать DTR управление потоком данных на терминальном конце кабеля с RTS/CTS управлением потоком данных на компьютерном конце кабеля. Тогда при использовании этого вы должны «stty local» так как терминальный вывод DTR не может выполнить свою обычную функцию сообщения главному компьютеру, что терминал включен.

Отличие от старого подтверждения связи RTS/CTS

При объяснении значений сигналов возникает путаница, из-за того, что имеется первоначальное значение RTS, которое противоположно вешеприведенному объяснению. Первоначальное его значение: я запрашиваю разрешение на посылку вам данных (Request To Send). Этот запрос был предназначен для посылки с терминала (или компьютера) на модем, который, если решит удовлетворить запрос, пошлет обратно установленный сигнал CTS с вывода CTS на вывод CTS компьютера: для посылки мне все чисто (Cleared to Send). Обратите внимание, что в отличие от современного RTS/CTS двунаправленного управления потоком данных, этот метод защищает поток только в одном направлении: от компьютера (или терминала) к модему.

Обратный канал

Старые аппратные терминалы могут иметь вывод обратного канала (типа вывода 19), который ведет себя подобно выводу RTS в RTS/CTS управлении потоком данных. Но этот вывод будет также инвертироваться, если бумага или лента выходит наружу. Часто можно соединить этот вывод с выводом CTS главного компьютера.

Может иметься dip-переключатель для установки полярности сигнала.

Некоторые думают, что аппаратное управление потоком данных выполнено аппаратными средствами, но (если вы не используете интеллектуальную последовательную плату с несколькими последовательными портами) это фактически выполнено программным обеспечением вашей операционной системы. Чипы UART и связанные аппаратные средства обычно не знают ничто вообще о аппаратном управлении потоком данных. Когда аппаратный сигнал управления потоком данных получен, сигнальный провод меняет полярность, и аппаратные средства дают электрический сигнал прерывания центральному процессору. Однако, аппаратные средства понятия не имеют, что это прерывание означает. Центральный процессор останавливает работу и переходит к таблице в оперативной памяти, которая сообщает центральному процессору, где находится программу, которая выяснит то, что случилось и предпримет соответствующие действия.

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

Затем программное обеспечение понимает, что был получен сигнал управления потоком данных и останавливает (или запускает) поток. Однако, если был получен сигнал останова, поток останавливается почти немедленно по прибытии сигнала, потому что прерывание останавливает любой процесс, выполняемый центральным процессором (включая программу, которая посылала данные и помещала ее в аппаратные буфера последовательных портов для передачи).

Источник

Русские Блоги

Управление последовательным потоком UART (управление потоком)

Как правило, при последовательной связи на некоторых компьютерах верхнего уровня мы увидим параметры RTS / CTS, DTR / DSR и XON / XOFF.Это параметр для управления потоком, который обычно применяется к интерфейсу RS232, который является данными от модема. Общение

1. Роль управления потоками

Упомянутый здесь «поток» относится к потоку данных; при передаче данныхУправление потокомЭто процесс управления скоростью передачи данных между двумя узлами для предотвращения заполнения буфера данных на принимающей стороне, в то время как отправляющая сторона продолжает отправлять данные, что приводит к потере данных.

2. Принцип работы

Когда буфер данных на принимающей стороне заполнен и данные не могут быть обработаны, он отправит сигнал «больше не принимает», а отправляющая сторона прекратит отправку, пока отправляющая сторона не получит сигнал «можно продолжить отправку» перед отправкой данных. В компьютерах обычно используются два типа управления потоком: аппаратное управление потоком (RTS / CTS, DTR / DSR и т. Д.) И программное управление потоком (XON / XOFF).

Три, определение контакта RS232

RS-232 в настоящее время имеет разъемы типа DB-25 и DB-9, а интерфейсы типа DB-9 используются чаще.

Назначение контактов типа DB-9 в RS-232:

Описание его сигнального контакта:

4. Аппаратное управление потоком (в основном RTS / CTS)

RTS / CTS был первоначально разработан для полудуплексной совместной связи между телетайпом и модемом, и только один модем может отправлять данные одновременно. Терминал должен отправить запрос на отправку сигнала, а затем ждать, пока модем не ответит разрешением на отправку. Хотя в RTS / CTS квитирование осуществляется аппаратно, у него есть свои преимущества.

1. Стандартный метод подключения RS232

Когда оборудование на стороне A готово, сигнал DTR (оборудование для передачи данных готово) будет отправлен на RI (вызывной сигнал) и DSR (оборудование связи готово) на стороне B. Таким образом, пока A готов (DTR), B будет генерировать вызов (RI) и быть готовым (DSR).

Обратите внимание, что RTS (запрос на отправку), CTS (разрешена отправка) и CD (обнаружение несущей) на стороне B соединены вместе, что означает, что как только A запрашивает отправку (RTS), он будет немедленно разрешен (CTS) и сделает обнаружение B Несущий сигнал (CD). TXD терминала A соединен с RXD терминала B, и A отправляет, а B принимает.

2. Упрощенный способ подключения RS232.

Исходные RTS и CTS используются, чтобы спросить и ответить, можно ли передавать данные. Но в этом режиме соединения он просто сообщает другой стороне, могут ли они общаться. В настоящее время для управления потоком данных могут использоваться как RTS, так и DTR.

DTR (готовность устройства данных) на стороне A. Когда сторона B готова, DTR (готовность устройства данных) на стороне B отправляет сигнал DSR (устройство связи готово) на стороне A. Затем вы можете контролировать связь через RTS (запрос на отправку) и DTR (разрешить отправку).

3. Дальнейшее упрощение (то есть на основе RTS / CTS)

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

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

Пять, программное управление потоком

Стоит отметить, что получатель отправляет отправителю сигналы XON / XOFF, чтобы контролировать, когда отправитель отправляет данные.Эти сигналы противоположны направлению передачи отправленных данных.

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

XON / XOFF, как правило, не рекомендуются. Рекомендуется заменить их потоком управления RTS / CTS. Потому что, если вы передаете двоичные данные, в отправляемых вами данных могут быть двоичные значения, соответствующие XON и XOFF, что может привести к неправильной работе. Это дефект программного управления потоком, и аппаратное управление потоком не будет иметь этой проблемы; конечно, вы Вы также можете избежать XON и XOFF

Шесть, управление нижним уровнем UART

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

Источник

Управление потоком данных

Для управления потоком данных (Flow Control) могут использоваться два варианта протоко-

ла – аппаратный и программный. Иногда управление потоком путают с квитированием. Квитиро-

вание (handshaking) подразумевает посылку уведомления о получении элемента, в то время как управление потоком предполагает посылку уведомления о возможности или невозможности после- дующего приема данных. Зачастую управление потоком основано на механизме квитирования.

Аппаратный протокол управления потоком RTS/CTS (hardware flow control) использует сиг-

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

Передатчик «выпускает» очередной байт только при включенной линии CTS. Байт, который уже начал передаваться, задержать сигналом CTS невозможно (это гарантирует целостность по- сылки). Аппаратный протокол обеспечивает самую быструю реакцию передатчика на состояние при- емника. Микросхемы асинхронных приемопередатчиков имеют не менее двух регистров в приемной части – сдвигающий, для приема очередной посылки, и хранящий, из которого считывается приня- тый байт. Это позволяет реализовать обмен по аппаратному протоколу без потери данных.

Аппаратный протокол удобно использовать при подключении принтеров и плоттеров, если они

его поддерживают. При непосредственном (без модемов) соединении двух компьютеров аппарат- ный протокол требует перекрестного соединения линий RTS – CTS. При непосредственном соеди- нении у передающего терминала должно быть обеспечено состояние «включено» на линии CTS (со- единением собственных линий RTS – CTS), в противном случае передатчик будет «молчать».

Применяемые в IBM PC приемопередатчики (8250) сигнал CTS аппаратно не отрабатывают, а только показывают его состояние в регистре MSR. Реализация протокола RTS/CTS возлагается на драйвер BIOS Int 14h, и называть его «аппаратным» не совсем корректно. Если же программа, пользующаяся СОМ-портом, взаимодействует с UART на уровне регистров (а не через BIOS), то обработкой сигнала CTS для поддержки данного протокола она занимается сама. Ряд коммуника- ционных программ позволяет игнорировать сигнал CTS (если не используется модем), и для них не требуется соединение входа CTS с выходом даже своего сигнала RTS. Однако существуют и иные приемопередатчики (например, 8251), в которых сигнал CTS отрабатывается аппаратно. Для них, а также для «честных» программ, использование сигнала CTS на разъемах (а то и на кабелях) обязательно. Преимущество протокола RTS/CTS во времени реакции (по сравнению с программ- ным методом XON/XOFF) остается лишь для буферированной (в режиме FIFO) передачи.

Программный протокол управления потоком XON/XOFF предполагает наличие двунаправ-

ленного канала передачи данных. Работает протокол следующим образом: если устройство, прини- мающее данные, обнаруживает причины, по которым оно не может их дальше принимать, оно по об- ратному последовательному каналу посылает байт-символ XOFF (13h). Противоположное устрой- ство, приняв этот символ, приостанавливает передачу. Когда принимающее устройство снова стано- вится готовым к приему данных, оно посылает символ XON (llh), приняв который противополож- ное устройство возобновляет передачу. Время реакции передатчика на изменение состояния при- емника по сравнению с аппаратным протоколом увеличивается, по крайней мере, на время переда- чи символа (XON или XOFF) плюс время реакции программы передатчика на прием символа.

Из этого следует, что данные без потерь могут приниматься только приемником, имеющим до- полнительный буфер принимаемых данных и сигнализирующим о неготовности заблаговременно (имея в буфере свободное место).

Преимущество программного протокола заключается в отсутствии необходимости передачи

управляющих сигналов интерфейса – минимальный кабель для двустороннего обмена может иметь только 3 провода. Недостатком, помимо обязательного наличия буфера и большего времени реакции (снижающего общую производительность канала из-за ожидания сигнала XON), является сложность реализации полнодуплексного режима обмена. В этом случае из потока принимаемых дан- ных должны выделяться (и обрабатываться) символы управления потоком, что ограничивает набор передаваемых символов.

Интерфейс RS-485

Стандарт RS-485 был совместно разработан двумя ассоциациями производителей: Амери- канскими Ассоциацией электронной промышленности (EIA – Electronics Industries Association) и Ассоциацией промышленности средств связи (TIA – Telecommunications Industry Associastion).

«Официальное» название стандарта – TIA/EIA-485 Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems (Электрические характеристики передатчи- ков и приемников, используемых в балансных цифровых многоточечных системах). Однако боль- шинство специалистов используют старое обозначение, RS-485.

Интерфейс RS-485 – широко распространенный достаточно высокоскоростной и помехо- устойчивый промышленный последовательный интерфейс передачи данных. Практически все со- временные компьютеры в промышленном исполнении, большинство интеллектуальных датчиков и исполнительных устройств, программируемые логические контроллеры наряду с традиционным интерфейсом RS-232 содержат в своем составе ту или иную реализацию интерфейса RS-485.

Традиционный интерфейс RS-232 в промышленной автоматизации применяется достаточно

редко. Сигналы этого интерфейса передаются несимметричными сигналами относительно общего провода, длина линии связи, как правило, ограничена расстоянием в несколько метров из-за низ- кой помехоустойчивости. Интерфейс RS-232 принципиально не позволяет создавать сети, так как соединяет только 2 устройства (соединение «точка-точка»). До недавнего времени RS-232 имелся в каждом PC-совместимом компьютере, где использовался в основном для подключения «мыши», модема, реже – для передачи данных на небольшое расстояние из одного компьютера в другой.

Интерфейс RS-485 позволяет создавать сети путем параллельного подключения многих уст- ройств к одной физической линии («мультиплексная шина»), обеспечивая обмен данными между несколькими устройствами по одной двухпроводной линии связи в полудуплексном режиме (раз- новидность RS-485 – RS-422 – в дуплексном). Сигналы интерфейса RS-485 передаются дифферен- циальными перепадами напряжения, что обеспечивает высокую помехоустойчивость и общую длину линии связи до 1 км (и более, с использованием специальных устройств – повторителей).

Протоколы. Стандарт RS-485 не нормирует формат информационных кадров и протокол обмена. Наиболее часто для передачи байтов данных используются те же фреймы, что и в интер- фейсе RS-232: стартовый бит, биты данных, бит паритета (если нужно), стоповый бит. Протоколы обмена в большинстве систем работают по принципу «ведущий»–«ведомый»: одно устройство на магистрали является ведущим (master) и инициирует обмен посылкой запросов подчиненным (ве- домым) устройствам (slave), которые различаются логическими адресами. Одним из популярных протоколов является протокол Modbus RTU.

Разъемы. Тип соединителей и их распайка также не оговариваются стандартом RS-485.

Встречаются соединители DB9, клеммные соединители и т.д.

В интерфейсе RS-485 используется принцип дифференциальной (балансной) передачи дан- ных, суть которого заключается в передаче одного сигнала по двум проводам, причем по одному проводу идет оригинальный сигнал, а по другому – его инверсная копия. Таким образом, между двумя проводами витой пары всегда есть разность потенциалов: при «1» она положительна, при

Такой способ передачи обеспечивает высокую устойчивость к синфазной помехе (дейст- вующую на оба провода линии одинаково). Так, электромагнитная волна, проходя через участок линии связи, наводит в обоих проводах потенциал. Если сигнал передается потенциалом в одном проводе относительно общего («земли»), как в RS-232, то наводка на этот провод может исказить сигнал относительно хорошо поглощающей наводки «земли». Кроме того, на сопротивлении

длинной «земли» будет падать разность потенциалов земель – дополнительный источник искаже- ний. При дифференциальной же передаче искажения не происходит, поскольку, если два провода пролегают близко друг к другу (к тому же перевиты), то наводка на оба провода одинакова. По- тенциал в обоих одинаково нагруженных проводах изменяется одинаково, при этом информатив- ная разность потенциалов остается без изменений.

Существуют два варианта интерфейса: RS-422 и RS-485.

RS-422 – полнодуплексный интерфейс. Прием и передача идут по двум отдельным парам проводов. На каждой паре проводов может быть только по одному передатчику.

RS-485 – полудуплексный интерфейс. Прием и передача идут по одной паре проводов с раз-

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

Аппаратная реализация интерфейса – микросхемы приемопередатчиков с дифференциаль- ными входами/выходами (подключаемыми к линии) и цифровыми портами (подключаемыми к портам UART микроконтроллера).

D (driver) – передатчик; A – прямой дифференциальный вход/выход;

R (receiver) – приемник; B – инверсный дифференциальный вход/выход; DI (driver input) – цифровой вход передатчика; Y – прямой дифференциальный выход (RS-422); RO (receiver output) – цифровой выход приемника; Z – инверсный дифференциальный выход (RS-422) DE (driver enable) – разрешение работы передатчика;

RE (receiver enable) – разрешение работы приемника;

Для работы приемопередатчика RS-485 с микроконтроллером цифровой выход приемника (RO) подключается к порту приемника UART (RX), а цифровой вход передатчика (DI) – к порту передатчика UART (TX). Поскольку на дифференциальной стороне приемник и передатчик со- единены, то во время приема нужно отключать передатчик, а во время передачи – приемник. Для этого служат управляющие входы – разрешение приемника (RE) и разрешения передатчика (DE). Так как вход RE инверсный, то его можно соединить с DE и переключать приемник и передатчик одним сигналом с любого порта контроллера. При уровне «0» – работа на прием, при «1» – на пе- редачу.

Приемник, получая на дифференциальных входах (AB) разность потенциалов (UAB) перево- дит их в цифровой сигнал на выходе RO. Чувствительность приемника может быть разной, но га- рантированный пороговый диапазон распознавания сигнала обычно составляет ± 200 мВ. То есть, когда UAB > +200 мВ – приемник определяет «1», когда UAB

Источник