Оптим. организация асинхр. чтения COM-порта в отельном потоке

← →
Cyrax © (2006-11-21 12:29) [0]

Рассматриваю следующий фрагмент кода:
procedure TReadThread.Execute; var ComStat: TComStat; dwMask, dwError: DWORD; OverRead: TOverlapped; Buf: array[0..$FF] of Byte; dwRead: DWORD; begin OverRead.hEvent := CreateEvent(nil, True, False, nil); if OverRead.hEvent = Null then raise Exception.Create("Error creating read event"); FreeOnTerminate := True; while not Terminated do begin if not WaitCommEvent(hPort, dwMask, @OverRead) then begin if GetLastError = ERROR_IO_PENDING then WaitForSingleObject(OverRead.hEvent, INFINITE) else raise Exception.Create("Error waiting port event"); end; if not ClearCommError(hPort, dwError, @ComStat) then raise Exception.Create("Error clearing port"); dwRead := ComStat.cbInQue; if dwRead > 0 then begin if not ReadFile(hPort, Buf, dwRead, dwRead, @OverRead) then raise Exception.Create("Error reading port"); // В Buf находятся прочитанные байты // Далее идет обработка принятых байтов end; end; {while} end;
1. Не совсем ясен выделенный фрагмент. Функция WaitCommEvent инициирует процесс слежки за возникновением событий, отслеживаемых портом. После выполнения этой функции объект hEvent структуры OverRead будет установлен в сигнальное сотояние, если произойдёт какое-либо событие, отслеживаемое портом. Далее мы ждём функцией WaitForSingleObject(OverRead.hEvent, INFINITE), пока объект OverRead.hEvent не будет установлен в сигнальное сотояние. Нам здесь нужно ждать до тех пор, пока не придёт первый символ (во входной буфер COM-порта). Но объект Event может быть установлен в сигнальное сотояние при любом событии, отслеживаемом портом.

Допустим, в этом фрагменте кода подразумевается, что порт отслеживает только событие прихода во входной буфер первого символа (т.е. установили только флаг RXChar функцией SetCommEvent). Тогда всё сработает корректно. Но если порт отслеживает несколько событий ? - следовало бы определить тип события, которое установило hEvent в сигнальное сотояние. И если это не приход символа, то снова вызывать функцию WaitCommEvent, затем WaitForSingleObject, пока не возникнет событие прихода симола.
Но как определить тип события, ведь в структуре OverRead (типа Overlapped) нет полей с информацией о типе произошедшего события, а данные по указателю dwMask не будут определять тип произошедшего события, т.к. функция WaitCommEvent завершится до наступления события (т.е. параметр wdMask функции WaitCommEvent при асинхронных операциях бесполезен) ?

2. Функция ClearCommError в данном фрагменте кода используется только для того, чтобы получить число символов во входном буфере (cbInQue) ?
Или здесь обязателен сброс признака ошибки (т.е. что будет, если ошибку не сбросить) ?

3. Может ли функция WaitCommEvent в данном фрагменте вернуть 0 (теоретически), в коде этот случай не рассматривается...
Т.е. может ли произойти событие в ходе выполнения этой функции (после сброса hEvent"а функцией) ?

4. Можно ли получить число символов во входном буфере без использования функции ClearCommError ?

← →
Игорь Шевченко © (2006-11-21 13:29) [1]

Не сокращ.

← →
Evgeny V © (2006-11-21 15:02) [2]

1 Тип события в dwMask в твоем случае после WaitForSingleObject.
2 Количество байт и получение/сброс ошибки. Если не вызывать, и была ошибка, то при настройке порта на прерывание работы по ошибке дальнейшие операции чтения или записи будут прерваны.
3 Да
4 Не знаю другого способа (может и есть) - этот стандартный.

MSDN или хелп в дельфи по WinSDK - хорошо описаны функции, о которых ты спрашиваешь.

← →
Cyrax © (2006-11-21 22:55) [3]

Игорь Шевченко © (21.11.06 13:29) [1]
Не сокращ.

Не думаю, что "Оптимальная организация асинхронного чтения COM-порта в отдельном" было бы понятнее...
А вообще, 66 символов (две "шестёрки") вызывают нездоровые ассоциации (мягко говоря)...

Evgeny V © (21.11.06 15:02) [2]
2 Количество байт и получение/сброс ошибки. Если не вызывать, и была ошибка, то при настройке порта на прерывание работы по ошибке дальнейшие операции чтения или записи будут прерваны.

Ошибка может произойти только на WaitCommEvent. Но эта ошибка уже обрабатывается: raise Exception.Create("Error waiting port event");
(GetLastError() != ERROR_IO_PENDING)

MSDN или хелп в дельфи по WinSDK - хорошо описаны функции, о которых ты спрашиваешь.

Здесь же речь идёт не о работе конкретных функций, а об организации их взаимодействия...

WinSDK

Ставится отдельно или поставляется вместе с Delhpi ?

← →
Германн © (2006-11-22 02:08) [4]

А я лично считаю, что сабж
> Оптимальная организация асинхронного чтения COM-порта в
> отдельном потоке

- есть "бред сивой кобылы в тёмную мартовскую ночь"! Примите и прочь!

> Cyrax © (21.11.06 22:55) [3]

> Ошибка может произойти только на WaitCommEvent. Но эта ошибка уже > обрабатывается: raise Exception.Create("Error waiting port event");
> (GetLastError() != ERROR_IO_PENDING)

речь идет об аппаратной ошибке порта, это не та ошибка, которую ловят GetLastError

> Здесь же речь идёт не о работе конкретных функций, а об
> организации их взаимодействия...

если бы хелп глянули только на функции ClearCommError и WaitCommEvent, то вопросы 2 и 3 точно бы не воникли.

> WinSDK
>
> Ставится отдельно или поставляется вместе с Delhpi ?

C дельфи, в среде меню Неlp пункт Windows SDK

> Т.е. может ли произойти событие в ходе выполнения этой функции
> (после сброса hEvent"а функцией) ?

Ошибка поизойдёт когда ты поток на пустой порт повесишь - он у тебя из-за негораниченного времени ожидания повиснет.

Используй WaitForMultipleObject + доп объект для ожидания.

Оптим. организация асинхр. чтения COM-порта в отельном потоке Найти похожие ветки