Здравствуйте, ..Федя, Вы писали:
Ф>Несомтря на множество тем, например http://www.rsdn.ru/Forum/Message.aspx?mid=235437&only=1Автор:
Дата: 07.04.03
я все же не могу найти ответы на свои вопросы...
Ф>Итак...
Ф>ВОПРОС: COM порт, можно ли решить лимитирование времени написав драйвер?
Ф>Постановка задачи
Ф>---------------------------------
Ф> Нужно написать программу под ОС Windows 2000, которая реализует взаимодействие с устройством через последовательный порт (RS-232) на скорости 4800 бод. Компьютер должен принимать поток байт, если в потоке приходят 2 определенных байта, то нужно за 65 миллисекунд от момента их приема послать заранее подготовленных 20 байт. Управление потоком и т.п. не используется, устройство никак не контролирует приём байт компьютером, компьютер никак не контролирует устройство.
Ф> Проблема заключается в том, чтобы уложиться в эти 65 миллисекунд (это предельное значение), а желательно меньше 20-40 миллисекунд.
Ф> По моей оценке* на основе тестового приложения это невозможно сделать в рамках пользовательского Win32 приложения.
1) 4800 бод — этопримерно 2мс на пересылку 1 байта. Откуда у Вас устойчивое желание передать их за 20-40мс?
2) я бы взялся ответить 20 байтами за 65мс, тут основное ограничение не ОС, а скорость передачи
Ф>Вопросы
Ф>---------------------------------
Ф> Возможно ли решить эту задачу путём написания драйвера последовательного порта (или внесением модификации в существующий драйвер serial.sys, если я правильно понял пример из DDK под Windows 2000 и есть этот драйвер)?
можно
Ф> По моей оценке на основе исходников serial.sys проанализировать получение 2 байт можно непосредственно в обработчике прерывания (функция SerialISR()), остается инициировать из обработчика прерываний запись 20 байт в порт. Возможно ли сделать это в указанных временных рамках и если да, то по какой схеме это сделать?
а вот этого лучше не делать. PIO из обработчика прерывания существенно снизит производительность системы, лучше для этого использовать DPC
Ф> Можно реализовать задачу не через собственный драйвер, а обращаясь к существующему драйверу** из режима ядра используя Irp запросы?
можно
Ф> Может быть такое, что задачу можно реализовать из пользовательского приложения?
может быть и такое
Ф>** Как я понял, одна из проблем это буферизация порта. Если я правильно понял из пользовательского приложения можно только рекомендовать функцией SetupComm() размеры буферов (кажется драйвера, а не порта), но отключить её нельзя. Если я правильно понял драйвер анализирует микросхему и включает буферизацию вроде как особо никого не спрашивая.
Естественно нельзя отключить буферезацию, поскольку у драйвера serial.sys модель в/в буферезированная — т.е. данные принимаются в цикличекский буфер драйвера а потом по запросу копируются в клиентские буфера (с записью наоборот) Работа аппаратного FIFO буфера для драйвера прозрачна (правда, он может его отключить)
