Как из под WIndows 9x/NT ловить прерывания?

← →
Ш-К (2002-10-07 04:28) [0]

Есть проблема с получением данных через lpt порт. Заслать данные то я могу, а вот "поймать момент" когда порт начинает передавать данные - не получается.

Я использую TDLPortIO.dll, как драйвер пр. режима. Через него можно только читать данные. А как узнать "когда"?

Есл я понимаю правильно, надо обрабатывать int7. Или, может, есть какие обходные варианты для решения проблемы? Не только через прерывания.

← →
Ш-К (2002-10-22 05:18) [1]

Ну так что? Как мне узнать, что внешнее устройство выставило байт?

Может бывают какие-нить события драйвера и к ним можно подключиться? А прерывания совсем не надо юзать.

Народ! Чё делать?

← →
Наезжалкин (2002-10-22 10:09) [2]

>Народ! Чё делать?

1)Писать драйвер - заменитель std для LPT.

2)Бросать это дело.

← →
DenKop (2002-10-23 03:38) [3]

> Народ! Чё делать?

1)Я делал так. Открывал в отдельном потоке функцию, которая сравнивала текщее состояние линии порта (Н: ACK) с предидущим и если эти значения не совпадают -> на порт пришли данные.
Недостатком является то, что занимаю дополнительную ногу LPT порта и порта контроллера передающего данные. Но это устранил предачей и приёмом отдельными линиями для каждого направления + тактирующая = 3 входа LPT, т.е. получился паралельный порт с последовательной синхронизированной передачей. Меня это вполне устраивало, т.к. сверх скоростей мне нужно. И ещё пришлось подправить прошивку контроллера, мелочь, но всё же не приятно.

2)Свой драйвер, что довольно напряжно. Но дам маленький совет: выбираешь самую длинную ночь, берешь ящик пива, две банки кофе, открываешь С++ или ASM и погнал...

3)Выкинуть эту идею из головы и занятся более интересным делом.

Фуух, всё. Good Luck!

P.S. Для Low-Level работы с портами взгляни на библиотеку ZNTPort. IMHO, ZNTPort >> TDLPortIO.dll. Последняя на NT ядре не пашет, что крайне возмутительно.

← →
Ш-К (2002-10-24 07:31) [4]

Сразу скажу, что делаю это не ради удовольствия.

Сейчас у меня программа постоянно считывает состояние порта на предмет его измененний. Мне нужна реал-тайм оперативность, но греть из-за этого процессор просто глупо. Вот и нужны альтернативы.

Написать драйвер самому можно успеть всегда. Просто программный комплекс весь написан на Delphi и иметь заморочки ещё и с VC++ не разманно (весь создаваемый софт должен быть лицензионно чистый).

Если программа создана и работает исключительно на Delphi, но криво, то существует естественное желание сделать её "прямой" тоже исключительно на Delphi. Т.е. выправить фичу и переключиться на другие проблемы.

TDLPortIO.dll работает и под NT, иначе нахрен он был бы нужен. Другое дело, что ни он, ни какой другой свободно-распространяемый драйвер не поддерживает сабж. Ну, или то, что мне надо. Очень, кстати, нормально желание (не экзотика).

Мне не понятно, зачем люди вообще напрягаются, создают драйвера, которые не могут отвечать элементарным требованиям? Как, то, реагирование на изменения состояния регистра. После чего все советы: "Пишите сами".

Тема не закрыта.

← →
Digitman (2002-10-24 09:33) [5]

> "поймать момент" когда порт начинает передавать данные

А зачем это нужно ? Поясни.

← →
1234567 (2002-10-24 10:19) [6]

http://terol.narod.ru/gl_1.shtml.htm

← →
Ш-К (2002-10-24 12:15) [7]

Digitman © (24.10.02 09:33)
Это такие требования к внешнему оборудованию. Пока один коннектор общается с компьютером, всё оборудование ждёт окончания сеанса общения, и не работает. Причём, всё время ожидания складывается из скорости обмена данными.
Сами цыклы передачи данных удовлетворительны. Тормоза возникнут из-за невозможности "поймать момент", когда порт начинает передавать данные. Т.к. ПУ выставляет данные, а хост ещё не сразу их принимает.
Я говорю "возникнет", если я уберу безконечный цикл, с которым всё нормально работает. Вот я и хочу заменить этот цикл чем-нибудь меннее ресурсоёмким.

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

1234567 (24.10.02 10:19)
Я прекрасно осознаю проблемы NT как RTOS, но меня устраивает и то, что есть. Проблемы с задержками не желательны, но не кретичны. Если в половине случаев всё будет происходить как надо, то и это хорошо.
Спасибо за ссылку. Если я прийду к написанию драйвера своеручно, то обязательно буду иметь ввиду.
Кстати, я говорил: "... ни какой другой свободно-распространяемый драйвер не поддерживает сабж". Имхо, это камень и в ваш огород. Я, правда, потерял ссылку на ваш драйвер, но думаю, что прав.

P.S. Всё же ещё надеюсь, что решение моей проблемы через свободные драйвера и из Delphi существует.

← →
Digitman (2002-10-24 12:30) [8]

По-моему , ты все значительно усложняешь.

Открывай программный LPT-порт как файл в overlapped-режиме, как положено в Win32API

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

- возникает событие готовности к приему данных из ПУ (очер.данные, переданные периф.устр-вом в хост-выч.систему доступны для чтения выч.системой)

- возникает событие готовности к передаче данных в ПУ
(очер.данные, переданные хост-выч.системой, приняты периф.устр-вом и оно готово к передаче ей выч.системой очер.данных)

см. ReadFile, WriteFile

← →
Ш-К (2002-10-24 12:56) [9]

Я писал об этом месяца два назад.
Если действовать через ReadFile, WriteFile тогда не получается переключить порт в режим ЕРР, а ПУ в этом режиме работает.
Нет, само переключение получается (даже можно режим определить программно). Вот только доходит до ReadFile, WriteFile и Windows "лучше знает", какой режим должен быть.

← →
Digitman (2002-10-24 13:00) [10]

Не буду спорить, но что-то слабо верится в это.
А вариант с DeviceIOCtl ? Имеется ввиду - непоср.взаимодействие с драйвером LPT-дивайса ? Тоже не пробовал ?

← →
Ш-К (2002-10-24 13:21) [11]

Через DeviceIoControl режим переключить не удалось. Пришлось переключать через TDLPortIO.dll.
Да, в DeviceIoControl использовал хендл из CreateFile("lpt1").

← →
Digitman (2002-10-24 14:01) [12]

Какие зависимости от API-ф-ций ядра есть в TDLPortIO.dll ?
Имеется ввиду - ф-ции ввода/вывода, например, те же Create/Open/Read/WriteFile фигурируют ?

← →
Ш-К (2002-10-24 14:34) [13]

Нет там ничего. Только TDlPortReadPortUchar, TDlPortWritePortUlong и вариации таких функций.

ALL
А есть какие-нибудь драйвера, с которыми можно работать через CreateFile? Потому что ReadFile, WriteFile было бы самое то. Только боюсь, что режим не будет переключаться.

← →
Digitman (2002-10-24 15:10) [14]

Думаю, что TDLPortIO.dll под NT работать скорее всего не будет. Судя по отсутствию в ней явно импортируруемых ф-ций ядра, работает она с портами напрямую, не используя драйвер. Такие "выкрутасы" со стороны пользовательского процесса позволительны (и то - не всегда) лишь в Win9X.

Ищи самые свежие OEM-драйверы для твоего LPT-порта (конкретной модели, если - внешний, либо в составе конкретной motherboard, если - интегрирован) под все интересующие тебя платформы. Если порт поддерживает расширенные режимы (ECP, EPP), то OEM-драйвер скорее всего позволит сконфигурировать порт как вручную (через настройки в Панели управления или Система/Порты LPT), так и программно, через DeviceIoControl().
Последующие вызовы Read/WriteFile должны использовать тек.конфигурацию порта, о которой они "знают", ибо порт сконфигурирован не через ж., а как положено - по всем канонам WDM

← →
DenKop (2002-10-25 01:20) [15]

Повторюсь:
Юзай ZNTPort: имеет свой, независимый ни от чего драйвер, о котором ты так мечтаешь, маленькое время доступа(чего не скажешь о ReadFile, WriteFile) к реграм порта и пр.

Используется драйвер работы с портами giveio.sys, zntport.sys. Сняты лишние головняки по работе с драйвами, т.к. весь доступ к дровам осущ-ся через функции dll:
// Returns a value from specific ports.
function Inp(PortNum:word):word; stdcall; external "ntport.dll";
function Inport(PortNum:word):word; stdcall; external "ntport.dll";
function Inpw(PortNum:word):word; stdcall; external "ntport.dll";
function InportW(PortNum:word):word; stdcall; external "ntport.dll";
function Inpd(PortNum:word):longint; stdcall; external "ntport.dll";
function InportD(PortNum:word):longint; stdcall; external "ntport.dll";

// Write a value to specific ports.
procedure Outp(PortNum:word; Data:word); stdcall; external "ntport.dll";
procedure Outport(PortNum:word; Data:word); stdcall; external "ntport.dll";
procedure Outpw(PortNum:word; Data:word); stdcall; external "ntport.dll";
procedure OutportW(PortNum:word; Data:word); stdcall; external "ntport.dll";
procedure Outpd(PortNum:word; Data:longint); stdcall; external "ntport.dll";
procedure OutportD(PortNum:word; Data:longint); stdcall; external "ntport.dll";

На худой конец состряпай простой компонентик и сделай событие OnRecieve:TNotifyEvent, в котором проверяй текущее состояние порта.

← →
Ш-К (2002-10-25 06:04) [16]

Digitman © (24.10.02 15:10)
TDLPortIO.dll работает под NT. Это не совсем драйвер. Это драйвер и библиотека длл, в которой предоставлены функции Open и чтения/записи; больше никаких. Может в недрах библиотеки используются kernel mode функции, а может CreateFile - не знаю.

Требования к программе такие, что она должна работать на любой машине под Win32. Коробочный вариант. Не распространять же с оборудованием и матерь. Абсурд.

DenKop © (25.10.02 01:20)

> сделай событие OnRecieve:TNotifyEvent, в котором проверяй
> текущее состояние порта

Ты не въехал. Я же говорю, что греть процессор - дурдом. А если проверять через миллисекунду (меньше не получится), считай:
допустим пакеты по 50 байт, при каждом пакете задержка минимум в 1 мс, получается не более 50 кб/с. А нахрена мне на лпт такие скорости при заявленых 2МВ/с; я бы тогда с сом работал.

P.S. И вообще, уже мы уволили инженера. За LPT, ЕРР - это всё его идеи. И за то, что в Гука тыкал пальцем: "Вот же написано!".

← →
Digitman (2002-10-25 08:17) [17]

>Ш-К

> Это не совсем драйвер

Вернее, думается, совсем не драйвер. Любопытно было бы узнать, как инсталлируется сей "драйвер".

Я вот тебе вот что предложу. Организуй доступ к ф-циям ввода/вывода библиотеки в доп.код.потоке. Тогда, возможно, и никакие прерывания не понадобятся

← →
Ш-К (2002-10-25 09:51) [18]

> как инсталлируется сей "драйвер".

Поставляется мини-инсталятор. Копирует и запускает библиотеку как сервис. А потом из приложения можно делать Open.

> Организуй доступ к ф-циям ввода/вывода библиотеки в доп.код.потоке.

А я что делаю? И какая разница: поток - не поток.
И что, это нормально - делать задержку до наступления события циклом while? А если с прерываниями, да ещё оформленными как сообщения (мечта идиота), и ждать не надо.

← →
Digitman (2002-10-25 10:06) [19]

сервис-то сервисом) ... но вот каким образом этот сервис осуществляет доступ к порту на уровне kernel-mode без sys-драйвера - это непонятно пока

>>делать задержку до наступления события
Какого ? Какие события предоставляет интерфейс сервиса ? Как это реализовано в дан.момент тобой ? Приведи код обращения к сервису по чтению/записи из/в порт

← →
Ш-К (2002-10-25 10:54) [20]

Я же писал: есть драйвер.sys и сервис.dll. Сервис предоставляет только функции ReadByte и WriteByte. Ну, ещё есть процедуры Open и Close. Всё, больше никаких функций не описано. Никаких интерфейсов и никаких событий. Поэтому, к порту все обращения идут через функцию ReadByte (и разные её вариации, типа чтение регистра состояния порта).
А как работать с *.sys без этого сервиса я не знаю.

> >>делать задержку до наступления события
> Какого ?

Ну, не надо так буквально понимать термин "событие". Читайте: "изменение флага".
Программа просто становится в цикл чтения регистра порта:

while PinACK <> true do
begin
// пустой цикл.
// греем процессор, типа ждём PinACK,
// чтобы по его наступлению продолжить программу
end;

А я не хочу такой цикл. Не в потоке - не где ещё.
И если будет найдена возможность юзать прерывания - такой цикл будет не нужен.

← →
Digitman (2002-10-25 11:21) [21]

>>Я же писал: есть драйвер.sys и сервис.dll

Где писал-то ? Про *.SYS ? Первый раз слышу от тебя в этой ветке, что драйвер таки есть в составе пакета. А это уже меняет дело.

Сразу вопрос : каким символьным именем представлено вирт.устр-во, предоставляемое данным драйвером ? Скажем, стандартный драйвер LPT-дивайса имеет имя вирт.устр-ва "LPT", COM-дивайса - "COM" ... А в этом случае что имеешь ? Как следует обращаться к дивайсу по имени в CreateFile() ? Уж не "LPT" - это точно, в этом случае будет явно задействован станд.драйвер, а не твой.
Выясни это для начала.

PinACK - что это за флаг ? Откуда он взялся ? Кем и каким образом изменяется его значение в ходе программной работы с дивайсом ?

Как в документации описаны ф-ции Open, Close, ReadByte, WriteByte ? Есть ли параметры ? Синхронные они или асинхронные ?
Приведи описание из документации.

← →
jonik pegas (2002-10-25 11:34) [22]

>Ш-К
Раз вы уже уволили инженера, теперь нанимайте системотехника который сделает вам буферную память+микроконтроллер, который снимет проблему Realtime. Иначе никак, если не хотите юзать цикл.
Использовать прерывания поверьте вам не под силу.
>Digitman
Это sys-драйвер. Если активно юзать программы аппаратного мониторинга и всякие тестилки то таких драйверов можно в систему установить целую тучу-и giveio.sys, zlportio.sys, dlporio.sys,winio.sys и т.д. Единственно предоставляемая ими функция-читать писать в порт

← →
Digitman (2002-10-25 12:12) [23]

>jonik pegas

Это совершенно ни о чем не говорит - мало ли каких универсальных "примочек" налепили под NT ! Здесь нужно точно определитья в соотв.возможностях конкретного драйвера, иначе дальнейшие "потуги" попросту бессмысленны. Если данный драйвер дивайса после штатной инсталляции предоставляет управление таким св-вом, то - есть смысл двигаться дальше в этом направлении.

Скажем, функциональность стандартного LPT-драйвера (например, вот он у меня, под Винтукей, прямо перед носом ) позволяет использовать прерывания LPT-портов. О чем явно говорит соотв.вкладка в св-вах порта в сист.настройках . Другой вопрос, что этот станд.драйвер (parallel.sys, parport.sys) не "умеет" инициализировать порт для работы в расширенных режимах, ибо (как стандартный) он создавался для поддержки только совместимого режима, как безусловно поддерживаемого всеми производителями портов стандарта.

← →
jonik pegas (2002-10-25 12:48) [24]

>Digitman
Вкладка в системных настройках не говорит о том что стандартный драйвер использует прерывания. (В MSDOS int7 стандартно не обрабатывается,в Win2000 по умолчанию Never use an Interrupt ) Но стандартный драйвер поддерживает не только стандартный режим (выдержка из MSDN)
A parallel port is typically a multimode communication port that supports the following:
Byte and nibble (read) modes
IEEE 1284-compatibility mode
Extended Capabilities Port mode
Enhanced Parallel Port mode
For information about parallel port and device standards, see the following specifications:
IEEE Std 1284-1994, IEEE Standard Signaling Method for a Bidirectional Parallel Peripheral Interface for Personal Computers
IEEE P1284.3, Standard for Interface and Protocol Extensions to IEEE 1284-1994 Compliant Peripherals and Host Adapters, Draft D6.00, December 3, 1998
Другое дело что по стандарту IEE1284 устройство обязано выполнить последовательность согласования, после чего вероятно драйвер и включит режим
Вообще то в MSDN-DDK про парралельный порт достаточно всего много написано но народ не забивает себе голову и прет в обход.
P.S. Кстати автор Winio-Марк Руссинович, так что не не "налепили".

← →
Digitman (2002-10-25 13:06) [25]

LPT | Port Settings | Filter Resource Method | Use Any Interrupt Assigned to the Port :

Click to have the parallel port driver accept and use any interrupt signal assigned to it. This option disables the parallel port driver interrupt resource filtering. This option should be selected only if one of the following two cases applies: (1) The computer has broken hardware, BIOS, or legacy drivers that prevent the computer from working properly unless the parallel port has an interrupt resource, or (2) the user has installed a high speed parallel port device and driver that is known to be able to use an interrupt AND the user does not have any legacy sound or network devices that require the interrupt to work properly.

← →
Digitman (2002-10-25 13:09) [26]

← →
Ш-К (2002-10-25 13:35) [27]

Digitman ©

PinACK - это Pin ACK. Штырёк (ножка порта), при изменении состояния которой с 0 на 1 вызывается прерывание. Которое поймать не могу. Вот приходится программно за ней следить.

> Где писал-то ? Про *.SYS ? Первый раз слышу от тебя в этой
> ветке, что драйвер таки есть в составе пакета. А это уже
> меняет дело.

Моя цитата: " TDLPortIO.dll работает под NT. Это не совсем драйвер. Это драйвер и библиотека длл,...". В смысле два разных файла. Не точно выразился, скз. А "TDLPortIO.dll" вообще название компонента.

Теперь понятно, почему не понятно.

Имеется два файла DLPORTIO.sys и DLPORTIO.dll.

DLPortIO.dll

This is the DriverLINX DLL which provides Port I/O in Win95/98, and an interface to the WinNT kernel mode driver in Windows NT.

DLPortIO.sys

This is the DriverLINX kernel mode driver which provides Port I/O in WinNT, and as such is only
required if you are running Windows NT.

[procedure] OpenDriver()

Opens the DriverLINX DLL. If running under Windows NT, it will start the kernel mode driver, and if the driver isn’t installed, it will attempt to install it into the system.

[procedure] CloseDriver()

Closes the DriverLINX DLL. If running under Windows NT, it will stop the kernel mode driver (if started in OpenDriver), and remove it if it was installed in OpenDriver.

Properties
[Byte] Port[Address] Read/Write
[Word] PortW[Address] Read/Write
[DWord] PortL[Address] Read/Write

Функции (6 штук) для этих свойств загружаются из DLPortIO.dll.

Вот из функциии DriverInstall:
...........
Сначала проверка на OpenService, а потом: hService:=CreateService( hSCMan, "DLPortIO", "DriverLINX Port I/O Driver", SERVICE_START or SERVICE_STOP or DELETE or SERVICE_QUERY_STATUS, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, PChar(DriverPath), "SST miniport drivers", nil, nil, nil, nil);

DriverPath - путь к DLPORTIO.sys.
...........

Весь остальной код компонента - обёртка загруженых 6-и функций из DLPortIO.dll.

Т.е., все манипуляции с портом, "для удобства юзера", спрятаны в DLPortIO.dll. Сорцов которой нет.

← →
Ш-К (2002-10-25 13:50) [28]

jonik pegas ©

> Раз вы уже уволили инженера, теперь нанимайте системотехника
> который сделает вам буферную память+микроконтроллер, который
> снимет проблему Realtime. Иначе никак, если не хотите юзать
> цикл.

Проблема не Realtime. Есть и буферная память, и микроконтроллер. Просто логика оборудования такова, что оно может попасть в режим общения с очень мелкими пакетами (до 50 байт). И тогда получится, что скорость обмена падает и, как следствие, возникают искажения.

> Единственно предоставляемая ими функция-читать писать в порт

А зачем тогда их вообще создают? Пятивольтовые лампочки включать?

← →
Digitman (2002-10-25 14:03) [29]

> PinACK - это Pin ACK. Штырёк (ножка порта)

При чем здесь "штырек" ? Я спросил - что за идентификатор "PinACK" в твоей программе ? Как он объявлен у тебя ? Это что - переменная или ф-ция ?

Приведи описания ф-ций

PortRead/Write
PortWRead/Write
PortLRead/Write

Меня интересует, что говорится в док-ции по поводу синхронизации этих ф-ций с состоянием готовности порта к приему/передаче.

Возвращает ли , скажем, вызванная тобой ф-ция PortRead() управление вызывающему коду немедленно или блокирует выполнение код.потока до тех пор, пока порт не будет готов к чтению принятых данных ? Что возвращает ф-ция, если данные отсутствуют ?

← →
Digitman (2002-10-25 14:34) [30]

Кр. того. подозреваю, что инициализация EPP-режима вполне может быть доступна через ControlService(), подобно тому, как система работает со станд.сервисом с именем "Parport"

см.для примера
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\ACPI\PNP0401\3&61aaa01&0

← →
Digitman (2002-10-25 14:39) [31]

Оч показательно и полезно, думаю, будет взглянуть на реестровые записи для установленного в систему IOmega ZipDrive, соврем.модели которого, как известно, как раз позволяют использовать LPT для работы в EPP-режиме с использованием прерываний

← →
Ш-К (2002-10-25 14:52) [32]

function PinACK: boolean; begin result:= (Port[FLPTBase+1] and $40)<>0; end;
А что ещё тут может быть?

TDlPortReadPortUchar = function(Port : Word) : Byte; stdcall; ReadByte : TDlPortReadPortUchar; @ReadByte:=GetProcAddres(FDLLInst,"DlPortReadPortUchar");

Всё, больше никакой инфы по функциям. Ни в доках ни в текстах.

> Меня интересует, что говорится в док-ции по поводу синхронизации
> этих ф-ций с состоянием готовности порта к приему/передаче.

Ничего не говорится. Имхо её нет. Собственно, к этой синхронизации и больше не к чему я и пытаюсь подобраться.

> Возвращает ли , скажем, вызванная тобой ф-ция PortRead()
> управление вызывающему коду немедленно или блокирует выполнение
> код.потока до тех пор, пока порт не будет готов к чтению
> принятых данных ?

Возвращает немедленно. И вообще, работает на таймаутах (~10 Мкс).

> Что возвращает ф-ция, если данные отсутствуют ?

Они не могут отсутсвовать. Стоит например в порту $FF или $00, так функция будет считывать этот бай постоянно. С таймаутами через 10 Мкс. Если ПУ отвечает, то на порядок быстрее. И этот байт будет стоять пока либо хост, либо ПУ его не изменит.

← →
Ш-К (2002-10-25 15:08) [33]

> инициализация EPP-режима вполне может быть доступна через
> ControlService(),

Хотелось бы, чтоб и под 9х работало. Хотя интересно - сюда ещё не лазил.

> взглянуть на реестровые записи для установленного в систему
> IOmega ZipDrive

Или другого устройства, реально работающего с ЛПТ. Чувствую будет там работа простого самолепного кернел-драйвера.

← →
Digitman (2002-10-25 15:27) [34]

>Ш-К

Нет, подожди).. Мы тут как бы об NT-платформе рассуждаем в 1-ю очередь. В Маздае - там все до смешного просто, в т.ч. и доступ к IDT с целью установки собственного дескриптора шлюза

1. значение FLPTBase ты откуда взял ?
Из книжки по программированию станд.портов под MS-DOS ?
Если так, то для Win32 это не годится. Мало ли какие ресурсы (в части базы портов в/в) выделит система на этапе старта для LPT-дивайса при его инициализации ! Мало ли как P&P во взаимодействии с legacy-установками отработает !

2. >>И вообще, работает на таймаутах (~10 Мкс).
Вот это уже "ближе к телу". Что мешает тебе установить иной таймаут (вплоть до INFINITE-) для коммуникационного дивайса вызовом SetCommTimeouts() ?

← →
Ш-К (2002-10-25 15:49) [35]

Согласен, с 9х проблем меньше.

1. Поле объекта, реально вычисляется в конструкторе. Но это сейчас не актуально.

2. Таймауты реализованы на аппаратной части в маме. Они стандартны. А вызов функции ReadByte - это запуск цикла чтения чипсета.

Имхо, Винда программно может реализовать тоже самое. Сейчас DDK нет под рукой, но помню, есть файл ерр.с, где протокол расписан.

← →
jonik pegas (2002-10-25 15:58) [36]

>Digitman
> Меня интересует, что говорится в док-ции по поводу >синхронизации этих ф-ций с состоянием готовности порта к >приему/передаче.
А ничего не может говорится, потому что эти функции всего лишь обертки для ассемблерных функций in и out. Откуда они узнают о готовности порта? (Хотя мы наверное говорим о разных портах-я о портах ввода/вывода аппаратуры, а не о томчто в CreateFile подставляются ). Их поведение целиком определяется аппаратурой. Скажем записывая в регистр порта LPT_BASE_ADDRESS+3 байт (каким угодно способом) мы генерируем шинный цикл EPP. Данные выставляется, процессор приостанавливается и ожидает ответа от перифирийного устройства. Если оно пришло-процессор выполняет следующую команду, не пришло-через 10 мкс он все равно выполняет следующую команду. Узнать о успехе/неуспехе/неготовности операции можно только прочитав определенной бит регистра порта. Это определяется аппаратурой и совершенно не зависит от программной реализации.
>Ш-К
1.IMНО неправильная логика работы аппаратуры. И с никакими тайм-аутами DLPort не работает-читай выше.

← →
Digitman (2002-10-25 15:58) [37]

Ну какое тебе, скажи на милость, дело до того, как таймауты реализованы ? Если есть возможность изменить таймауты на любое нужное тебе значение, почему не попробовать воспользоваться этим ?

← →
Digitman (2002-10-25 16:03) [38]

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

Я и спрашиваю о документации, потому что понятия не имею, так ли выглядит на самом деле то, о чем ты говоришь в отношении конкретно данного библиотечного интерфейса

← →
jonik pegas (2002-10-25 16:09) [39]

>Diditman
>1. значение FLPTBase ты откуда взял ?
>Из книжки по программированию станд.портов под MS-DOS ?
>Если так, то для Win32 это не годится. Мало ли какие ресурсы (в >части базы портов в/в) выделит система на этапе старта для LPT->дивайса при его инициализации ! Мало ли как P&P во >взаимодействии с legacy-установками отработает !
Ты безусловно прав. НО! Для COM порта такие вещи проходят-WIN API функции в принципе позволят реализовать любой протокол обмена. С принтерным портом-такие вещи не проходят. В Microsoft не учли что существуют маньяки которые в принтерный порт всякую ерунду а не принтеры пихают. Если бы можно было сделать что то вроде
hPort=CreateFile ("LPT1",...
SetPortMode(hPort,EPP_MODE
SetPortState(hPort,ACK_HI-и т.д -например проблемы бы не было

← →
Eliseev Andrey (2002-10-25 16:10) [40]

Есть такая библиотека TetaPCHW ( http://www.geocities.com/tetasoft/).

Там есть все функции для работы с LPT включая установку IRQ.
Вот цитата из ReadMe.

procedure LPTEnableIRQ(IRQEnabled: Boolean);
--------------------------------------------
Forces an LPT device to generate interruptions when ACK line(Pin 10) has a HIGH
electrical level.

type
TInterruptHandler = procedure (IrqNumber : WORD) of object;
property OnHwInterrupt: TInterruptHandler;
------------------------------------------
This is an event property which allows you to install your own application
handler for all IRQs. Note, due to Windows is not a verily multi-task system of
real time the time of delivery a message about an IRQ generated up to your
application interrupt handler is not assured.

Как из под WIndows 9x/NT ловить прерывания? Найти похожие ветки