45812 (Ещё раз о прямом доступе к аппаратуре)
Описание файла
Документ из архива "Ещё раз о прямом доступе к аппаратуре", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "рефераты, доклады и презентации", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "45812"
Текст из документа "45812"
Ещё раз о прямом доступе к аппаратуре
Сивцов Павел
Преамбула
Однажды мой знакомый попросил написать ему простую программу — «сторожевой пёс». Всё, что нужно делать — это отловить момент размыкания или замыкания внешнего контакта и при наступлении такого события запустить другую программу. Работать программа должна под Windows XP. Задача выглядела элементарной. Единственное, что не хотелось делать — аппаратную часть. Т.е. лучше всего было бы найти такое решение, при котором почти ничего не нужно было бы паять.
Достаточно быстро выяснилось, что проще всего для такой цели использовать опрос состояний LPT- или COM-портов. Тут и начинается самое интересное.
LPT
Для реализации «сторожевого пса» на LPT-порту можно использовать периодический опрос состояния некоторых его контактов. Можно просто выявлять состояния линий SELECTED (контакт 13), BUSY (контакт 11) и PAPER EMPTY (контакт 12). Достаточно замыкать/размыкать выбранный контакт с «землей» (контакты 18–25). Я выбрал использование BUSY — замыкал контакты 11 и 23. Итак, аппаратная часть получалась элементарной, теперь нужно было как-то достучаться до выбранного контакта с программной стороны. Тут-то и встретилась первая сложность — легальных способов прямого доступа к портам в линейке Windows NT нет. Использовать примочки типа gwio.sys, разрешающие прямой доступ к аппаратуре, очень не хотелось. Работа с портом как с файлом в данном случае не подходит, т.к. нужно не данные читать, а опрашивать состояния. Тем не менее, после длительного изучения MSDN, легальный доступ к некоторым линиям порта был обнаружен! Способ этот — доступ к порту через функцию DeviceIoControl(…, IOCTL_PAR_QUERY_INFORMATION, …). Тут обнаружилась вторая сложность — отсутствие нужных заголовочных файлов для Delphi. Пришлось самостоятельно портировать ntddpar.h из DDK. Портированный файл получил название JwaNtDdPar.pas и был любезно добавлен Marcel van Brakel в JEDI Windows API Library.
Небольшой пример демонстрирует итоговый код. Delphi 7.
Пример кода
| uses SysUtils, JwaWinType, JwaWinNT, JwaWinBase, JwaNtDdPar; {$WARN SYMBOL_PLATFORM OFF} function GetLptStatus: Boolean; var eFileHandle: THandle; eInfo: TParQueryInformation; eBytesReturned: DWORD; begin // откроем порт eFileHandle := CreateFile('LPT1', GENERIC_READ, 0, nil, OPEN_EXISTING, 0, 0); Win32Check(eFileHandle <> INVALID_HANDLE_VALUE); try // узнаем состояние Win32Check(DeviceIoControl(eFileHandle, IOCTL_PAR_QUERY_INFORMATION, nil, 0, @eInfo, SizeOf(eInfo), @eBytesReturned, nil)); Result := (Byte(eInfo.Status) and PARALLEL_BUSY) = 0; finally // не забудьте закрыть хендл по завершению работы Win32Check(CloseHandle(eFileHandle)); end; end; |
Короткий и элегантный код, не правда ли? Для решения поставленной задачи достаточно опрашивать состояние порта раз-другой в секунду. В принципе, конечно же, лучше сразу открыть порт при старте, а закрыть по завершению.
| ПРЕДУПРЕЖДЕНИЕ К сожалению, не удастся открыть порт в режиме FILE_FLAG_OVERLAPPED, чтобы затем использовать преимущества асинхронной работы. Точнее, порт открыть удастся, не удастся получить событие при изменении статуса линий порта. Зато этот код успешно отработал из-под гостевой учетной записи под Windows XP. |
Последний нюанс — дребезг контактов. «Дребезг контактов — это явление многократного неконтролируемого замыкания и размыкания контактов в моменты их соприкосновения и расхождения». Длятся такие переходные процессы в кнопках около 10-15 миллисекунд. Т.е. с большой вероятностью мы будем получать ложные срабатывания нашего кода, если интервал между проверками будет короче.
Надеюсь, этот пример работы с LPT-портом послужит хорошей демонстрацией того, как во многих случаях легко получить легальный доступ к аппаратуре без написания драйверов или обхода Hardware Abstraction Layer. Не для того этот HAL придумывали, чтобы его обходить.
Доводилось читать о случаях захвата порта спулером печати, но на практике такую ситуацию встретить не удалось. Если кто-нибудь сможет прояснить этот вопрос, я буду рад.
| ПРИМЕЧАНИЕ Кстати, в середине страницы |
COM
При использовании COM-порта задача обнаружения внешнего события может быть решена ещё проще. Достаточно замыкать/размыкать контакты 7 (RTS) и 8 (CTS) у девятиконтактного разъема (опять ничего не придется паять) и проверять наличие сигнала CTS. Причем опрос можно производить через стандартный CommApi.
Пример кода
| function GetComStatus: Boolean; var eFileHandle: THandle; eStatus: DWORD; begin // откроем порт eFileHandle := CreateFile('COM1', GENERIC_READ, 0, nil, OPEN_EXISTING, 0, 0); Win32Check(eFileHandle <> INVALID_HANDLE_VALUE); try // узнаем состояние Win32Check(GetCommModemStatus(eFileHandle, eStatus)); Result := (eStatus and MS_CTS_ON) > 0; finally // не забудьте закрыть хендл по завершению работы Win32Check(CloseHandle(eFileHandle)); end; end; |
Впрочем, этот пример элегантным уже не назовешь, т.к. использование COM-порта дает возможность избавиться от периодического опроса, используя асинхронную работу через WaitCommEvent и WaitForMultipleObjects.
Ниже приведен код примера. Для пояснения сути происходящего код обильно прокомментирован. Но все-таки обращу внимание на некоторые нюансы:
WaitForMultipleObjects ждет бесконечно. Никаких периодических опросов — значит и никакого потребления ресурсов. Всё реализовано на событиях.
Нет необходимости в TerminateThread для принудительного прекращения выполнения потока. Выполнение может быть «культурно» завершено в любой момент. Для этого используется отдельное событие.
Простая реализация неблокирующей задержки для подавления дребезга. Поскольку периодический опрос мы не применяем, то, чтобы избавиться от ложных срабатываний программным путем, нужно подождать несколько десятков миллисекунд, и если состояние за это время не изменилось, то замыкание/размыкание цепи состоялось. В качестве таймера используется WaitableTimer. Обратите внимание на его теоретическую точность.
Ключевой метод
| procedure TComWatchdogThread.Execute; var // структура, используемая Win32 для хранения внутренней информации при // асинхронной работе. Ничего кроме поля hEvent нам от неё не требуется eOverlapped: TOverlapped; // запрос ожидания асинхронного события изменения состояния порта //........................................................................... procedure InitWaitCommEvent; var eEventMask: DWORD; begin // ошибки ERROR_IO_PENDING нужно просто игнорировать - их наличие означает // только то, что последняя операция с портом ещё не завершена. // Что интересно, нельзя дважды подряд вызвать WaitCommEvent, т.е. // запросил событие - значит, дождись его. if not WaitCommEvent(FComHandle, eEventMask, @eOverlapped) and (GetLastError <> ERROR_IO_PENDING) then RaiseLastOSError; end; var // TWOHandleArray - это просто готовый массив из 64 хендлов для // функции WaitForMultipleObjects. Мы используем только 3 хендла, // но для простоты воспользуемся готовым массивом на 64, чтобы // не связываться с ручным распределением памяти. eHandles: TWOHandleArray; eTime: Int64; eStatus: DWORD; eStubInstalled: Boolean; begin // заполним структуры для асинхронной работы FillChar(eOverlapped, SizeOf(eOverlapped), 0); eOverlapped.hEvent := FChangeEvent; eHandles[0] := eOverlapped.hEvent; eHandles[1] := FTerminateEvent; eHandles[2] := FFlutterTimer; // 0.5 секунды для SetWaitableTimer eTime := -5000000; // Ничего себе точность, не правда ли? // предварительно взведем флаг ожидания события, чтобы цикл заработал InitWaitCommEvent; while not Terminated do case WaitForMultipleObjects(3, @eHandles, False, INFINITE) of // при изменении состояния порта WAIT_OBJECT_0: begin // опять взведем флаг ожидания события InitWaitCommEvent; // для подавления дребезга сделаем небольшую задержку. Если состояние // порта изменится быстрее, чем истечет время задержки (дребезг), то // таймер просто будет переведен "на попозже". Win32Check(SetWaitableTimer(FFlutterTimer, eTime, 0, nil, nil, False)); end; // при запросе принудительного завершении потока WAIT_OBJECT_0 + 1: // незамедлительный выход - завершение выполнения потока Exit; // после задержки для подавления дребезга WAIT_OBJECT_0 + 2: begin // узнаем состояние Win32Check(GetCommModemStatus(FComHandle, eStatus)); eStubInstalled := (eStatus and MS_CTS_ON) > 0; // вызовем обработчик события if eStubInstalled then DoOnChange; end; // при нежданной ошибке WAIT_FAILED: // случилось страшное... RaiseLastOSError; end; end; |
Полный код примера приведен в прилагаемом к статье архиве.
Список литературы
JEDI Windows API Library http://members.chello.nl/m.vanbrakel2/win32api.zip
Parallel Port Central http://www.lvr.com/parport.htm
Serial Port Central http://www.lvr.com/serport.htm
Письмо в журнал «Cooler» о прямом доступе к LPT 
http://cooler.irk.ru/cl190902.html
Для подготовки данной работы были использованы материалы с сайта http://www.rsdn.ru/
