Передача даних

Передача даних простіша, ніж їх прийом, оскільки програма повністю контролює склад даних і швидкість, з якою вони повинні посилатися. Проте процедури передачі можуть бути досить складними, якщо вони обробляють дані по мірі того, як вони посилаються. Можуть бути також проблеми з синхронізацією при використанні протоколу XON/XOFF. Цей протокол використовує коди ASCII 17(XON) і 19(XOFF), для того щоб сигналізувати приймаючій станції, що передавач хоче продовжити передачу тимчасово перерваного потоку даних. Щоб прийняти ці сигнали, програма повинна безперервно аналізувати символи, що приймаються при передачі (у повнодуплексном режимі, в якому зазвичай працюють модеми, сигнали одночасно йдуть в обидві сторони по телефонному каналу). Крім того, щоб виявити, що віддалена станція посилає рядок нулів як сигнал перерви, повинен безперервно аналізуватися статус біта перерви (номер 4) регістра статусу лінії [4].

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

Середній рівень

Функція 1 переривання 14Н BIOS посилає символ, що знаходиться в AL, в комунікаційний канал. При вході DX містить номер порту (0 або 1). При поверненні AH отримує байт статусу, в якому біт 7 = 1, якщо операція неуспішна. У цьому випадку мають значення наступні біти:

біт 4 виявлений перерва (сигнал " стоп" від приймаючої станції)

5 регістр зсуву передавача пустий

6 регістр зберігання передавача пустий

MS-DOS має функцію для передачі по комунікаційному каналу символа, що вміщується в DL. Це функція номер 4 переривання 21Н, але у неї немає ніяких переваг перед функцією BIOS; вона не повертає статусної інформації і не дозволяє призначати, який з комунікаційних портів треба використати (це завжди СОМ1).

Щоб вивести рядок даних, скористайтеся функцією 40Н переривання 21Н. Це звичайна функція виводу для всіх файлів і пристроїв методом доступу дескриптора файлів. СОМ1 має визначений номер - #3. Вмістіть номер файла в BX, а число байтів, що передаються в CX. Нехай DS: DX вказують на буфер даних, що виводяться, потім викликайте функцію.

MOV AH, 40H; номер функції

MOV BX, 3; наперед визначений номер файла для СОМ 1

MOV CX, 50; виводимо 50 байт

LEA DX, BUFER; DS: DX вказують на буфер даних

INT 21Н; посилаємо дані

JC COM_ERROR; відхід на обробку помилки

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

Низький рівень

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

У наступному прикладі дані основні поняття про цю процедуру. Звичайно, вона може бути створена надзвичайно складної (зокрема, програмування зв'язку вимагає особливо ретельних процедур виявлення помилок і відновлення при збоях). У прикладі передбачається, що комунікаційний порт і модем вже ініціалізовані, як показано в [2] і [5]. Перша частина це цикл перевірки помилок і прийому символів. У [7] приведений код для процедури прийому даних.

; чекаємо, поки все буде готове для посилки символа

KETRY: MOV DX, BASADR; базова адреса

ADD DX, 5; вказуємо на регістр статусу лінії

IN AL, DX; отримуємо байт статусу

TEST AL, 00011110B; перевіряємо на помилку

JNZ ERRROUT; якщо є, то на процедуру обробки помилки

TEST AL, 00000001B; перевіряємо, чи отримані дані

JNZ RECEIVE; якщо так, то на процедуру прийому

TEST AL, 00100000B; перевіряємо готовність до передачі

JZ KETRY; якщо немає, то повертаємося назад

; передаємо символ, що приймається з клавіатури

MOV AH, 1; функція перевірки натиснення клавіші

INT 16H; переривання клавіатури BIOS

JZ KETRY; повернення, якщо не було натиснення

MOV AH, 0; функція отримання коду з клавіатури

INT 16H; тепер потрібний символ в AL

SUB DX, 5; адреса регістра зберігання передавача

OUT DX, AL; посилаємо символ

JMP SHORT KETRY; повертаємося на початок циклу