Работа с COM и LPT в Win32.

Познакомимся с параметрами функции CommConfigDialog:

lpszName

Указатель на строку с именем порта для которого отображается диалоговое окно. К реальному имени порта эта строка не имеет никакого отношения, она просто выводится в заголовке окна.

hWnd

Описатель окна, которое владеет данным диалоговым окном. Должен быть передан корректный описатель окна-владельца или NULL, если у диалогового окна нет владельца.

lpCC

Указатель на структуру COMMCONFIG. Эта структура содержит начальные установки используемые для отображения в диалоговом окне, и установленные пользователем изменения, при завершении диалога.

Как и большинство других функций Win32 API, функция CommConfigDialog возвращает отличное от нуля значение, в случае успешного завершения, и нуль, если возникла ошибочная ситуация.

Функция CommConfigDialog не выполняет настройки порта. Она все лишь позволяет пользователю изменить некоторые поля в блоке DCB, содержащемся в структуре COMMCONFIG. Разумеется, Вы можете изменить установленые пользователем некорректные значения или выполнить дополнительные настройки после вызова функции GetCommConfig. Фактическая настройка порта выполняется функцией SetCommConfig:

BOOL SetCommConfig(HANDLE hCommDev, LPCOMMCONFIG lpCC, DWORD dwSize);

Параметры имеют тоже самое значение, как и в функции GetCommConfig. Следует заметить, что описаные три функции позволяют настраивать и некоторые параметры модема, если он подключен к порту и опознан системой. Впрочем, эта возможность может отсутствовать, если она не предусмотрена производителем оборудования.

Обратите внимание на кнопку "Restore Defaults". Вы в состоянии управлять ее поведением, правда опосредовано, с помощью функций GetDefaultCommConfig и SetDegaultCommConfig. Вот их прототипы:

BOOL GetDefaultCommConfig(LPCSTR lpszName, LPCOMMCONFIG lpCC, LPDWORD lpdwSize);

BOOL SetDefaultCommConfig(LPCSTR lpszName, LPCOMMCONFIG lpCC, DWORD dwSize);

Эти функции очень похожи на GetCommConfig и SetCommConfig, но предназначены совсем для другой цели. Предположим, что Ваше устройство, по умолчанию, работает на скорости 175 бит в секунду и обменивается пятибитными символами. Системные же умолчания – 9600 бит в секунду и 8 бит в символе. Что бы пользователь, при нажатии на кнопку "Restore Defaults", получал не системные, а Ваши умолчания, воспользуйтесь функциями GetDefaultCommConfig и SetDefaultCommConfig. SetDefaultCommConfig не настраивает порт, это выполняется функцией SetCommConfig, а изменяет параметры во внутренней области коммуникационного драйвера.

Теперь познакомимся с функцией SetupComm, которая, на самом деле, совсем не то, что следует из названия.

BOOL SetupComm(HANDLE hFile, DWORD dwInQueue, DWORD dwOutQueue);

Эту функцию скорее следовало назвать SetCommQueueSize, поскольку все, что она делает, это устанавливает размеры (в байтах) очередей приема и передачи. Причем размеры рекомендуемые. В общем случае, система сама в состоянии определить требуемый размер очередей, однако Вы можете вмешаться в этот процесс. Внутренние очереди драйвера позволяют избежать потери данных, если Ваша программа не успевает их считывать, и пауз в работе программы, если она передает данные слишком быстро. Размер очереди выбирается немного большим максимальной длины сообщения. Например, для протокола YMODEM, пакет данных которого имеет длину 1024 байт, разумным размером очереди будет 1200 байт.

Указаный Вами размер очереди будет принят драйвером к сведению. Но он оставляет за собой право внести коррективы или вообще отвергнуть устанавливаемое значение. В последнем случае функция завершится с ошибкой.

Внешние устройства управления объектами, чаще всего подключаемые к портам, обычно обмениваются с компьютером короткими сообщениями. Соответственно и вызов функции SetupComm не требуется. Однако, если Ваше устройство передает или принимает блоки данных длиной в несколько тысяч байт, рекомендуется установить размеры очередей драйвера.

Давайте сделаем паузу в изучении функций настройки и получения состояния коммуникационных портов. Пора от слов переходить к делу, а именно к приему и передаче данных. Начнем с синхронного чтения/записи, это проще.

Прием и передача данных выполняется функциями ReadFile и WriteFile, то есть теми же самыми, которые используются для работы с дисковыми файлами. Вот как выглядят прототипы этих функций:

BOOL ReadFile(HANDLE hFile, LPVOID lpBuffer, DWORD nNumOfBytesToRead, LPDWORD lpNumOfBytesRead, LPOVERLAPPED lpOverlapped);

BOOL WriteFile(HANDLE hFile, LPVOID lpBuffer, DWORD nNumOfBytesToWrite, LPDWORD lpNumOfBytesWritten, LPOVERLAPPED lpOverlapped);

Вы наверняка работали с этими функциями и знаете значение их параметров. Но я все таки кратко остановлюсь на их описании:

hFile

Описатель открытого файла коммуникационного порта.

lpBuffer

Адрес буфера. Для операции записи данные из этого буфера будут передаваться в порт. Для операции чтения в этот буфер будут помещаться принятые из линии данные.

nNumOfBytesToRead, nNumOfBytesToWrite

Число ожидаемых к приему или предназначеных к передаче байт.

nNumOfBytesRead, nNumOfBytesWritten

Число фактически принятых или переданых байт. Если принято или передано меньше данных, чем запрошено, то для дискового файла это свидетельствует об ошибке, а для коммуникационного порта совсем не обязательно. Причина в тайм-аутах.

lpOverlapped

Адрес структуры OVERLAPPED, используемой для асинхронных операций. Подробнее как с структурой, так и с асинхронными операциями мы познакомимся позже. Для синхронных операций данный параметр должен быть равным NULL.

Еще раз коснусь темы тайм-аутов. Если Вы не используете ни общий, ни межбайтный тайм-ауты для операции чтения и внешнее устройство прекратило передачу, то Ваша программа будет вечно ждать завершения синхронной операции. Другими словами она зависнет. Аналогичный результат может быть при использовании программного или аппаратного управления потоком. Если же тайм-ауты используются, то операция чтения нормально завершится. Только количество считанных байт будет меньше количества запрошеных для чтения. Это не обязательно свидетельствует об ошибке. Например программа может по тайм-ауту определять конец очередного блока данных. Аналогично и для операции записи, с той лишь разницей, что неполная передача данных из буфера, скорее всего, будет свидетельствовать о проблеме во внешнем устройстве. То есть будет считаться ошибкой.

Коммуникационный порт не совсем обычный файл. Например, для него нельзя выполнить операцию позиционирования файлового указателя. С другой стороны, порт позволяет управлять потоком, что нельзя делать с обычным файлом. Настало время познакомиться с функциями управления приемом/передачей данных через коммуникационные порты. Поскольку первой операцией, после открытия порта, является его сброс, то и начнем с функции выполняющей требуемые действия.

BOOL PurgeComm(HANDLE hFile, DWORD dwFlags);

Вызов этой функции позволяет решить две задачи: очистить очереди приема/передачи в драйвере и завершить все находящиеся в ожидании запросы ввода/вывода. Какие именно действия выполнять задается вторым параметром (значения можно комбинировать с помощью побитовой операции OR):

PURGE_TXABORT	Немедленно прекращает все операции записи, даже если они не завершены
PURGE_RXABORT	Немедленно прекращает все операции чтения, даже если они не завершены
PURGE_TXCLEAR	Очищает очередь передачи в драйвере
PURGE_RXCLEAR	Очищает очередь приема в драйвере

Вызов этой функции нужен для отбрасывания мусора, который может находиться в приемном буфере на момент запуска программы, или как результат ошибки в работе устройства. Очистка буфера передачи и завершение операций ввода/вывода так же потребуются при ошибке, как процедура восстановления, и при завершении программы, для красивого выхода.

Следует помнить, что очистка буфера передачи, как и экстреное завершение операции записи, не выполняют передачу данных находящихся в этом буфере. Данные просто отбрасываются. Если же передача остатка данных необходима, то перед вызовом PurgeComm следует вызвать функцию:

BOOL FlushFileBuffers(HANDLE hFile);

Приведу пример выполнения настройки порта и выполнения чтения/записи данных.

#include <windows.h>

#include <string.h>

. . .

DCB dcb;

COMMTIMEOUTS ct;

HANDLE port;

DWORD bc;

char *buf_out="Test string";

char *buf_in;

. . .

dcb.DCBlength = sizeof(DCB);

BuildCommDCB("baud=9600 parity=N data=8 stop=1",&dcb);

dcb.fNull = TRUE;

ct.ReadIntervalTimeout = 10;

ct.ReadTotalTimeoutMultiplier = ct.ReadTotalTimeoutConstant = 0;

ct.WriteTotalTimeoutMultiplier = ct.WriteTotalTimeoutConstant = 0;

port = CreateFile("COM2", GENERIC_READ|GENERIC_WRITE, 0 ,NULL, OPEN_EXISTING, 0, NULL);

SetCommState(port, dcb);

SetCommTimeouts(port, &ct);

PurgeComm(port, PURGE_TXCLEAR|PURGE_RXCLEAR);

SetupComm(port, 256, 256);

. . .

buf_in = (char*)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, strlen(buf_out)+1);

WriteFile(port, buf_out, strlen(buf_out), &bc, NULL);

ReadFile(port, buf_in, strlen(buf_out), &bc, NULL);

HeapFree(GetProcessHeap(), 0, buf_in);

CloseHandle(port);

. . .

Если на COM2 установить перемычку между сигналами TxD и RxD, то переменная buf_in, после выполнения ReadFile, будет содержать ту же информацию, что и buf_out. Других пояснений пример не требует, все уже было подробно рассмотрено раньше.

Иногда требуется срочно передать символ, имеющий определенное специальное значение, а в очереди передатчика уже есть данные, которые нельзя терять. В этом случае можно воспользоваться функцией:

BOOL TransmitCommChar(HANDLE hFile, char cChar);

Данная функция передает один (и только один) внеочередной байт в линию, не смотря на наличие данных в очереди передатчика, и перед этими данными. Однако управление потоком действует. Функцию можно вызвать только синхронно. Более того, если байт экстренных данных, от предыдущего вызова этой функции, еще не передан в линию (например из-за функций управления потоком), то попытка экстренной передачи еще одного байта завершится ошибкой. Если Вы используете программное управление потоком, то символы приостановки и возобновления передачи (обычно CTRL-S и CTRL-Q), лучше всего передавать именно этой функцией.

Последовательный канал передачи данных можно перевести в специальное состояние, называемое разрывом связи. При этом передача данных прекращается, а выходная линия переводится в состояние "0". Приемник, обнаружив, что за время необходимое для передачи стартового бита, битов данных, бита четности и стоповых битов, приемная линия ни разу не перешла в состояние "1", так же фиксирует у себя состояние разрыва.

BOOL SetCommBreak(HANDLE hFile);

BOOL ClearCommBreak(HANDLE hFile);

Следует заметить, что состояние разрыва линии устанавливается аппаратно. Поэтому нет другого способа возобновить прерваную, с помощью SetCommBreak, передачу данных, кроме вызова ClearCommBreak.

Более тонкое управление потоком данным позволяет осуществить функция:

BOOL EscapeCommFunction(HANDLE hFile, DWORD dwFunc);

Выполняемое действие определяется вторым параметром, который может принимать одно из следующих значений:

CLRDTR	Сбрасывает сигнал DTR
CLRRTS	Сбрасывает сигнал RTS
SETDTR	Устанавливет сигнал DTR
SETRTS	Устанавливает сигнал RTS
SETXOFF	Симулирует прием символа XOFF
SETXON	Симулирует прием символа XON
SETBREAK	Переводит выходную линию передатчика в состояние разрыва. SetCommBreak является упрощенной формой данного вызова.
CLRBREAK	Снимает состояние разрыва для выходной линии передатчика. ClearCommBreak является упрощенной формой данного вызова.

Приостановить прием/передачу данных может и возникновение любой ошибки при установленом в TRUE поле fAbortOnError в структуре DCB использованой для настройки режимов работы коммуникационного порта. В этом случае, для восстановления нормальной работы порта, следует использовать функцию:

BOOL ClearCommError(HANDLE hFile, LPDWORD lpErrors, LPCOMSTAT lpStat);

Эта функция не только сбрасывает признак ошибки для соответсвующего порта, но и возвращает более подробную информацию об ошибке. Кроме того, возможно получение информации о текущем состоянии порта. Вот что означают параметры:

hFile

Описатель открытого файла коммуникационного порта.

lpErrors

Адрес переменной, в которую заносится информация об ошибке. В этой переменной могут быть установлены один или несколько из следующих бит:

CE_BREAK	Обнаружено состояние разрыва связи
CE_DNS Только для Windows95.	Параллельное устройство не выбрано.
CE_FRAME	Ошибка обрамления.
CE_IOE	Ошибка ввода-вывода при работе с портом
CE_MODE	Запрошеный режим не поддерживается, или неверный описатель hFile. Если данный бит установлен, то значение остальных бит не имеет значение
CE_OOP	Только для Windows95. Для параллельного порта установлен сигнал "нет бумаги".
CE_OVERRUN	Ошибка перебега (переполнение аппаратного буфера), следующий символ потерян
CE_PTO	Только для Windows95. Тайм-аут на параллельном порту
CE_RXOVER	Переполнение приемного буфера или принят символ после символа конца файла (EOF)
CE_RXPARITY	Ошибка четности
CE_TXFULL	Переполнение буфера передачи

lpStat

Адрес структуры COMMSTAT. Должен быть указан, или адрес выделенного блока памяти, или NULL, если не требуется получать информацию о состоянии.

Если с информацией об ошибке все ясно, то со структурой COMMSTAT мы еще не встречались. Вот она:

typedef struct _COMSTAT

 DWORD fCtsHold:1;

 DWORD fDsrHold:1;

 DWORD fRlsdHold:1;