Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
А4_Методичка.doc
Скачиваний:
0
Добавлен:
01.04.2025
Размер:
3.79 Mб
Скачать

2.1.2 Системи керування потоком

Для керування потоком даних (Flow Control) може використовуватися один з варіантів протоколу: апаратний, програмний. Іноді керування потоком плутають з квітіруванням, але це різні методи досягнення однієї мети - узгодження темпу передачі і прийому. Квітірування (Handshaking) - це посилка повідомлення про отримання (квитанції) даних, в той час як керування потоком передбачає посилку повідомлення про неможливість подальшого отримання даних.

Апаратний протокол керування потоком RTS / CTS (Hardware Flow Control) використовує сигнал CTS, який дозволяє зупинити передачу даних, якщо приймач не готовий до їх прийому, рис. 2.2. Передавач "випускає" черговий байт тільки при включеному стані лінії CTS. Байт, який вже почав передаватися, затримати сигналом CTS неможливо (це гарантує цілісність посилки). Апаратний протокол забезпечує найшвидшу реакцію на стан приймача. Зазвичай мікросхеми асинхронних прийомопередавачів мають не менше двох регістрів в приймальній частині - зсувний для прийому чергової посилки і збереження, з якого прийнятий байт зчитується. Це дозволяє реалізувати обмін з апаратним протоколом без втрати даних, не вдаючись до програмної буферизації.

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

Апаратний протокол зручно використовувати при підключенні принтерів і плоттерів, і підтримують цей режим (рис. 2.3). При безпосередньому (без модемів) з'єднанні двох комп'ютерів апаратний протокол вимагає перехресного з'єднання ліній RTS - CTS.

Якщо апаратний протокол не використовується, то при безпосередньому з'єднанні у передавального терміналу має бути забезпечено стан "включено" на лінії CTS (зазвичай з'єднання власних ліній RTS-CTS). В іншому випадку передавач буде наполегливо мовчати (хоча є програмний спосіб його "розговорити", але ним користуються рідко).

Рис. 2.3. Кабель підключення принтера з протоколом RTS-CTS

Програмний протокол керування потоком XON / XOFF припускає наявність двонаправленого каналу передачі даних. Працює він у такий спосіб: якщо пристрій, що приймає дані, виявляє причини, по яких воно не може їх далі приймати, воно по зворотному послідовному каналу посилає байт-символ XOFF (13h). Протилежний пристрій, прийнявши цей символ, призупиняє передачу. Далі, коли приймаючий пристрій знову стає готовим до прийому даних, воно посилає символ XON (11h), прийнявши який протилежне пристрій відновлює передачу. Час реакції передавача на зміну стану приймача в порівнянні з апаратним протоколом збільшується принаймні на час передачі символу (XON / XOFF) плюс час реакції програми передавача на прийом символу (рис. 2. 4). З цього випливає, що дані без втрат можуть прийматися лише приймачем, що має додатковий буфер прийнятих даних і завчасно сигналізує про неготовність (маючи в буфері вільне місце).

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

Перевага програмного протоколу при безпосередньому з'єднанні пристроїв полягає у відсутності необхідності передачі керуючих сигналів інтерфейсу - мінімальний кабель для двостороннього обміну може мати тільки три дроти (мінімальний нуль-модемний кабель). Недоліком, крім вимоги наявності буфера і більшого часу реакції (знижує і загальну продуктивність каналу через очікування проходження сигналу XON), є складність реалізації повнодуплексного режиму обміну. У цьому випадку з потоку даних, що приймаються повинні виділятися (і оброблятися) символи керування потоком, що обмежує набір переданих символів. Мінімальний варіант кабелю для підключення принтера / плоттера з протоколом XON / XOFF наведено на рис. 2.5.

Рис. 2.5. Кабель підключення принтера з протоколом XON / XOFF

Крім цих двох поширених стандартних протоколів, що підтримуються і пристроями, і ОС, існують і інші. Наприклад, деякі пристрої з послідовним інтерфейсом використовують програмне керування, але використовують не стандартні символи XON / XOFF, а слова (ASCII-рядка). Такий обмін на рівні системної підтримки протоколу практично не підтримується (ці пристрої розраховані на прямий діалог з прикладним ПЗ). Кабель для підключення такого пристрою з наведений на рис. 2.5.