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

А, в смысле DeviceIOControl только к файлам относится... А то можно двояко прочитать.

> я же его открываю как CreateFile


И что ?

Первым параметром ты указал 'COMn', следовательно, требуешь от системы работу с этим файлом как с файлом коммуникационного дивайса ..

Вот нашел - может иметь отношение к теме. А может и не иметь...
http://support.microsoft.com/kb/q184072/

Пробовал сделать через макрос HasOverlappedIoCompleted. Как то не то...

> REA   (19.05.08 14:36) [40]

Отвечая на вопрос -сколько байт и когда читать, а также  для удобной работы с портом посмотри следующие функции
WaitCommEvent - ждем нужных событий,
SetCommMask - подписаться на нужные нам события.
ClearCommError -  обрати внимание на стурктуру COMSTAST и поле cbInQue.

А разница между "короткими" и "длинными" кадрами объсняется просто - при коротких кадрах WaitForSingleObject попросту не вызывается (ReadFile возвращает True) и все работает. Как только доходит до WaitForSingleObject работает через раз.

Переделал чтение "одним куском" с прекращением по межбайтовому таймауту. Работать стало несколько стабильнее, хотя таймауты Wait по прежнему иногда возникают.

Есть чудная статья на "Королевство Дельфи"
http://www.delphikingdom.com/asp/articles_forum.asp?ArticleID=1126
Реализовывал на ее основе приложение (чтение сигнала из COM-порта) - все работало корректно. Данные не терялись.  
В процессе отладки также использовал программу Portmon

Еще одна странность: вызов функции CancelIO в случае возникновения таймаута приводит к Acess Violation. Это вообще странно для API функции.

> Это вообще странно для API функции.
>


Похоже что у тебя просто ошибка в 17-й строке, и система тут ни причем)

Почитал статью - принципиально только то, что они сначала дожидаются прихода хотя бы одного байта и потом вызывают ReadFile тем самым пытаясь исключить как я понял злополучной WaitForSingleObject. Но тоже без гарантии...

>Похоже что у тебя просто ошибка в 17-й строке, и система тут ни причем)

Это то и неприятно :( Убрал CancelIO, ошибка пропала. Попробовал сделать с WaitCommEvent перед ReadFile - тоже ничего не получается хорошего

> Почитал статью - принципиально только то, что они сначала
> дожидаются прихода хотя бы одного байта и потом вызывают
> ReadFile тем самым пытаясь исключить как я понял злополучной
> WaitForSingleObject. Но тоже без гарантии...

Я не знаю какую гарантию Вы хочете получить, так как Вы не описали полностью свою задачу.
Реально приложение, базирующееся на данном примере работает система
- чтение данных из компорта (~12байт) - код карточки
- работа 24*365
- срок реальной эксплуатации 9 мес.
- среднее количество считываний при максимальной загрузке - 20 в мин.
- использование данного приложения как COM-сервера(результат считывания возвращается в родительское приложение)
- на компьютере также крутится серверное приложение и MS SQL Server

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

Похоже проблема решена:
установил общий таймаут на чтение ReadTotalTimeoutConstant = 100 и видимо когда ReadFile не может завершить чтение по межбайтовому таймауту он завершает по общему таймауту. В итоге таймаута WaitForSingleObject не возникает. Байты все на месте.

>среднее количество считываний при максимальной загрузке - 20 в мин.

Я думаю у меня столько же, но в секунду... Работает 12 лет на разных операционках 24 часа в сутки 365 дней в году, параллельно можно играть в Doom :)

История продолжается: на одном компьютере все работает, а на другом выдает, что считано 0 байт, таймаутов не возникает, но после этого уже ничего читать не желает (всегда 0 байт).

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

> Сделал задержку 1мс после записи, чтобы приемник не обрезал
> конец кадра.


А тайминги просто на операции чтения/записи никак проставить ?


> Почему то еще при чтении возвращалось больше байт, чем нужно.


Порт зачищай при открытии. Буфер порта, если не изменяет память, при открытии мусор содержит. По крайней мере , реально ставлкивался.

>А тайминги просто на операции чтения/записи никак проставить ?
См. выше про DTR и уход последнего бита

>Порт зачищай при открытии. Буфер порта, если не изменяет память, при открытии мусор содержит.

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

> REA  (23.05.2008 16:20:58)  [58]

Если контрольная сумма совпадает, то это не лишнии байты.