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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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