Comunicación de puerto serie: sondeo del puerto serie frente al uso del puerto serie Evento DataReceived

Question

Solo estoy revisando un código que escribí para comunicarme con el puerto serie en C # en CF2.0. No estoy usando el evento DataReceived ya que no es confiable. MSDN declara que:

  

El evento DataReceived no es   garantizado para ser elevado por cada byte   recibido. Use la propiedad BytesToRead   para determinar cuántos datos quedan para   ser leído en el búfer.

Encuesta 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 dan explicaciones).

¿Alguna idea de por qué las encuestas pueden ser malas? aparte de las precauciones de subprocesamiento habituales: tengo un subproceso separado (subproceso de fondo) que sondea el puerto, el subproceso se cierra después de leer los datos, todos se prueban y funcionan bien.

Answer 1

La forma en que lo leí, podría obtener un evento para varios bytes, en lugar de un evento por byte. Todavía esperaría obtener un evento cuando los datos estén listos, y no tenerlo '' 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 "las encuestas son malas" porque a menudo termina siendo un proceso vinculado a la CPU. Si en su lugar se usa el bloqueo de E / S, entonces la CPU está disponible para otros procesos hasta que ocurra el evento.

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

No he usado puertos serie de C # en absoluto, pero voy a arriesgarme a adivinar qué significaba la documentación

  

No se garantiza que el evento DataReceived se genere por cada byte recibido. Utilizar   la propiedad BytesToRead para determinar cuántos datos quedan por leer en el búfer.

es que no puedes esperar obtener un evento por personaje. 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 podría ser la mejor respuesta en general. No está sondeando per se ya que el hilo está bloqueado hasta que lleguen los caracteres. Es posible que deba 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 en trozos de tamaño fijo.

Answer 3

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