Управление потоком xon xoff что это

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

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

Аппаратный протокол управления потоком RTS/CTS (Hardware Flow Control)использует сигнал CTS,который поз­воляет остановить передачу данных, если приемник не готов к их приему (рис. 2.9). Передатчик «выпускает» очередной байт только при включенной линии CTS. Байт, который уже начал передаваться, задержать сигналом CTS невозможно (это гарантирует целостность посылки). Аппаратный протокол обеспечивает самую быструю реакцию передатчика на состо­яние приемника. Микросхемы асинхронных приемопередат­чиков имеют не менее двух регистров в приемной части —

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

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

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

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

XON (llh), приняв который противоположное устройство возобновляет передачу. Время реакции передатчика на из­менение состояния приемника по сравнению с аппаратным протоколом увеличивается по крайней мере на время пере­дачи символа (XON или XOFF) плюс время реакции програм­мы передатчика на прием символа (рис. 2.11). Из этого сле­дует, что данные без потерь могут приниматься только приемником, имеющим дополнительный буфер принимае­мых данных и сигнализирующим о неготовности заблаго­временно (имея в буфере свободное место).

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

Кроме этих двух распространенных стандартных протоко­лов, поддерживаемых и ПУ, и ОС, существуют и другие. Некоторые плоттеры с последовательным интерфейсом ис­пользуют программное управление, но посылают не стан­дартные символы XON/XOFF, а слова (ASCII-строки). Такой обмен на уровне системной поддержки протокола практи­чески не поддерживается (эти плоттеры непосредственно

«разговаривают» с прикладной программой). Конечно, можно написать драйвер СОМ-порта (перехватчик INT 14h),но не­обходимость обработки в нем текстовых сообщений от уст­ройства вывода обычно не вызывает восторга у системного программиста. Кабель для подключения совпадает с приве­денным на рис. 2.12.

2.3. Интерфейс «токовая петля»

Распространенным вариантом последовательного интерфей­са является токовая петля. В ней электрическим сигналом является не уровень напряжения относительно общего про­вода, а токв двухпроводной линии, соединяющей приемник и передатчик. Логической единице (состоянию «включено») соответствует протекание тока 20 мА, а логическому нулю — отсутствие тока. Такое представление сигналов для описан­ного формата асинхронной посылки позволяет обнаружить обрыв линии — приемник заметит отсутствие стоп-бита (об­рыв линии действует как постоянный логический нуль).

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

Токовая петля с гальванической развязкой позволяет пере­давать сигналы на расстояния до нескольких километров. Расстояние определяется сопротивлением пары проводов и уровнем помех. Поскольку интерфейс требует пары прово­дов для каждого сигнала, обычно используют только два сиг­нала интерфейса. В случае двунаправленного обмена при­меняются только сигналы передаваемых и принимаемых данных, а для управления потоком используется программ­ный метод XON/XOFF.Если двунаправленный обмен не тре­буется, используют одну линию данных, а для управления потоком обратная линия задействуется для сигнала CTS(ап­паратный протокол) или встречной линии данных (про­граммный протокол).

Преобразовать сигналы RS-232Cв токовую петлю можно с помощью несложной схемы (рис. 2.13). Здесь принтер под­ключается по токовой петле к СОМ-порту с аппаратным управлением потоком. Для получения двуполярного сигна­ла, требуемого для входных сигналов СОМ-порта, приме­няется питание от интерфейса.

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

Управление потоком xon xoff что это

1. Главная
2. ПОЛЕЗНАЯ ИНФОРМАЦИЯ
3. Вопросы и ответы (FAQ)
4. Что такое программное управление потоком Xon/Xoff?

Xon/Xoff — это программный механизм управления потоком.

Его можно использовать только в символьно-ориентированной передаче данных (не в двоичной передаче), поскольку он основан на использовании предварительно определенных символов Xon и Xoff. Основная идея проста: когда буфер приемника заполняется до такой степени, что он больше не может принимать данные, он выдает Xoff (отключение передачи) передатчику. Когда передатчик видит символ Xoff, он прекращает передачу. Он возобновится только после того, как увидит соответствующий Xon.

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

Категории

• Преобразователи COM-портов в Ethernet
  • Преобразователи RS485, RS232 в Ethernet
    • Экономичная M0 серия
    • Промышленная M4 серия
    • Экономичная M0 серия
    • Промышленная M4 серия
    • Преобразователи RS485, RS232 в WiFi
    • Встраиваемые бескорпусные преобразователи WiFi
    • GSM/GPRS модемы
    • 4G LTE роутеры
    • Встраиваемые бескорпусные модули GSM/GPRS
    • LoRa сеть

    Управление потоком xon xoff что это

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

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

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

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

    1. Поток байтов от компьютера к терминалу
    2. Поток байтов с клавиатуры терминала на компьютер.

    Вы могли бы спросить: «Почему не замедлить скорость передачи так, чтобы устройство успевало принимать информацию и таким образом избавиться от необходимости управлять потоком данных?». Это возможно, но обычно значительно медленнее, чем быстрая отправка и использование управления потоком данных. Одна из причин — это, что нельзя выбрать любую скорость передачи последовательного порта типа 14,500. Имеется только дискретное количество значений скоростей. Скорость должна выбираться немного выше, чем быстродействие устройства, но использование управления потоком данных заставить все работать правильно. Другая причина в том, что максимальная скорость, с какой устройство может работать (без управления потоком данных) часто зависит от того, что именно послано. Посылка escape-последовательностей на терминал, коорые выполняют сложные вещи, обычно требует более медленной скорости в бодах. Для модема увеличение эффективности сжатием потока данных, посланных ему, зависит от того, насколько данные могут быть сжаты. Это случайная величина, так что для модемов также необходимо управление потоком данных.

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

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

    Одна из причин этого — буфер аппаратных средств последовательного порта очень мал. Старые последовательные порты имели размер аппаратного буфера только один байт (внутри микросхемы UART). Если этот один полученный байт данных в буфере не удален (извлечен) командами центрального процессора, то если прибывает следующий байт, этот байт теряется (буфер переполняется). Более новые микросхемы UART, а именно 16550A, имеют 16-байтовые буфера (но могут настроиться на эмуляцию однобайтного буфера) и их переполнение менее вероятно. Микросхемы модет быть настроена на генерацию прерывания, когда число байтов в буфере достигает 1, 4, 8 или 14 байтов. А другая компьютерная микросхема (обычно микросхема центрального процессора компьютера) извлекает входящие байты из этого маленького аппаратного буфера и обрабатывает их (также выполняя и другие задачи).

    Когда содержимое этого маленького аппаратного буфера достигает определенного ограничения (один байт для старого 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)».

    Когда на этих выводах появляется положительное напряжение в приемнике это означает: сохранение посыланных ко мне данных. Если RTS инвертирован (напряжение отрицательное), то «Запрос передачи» обратный, что означает: не посылать мне данные» (прекратить посылку). Когда приемник готов опять принимать данные, он устанавливает сигнал RTS для другой стороны, чтобы она продолжила передачу. Для компьютеров и терминалов (оба — оборудование типа DTE) вывод RTS посылает сигнал управления потоком данных, а вывод CTS (Готов к передаче — Clear To Send) получает сигнал. То есть вывод RTS на одном конце кабеля соединен с выводом CTS на другом конце.

    Для модема (DCE оборудование) — по другому; модемный вывод RTS получает сигнал, а вывод CTS — посылает. В то время как такая ситуация может казаться запутанной, для нее имеются веские исторические причины, которые также включены в данное обсуждение. Для DTR управления потоком данных в терминале DTR сигнал подобен сигналу, посланному из вывода RTS.

    Связь с помощью интерфейса 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 двунаправленного управления потоком данных, этот метод защищает поток только в одном направлении: от компьютера (или терминала) к модему.

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

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

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

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

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

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

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

    Однако те байты (до 16), которые были уже в аппаратном буфере последовательного порта будут переданы ??

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

    Это тоже программное управление потоком данных и требует драйвера устройства, который знает об этом. Байты отправляются в пакетах (через async последовательный порт), каждый пакет завершается управляющим символом ETX (End of Text — конец текста) .

    Когда терминал получает ETX, он ждет, сигнала готовности получить следующий пакет и тогда возвращает ACK (Acknowledge — подтверждение). Когда компьютер получает ACK, он посылает следующий пакет. И так далее. Это не поддерживается в Linux ??

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

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

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

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

    Программный метод управления потоком.

    Программный метод управления потоком, или метод XON/XOFF, заключается в следующем:

    > передача знака XOFF (код DC3h ASCII) по линии TxD (103) для сообщения местному или удаленному DTE о необходимости прерывания потока информации;

    > передача знака XON (код DClh ASCII) по линии RxD (104) для сообщения местному или удаленному DTE о необходимости восстановления потока информации.

    Знак XOFF представляет собой символ CTRL-S («S), a XON — символ CTRL-Q (*0). Если управление потоком разрешено по канальному интерфейсу модема и по последовательному порту, и знак XOFF принят по каналу связи, то этот знак заставляет модем приостановить передачу данных из своего буфера в канал связи.

    Буфер модема заполняется в процессе передачи данных местным DTE через последовательный порт. Если буфер заполнился, модем передает знак XOFF через последовательной порт, который сообщает местному DTE-устройству о необходимости прервать передачу. Местное DTE возобновляет передачу данных только в том случае, если оно принимает знак XON от модема или по каналу связи от удаленной системы (через местный модем). Это заставляет местное DTE-устройство возобновить передачу данных.

    Рассмотренный метод называется программным методом управления потоком (.Software Hand-Shaking). Его преимущество заключается в возможности

    3.13. Простейшая схема соединения для программного управления потоком

    применения соединения между компьютером и модемом (DTE-DCE) с использованием небольшого числа проводников. Одна из возможных схем такого соединения приведена на рис. 3.13.

    Модемы также поддерживают так называемое «аппаратное управление потоком», реализованное только средствами последовательного порта.

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

    DCE могут использовать два типа аппаратного управления потоком: однонаправленный и двунаправленный. Однонаправленное аппаратное управление потоком аналогично методу управления XON/XOFF. Вместо передачи знака XOFF местному терминалу модем переводит в низкое логическое состояние уровень сигнала на линии CTS (106) («Готов к передаче»).

    При изменении уровня сигнала CTS, DTE прекращает передачу данных по последовательному порту. Передача данных возобновляется, когда DCE переводит уровень сигнала на линии CTS в высокое логическое состояние, что для последовательного порта аналогично передаче сигнала XON.

    DTE может запретить DCE передавать данные в его сторону. Это возможно только тогда, когда действует двунаправленное аппаратное управление потоком. При таком управлении потоком линия CTS используется точно также, как и при однонаправленном управлении. Кроме того, DCE останавливает передачу данных к DTE, если последний переводит в низкое состояние уровень сигнала на линии RTS (105) («Запрос передачи»). DCE возобновляет передачу при переходе уровеня сигнала на линии RTS в высокое логическое состояние. Для большинства применений эффективен однонаправленный метод управления потоком.

    Аппаратное управление потоком носит также название Hardware Hand-Shaking. Для соединения аппаратуры DTE и DCE с использованием аппаратного протокола управления потоком рекомендуется использовать полную схему соединения, приведенную на рис. 3.14.

    

    3.14. Схема соединения DCE и DTE при аппаратном управлении потоком

    Также по теме:

    • Управление потоком данных
    • Соединения по интерфейсу RS-232. Кабели
    • Последовательные интерфейсы
    Похожие публикации:

    1. Как проверить эндоскопом дизельный двигатель
    2. Какие машины выгодно покупать в армении
    3. Какие права нужны в египте на авто
    4. Сколько литров в баке приоры