Не поможете ли разобраться с параметром функции API SetCommTimeouts при чтении из RS232?
У неё пять параметров:
ReadByte
ReadMult
ReadTotal
WriteMult
Write Total
Непонятно действие первого параметра. Все остальные работают так, как и описано в API – ждут с домножением на число запрошенных байт или, соответственно, добавляют общую задержку.
Не могу понять как работает первый параметр (ReadByte). Если  все параметры 0, то ожидание бесконечно. Если первый параметр имеет любое значение, кроме MAXDWORD, то ожидание бесконечно. При MAXDWORD – мгновенный возврат из API.
Как пользоваться этим параметром?

На скоростях до 9600 программа работает нормально.
На скорости 115200 - раз в 10 - 15 минут виснет, причём внутри API, да так, что только Program Reset можно останоовить.

> JohnKorsh   (14.05.12 13:18)

Ты неверно перечислил имена параметров.

 DWORD ReadIntervalTimeout;
 DWORD ReadTotalTimeoutMultiplier;
 DWORD ReadTotalTimeoutConstant;
 DWORD WriteTotalTimeoutMultiplier;
 DWORD WriteTotalTimeoutConstant;

Если речь о ReadIntervalTimeout, то это максимальный интервал времени в миллисекундах между "прибытием" двух байт. Если интервал времени превышен, то функция немедленно завершается и в буфере возвращаются все принятые байты (если они были приняты).


> Если  все параметры 0, то ожидание бесконечно.


Абсолютно верно, так и должно быть

Если
ReadTotalTimeoutMultiplier=0 и  ReadTotalTimeoutConstant=0 и
ReadIntervalTimeout=MAXDWORD, то мгновенный возврат из API - так и должно быть, и если в буфере были приняты байты, то они и вернутся в буфере.

А если  ReadTotalTimeoutMultiplier=0 и  ReadTotalTimeoutConstant=0 и
ReadIntervalTimeout <> MAXDWORD и  ReadIntervalTimeout <> 0, то
операция чтения будет висеть вечно , если не будет получено ни одного байта(так и должно быть). Только после получения первого байта, будет запущен механизм вычисления тайм-аута между двумя байтами.


> На скоростях до 9600 программа работает нормально.
> На скорости 115200 - раз в 10 - 15 минут виснет, причём
> внутри API, да так, что только Program Reset можно останоовить.
>


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

И еще об обработке ошибок. Прочитай обязательно о ClearCommError.

Спасибо.

> Не поможете ли разобраться с параметром функции API SetCommTimeouts
> при чтении из RS232?


Конечно, знание API похвально, однако при реальной работе с COM-портами лучше использовать готовые, надежные, проверенные годами компоненты. Имхо, самый лучший (заодно и бесплатный):
http://sourceforge.net/projects/comport/

> Конечно, знание API похвально, однако при реальной работе
> с COM-портами лучше использовать готовые, надежные, проверенные
> годами компоненты.

Ну наконец-то кто-то высказал эту "крамольную" мысль на ДМ. (Которую, кстати я полностью поддерживаю ещё и по другой причине).
А автору очень советую прочитать эту книгу http://rouse.drkb.ru/books.php#agurov_com

> Конечно, знание API похвально, однако при реальной работе
> с COM-портами лучше использовать готовые, надежные, проверенные
> годами компоненты. Имхо, самый лучший (заодно и бесплатный):
>
> http://sourceforge.net/projects/comport/


А пофиксили ли в этом компоненте не вызывание OnError при ошибке переполнения буфера Rx? ;)

> Конечно, знание API похвально, однако при реальной работе
> с COM-портами лучше использовать готовые, надежные, проверенные
> годами компоненты.


Он в потоках работает? WaitCommMask не глючит у него?

> tesseract ©   (27.06.12 10:59) [7]

Тебе то он зачем?

> Он в потоках работает? WaitCommMask не глючит у него?


Проверял, в исходниках все грамотно сделано, на высоком уровне, замечаний нет.
В потоках работает, хотя по умолчанию работа производится в основном потоке, что также весьма грамотно (в отличии от дот-нетовского SerialPort)
С чего должен глючить WaitCommMask? Помню, глючило оно в старых версиях APRO из-за ожидания недокументированных событий (некий RING_TE), но потом это дело исправили. Разумеется, если драйвер COM-порта не умеет вызывать SetEvent (попадаются и такие), то CPort здесь бессилен (в APRO имеется обработка подобных ситуаций, но она ужасна).

> С чего должен глючить WaitCommMask? Помню, глючило оно в
> старых версиях APRO из-за ожидания недокументированных событий
> (некий RING_TE), но потом это дело исправили.

?