Задержки для СОМ порта, програмирование на С++ 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 передатчике, никаких левых задержек не наблюдалось.
Кто знает в чем дело - помогите, плз. Кто не знает - может выдвигать версии, все будет внимательно рассмотрено, проверено.

[Krom]

Вот именно. Не стоит забывать, что форточки - система многозадачна. Очччень много геморроя с этим бывает, особенно если требуется переключать направление передачи в преобразователе RS485. То есть виндовая прога передала пакет, переключает на прием, а вот время, через которое выполнится реально это переключение - плавает в зависимости от мощности компа, числа выполняемых задач и проч. Такие навороты приходится в протоколы вводить - мама не горюй.

Для справки - если не ошибаюсь, то стандартное время переключения между задачами в виндах что-то около 5 мс. Вполне реально, что эти 30 мс отбирет ядро или висящие в фоне задачи.

Тут или приоритет задачи нужно повышать, или, если число циклов передача-прием за один раз ограничено и не очень большое, то сделать критической секцией.

[fantasy]

Вот именно. Не стоит забывать, что форточки - система многозадачна. Очччень много геморроя с этим бывает, особенно если требуется переключать направление передачи в преобразователе RS485. То есть виндовая прога передала пакет, переключает на прием, а вот время, через которое выполнится реально это переключение - плавает в зависимости от мощности компа, числа выполняемых задач и проч. Такие навороты приходится в протоколы вводить - мама не горюй.

Для справки - если не ошибаюсь, то стандартное время переключения между задачами в виндах что-то около 5 мс. Вполне реально, что эти 30 мс отбирет ядро или висящие в фоне задачи.

Тут или приоритет задачи нужно повышать, или, если число циклов передача-прием за один раз ограничено и не очень большое, то сделать критической секцией.

Влезу немного... так сказать из собственного опыта... <_<

1) в windows передача и приём по COM-портам работают "параллельно", причём приём идёт во внутренний буфер самой ОС, а не Вашей программы;
2) скорость обмена ОС с девайсом почти не зависит от приоритета задачи. Можно создать даже отдельный поток с предельным приоритетом - единственное что получите, так это полную загрузку CPU и "зависание" остальных задач...
3) реально скорость обмена можно увеличить только увеличивая длину пакета (легко можно "закинуть" в COM-порт пару-тройку килобайт и смотреть как они "красиво" и почти без остановки передаются девайсу, а потом... пауза до следующего пакета). Это точно справедливо при использовании WriteFile...

Отсюда вывод: нужна высокая скорость передачи по COM-порту - увеличивайте длину пакетов. Из собственного опыта: собрал свой девайс и для него написал оболочку, которая гоняла данные пакетами по 16 байт. Скорость работы мягко говоря была никакая... увеличил длину пакетов до 32 байт, время обмена сократилось почти в 2 раза...

Если длину пакетов невозможно увеличить (например, при загрузке алгоритмов программирования в TMS320LF240xA), то можно "схитрить" следующим способом: отправить ВСЕ данные (т.е. записать в "файл"), а потом прочитать ВЕСЬ результат из "файла". Сравнить результат "постфактум" и на основе этого принимать дальнейшие решения. Может немного грубо, но ОС Windows не является системой реального времени со всеми вытекающими...

Если же Вам нужна жёсткая синхронизация отправляемых-принимаемых данных, то либо смиритесь с задержками, либо пишите свой драйвер...

З.Ы.: никто не пробовали писать программу, которая ведёт обмен по COM-порту из под терминальной сессии в Win2k3? Врагу не пожелаю разбираться, сколько там "подводных" засад!