Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Подземелье Магов
  
 

Фильтр по датам

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  17:57[Войти] | [Зарегистрироваться]

Работа с портами ввода-вывода в DELPHI. Часть V

Дмитрий Кузан
дата публикации 10-05-2001 00:00

Работа с портами ввода-вывода в DELPHI. Часть V

«Все новое ,это хорошо забытое старое»

Данная 5 часть полностью взята из статьи «Работа с коммуникационными портами (COM и LPT) в программах для Win32 в среде C++» Титова Олега.
Это было сделано для полноты цикла по теме, просто не будем заново изобретать велосипед и продолжим разговор о работе с портам, основываясь на статье Титова Олега.

Получить информацию об устройстве в виде структуры COMMPROP можно функцией GetCommProperies.

Вот ее описание в эквиваленте С
   BOOL GetCommProperties(
      HANDLE     hFile,
      LPCOMMPROP lpCommProp
    );

Следует отметить, что запросить информацию можно только об уже открытом устройстве, т.е устройстве открытом функциями CreateFile OpenFile.
Так-же для структуры lpCommProp должна быть предварительно выделена память.

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

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

typedef struct _COMM_CONFIG 
{
      DWORD dwSize;
      WORD  wVersion;
      WORD  wReserved;
      DCB   dcb;
      DWORD dwProviderSubType;
      DWORD dwProviderOffset;
      DWORD dwProviderSize;
      WCHAR wcProviderData[1];
   } COMMCONFIG, *LPCOMMCONFIG;
Основной частью этой структуры является уже знакомый нам DCB. Остальные поля содержат вспомогательную информацию, которая, для наших целей, не представляет особого интереса (однако эта информация может быть полезной для получения дополнительных данных о порте). Познакомимся поближе с полями:

dwSize
Задает размер структуры COMMCONFIG в байтах
wVersion
Задает номер версии структуры COMMCONFIG. Должен быть равным 1.
wReserved
Зарезервировано и не используется
dcb
Блок управления устройством (DCB) для порта RS-232.
dwProviderSubType
Задает тип устройства и формат устройство-зависимого блока информации. Фактически это тип порта. Конкретные значения данного поля приведены в описании структуры COMMPROP выше.
dwProviderOffset
Смещение, в байтах, до устройство-зависимого блока информации от начала структуры.
dwProviderSize
Размер, в байтах, устройство-зависимого блока информации.
wcProviderData
Устройство-зависимый блок информации. Это поле может быть любого размера или вообще отсутствовать. Поскольку структура COMMCONFIG может быть в дальшейшем расширена, для определения положения данного поля следует использовать dwProviderOffset. Если dwProviderSubType PST_RS232 или PST_PARALLELPORT, то данное поле отсутствует. Если dwProviderSubType PST_MODEM, то данное поле содержит структуру MODEMSETTINGS.

Не смотря на то, что нам нужен только DCB, приходится иметь дело со всеми полями. Заполнение данной структуры противоречивыми данными может привести к неправильной настройке порта, поэтому следует пользоваться функцией GetCommConfig:
   BOOL GetCommConfig(
      HANDLE       hCommDev,
      LPCOMMCONFIG lpCC,
      LPDWORD      lpdwSize
   );
Параметры функции следующие:
hCommDev
Описатель открытого коммуникационного порта.
lpCC
Адрес выделеного и заполненого нулями, кроме поля dwSize, блока памяти под структуру COMMCONFIG. В поле dwSize нужно занести размер структуры COMMCONFIG. После вызова функции все поля структуры будут содержать информацию о текущих параметрах порта.
lpdwSize
Адрес двойного слова, которое после воврата из функции будет содержать число фактически переданных в структуру байт.
В случае успешного завершения функция возвращает ненулевое значение.

Как всегда не обошлось без тонкостей. Структура COMMPROP имеет перемнную длину, поэтому затруднительно сразу выделить требуемый блок памяти. Как и в случае с функцией GetCommProperties, функцию GetCommConfig придется вызывать дважды:

Теперь, имея заполненую корректной информацией структуру COMMCONFIG, можно позволить пользователю выполнить настройку параметров с помощью функции CommConfigDialog:
   BOOL CommConfigDialog(
      LPTSTR       lpszName,
      HWND         hWnd,
      LPCOMMCONFIG lpCC
   );
Вызов этой функции приводит к отображению диалогового окна. Вид окна может отличаться от приведенного. Это зависит от операционной системы и динамической библиотеки, предоставленной производителем порта.

Познакомимся с параметрами функции 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
   );

Если на 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;
      DWORD fXoffHold:1;
      DWORD fXoffSent:1;
      DWORD fEof:1;
      DWORD fTxim:1;
      DWORD fReserved:25;
      DWORD cbInQue;
      DWORD cbOutQue;
   } COMSTAT, *LPCOMSTAT;

Поля структуры имеют следующее значение:

fCtsHold
Передача приостановлена из-за сброса сигнала CSR.
fDsrHold
Передача приостановлена из-за сброса сигнала DSR.
fRlsdHold
Передача приостановлена из-за ожидания сигнала RLSD (receive-line-signal-detect). Более известное название данного сигнала - DCD (обнаружение несущей).
fXoffHold
Передача приостановлена из-за приема символа XOFF.
fXoffSent
Передача приостановлена из-за передачи символа XOFF. Следующий передаваемый символ обязательно должен быть XON, поэтому передача собственно данных тоже приостанавливается
fEof
Принят символ конца файла (EOF).
fTxim
В очередь, с помощью TransmitCommChar, поставлен символ для экстреной передачи.
fReserved
Зарезервировано и не используется
cbInQue
Число символов в приемном буфере. Эти символы приняты из линии но еще не считаны функцией ReadFile.
cbOutQue
Число символов в передающем буфере. Эти символы ожидают передачи в линию. Для синхронных операций всегда 0.

Теперь Вы знаете почти все о работе с последовательными и параллельными портами в синхронном режиме. Особенности непосредственной работы с модемами я не буду рассматривать, так как существует большой набор высокоуровневых функций и протоколов, таких как TAPI, специально предназначеных для работы с модемами. Если Вас все же интересует эта тема, то почитайте описания функции GetCommModemStatus, и структур MODEMDEVCAPS и MODEMSETTINGS. В остальном работа с модемом ничем не отличается от работы с обычным портом.

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

Начнем с событий связаных с последовательными портами. Вы указываете системе осуществлять слежение за возникновением связанных с портом событий устанавливая маску с помощью функции
   BOOL SetCommMask(
      HANDLE hFile,
      DWORD  dwEvtMask
   );
Маска отслеживаемых событий задается вторым параметром. Можно указывать любую комбинацию следующих значений:
  • EV_BREAK Состояние разрыва приемной линии
  • EV_CTS Изменение состояния линии CTS
  • EV_DSR Изменение состояния линии DSR
  • EV_ERR Ошибка обрамления, перебега или четности
  • EV_RING Входящий звонок на модем (сигнал на линии RI порта)
  • EV_RLSD Изменение состояния линии RLSD (DCD)
  • EV_RXCHAR Символ принят и помещен в приемный буфер
  • EV_RXFLAG Принят символ заданый полем EvtChar структуры DCB использованой для настройки режимов работы порта
  • EV_TXEMPTY Из буфера передачи передан последний символ
Если dwEvtMask равно нулю, то отслеживание событий запрещается. Разумеется всегда можно получить текущую маску отслеживаемых событий с помощью функции
   BOOL GetCommMask(
      HANDLE  hFile,
      LPDWORD lpEvtMask
   );

Вторым параметром задается адрес переменной принимающей значение текущей установленой маски отслеживаемых событий. В дополнение к событиям, перечисленым в описании функции SetCommMask, данная функция может возвратить следующие:
  • EV_EVENT1 Устройство-зависимое событие
  • EV_EVENT2 Устройство-зависимое событие
  • EV_PERR Ошибка принтера
  • EV_RX80FULL Приемный буфер заполнен на 80 процентов
Эти дополнительные события используются внутри драйвера. Вы не должны переустанавливать состояние их отслеживания.

Когда маска отслеживаемых событий задана, Вы можете приостановить выполнение своей программы до наступления события. При этом программа не будет занимать процессор. Это выполняется вызовом функции
BOOL 
WaitCommEvent(
      HANDLE       hFile,
      LPDWORD      lpEvtMask,
      LPOVERLAPPED lpOverlapped,
   );

Замечу, что в переменной, адресуемой вторым параметром, не будут устанавливаться внутренние события драйвера (перечислены в описании функции GetCommMask). В единичное состояние установятся только те биты, которые соответствуют реально произошедшим событиям.

Адрес структуры OVERLAPPED требуется для асинхронного ожидания (возможно и такое). Однако пока будем полагать, что порт открыт для синхронных операций, следовательно этот параметр должен быть NULL. Замечу только, что при асинхронном ожидании данная функция может завершиться с ошибкой, если в процессе этого ожидания будет вызвана функция SetCommMask для переустановки маски событий. Кроме того, связанное со структурой OVERLAPPED событие (объект создаваемый функцией CreateEvent, а не событие порта) должно быть с ручным сбросом. Вообще, поведение функции с ненулевым указателем на структуру OVERLAPPED аналогично поведению функций чтения и записи.

Освобождать процессор на время ожидания хорошо, но хотелось бы параллельно с вводом/выводом делать какую-либо полезную работу. Что бы это стало возможным, необходимо в качестве параметра dwFlagsAndAttributes вместо 0 указать FILE_FLAG_OVERLAPPED. Кроме того, для функций ReadFile, WriteFile и WaitCommEvent необходимо в качестве параметра lpOverlapped указывать адрес правильно инициализированной структуры OVERLAPPED. Вот как выглядит эта структура:
   typedef struct _OVERLAPPED {
      DWORD  Internal;
      DWORD  InternalHigh;
      DWORD  Offset;
      DWORD  OffsetHigh;
      HANDLE hEvent;
   } OVERLAPPED, *LPOVERLAPPED

Подробно описывать поля этой структуры не буду, поскольку данная статья не о файловом вводе/выводе вообще, а о работе с портами. Для наших целей, за исключением WaitCommEvent, можно просто обнулить все поля этой структуры. Для WaitCommEvent поле hEvent должно содержать корректный описатель объекта "событие". Что бы все стало понятно, надо разобраться с таким обязательным атрибутом параллельной работы как синхронизация.

ВНИМАНИЕ!!! Дескриптор файла, в данном случае дескриптор файла порта, является синхронизирующим объектом ядра (согласно официальной документации Microsoft). Это означает, что его можно использовать в функциях ожидания событий наравне с дескрипторами событий. Таким образом в поле hEvent в структуре OVERLAPPED можно занести NULL и ожидать освобождения дескриптора файла, а не дескриптора события. Это действительно работает в Windows NT. Однако в Windows95/98 все совсем иначе. Обсуждение ошибок, неточностей и прочих проблем документации оставим в стороне. Просто замечу, что в Windows95/98 поле hEvent должно содержать корректный дескриптор объекта event В ЛЮБОМ СЛУЧАЕ!!! Иначе функции асинхронного ввода/вывода будут работать более чем странным образом. Кроме того, мы должны ожидать освобождения именно дескриптора этого события, а не дескриптора файла.

Синхронизация нужна для упорядочения доступа к совместно используемым объектам. Предположим, что две программы одновременно пытаются изменить значение общей переменной. Каков будет результат? Скорее всего неопределенный. Что бы этого избежать требуется разрешать доступ второй программы к переменной только после того, как с ней закончила работать первая программа.

Для синхронизации используются различные методы: семафоры, блокировки, события, критические секции и т.п. События являются простейшими синхронизирующими объектами. Они могут находиться только в двух состояниях: установленом (событие произошло или наступило) и сброшеном (собитие не произошло или не наступило). События создаются функцией CreateEvent и разрушаются функцией CloseHandle. Установить событие можно функцией SetEvent, а сбросить ResetEvent.

Фнкции записи/чтения для файла открытого для асинхронного ввода/вывода будут немедленно возвращать управление с кодом ошибки ERROR_IO_PENDING. Это означает, что асинхронная операция успешно стартовала. Если возвращается другой код ошибки, то операция не стартовала (например из-за ошибки в параметрах). Теперь Вы можете спокойно заниматься другой работой периодически проверяя, завершилась ли операция ввода/вывода. Эта проверка выполняется функцией
   BOOL GetOverlappedResult(
      HANDLE       hFile,
      LPOVERLAPPED lpOverlapped,
      LPDWORD      lpcbTransfer,
      BOOL         fWait
   );

Параметр hFile определяет дескриптор опрашиваемого файла, lpOverlapped задает адрес структуры OVERLPPED. Третий параметр задает адрес переменной, куда будет помещено количество считанных или записанных байт. Соответсвующий параметр функций ReadFile и WriteFile, хоть и ДОЛЖЕН БЫТЬ ЗАДАН НЕ НУЛЕВЫМ, не позволяет получить количество переданных байт, так как на момент возврата управления из функций чтения/записи не передано ни одного байта. Параметр fWait означает, должна ли функция GetOverlappedResult ждать завершения операции ввода/вывода. Если этот параметр равет FALSE, то функция немедленно вернет управление. При этом код возврата будет TRUE, если операция завершена, или FALSE, если операция не завершена. В послед случае код ошибки возвращаемой функцией GetLastError будет ERROR_IO_INCOMPLETE. Если функция GetOverlappedResult завершилась с кодом возврата FALSE, и другим кодом ошибки, то ошибка произошла именно при вызове самой функции. Если параметр fWait равен TRUE, то функция будет дожидаться завершения операции ввода-вывода.

Замечу, что ожидать завершения ввода/вывода с помощью функции GetOverlappedResult не самое правильное решение. При работе с дисковым файлом операция завершится гарантированно, а при работе с последовательным или параллельным портом совсем не обязательно. Представьте, что Вы не настроили тайм-ауты последовательного порта, а подключенное устройство неисправно. GetOverlappedResult будет ждать вечно, так как нет способа указать максимальное время ожидания. Ждать завершения ввода/вывода лучше с помощью функций:
   DWORD WaitForSingleObject(
      HANDLE hObject,
      DWORD  dwTimeot
   );
   
   DWORD WaitForMultipleObjects(
      DWORD    cObjects,
      LPHANDLE lpHandles,
      BOOL     bWaitAll,
      DWORD    dwTimeout
   );

Как следует из названия, эти функции предназначены для ожидания одного или нескольких объектов. Однако следует вспомнить примечание, которое я привел к описанию структуры OVERLAPPED! Поэтому не мудрствуя лукаво будем ожидать только объекты event.

Функция WaitForSingleObject ожидает только один объект задаваемый первым параметром. Вторым параметром задается максимальное время ожидания наступления события в миллисекундах. Если вместо времени указана магическая величина INFINITE, то событие будет ожидаться вечно.

Функция WaitForMultipleObjects ждет несколько событий. Первый параметр указывает сколько именно, а второй задает массив дескрипторов этих событий. Замечу, что один и тот же дескриптор нельзя указывать в этом массиве более одного раза. Третий параметр задает тип ожидания. Если он равен TRUE, то ожидается наступление всех событий. Если FALSE, то наступления любого одного из указанных. И естественно тоже можно задать максимальное время ожидания последним параметром.

Если событие наступило, то функции возвращают значения от WAIT_OBJECT_0 до WAIT_OBJECT_0+cObject-1. Естественно, что WaitForSingleObject может вернуть только WAIT_OBJECT_0 (если конечно не произошло ошибки). Если произошла ошибка, то будет возвращено WAIT_FAILED. При превышении максимального времени ожидания функции вернут WAIT_TIMEOUT.

Вернусь к объектам event, которые мы собственно и используем для ожидания. Поясню, почему для наших целей требуются события с ручным сбросом. Функции ReadFile и WriteFile в асинхронном режиме первым делом сбрасывают (переводят в занятое состояние) как дескриптор файла, так и дескриптор объекта event задананный в структуре OVERLAPPED. Когда операция чтения или записи завершается система устанавливает эти дескрипторы в свободное состояние. Тут все логично. Однако и функции WaitForSingleObject и WaitForMultipleObjects для событий с автоматическим сбросом так же выполняют их перевод в занятое состояние при вызове. Для событий с ручным сбросом этого не происходит. Теперь представьте, что операция ввода/вывода завершилась ДО вызова WaitForSingleObject. Представили? Для событий с автоматическим сбросом снова будет выполнен перевод объекта в занятое состояние. Но освобождать то его будет некому! Более подробная информация об объектах event выходит за рамки этой статьи.

Теперь небольшой пример на С. Все подробности, не относящиеся к работе в асинхронном режиме я опускаю.
   #include <windows.h>
   #include <string.h>
      
   . . .
      
   HANDLE        port;
   char*         buf;
   OVERLAPPED    ovr;
   DWORD         bc;

   . . .

   port=CreateFile("COM2",GENERIC_READ,0,NULL,OPEN_EXISTING,
                   FILE_FLAG_OVERLAPPED,NULL);
   
   memset(&ovr,0,sizeof(ovr));
   ovr.hEvent=CreateEvent(NULL,FALSE,FALSE,NULL);
   ReadFile(port,buf,buf_size,&bc,&ovr);
   
   /* Выполняем некую полезную работу */
   
   if(WaitForSingleObject(ovr.hEvent,10000)==WAIT_OBJECT_0) {
      GetOverlappedResult(port,&ovr,&bc,FALSE);
   } else {
   
      /* Обработка ошибки */
   
   }   
   CloseHandle(port);
   CloseHandle(ovr.hEvent);

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

Безусловно, можно придумать очень сложные схемы распараллеливания ввода/вывода и вычислений, базирующиеся на использовании асинхронных операций и объектов event. Позволю себе не приводить реально работающих примеров программ. Таких программ работающих в реальном масштабе времени много, но они очень сложны и громоздки для этой статьи.

Вернемся ненадолго с структуре OVERLAPPED и функциям ReadFile и WriteFile. Для дискового ввода/вывода возможно задать одновременно несколько конкурирующих операций чтения/записи. Однако для каждой такой операции необходимо использовать свою структуру OVERLAPPED. Для работы с портами нельзя задавать конкурирующие операции. Точнее можно, но только в Windows NT. Поэтому для целей совместимости лучше этого не делать.

Теперь, уже совсем кратко, еще об одной возможности, реализованной только в Windows NT. Речь идет о "тревожном вводе-выводе". Эта возможность реализуется функциями ReadFileEx, WriteFileEx и SleepEx. Суть использования данных функий такова. Вы вызываете расширенную функцию записи или чтения, которая имеет еще один параметр - адрес функции завершения. После чего, вызвав расширенную функцию засыпания, освобождаете процессор. После завершения ввода/вывода Ваша функция завершения будет вызвана системой. Причем вызвана ТОЛЬКО в том случае, если ваша программа вызвала SleepEx. Нетрудно заметить, что данный вариант работы подходит для систем с большим количеством портов и работающих в режиме ответа по требованию. Например, сервер с мультипортовым контроллером последовательного порта, к которому подключены модемы.

Теперь, но ОЧЕНЬ кратко, залезем в еще большие дебри. Предположим, что протокол обмена с Вашим устройством, подключенным к последовательному порту, очень сложен (передаются большие и сложные структуры данных). При этом Ваша программа должна получать уже полностью принятую и проверенную информацию. Предположим так же, что Ваша программа занимается очень большими и сложными вычислениями и ей нет времени отвлекаться на обработку ввода/вывода. Да и сложность ее такова, что встраивание фонового ввода/вывода сделает ее трудно прослеживаемой и неустойчивой. Чувствуете, куда я клоню? Правильно, к выделению всех тонкостей ввода/вывода в отдельный поток. Возможно выделение и в отдельную задачу, но в этом случае мы не получим никакой выгоды, а накладные расходы на переключение задач гораздо больше, нежели на переключение потоков в одной задаче.

Потоки создаются функцией CreateThread, и уничтожаются функциями ExitThread и TerminateThread. Принцип работы таков. Вы создаете поток. При этом управление получает Ваша функция потока. Она работает параллельно, как минимум, основному потоку Вашей программы. Функция открывает порт и выполняет все необходимые настройки. Затем она выполняет весь ввод/вывод, при чем совершенно не важно, используется синхронный или асинхронный режим. При засыпании потока (при синхронном режиме) остальные потоки Вашей программы продолжат выплняться. Когда завершится необходимый обмен информацией с устройством и данные будут готовы для передачи основной программе Ваш поток установит некий флаг, котрый будет воспринят основной программой как готовность данных. После их обработки и формирования блока выходной информации основной поток установит другой флаг, который будет воспринят потоком ввода-вывода как готовность данных для передачи. При этом в качестве флагов можно использовать как объекты event, так и обычные переменные (ведь все потоки задачи выполняются в едином адресном прогстранстве). В случае использования обычных глобальных переменных не забудте в их определения добавить модификатор volatile. Он обозначает, что переменная может измениться асинхронно и компилятор не должен строить иллюзий насчет возможности ее оптимизации. В противном случае у Вас ничего не получится. Так как в потоке ввода/вывода, выполняющемся параллельно основному потоку программы, можно использовать асинхронный ввод/вывод, то достаточно просто реализуется возможность обработки большого количества портов. Фактически поток ввода/вывода будет работь еще и параллельно самому себе. При запуске такой задачи на многопроцессорной машине выгода от использования многопоточности будет очевидна, поскольку потоки будут выполняться на разных процессорах.

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

Еще раз повторяюсь что данная часть полностью взята из «Работа с коммуникационными портами (COM и LPT) в программах для Win32 в среде C++» Титова Олега, дабы исключить обвинения в плагиате.

Продолжение следует…

Дмитрий Кузан
10 мая 2001г.
Специально для Королевства Delphi

Титов Олег Работа с коммуникационными портами (COM и LPT) в программах для Win32.




Смотрите также материалы по темам:
[TForm] [TQueue] [TEvent] [TThread] [Работа с портами ввода/вывода]

 Обсуждение материала [ 12-07-2002 05:28 ] 2 сообщения
  
Время на сайте: GMT минус 5 часов

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

Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

 
© При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
Все используемые на сайте торговые марки являются собственностью их производителей.

Яндекс цитирования