Некоторые руководства терминала вызывают подтверждение связи "управления потоком
данных". Управление потоком данных должно предотвратить слишком быстрое
поступление потока байтов, чтобы не "переполнить" терминал, компьютер, модем или
другое устройство. "Переполнение" - это когда устройство не может обрабатывать
получаемую информацию достаточно быстро и таким образом теряет байты и/или
делает другие серьезные ошибки. Управление потоком данных останавливает поток
байтов до тех пор, пока терминал (например) не будет готов к приему следующих
байтов. Управление потоком данных посылает сигнал остановки потока в
направлении, противоположному тому потоку байтов, который надо остановить.
Управление потоком данных должно быть настроено и в терминале, и в компьютере.
Имеются 2 типа управления потоком данных: аппаратное и программное (Xon/Xoff).
Аппаратное управление потоком данных использует специальный сигнальный провод, в
то время как программное управление потоком данных сигнализирует, посылкой
служебных байтов Xon или Xoff по обычному проводу данных. Для аппаратного
управления потоком данных, кабель должен быть правильно распаян.
Поток байтов данных в кабеле между 2 последовательными портами двунаправлен так
что имеются 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 ??
Вперед
Назад
Содержание
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
Виртуальные VPS серверы в РФ и ЕС
