Управление потоком xon xoff что это
Перейти к содержимому

Управление потоком 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). Здесь принтер под­ключается по токовой петле к СОМ-порту с аппаратным управлением потоком. Для получения двуполярного сигна­ла, требуемого для входных сигналов СОМ-порта, приме­няется питание от интерфейса.

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

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

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

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

Аппаратный протокол управления потоком RTS/CTS. Он использует дополнительно два провода в кабеле, а не передачу специальных символов по линиям данных. Поэтому аппаратное управление потоком не замедляет обмен в отличие от протокола Xon-Xoff. При необходимости послать данные компьютер устанавливает сигнал на линии RTS. Если приемник (модем) готов к приему данных, то он отвечает установкой сигнала на линии CTS, и компьютер начинает посылку данных. При неготовности устройства к приему сигнал CTS не устанавливается.

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

Программный протокол управления потоком Xon/Xoff использует два символа: Xon и Xoff. Код ASCII символа Xon — 17, а ASCII код Xoff — 19. Модем имеет маленький буфер, поэтому при его заполнении модем посылает символ Xoff компьютеру для прекращения посылки данных. При появлении возможности приема данных посылается символ Xon и компьютер продолжит пересылку данных. Этот тип управления имеет преимущество в том, что не требует дополнительных линий, т.к. символы передаются по линиям TD/RD. Но на медленных соединениях это может привести к значительному замедлению соединения, т.к. каждый символ требует 10 битов.

RS-485 используется для обмена данными между несколькими устройствами по одной двухпроводной линии связи (витой паре) в полудуплексном режиме. Передача выполняется одновременно только в одну сторону. Прием при этом невозможен. Для приема данных требуется переключения приёмопередатчика в режим приема. По электрическим характеристикам и принципам передачи данных RS-422 полностью совместим с RS-485, но является дуплексным. В нем одна витая пара постоянно используется для приема, а другая для передачи данных. Уровни сигналов RS-422 Передача данных идёт по двум линиям, A и B, представляющим собой витую пару (два скрученных провода). Используется принцип дифференциальной передачи одного сигнала. По проводу A идет исходный сигнал, по проводу B противофазный. Когда на одном проводе логическая 1 , на другом логический 0 и наоборот. Этим достигается высокая устойчивость к синфазной помехе, действующей на оба провода одинаково. Электромагнитная помеха, проходя через участок линии связи, наводит в каждом проводе одинаковый потенциал, при этом информативная разность потенциалов остается без изменений. Передатчик должен обеспечивать уровень сигнала 1,5 В при максимальной нагрузке (32 стандартных входа и 2 терминальных резистора) и не более 6 В без нагрузки. На стороне приемника минимальный уровень принимаемого сигнала должен быть не менее 200 мВ. Аппаратная реализация RS-422 — полнодуплексный интерфейс. Прием и передача идут по двум отдельным парам проводов. На каждой паре проводов может быть только по одному передатчику. Реализован в микросхемах MAX488, MAX490. .

Расстояние и скорость передачи данных

Согласование Электрический сигнал отражается от открытых концов линии передачи. Если расстояние достаточно большое, фронт сигнала, отразившийся в конце линии и вернувшийся обратно, может исказить текущий или следующий сигнал. В таких случаях нужно каким-то образом подавлять эффект отражения. На удаленном конце линии, между проводниками витой пары включають резистор с номиналом равным волновому сопротивлению линии. Электромагнитная волна дошедшая до «тупика» поглощается на резисторе. Отсюда его названия — согласующий резистор или «терминатор». Номинальное сопротивление согласующего резистора соответствует волновому сопротивлению кабеля и обычно составляет 120 Ом. Резистор может быть запаян на контакты кабельных разъемов у конечных устройств. Иногда резисторы бывают смонтированы в самом устройстве и для подключения резистора нужно установить перемычку (как в нашей продукции VTR-232/485, VTR-E/485, USB-485M).

Защитное смещение При отсоединении приемника от линии, либо при отсутствии в линии активных передатчиков, уровень электрического сигнала на проводах A и B может быть произвольным. Чтобы избежать выдачи ошибочных сигналов на приемник UART, необходимо установить подтяжку входа А к питанию, а B — к «земле». В выпускаемой нами продукции (VTR-232/485, VTR-E/485, USB-485M . ) установлены резисторы защитного смещения номиналом 680 Ом. Исключение приема при передаче RS-485 При работе RS-485 на передачу, выход приемника RO переводится в третье состояние и ножка RX контроллера (приемник UART) «повисает в воздухе». В результате, во время передачи на приемнике UART любая помеха будет принята за входной сигнал. Для исключения этой ситуации необходимо выход приемника RO подтягивать к логической 1. В выпускаемой нами продукции (VTR-232/485, VTR-E/485, USB-485M . ) установлен резистор подтяжки выхода приемника номиналом 10 кОм.

Отключение передатчика при включении оборудования При включении питания или перезагрузке оборудования по сигналу «Reset», контроллеру требуется несколько милисекунд на инициализацию. Получается ситуация, при которой питание на микросхему приемопередатчика RS-485/422 уже подано, но входы разрешения приемника /RE и передатчика DE «висят в воздухе». В результате, приемопередатчик может по помехе открыться на передачу и все время пока микроконтроллер иницализируется передавать в работающую линию мусор. Для исключения этого необходимо резистором подтянуть включение передатчика к “земле”. Таким образом, сразу при включении питания передатчик включен на прием и не сорит в линию. В выпускаемой нами продукции (VTR-232/485, VTR-E/485, USB-485M . ) установлен резистор подтяжки включения передатчика номиналом 10 кОм.

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

Допустимое число Tx и Rx

Программное управление потоком — Software flow control

Программное управление потоком — это метод управления потоком, используемый в компьютер каналы передачи данных, особенно последовательный порт RS-232. Он использует специальные коды, передаваемые внутри полосы по основному каналу связи. Эти коды обычно называются XOFF и XON (от «передача выключена» и «передача включена» соответственно). Таким образом, «программное управление потоком» иногда называют «управление потоком XON / XOFF». Это отличается от управления потоком через выделенные внеполосные сигналы — «аппаратное управление потоком » — например, RS-232 RTS / CTS.

  • 1 Представление
  • 2 Механизм
  • 3 Сравнение с аппаратным управлением потоком
  • 4 Приложения
  • 5 См. Также
  • 6 Ссылки

Представление

Для систем, использующих Код символа ASCII, XOFF обычно представляется с помощью символа или байта с десятичным значением 19; XON со значением 17.

Стандарт ASCII не резервирует никаких управляющих символов специально для использования в качестве XON / XOFF. Однако он предоставляет четыре общих символа «управления устройством» (от DC1 до DC4). Телетайп модели 33 ASR принял два из них, DC3 и DC1, для использования в качестве XOFF и XON соответственно. Это использование было скопировано другими и теперь является стандартом де-факто. Клавиатурные эквиваленты Ctrl + S для XOFF и Ctrl + Q для XON также являются производными от этого использования.

Представления XOFF / XON в ASCII

Код Значение ASCII Dec Hex Keyboard
XOFF Приостановить передачу DC3 19 13 Ctrl + S
XON Возобновить передачу DC1 17 11 Ctrl + Q

Механизм

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

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

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

Сравнение с аппаратным управлением потоком данных

Основным преимуществом программного управления потоком данных является уменьшение количества электрических проводов между отправителем и получателем. При общем заземлении необходимы только два сигнала: один для отправки, а другой для приема. Аппаратное управление потоком требует дополнительных проводов между двумя устройствами. Это также требует специальной аппаратной реализации, которая в ранние дни вычислительной техники (то есть в 1960-е и 70-е годы) требовала более значительных затрат.

Однако программное управление потоком данных не без проблем. Для отправки XOFF требуется как минимум один символ времени для передачи, и он может быть поставлен в очередь после уже переданных данных, все еще находящихся в буферах. Аппаратные сигналы могут быть заявлены почти мгновенно и не по порядку.

Как следует из названия «программное управление потоком данных», управление потоком с использованием этого метода обычно реализуется в программном обеспечении (или, по крайней мере, на более высоком уровне прошивки ), что может вызвать дополнительные задержки в XOFF ответ. Аппаратное управление потоком обычно находится под прямым управлением передающего UART, который может немедленно прекратить передачу без вмешательства более высоких уровней.

Наконец, поскольку коды XOFF / XON отправляются внутри полосы, они не могут появляться в передаваемых данных, не будучи ошибочно принятыми за команды управления потоком. Таким образом, любые данные, содержащие коды XOFF / XON, должны быть каким-то образом закодированы для правильной передачи с соответствующими накладными расходами. Часто это делается с помощью какой-то escape-последовательности . Для печатающих устройств, которые напрямую интерпретируют коды ASCII, это не представляет большой проблемы, поскольку коды XON и XOFF используют кодовые числа ASCII «управление устройством».

Приложения

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

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

Эмулятор терминала ПО обычно реализует поддержку XOFF / XON как базовую функцию. Это обычно включает в себя системную консоль на современных машинах Unix и Linux, а также эмуляторы GUI, такие как xterm и консоль Win32.

Надежный XON — это метод перезапуска связи на случай, если он был остановлен случайно полученным XOFF. Приемный блок периодически отправляет символы XON, когда он может принимать данные, а линия свободна. Один из распространенных способов использования — последовательные принтеры (например, HP LaserJet II), чтобы указать, что они подключены к сети и готовы принимать данные. XON отправляется каждые 1–30 секунд в зависимости от прошивки принтера.

См. Также

Ссылки

  • «Принтеры HP LaserJet IIP и IIP Plus — Клавиши и меню панели управления». Hewlett-Packard. Архивировано из оригинала 9 мая 2006 г.

Управление потоком 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 ??

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *