
Tengo que hacer un código en C para detectar el tiempo entre caracteres dentro de una línea rs232 en Linux. El tiempo de detección entre caracteres podría ser de 1 ms. Así que necesito algo para marcar la hora muy rápidamente en los caracteres entrantes. Cuando digo muy rápido es menos de 1ms. El objetivo es detectar el final de un cuadro y el comienzo de un nuevo cuadro en la línea.
No pido una solución de codificación, solo quiero una ayuda inicial para saber qué camino debo tomar: ¿es posible hacer esto en Linux? ¿Tengo que modificar un controlador para llegar a este tipo de tiempo? O algo en el espacio del usuario puede hacerlo (no lo creo).
Respuesta1
¿Es un UART integrado o un dongle USB? Para el primero, modificaría la rutina de interrupción del controlador serie para almacenar los datos junto con una marca de tiempo, entregar los datos con la marca de tiempo al espacio del usuario y dejar que el espacio del usuario los ordene. Si bien Linux no es en tiempo real, espero que pueda responder a todas las interrupciones en menos de 1 ms, por lo que debería ser suficiente.
Para un dongle USB, usbmon
ya proporciona marcas de tiempo en microsegundos, por lo que supongo que debería poder usarse usbmon
junto con el controlador USB en serie normal y modificar el controlador USB en serie para que esas marcas de tiempo sean accesibles.
Respuesta2
Tengo que hacer un código en C para detectar el tiempo entre caracteres dentro de una línea rs232 en Linux...
Has publicado unproblema xy.
Quiero hacer eso porque un silencio de más de 1 ms significa el final de un cuadro y el comienzo de un nuevo cuadro.
(Por cierto, en comunicaciones serie asíncronas como RS-232, uso no calificado de"marco"es ambiguo, ya que cada personaje está enmarcado. Por ejemplo, cuando un UART informa un "error de encuadre", (posiblemente) se perdió un carácter. Es de suponer que en realidad te refieres a paquete o unidad de mensaje).
Su comentario adicional finalmente revela el problema X real que necesita solución.
Dado que el problema real es detectar lagunas entre mensajes, su pregunta original sobre Y no solo es difícil de implementar con precisión en el software, sino que ni siquiera es una solución viable al problema X.
Cualquier solución que implique la "medición" del intervalo de tiempo entre caracteres recibidos mediante software para detectar una brecha entre mensajes es una solución defectuosa. Este enfoque falla en el caso degenerado:
cuando llega el último carácter de un mensaje y si no hay más caracteres (por un tiempo), entonces ese último mensaje recibido esestancadoindefinidamente mientras el algoritmo espera el siguiente carácter (el primer byte del siguiente mensaje) para poder calcular la diferencia horaria.
Mientras no se reciba el "siguiente carácter", no se determina el "fin del mensaje" y el último mensaje válido está completo pero no procesado.
La solución adecuada es utilizar hardware que pueda medir cuándo se ha recibido o, mejor dicho, no se ha recibido un carácter. Algunos USART de Atmel tienen unTiempo de espera del receptorcaracterística para detectar la brecha entre mensajes.
Una posible solución de software requeriría un temporizador periódico (de alta resolución) que el controlador U(S)ART usaría para contar los intervalos de tiempo entre los caracteres recibidos. Al usar PIO en lugar de DMA, el controlador tendría que restablecer el recuento de intervalos a medida que se recibe cada carácter. Cuando el conteo excede un umbral (es decir, conteo * intervalo_tiempo > inter_message_gap_time), entonces el receptor ha estado en silencio demasiado tiempo, lo que indica un intervalo entre mensajes.