Я просто просматриваю код, который я написал для связи с последовательным портом в С# на CF2.0. Я не использую событие DataReceived, так как оно не является надежным. MSDN заявляет, что:
Событие DataReceived не является подавать на каждый байт получено. Использовать свойство BytesToRead определить, сколько данных осталось читать в буфере.
Я просматриваю порт с помощью read() и имеет делегат, который обрабатывает данные при чтении. Я также где-то читал, что "опрос плохой" (никаких объяснений не приводится).
Любые идеи, почему опрос может быть плохим? кроме обычных предупреждений о потоке - у меня есть отдельный поток (фоновый поток), который опросает порт, поток выходит после чтения данных, все проверяется и работает хорошо.
Как я читал это, вы можете получить одно событие для нескольких байтов, а не одно событие за байт. Я бы все же ожидал получить событие, когда данные будут готовы, и не иметь "пропустить" некоторые байты целиком.
Я всегда использовал это событие и не имел никаких проблем с ним.
Традиционная мудрость гласит, что "опрос является плохим", потому что он часто заканчивается процессом, связанным с процессором. Если вместо этого используется блокировка ввода-вывода, тогда CPU доступен для других процессов до тех пор, пока не произойдет событие.
Тем не менее, как правило, можно настроить вещи так, чтобы опрос ожидал (короткий) тайм-аут перед возвратом, когда нет доступных символов. Если выбран подходящий тайм-аут, то ваш простой цикл опроса использует значительно меньшее время процессора, а другие процессы также запускаются.
Я вообще не использовал последовательные порты из С#, но я собираюсь помешать предположить, что документация означала
Событие DataReceived не гарантируется для каждого полученного байта. использование свойство BytesToRead, чтобы определить, сколько данных осталось читать в буфере.
заключается в том, что вы не можете ожидать получить одно событие за символ. В некоторых случаях это может привести к событию с более чем одним символом. Просто загрузите все доступные символы в обработчике событий, и все будет хорошо.
Изменить: Выполнение блокирующего вызова в потоке чтения может быть лучшим ответом в целом. Это не опрос как таковой, поскольку поток блокируется до тех пор, пока персонажи не прибудут. Возможно, вам потребуется настроить размеры буфера и некоторые параметры последовательного порта, если вам нужно обработать данные по мере их поступления, а не в фиксированных размерах.
Я уверен, что базовый код драйвера последовательного порта управляется прерыванием даже при использовании блокирующего вызова Read.