wpf - studio - ¿Qué ocasiona que se desate el evento DataReceived de la clase.NET SerialPort?
visual studio system io ports (2)
DataReceived puede disparar en cualquier momento que uno o más bytes estén listos para leer. Exactamente cuando se dispara depende del sistema operativo y los controladores, y también habrá un pequeño retraso entre los datos que se reciben y el evento que se activa en .NET.
No debe confiar en el tiempo de los eventos DataReceived para el flujo de control.
En cambio, analice el protocolo subyacente y, si no ha recibido un mensaje completo, espere más. Si recibes más de un mensaje, asegúrate de evitar que los elementos sobrantes analicen el primer mensaje porque serán el comienzo del siguiente mensaje.
Entiendo por los documentos de MSDN que el evento DataReceived no se activará necesariamente una vez por byte.
Pero, ¿alguien sabe cuál es exactamente el mecanismo que causa el evento para disparar?
¿El recibo de cada byte reinicia un temporizador que tiene que alcanzar, digamos 10 ms entre bytes, antes de que el evento se desactive?
Lo pregunto porque estoy tratando de escribir una aplicación que lea datos XML provenientes de un puerto serie.
Debido a que mi computadora portátil no tiene puertos serie, utilizo un emulador de puerto serial virtual. (Lo sé, lo sé, no puedo hacer nada al respecto).
Cuando paso los datos a través del puerto emulado a mi aplicación, el evento se dispara una vez por cada registro XML (alrededor de 1500 bytes). Perfecto. Pero cuando un colega en otra oficina lo intenta con dos computadoras conectadas por un cable real, el evento DataReceived se dispara repetidamente, después de cada 10 bytes de XML, lo que arroja totalmente la aplicación.
Como Mark Byers señaló, esto depende del sistema operativo y los controladores. En el nivel más bajo, un chip estándar RS232 (por mi vida, no puedo recordar la designación de uno que todos copiaron para hacer el ''estándar'') disparará una interrupción cuando tenga datos en su registro entrante. El ''extremo inferior'' del controlador tiene que obtener esos datos (que podrían ser cualquier cantidad hasta el tamaño del búfer del chip), y almacenarlos en el búfer del controlador e indicarle al sistema operativo que tiene datos. Es en este punto que el .NET Framework puede comenzar a descubrir que los datos están disponibles. Dependiendo de cuándo el sistema operativo señala la aplicación que abrió el puerto serie (que es una operación de nivel de sistema operativo y proporciona el enlace "real" desde .NET Framework a la implementación del nivel de OS / controlador), literalmente podría haber cualquier cantidad de datos > 1 byte en el búfer, porque el extremo inferior del controlador podría haber cargado más datos mientras tanto. Mi apuesta es que en su sistema, el controlador proporciona un gran buffer, y solo señaliza después de una pausa significativa en la secuencia de datos. El sistema de tu colega, por otro lado, señala con mucha más frecuencia. Una vez más, el consejo de Mark Byer para analizar el protocolo es perfecto. Implementé un sistema similar a través de sockets TCP, y la única forma de manejar la situación es almacenar los datos hasta que tenga un mensaje de protocolo completo, luego entregar el mensaje completo a la aplicación.