93. Ініціалізація послідовного порта. Передача і прийом даних

При ініціалізації порту комунікації (''відкритті ") встановлюються всі його параметри. Це параметри довжини слова, числа стоп-бітів, установки парності і швидкості обміну. ​​Довжина слова це число бітів, яке утворює основну одиницю даних. Якщо ми працюємо зі звичними порціями по 8 бітів, то 7 бітів достатні для стандартних файлів АБСП (в ​​яких всі символи латинського алфавіту мають коди, що не перевищують АБСН 128), в той час як для передачі чисельних даних досить порцій по 4 біта.

Незалежно від того, чи займаємося ми введенням або виведенням, як мінімум 4 регістра повинні бути ініціалізований для операцій обміну. Це регістри дільника швидкості обміну, реєстр контролю лінії і регістр дозволу переривання.

Ініціалізація швидкості обміну. Дільник швидкості обміну це число, на яке треба розділити чісло115200, щоб отримати бажану швидкість обміну. Чим більше дільник, тим менше швидкість обміну. Швидкості обміну 300 і менше потребують двухбайтного числа для дільника. Старший байт посилається в ЗР9Ь (або 2Р9Ь), а молодший у ЗР8Ь (2Р81т). В обох випадках біт 7 регістра керування лінії повинен бути встановлений в 1 перед засиланням значень, інакше за цими двома адресами значення будуть адресовані в інші регістри.

Регістри швидкості обміну слід встановлювати першими, так як вони єдині, які вимагають, щоб був встановлений біт 7 у регістрі контролю лінії. Після цього треба змінити вміст регістру контролю лінії, скидаючи 7-й біт, щоб всі інші доступи до регістрів були правильними. Оскільки регістр контролю лінії є регістром тільки для запису, то немає способу повернути біт 7 назад в 1 без одночасної установки всіх інших бітів цього регістра.

Ініціалізація регістра контролю лінії. Значення бітів регістра контролю лінії, адреса порту якого дорівнює ЗРВІ (або 2РВЬ) наведено раніше в п. 3.1.1. При ініціалізації регістра контролю лінії біти 5-7 зазвичай встановлюються в 0, Решта описують значення, визначені протоколом обміну.

Ініціалізація регістра дозволу переривання, Навіть якщо Ви не використовуєте переривання, все одно необхідно провести запис в регістр дозволу переривання, щоб бути впевненим, що переривання заборонені. Просто помістіть в цей регістр 0. Регістр ідентифікації переривання в цьому випадку можна ігнорувати.

Ініціалізація регістрів управління модемом. Ініціалізація інших регістрів пов'язана з модемами. Ясно, що модеми потрібні тільки для зв'язку з віддаленими пристроями, а не для управління прилеглими пристроями, наприклад, такими як послідовний принтер. У п.3.1.1 розглянуто призначення бітів регістра керування модему.

Передача і прийом даних

Передача даних простіше чим прийом, оскільки програма має повний контроль над складом даних і швидкістю, з якою вони повинні надсилатися. Проте процедури передачі можуть бути досить складними, якщо вони обробляють дані в міру того, як вони посилаються. Можуть бути також проблеми з синхронізацією при використанні протоколу ХОИ / Хорген. Щоб прийняти ці сигнали, програма повинна безперервно аналізувати прийняті символи при передачі (в дуплексному режимі, в якому зазвичай працюють модеми, сигнали одночасно йдуть в обидві сторони по телефонному каналу).

Щоб виявити, що віддалена станція посилає рядок нулів в якості сигналу перерви, необхідно безперервно аналізувати статус біта перерви (номер 4) регістра статусу лінії.

Тому незалежні процедури передачі даних в якійсь мірі є штучними. Але їх зазвичай розробляють спільно з процедурами отримання даних для створення загального обміну даними. Ясно, що для створення працездатної процедури необхідно затратити великих зусиль, особливо в частині виявлення та виправлення помилок при передачі даних.

Коли байт даних поміщається в регістр зберігання передавача, він автоматично виводиться в послідовний канал через регістр зсуву передавача. Немає необхідності в імпульсі біта строба, як це робиться у випадку паралельного адаптера. Біт 5 регістра статусу лінії показує чи вільний регістр зберігання передавача для отримання даних. Регістр постійно перевіряється до тих пір, поки біт 5 не стане рівним 1. Після цього в регістр зберігання передавача надсилається черговий байт. В процесі передачі біт 5 дорівнює 0 і тільки коли він знову стане рівним 1, то в регістр зберігання передавача може бути посланий наступний символ. Цей процес повторюється до тих пір, поки виконується передача даних.

Отримання даних. Комунікаційна програма готова приймати дані як тільки инициализирован комунікаційний порт і встановлено зв'язок з віддаленою станцією. Отримання даних ніколи повністю не відділений від передачі даних, оскільки програмі може знадобитися послати сигнал XOFF (ASCII 19), щоб зупинити потік даних, якщо вони надходять надто швидко і вона не встигає їх обробляти. Код XON (ASCII 17) повідомляє віддаленої станції, що можна продовжити передачу.

Залежно від складності використовуваного протоколу обміну прийняті дані можуть вимагати простої або складної обробки. Може бути отримано один з набору керуючих кодів. Ті з них, які є обмежувачами даних частіше виявляються при синхронному обміні. При виведенні одержуваних символів на екран слід враховувати вплив символів переведення рядка (ASCII 10), оскільки деякі мови автоматично вставляють переклад рядка після повернення каретки, в цьому випадку необхідно виключити символи перекладу рядка з прийнятих даних, щоб уникнути порожніх рядків при виведенні.

94. СОМ-порт

СОМ-порт і РпР

Сучасні периферійні пристрої, що підключаються до СОМ-порту - миша, модеми та інші, - можуть підтримувати специфікацію РпР. Основне завдання операційної системи РпР полягає в ідентифікації підключеного пристрою, для чого розроблений нескладний протокол, реалізований на будь-яких COM-портах чисто програмним способом. Він складається з наступної послідовності кроків, показаних на рис. 3.2.

1. Порт ініціалізується зі станом ліній DTR = ON, RTS = OFF, TXD = Mark - стан спокою (Idle).

2. Деякий час (0,2 с) очікується поява сигналу DSR, яке вказало б на наявність пристрою, підключеного до порту. У простому випадку пристрій має на своєму роз'ємі перемичку DTR-DSR, яка і забезпечує зазначений відповідь. Якщо пристрій виявлено, виконуються маніпуляції управляючими сигналами DTR і RTS з метою отримання інформації від пристрою. Якщо відповідь від пристрою не отримано, операційна система, що підтримує динамічне реконфигурирование, повинна періодично опитувати стан порту для виявлення нових пристроїв.

3. Порт програмується на режим 1200 біт / с, 7 біт даних, без паритету, 1 стоп-біт, і на 0,2 с знімається сигнал DTR. Після цього встановлюється DTR = 1, а ще через 0,2 с встановлюється і RTS-1.

4. Протягом 0,2 с очікується прихід першого символу від пристрою. По приходу цього символу починається прийом ідентифікатора (див. нижче). Якщо за цей час символ не прийшов (цей випадок і зображений на рис. 3.2), виконується друга спроба опитування (див. крок 5), дещо різниться від першої.

5. На 0,2 с знімаються обидва сигналу (DTR = 0 і RTS = 0), після чого вони обидва встановлюються (DTR = 1 і RTS = 1).

6. Протягом 0,2 с очікується прихід першого символу від пристрою, по приходу цього символу починається прийом ідентифікатора (див. нижче). Якщо за цей час символ не прийшов, то 'в залежності від стану сигналу DSR переходять до перевірки відключення Verify Disconnect (при DSR = 0) або в чергове стан Connect Idle (при DSR = 1), як показано на рис. 3.2.

7. У черговому стані Connect Idle встановлюється DTR = 1, RTS = 0, порт програмується на режим 300 біт / с, 7 біт даних, без паритету, 1 стоп-біт. Якщо в цьому стані виявиться DSR ~ 0, операційну систему слід повідомити про відключення пристрою.

Посимвольної прийом ідентифікатора пристрою має обмеження по тайм-ауту в 0,2 с на прийом кожного символу, а також загальне обмеження в 2,2 с, що дозволяє прийняти рядок довжиною до 256 символів. Рядок ідентифікатора РпР повинна мати маркери початку (28h чи 08h) і кінця (29h чи 09h), між якими розташовується тіло ідентифікатора встандартізованном форматі. Перед маркером початку може перебувати до 16 символів, що не відносяться до ідентифікатора РпР. Якщо за перші 0,2 с очікування символу (на кроці 4 або 6) маркер початку не прийшов, або ж спрацював тайм-аут, а маркер кінця не отримано, або ж який-небудь символ прийнятий з помилкою, то відбувається перехід у стан Connect Idle. Якщо отримана коректна рядок ідентифікатора, то вона передається операційній системі для аналізу і зроблена подальших дій по програмі РпР.

Для перевірки відключення (Verify Disconnect) встановлюється DTR-1, RTS = 0 і через 5 с перевіряється стан сигналу DSR. При DSR-1 відбувається перехід у стан Connect Idle (див. крок 7), при DSR == 0 відбувається перехід у стан Disconnect Idle, в якому система може періодично опитувати сигнал DSR для виявлення підключення пристрою.