Доброго времени суток всем. 
Собрал свое устройство, по сути преобразователь протоколов. С одной стороны COM порт c другой устройство с инфракрасной связью, своим специфическим протоколом и набором комманд. Написал свою прогу(вернее написание в процессе, но кое-что уже работает) 
Использовал найденный в инете TComThread. Наследованный от TThread. Суть не в этом. Скорость выше 57600 использовать не могу, дальше слишком большой разбег между желаемой и реальной частотой, комп уже адекватно не воспринимает данные от контроллера. (Изменить кварц тоже не легко, инфракрасный девайс не менее критичен)  Сообщения передаваемые от/к девайсу имеют длину от 3-х до 12 байт.
При трех в принципе проблем не возникает, а вот при 12... Время передачи 12-и байт через COM-порт равно 2086 мкс, а время ожидания ответа оптическим девайсом, не превосходит 4500 мкс. Если бы я писал под ДОС, то у меня было бы прерываание по приходу символа, и соответственно время реакции программы было бы минимальным, мне в полне хватило бы чтобы принять посылку, сформировать ответ и передать его, тем более что мое устройство начало бы передавать сразу же. ( время передачи по оптике одного байта, процентов на 20 больше чем передачи его же по COM, так  что все было бы в ажуре ) Но как я понял дядя Билли не снабдил COM порт механизмом сообщений,
и все существующие компоненты и библиотеки работают по принципу "подождал, проверил количество принятых байт, если не ноль вызвал обработчик" При этом времени проходит достаточно, чтоб девайс перестал ждать ответа   

Уменьшая время ожидания я добился того что интерфейс стал почти не юзабельным, но положительных сдвигов не наметилось.  

Может кто подскажет есть ли какие либо драйвера или может исходники, как обойти микрософтовскую заглушку на COM и получит возможность "получать" ( извините за тафталогию ) прерывание от COM и обрабатывать его своей функцией?

Слыхал что в .NET есть стандартный компонент работы с COMом, но боюсь что там тот же принцип.
Кто работал с DirectX, может  там есть такая возможность?

Заранее и в любом случае всем спасибо.

P.S. Стандартный файловый доступ пробовал, оверлапед тоже, TComPort и TPAPro работают схожими с TComThread способами.

Вообще то снабдил - overlapped называется. Так же надо не забывать настроить timeout'ы на прием байта (выкрутить их в 0). Еще надо тому thread'у, на котором висит обработка COM порта выкрутить приоритет в real-time, иначе переключение thread'ов сожрет все время.


Написать свой драйвер и вставить в него все преобразование - Windows не real-time система :(

Угу, еще можно в Java поискать   

Если таймаут выкрутить в 0 и дать треду приоритет real-time, то интерфейс вообще повиснет ;(
overlaped - не тоже, что обработка прерывания по приходу байта. После запуска чтения порта в оверлаппед режиме, необходимо постоянно опрашивать систему о том принято ли какое-либо количество байт. Что в принципе и реализовано. Единственный выход, как я сам думаю, написать свой драйвер, который будет делать то что мне нужно, но подумал спросить у людей, вдруг я ошибаюсь и есть другие методы.
Тем более что с DDK никогда не работал( ставил как-то DDK2000, но дальше просмотра примеров не пошел, тем более что DDK2000 требовал VC4, а я тогда смог найти только VC6.

Есть у меня правда другой вариант, даже два:
1) Написать что либо под ДОС, тем более в свое время работал с Turbo Vision
2) Задействовать BigPIC4 в качестве платформы, и писать под PIC18.

Потому пока есть некоторое время, подожду, вдруг кто поделится ссылкой, идеей, исходниками и т.п. А если нет, буду решать указанными выше способами.

Спасибо.

Не повиснет, если делать с умом: ReadIntervalTimeout и ReadTotalTimeoutMultiplier в 0, ReadTotalTimeoutConstant во что-нибудь осмысленное. Но в случае бага в этой нитке машину придется перезагружать 


Хм, вообще то для этого используют поле hEvent в OVERLAPPED структуре и WaitForSingleObject. Ничего постоянно опрашивать не надо.

Тут соглашусь, я с оверлапедом игрался лет пять-семь назад. Тогда о паралельном выполнении двух потоков (тредов) я и не помышлял ;)
Сейчас уже не помню деталей, но по-моему у меня программа не могла ничего сделать пока не получит этот самый эвент, возможно я делал что не так. Вот и отложилось в памяти. В понедельник попробую(сейчас дел по горло, даже некогда за комп по нормальному сесть). Спасибо еще раз гляну хелп по API ;)