[AKK 0]

Доброго всем времени суток.

При иннициализации порта:

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 передатчике, никаких левых задержек не наблюдалось.

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

[psL 0]

Попробуйте таймауты установить в ноль, или хотябы только ReadTotalTimeoutConstant.

 

http://www.citforum.ru/hardware/articles/comports/

[Old1 0]

Доброго всем времени суток.

При иннициализации порта:

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 передатчике, никаких левых задержек не наблюдалось.

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

<{POST_SNAPBACK}>

ИМХО 30 мс это может быть вполне нормально. На осциллографе ты измеряешь время между уходом пакета и приходом ответного пакета, но при этом сколько длится выполнение функций ReadFile и WriteFile не известно. На длительность выполнения этих функций могут влиять: количество задач, выполняемых в данный момент системой, быстродействие драйвера (а в твоем случае драйверов наверное несколько) и т.п. Кстати ф-ции ReadFile и WriteFile самые медленные функции. Есть функция прямого доступа к драйверу DeviceIoControl, она работает гораздо быстрее, попробуй использовать ее... Насколько критична задржка между получением данных от подключенного к PC устройва и отправкой ему ответа?

[Krom 0]

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

 

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

 

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

[AKK 0]

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

[fantasy 0]

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

 

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

 

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

<{POST_SNAPBACK}>

 

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

 

1) в windows передача и приём по COM-портам работают "параллельно", причём приём идёт во внутренний буфер самой ОС, а не Вашей программы;

2) скорость обмена ОС с девайсом почти не зависит от приоритета задачи. Можно создать даже отдельный поток с предельным приоритетом - единственное что получите, так это полную загрузку CPU и "зависание" остальных задач...

3) реально скорость обмена можно увеличить только увеличивая длину пакета (легко можно "закинуть" в COM-порт пару-тройку килобайт и смотреть как они "красиво" и почти без остановки передаются девайсу, а потом... пауза до следующего пакета). Это точно справедливо при использовании WriteFile...

 

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

 

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

 

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

 

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