Задержки для COM порта под Win XP, Программирование на С++ Builder Опции

[AKK]

Доброго всем времени суток.
При иннициализации порта:
hCom = CreateFile("COM3", GENERIC_READ | GENERIC_WRITE,0, NULL,OPEN_EXISTING, 0,NULL );
Устанавливаются следующие задержки на чтение:
COMMTIMEOUTS times;
...
times.ReadIntervalTimeout = MAXDWORD;
times.ReadTotalTimeoutMultiplier = MAXDWORD;
times.ReadTotalTimeoutConstant = 5;
...
Далее в программе происходит запись в порт 8 байт, и прием одного байта ответа:
WriteFile(hCom,Buffer,8,&b,NULL);
ReadFile (hCom,&i,1,&b,NULL);
И все это происходит в цикле.
Собственно проблема: на осциллографе видно, что передача 8 байт и ответный байт на скорости 9600 укладываются примерно в 10 мс, а следующая посылка данных происходит примерно только через 30 мс. Откуда берется это время - не понятно. При попытке читат 2 байта из порта (второго байта нет, т.е. должен происходить таймаут) картина полностью идентична описаной. При коде:
WriteFile(hCom,Buffer,8,&b,NULL);
ReadFile (hCom,&i,1,&b,NULL);
ReadFile (hCom,&i,1,&b,NULL);
задержка возрастает примерно до 100 мс. :-(.
При увеличении скорости порта до 19200 скорость передачи данных сократилась незначительно: задержка между посылками возросла на то же самое время, на какое сократилось время передачи данных.
Да, забыл: СОМ3 - это порт для преобразователя USB-RS485. Т.е. с компутера данные реально отправляются на через USB порт на преобразователь, и далее по линии RS485. Данные снимались осциллографом на преобразователе со стороны RS485, но преобразователь тут точно не при чем, он был испытан на самодельном устройстве - USB передатчике, никаких левых задержек не наблюдалось.
Кто знает в чем дело - помогите, плз. Кто не знает - может выдвигать версии, все будет внимательно рассмотрено, проверено.

[TsAN]

AKK, если хотите избежать таких вот лишних задержек - при передаче/приеме информации работайте с портами В/В (конкретно - с регистрами этого COM-порта) напрямую из своей программы, в обход драйверов и прочих наворотов ОС. При этом все возможные задержки будут под Вашим контролем.
Хотя м не все ОС это допускают, но, тем не менее, такая вот работа - наиболее кардинальное решение.
В ОС наподобие Windows пожно попробовать поиграть приоритетами заданий, хотя это будет и не столь эффективно.

Удачи!

добавлено
И лучше для наких целей использовать аппаратный COM-порт, ибо USB ориентирована прежде всего на обслуживание многих устройств по одному каналу. Возможно, уже одно это позволит получить нужные Вам параметры.

[AKK]

AKK, если хотите избежать таких вот лишних задержек - при передаче/приеме информации работайте с портами В/В (конкретно - с регистрами этого COM-порта) напрямую из своей программы, в обход драйверов и прочих наворотов ОС. При этом все возможные задержки будут под Вашим контролем.

К сожалению я не настолько знаю програмирование под Win XP, чтобы работать напрямую с виртуальным СОМ портом или напрямую с USB, может подскажите в каком направлении надо начинать двигаться?

[TsAN]

я не настолько знаю програмирование под Win XP, чтобы работать напрямую с виртуальным СОМ портом или напрямую с USB, может подскажите в каком направлении надо начинать двигаться?

Вообще-то в ОС типа NT для этого непосредственно взаимодействие с железом надо разрабатывать как драйвер, что само по себе требует значительного объема начальных знаний как в области структуры ОС, так и протокола работы железа. Поскольку драйвер Ваш - то и задержки под Вашим полным контролем, да и всю программу Вы полностью можете оформить как драйвер, хотя выигрыш от этого чисто теоретический: переключение на драйвер и обратно может выполняться достаточно быстро - за несколько машинных инструкций.
В эпоху NT4 был какой-то драйвер - названия, к сожалению, сразу вот так вспомнить не могу - который позволял работать напрямую с портами - так, как это было бы в DOS'е. Но, скорее всего, с виртуальными портами это работать не будет.
В данном случае, IMHO, резонно обратить внимание на совет ув. Tech - по крайней мере, в данном случае можно сделать, что ОС не будет пытаться оптимизировать обмен путем кэширования, ибо кэширование хорошо при больших объемах перекачимваемой информации. Плюс посмотреть, чтобы на USB при этом ничего не висело - по крайней мере, пока не будет получен положительный результат. Торможение при работе с FDD, которое отметил Tech, позникает по причине того, что, поскольку в FDD нет буферной памяти, то отложить обмен информацией с ним невозможно (точнее, при откладывание вознивает задержка на время оборота диска). Поэтому и такие процессы тоже надо исключить.

Удачи!