Comunicación de puerto serie: puerto serie de sondeo frente a puerto serie Evento DataReceived

Question

Estoy revisando un código que escribí para comunicarme con el puerto serie en C# en CF2.0. No estoy utilizando el evento DataReceived porque no es confiable. MSDN states that:

El evento DataReceived no es gauranteed ser levantado por cada byte recibido. Use la propiedad BytesToRead para determinar la cantidad de datos que se deja leer en el búfer.

Inspecciono el puerto con read() y tengo un delegado que procesa los datos cuando se leen. También leí en alguna parte que "las encuestas son malas" (no se da ninguna explicación).

¿Alguna idea de por qué las encuestas pueden ser malas? además de las precauciones de enhebrado usuales, tengo un hilo separado (hilo de fondo) que sondea el puerto, el hilo se sale después de que se leen los datos, todo probado y funciona bien.

Answer 1

La forma en que leo eso, puede obtener un evento por varios bytes, en lugar de un evento por byte. Todavía esperaría obtener un evento cuando los datos estén listos, y no tener que "omitir" algunos bytes por completo.

Siempre he usado este evento y no he tenido ningún problema con él.

Answer 2

La sabiduría convencional dice que "el sondeo es malo" porque a menudo termina siendo un proceso vinculado a la CPU. Si se usa el bloqueo de E/S, la CPU estará disponible para otros procesos hasta que ocurra el evento.

Dicho esto, generalmente es posible configurar las cosas de modo que una encuesta espere un tiempo de espera (corto) antes de volver cuando no haya caracteres disponibles. Si se elige un tiempo de espera adecuado, entonces su bucle de sondeo simple usa mucho menos tiempo de CPU, y otros procesos también se ejecutan.

No he utilizado puertos serie desde C# en absoluto, pero voy a aventurar una respuesta que lo que la documentación entiende por

El evento DataReceived no está garantizada para ser levantado por cada byte recibido. Use la propiedad BytesToRead para determinar la cantidad de datos que quedan por leer en el búfer.

es que no puede esperar obtener un evento por carácter. En algunas circunstancias, podría entregar el evento con más de un personaje disponible. Simplemente recupere todos los caracteres disponibles en su controlador de eventos, y todo estará bien.

Editar: Hacer una llamada de bloqueo en un hilo lector puede ser la mejor respuesta en general. No es una votación en sí, ya que el hilo está bloqueado hasta que llegan los caracteres. Es posible que necesite ajustar los tamaños del búfer y algunas de las configuraciones del puerto serie si necesita procesar los datos a medida que llegan en lugar de hacerlo en fragmentos de tamaño fijo.

Answer 3

Estoy bastante seguro de que el código del controlador del puerto serie subyacente es impulsado por interrupciones, incluso cuando se usa la llamada de bloqueo de lectura.