Связь с последовательным портом: последовательный порт опроса против использования последовательного порта. Событие DataReceived

Я просто просматриваю код, который я написал для связи с последовательным портом в С# на CF2.0. Я не использую событие DataReceived, так как оно не является надежным. MSDN заявляет, что:

Событие DataReceived не является подавать на каждый байт получено. Использовать свойство BytesToRead определить, сколько данных осталось читать в буфере.

Я просматриваю порт с помощью read() и имеет делегат, который обрабатывает данные при чтении. Я также где-то читал, что "опрос плохой" (никаких объяснений не приводится).

Любые идеи, почему опрос может быть плохим? кроме обычных предупреждений о потоке - у меня есть отдельный поток (фоновый поток), который опросает порт, поток выходит после чтения данных, все проверяется и работает хорошо.

Ответ 1

Как я читал это, вы можете получить одно событие для нескольких байтов, а не одно событие за байт. Я бы все же ожидал получить событие, когда данные будут готовы, и не иметь "пропустить" некоторые байты целиком.

Я всегда использовал это событие и не имел никаких проблем с ним.

Ответ 2

Традиционная мудрость гласит, что "опрос является плохим", потому что он часто заканчивается процессом, связанным с процессором. Если вместо этого используется блокировка ввода-вывода, тогда CPU доступен для других процессов до тех пор, пока не произойдет событие.

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

Я вообще не использовал последовательные порты из С#, но я собираюсь помешать предположить, что документация означала

Событие DataReceived не гарантируется для каждого полученного байта. использование свойство BytesToRead, чтобы определить, сколько данных осталось читать в буфере.

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

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

Ответ 3

Я уверен, что базовый код драйвера последовательного порта управляется прерыванием даже при использовании блокирующего вызова Read.