Нужно соединить компутер с устройством через RS232. Обмен такой. Устройство непрерывно шлет пакеты по 16 байт и принимает ответные пакеты. Скорость обмена 115200, частота отправки пакетов 50 Гц.
Под WinXP пользуюсь стандартными API. В билдере я открываю ком порт через CreateFile, дальше вешаю на таймер функцию которая проверяет сколько байт в приемном буфере, если не 0, то считывает буфер.
Проблема в том что считывается не 16 байт, а от 80 до 96. Т.е. получается что виндосовский таймер может работать с частотой 18 Гц и никак не чаще. Подскажите способ чтоб мне уложится в частоту 50 Гц.

Обмен бездарный. Сами придумали?

Предложите, пожалуйста, или ткните ссылкой в правильный. Тоже очень нужно.

Опрашивайте порт в отдельном потоке. Никаких проблем не будет.

Работайте по таймауту, не используя таймер вообще. Посмотрите на SetCommTimeouts.

Вас не устраивает точность работы таймера? В Win несколько таймеров. Самый точный из них - мультимедийный (см. Multimedia Timer Functions: timeBeginPeriod, timeSetEvent, и др.). Однако при работе с ним нужно проявлять хотя бы элементарную осторожность: запуск из под этого таймера - в режиме "Real time".

Решалась подобная задача, писал на PureBasic. Открывал в приложении параллельный поток. В нем выполнялась функция приема из COM порта. Пользовался тупым сравнением прошедшего времени в мс. т.е. что то типо того :

на PureBasic это выглядит несколько иначе:


Сообщение отредактировал ibiza11 - Jul 21 2011, 13:01

Передавайте данные текстом, а поле текста обрамляйте STX/ETX, или просто после данных код перевода строки

Можно будет смотреть данные обычным гипертерминалом.
Тайм-аут не нужен вообще.

А есть в С++ билдере компоненты с этим таймером?

Не совсем понял как это не использовать таймер. Если я без таймера буду непрерывно опрашивать приемник, то программа просто повиснет.
Если только добавлю таймаут, то это даст то что вместо 96 байт я приму 16. А остальные 80 потеряются. Т.е. проблема не решится

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

Такой протокол может дать только препод
Никакой логики - если принял-ответил, тогда почему устройство передает опять, не дожидаясь ответа?

Не надо его опрашивать. Функция read() сама веренет управления после приема N байт или истечения таймаута. Можете использовать асинхронные события (используя структуру OVERLAPPED), тогда вообще ничего ждать не надо будет.

Не знаю. Но, похоже, таймер Вам и не нужен... Я думал, что Вам нужно передавать строго через 20 мс... Для приёма использовать таймер - моветон. Рациональнее - вынести приём в отдельный поток.

Но ведь переключение между потоками по таймеру. В чем тогда выигрыш?

Необходимо ждать наступления события - приема нескольких байт. Это можно сделать по прерываниям в МК, в Win - не знаю. Нужно смотреть, можно ли ждать события для последовательного порта.
Либо, действительно, настроить таймауты, чтобы система не повисла. С таймером бы не стал связываться. Как-то интуитивно не вяжется...

По истечению выделенного кванта времени переключаются чисто вычислительные потоки, которых, обычно, раз-два и обчёлся... Любое ожидание события (а, ввод-вывод без ожидания, обычно, не обходится) приводит к переключению потоков.