Точность измерения временных интервалов для UART в windows
Страницы:
<
1
2
3
>
vertal © (2006-12-24 17:20:00)
По com-порту отправляю сообщение (WriteFile). Жду завершения
его отправки через FlushFileBuffers. Пытаюсь принять ответ,
состоящий из символов. Признаком конца сообщения-ответа служит
отсутствие прибытия нового символа после предыдущего в
течение более 4 милисекунд. Максимальная длина ответа - 256
символов. Осуществляется это все как:
PurgeComm(fPort, PURGE_RXCLEAR);
OpResult = WriteFile(fPort, Msg, cnt, &Garbage,
NULL);
FlushFileBuffers(fPort);
OpResult = ReadFile(fPort, OutBuf, 257,
&ActualRead, NULL);
Для того, чтобы после 4 милисекунд отсутствия символов на
линнии ReadFile вернула то, что было прочитано, предварительно
вызываю SetCommTimeouts, со значением 4 в
ReadIntervalTimeout. Проблема в том, что при таких условиях
_иногда_ (через раз примерно) прием сообщения-ответа прекращался на
середине. То есть я предполагаю, что это из-за неточности измерения
таких промежутков времени windows или стандартными драйверами.
После установки ReadIntervalTimeout в значение 16 (8 не помогло)
сбои исчезли. Сталкивался ли кто-нибудь с подобным? Или что-то не
так в приведенном коде?
RayGun (2007-01-02 12:05:00) [41]
16 мс - квант времени Windows. С помощью SetCommTimeouts
установить значение таймаута меньше 16 мс не получиться, Windows
может на это время отобрать управление у твоего процесса. Можно
попробовать работать с com-портом в асинхронном режиме (overlapped)
и использовать CreateWaitableTimer (вроде бы обеспечивает бОльшую
точность), WaitForMultipleObjects.
Страницы:
<
1
2
3
>
Наверх 
ЧАТ |
Орешник |
|
