Доброе время суток! Уважаемые программисты помогите пожалуйста. Может кто-нибудь сталкивался с этой проблемой или просто умный. Я пишу драйвер виртуального COM-порта. В процедуре DispatchDeviceControl необходимо обрабатывать Device Control Requests. Например, IOCTL_SERIAL_CLEAR_STATS, IOCTL_SERIAL_CLR_DTR,IOCTL_SERIAL_CLR_RTS, IOCTL_SERIAL_CONFIG_SIZE,IOCTL_SERIAL_GET_BAUD_RATE,IOCTL_SERIAL_GET_C HARS,IOCTL_SERIAL_GET_COMMSTATUS и т.д. Все эти запросы описаны в DDK в разделе "Serial Device Control Requests". Там же описаны все входные и выходные параметры для этих запросов. Но вот вопрос: меня интересует, например параметр IOCTL_SERIAL_WAIT_ON_MASK. В исходнике в DDK нормального serial.sys там работа с какими-то очередями(queue). А суть в том, что, когда я работаю со своим портом в HyperTerminal начальные запросы проходят нормально, а вот на IOCTL_SERIAL_WAIT_ON_MASK все заканчивается. Я просто неправильно описываю обработку этого запроса. Вот в DDK там как раз и работают с очередями. Если знаете что это за очереди в данном контексте, то расскажите пожалуйста. Заранее спасибо!
Твой драйвер могут попросить просигналить по наступлении некого события. Можешь посмотреть MSDN BOOL SetCommMask( HANDLE hFile, DWORD dwEvtMask ); dwEvtMask - маска событий. А с помощью IOCTL_SERIAL_WAIT_ON_MASK маску передают тебе.
<font color="gray][ Bill_Prisoner</font><!--color--><font color="gray]: Если знаете что это за очереди в данном контексте, то расскажите пожалуйста. ]</font><!--color--> Имеется ввиду очередь IRP. Если драйвер может обработать запрос сразу, то он это делает и завершает IRP с соответствующим статусом. Если не может, то ставит в очередь и возвращает STATUS_PENDING. Когда созреют условия для обработки IRP, драйвер достанет его из очереди и завершит или вообще отменит. Читай в ДДК "Driver-Managed IRP Queues", но лучше у Вальтера Они "Queuing I/O Requests".
Я написал драйвер виртуального COM порта (точнее два виртуальных COM порта которые между собой связаны) В нем я осуществляю обработку Read и Write. В принципе, обмен данными между двумя терминалами подключенным через эти два COM порта осуществляется, но если я начинаю использовать другие программы вместо терминала (именно работа с ними меня интересует) возникает следующая проблема: обмен идет лишь в одну сторону (передача с программы "1" через COM на терминал идет, а с терминала на программу "1" нет). Как оказалось автор программы "1" использует некоторую API функцию, которая определяет количество байт содержащихся в буфере порта, а так же отслеживает событие прихода нового байта (в терминале судя по всему просто в цикле осуществляется Write потому и все работает). В связи с чем вопрос, какой минимум IOCTL необходимо обрабатывать что бы заработало при таком методе работы с COM портом. Прошу сразу к MSDN не отсылать. Заранее благодарен.
без обид но к этому вопросу с Вашего позволения добавлю свой Код (Text): var TMask :DWord; ii:smallInt; begin bb:=true; while bb do begin If not WaitCommEvent(hCOM, TMask,@StrOvr) then If GetLastError = Error_IO_Pending then WaitForSingleObject(StrOvr.hEvent, InfInite); ClearCommError(hCOM,xn,@StatCOM); // состояние COM в StatCOM пихаем If TMask = EV_RxChar then begin xn :=StatCOM.cbInQue; // кол-во байт в буфере if xn > 0 then If ReadFile(hCOM,buf_read_1,sizeOfBuf,xb,@StrOvr) then SendMessage(Form1.Handle, wmCOMPort,1,0); // отсыл месаги гл форме end; //If TMask end; // while bb end; и вот в чем проблема при получениии данных дело доходит до ReadFile (при этом xn <>0, т.е. данные содержатся в буфере) после чтения данных этой процедурой - buf_read_1 (а значит и сам буфер входной) не содержит данных никаких... ПОЧЕМУ?? подскажите плз, может я чего не так сделал??
а у меня, с Вашего позволения, плюс к этому еще один вопрос почему при записи в неоткрытый порт сильно притормаживает вся система, хотя я работаю с портом в отдельном потоке
уменьшил до нормал - ксожалению не помогло такое ощущение при подключении к порту и при передаче пакетов с одновременным получением ответа моя прога занимает весь процесс 98% в диспетчере
