Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как из под WIndows 9x/NT ловить прерывания? [Win95/98, NT4]


Страницы:   1 2 3

Ш-К ©   (2002-10-07 04:28:00) 

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

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

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


jonik pegas   (2002-10-25 12:48:00) [21]

>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 12:12:00) [22]

>jonik pegas

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

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


jonik pegas   (2002-10-25 11:34:00) [23]

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


Digitman   (2002-10-25 11:21:00) [24]

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

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

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

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

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


Ш-К   (2002-10-25 10:54:00) [25]

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

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

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

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

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


Digitman   (2002-10-25 10:06:00) [26]

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

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


Ш-К   (2002-10-25 09:51:00) [27]


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

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

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

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


Digitman   (2002-10-25 08:17:00) [28]

>Ш-К


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


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

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


Ш-К   (2002-10-25 06:04:00) [29]

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, ЕРР - это всё его идеи. И за то, что в Гука тыкал пальцем: "Вот же написано!".


DenKop   (2002-10-25 01:20:00) [30]

Повторюсь:
Юзай 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, в котором проверяй текущее состояние порта.


Digitman   (2002-10-24 15:10:00) [31]

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

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


Ш-К   (2002-10-24 14:34:00) [32]

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

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


Digitman   (2002-10-24 14:01:00) [33]

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


Ш-К   (2002-10-24 13:21:00) [34]

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


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

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


Ш-К   (2002-10-24 12:56:00) [36]

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


Digitman   (2002-10-24 12:30:00) [37]

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

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

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

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

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

см. ReadFile, WriteFile


Ш-К   (2002-10-24 12:15:00) [38]

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

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

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

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


1234567   (2002-10-24 10:19:00) [39]

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


Digitman   (2002-10-24 09:33:00) [40]


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


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


Страницы:   1 2 3

Наверх

Титульная страница Поиск, карта сайта Написать письмо