¿Qué puedo hacer para disminuir la latencia de estos puertos serie que están conectados a una PC a través de un adaptador de serie a USB?

8

Creo que descubrí accidentalmente una necesidad en mi vida de sistemas embebidos. ¡Lo cual es genial! Y un poco de miedo. Y necesito ayuda.

Antecedentes : me contrataron para crear una aplicación GUI que toma escaneos de dos SICK LMS-291 y los integra con un GPS de precisión de menos de una pulgada, para que sepa dónde ocurrió cada escaneo. Como ingenuo programador web que soy, entendí que el tiempo sería importante, ¡pero no me di cuenta de que también sería difícil! Si no sabe cuándo se produjo cada punto GPS y cada escaneo, no puede averiguar dónde ocurren los escaneos. Ups

Habían especificado Windows 7 como plataforma, así como compraron una caja SeaLevel RS422 a USB para conectar los sensores y el GPS, y en poco tiempo descubrí mi locura. En algún lugar entre los sensores y mi programa de computadora, algo impedía que los escaneos llegaran a tiempo. El LMS escupe 75 escaneos por segundo, o a 13.32 ms / escaneo. Mi programa no los recibe de manera oportuna. Los recibe cada 100 milésimas de segundo, en grupos de 7 u 8 o 10 o algo así. Además, a veces no aparecen suficientes escaneos, o están destrozados. O este adaptador SeaPort solo envía diez veces por segundo (¿es posible? No sé cómo funciona el USB) o Windows no está comprobando el búfer (debe haber un búfer en algún lugar, ¿verdad?) Con la suficiente frecuencia.

Actualidad : Esto lleva a algunas imprecisiones con las que el cliente está básicamente de acuerdo. Sin embargo, no lo soy, y dado que tengo la oportunidad de hacer un trabajo similar para el cliente (¡integrando más entradas de sensores!), Me gustaría descubrir cómo hacerlo correctamente, por ejemplo, dada la precisión del GPS , podrá brindar garantías sobre la precisión y exactitud de las ubicaciones de escaneo.

¿Cómo se ve eso? Necesito una IU y poder verificar la entrada de estos tres dispositivos cada 13,32 milisegundos. Si usara FreeRTOS con, digamos, Nano-X para la GUI, ejecute en una computadora portátil que proporcionan, ¿eso sonaría como una solución sensata? ¿Es posible que el adaptador RS-422 a USB esté causando estos retrasos, y el uso de Windows en realidad está bien para este propósito?

canisrufus
fuente
2
¿A quién tuviste que asesinar para obtener esos telémetros láser, y tenía un amigo que también podría tener algunos?
Connor Wolf
@ConnorWolf Hah! Desearía tenerlos. Es para ag (determinar el volumen de cultivo), por lo que estaban dispuestos a pagar por el hardware (los tractores pueden costar $ 75k ...), pero no estaban dispuestos a pagar por el talento de programación.
canisrufus
No sé el tamaño del búfer en Windows, pero ciertamente quieres comprobarlo. En Linux, estos búferes tienen un tamaño de 4 KB y, según los datos que envíe y las llamadas del sistema que utilice, un programa solo puede recibir fragmentos de datos de 4 KB. Si ese es el problema, desea verificar cuidadosamente qué llamadas al sistema usa para leer de los buffers.
jippie
1
Le sugiero que busque obtener una conexión en serie directa: puede obtener tarjetas de puerto en serie para PC y portátiles (también tenga en cuenta que la mayoría de los hardbooks de Panasonic todavía tienen puertos en serie de serie). Esto evitará cualquier problema de almacenamiento en búfer en la interfaz serial USB. Windows 7 tiene suficiente capacidad en tiempo real, por lo que probablemente no necesite alejarse de eso.
Preocupado por
Solo un comentario: el título es divertido, pero no ayuda mucho a descifrar el contenido de la pregunta: ¿podría aclararlo?
clabacchio

Respuestas:

6

El problema es casi seguro en el almacenamiento en búfer USB relacionado con el convertidor USB-RS422. USB tiene latencia variable y bastante alta.

La solución más sencilla sería una mejor interfaz RS422, idealmente basada en PCI / PCI-e. Eso resolvería los problemas de latencia.

También es posible que pueda modificar la velocidad de sondeo de USB, aunque esto depende bastante del sistema operativo host (¿en qué plataforma se encuentra?).


Por lo que vale, busqué en el sitio web del sistema de nivel del mar, y está MASIVAMENTE infectado con mentiras de marketing. Literalmente gastan como 10 páginas y varios libros blancos en decir "usamos un concentrador USB internamente, en lugar de hacer multiplexación MCU".

¡Hola SeaLevel! ¡Eso es lo que hace también la interfaz USB serie de 4 puertos de $ 50 que compré en e-bay de China! ¡No eres especial, incluso si escribes media docena de libros blancos insípidos tratando de hacer que suene como lo eres!

¿Has intentado forzar esas cosas a usar controladores FTDI? Pondría dinero en eso, solo están usando FTDI FT232 estándar o similar. ¿Puedes abrir el cuadro en uno de ellos y tomar fotos?


Si realmente desea hacer girar su propio hardware, por diversión o por oportunidades educativas, le sugiero encarecidamente que no intente hacer todo en el hardware. Dado que solo necesita correlacionar las tres señales en el tiempo, todo lo que realmente necesita es algo que pueda escuchar en tres líneas seriales (dos RS422, una RS232 (el GPS)), sellar con tiempo los datos y enviarlos a la computadora principal .

Una vez que los datos tienen una marca de tiempo, puede tener toda la latencia de búfer que desee, ya que siempre puede mirar las marcas de tiempo.

Siendo realistas, si no tienes una base en hardware, diseñar algo con suficiente contracción para dibujar una buena GUI es toda una tarea.

Personalmente, probablemente arrojaría una MCU ARM bastante gruesa al problema del almacenamiento en búfer, y terminaría con eso. A pesar del hecho de que es un Arduino, el Arduino Due tiene mucha SRAM y es más que lo suficientemente rápido para lo que necesita (y hay mucho soporte, lo que siempre es bueno).
Alternativamente, la serie STM32 tiene un rendimiento similar, y está más destinada a usuarios "avanzados" (lea, hay menos ejemplos o no hay referencias). ST hace muchos tableros de evaluación bastante buenos y extremadamente económicos también.

Con el Due, obtienes un puerto USB nativo, para el cual puedes rodar tu propio controlador CDC si lo deseas. Algunas de las placas STM32 también tienen USB nativo.

Connor Wolf
fuente
Con respecto al sistema operativo: estoy usando Windows 7 en una tableta de núcleo único en este momento. También puedo usar una computadora portátil e instalar lo que quiera.
canisrufus
77
Dedicar un microcontrolador a correlacionar los datos y luego reenviarlo a un cuadro de Windows para su visualización es la forma en que yo también elegiría +1
JustJeff
1
La tarjeta que vincule probablemente funcionaría, aunque por cuán llena de mierda SeaLevel parece en otro lugar, no estoy seguro de confiar en ellos. Por lo que vale, que hacen mención de que la tarjeta PCI-e utiliza un 16C954quad hardware UART IC (presumiblemente hay dos de ellas en la tarjeta).
Connor Wolf
1
Realmente, creo que la única solución adecuada sería llamarlos y preguntarles si tienen problemas de latencia. ¡Puede haber cosas que se pueden ajustar en su controlador!
Connor Wolf
2
+1 en la solución STM32F4; La placa STM32F4-Discovery tiene un precio cómico bajo , tiene hasta 6 UART y un puerto USB OTG FS. Si no está familiarizado con el diseño embebido, le resultará bastante difícil poner el USB en funcionamiento; Es más sencillo conectarlo a través de un UART con un cable FTDI. Coocox IDE es gratuito, no tiene límites de tamaño de código y es compatible con la placa Discovery razonablemente bien.
markt
3

Si entiendo la pregunta, a lo que se reduce esto es a tomar mensajes de tiempo / lugar del GPS a través de una línea en serie, y correlacionar los mensajes de datos de rango recibidos en otras líneas en serie. Idealmente, los mensajes del buscador de rango tendrían su propia marca de tiempo, y si pudiera sincronizar todos los relojes, podría precisar la ubicación donde se tomó el rango interpolando la marca de tiempo de rango entre los dos mensajes gps con el sellos de tiempo coincidentes más cercanos. Pero, por supuesto, no tienes eso.

Se me ocurren un par de soluciones, en la línea de usar un microcontrolador para hacer la correlación de datos en tiempo real, y bombear la salida de eso al PPC para propósitos de visualización. Básicamente, el microcontrolador está ahí para lidiar con los problemas de tiempo apretado.

Entonces, para una solución más simple, todo lo que necesita es alguna forma de recopilar todos los mensajes de varias líneas seriales diferentes, y combinarlos en una sola secuencia, en el orden en que fueron recibidos, y transferirlos a la PC. Puede inferir que cualquier mensaje del buscador de rango entre dos mensajes GPS ocurrió en algún momento entre esos dos mensajes.

Por supuesto, esto le da un grado de incertidumbre, que depende de la frecuencia de los mensajes GPS. La desventaja es que a medida que aumenta la frecuencia de los mensajes GPS (para obtener una correlación más precisa), aumenta las demandas en el microcontrolador y las demandas en el enlace serie a la PC. En un extremo, el enlace en serie está saturado con mensajes GPS con un mensaje de alcance ocasional incluido. Obviamente, la mayoría de esos mensajes GPS no son necesarios. Sin embargo, la ventaja de esta solución es que el micro tiene muy poco que hacer, desde el punto de vista del software. Puede hacerlo todo en un simple ciclo de lenguaje ensamblador, no requiere sistema operativo.

Para una solución más compleja, puede formar un reloj local en el micro, y usar el GPS para sincronizar ese reloj, de modo que cuando reciba un mensaje de alcance, pueda obtener una marca de tiempo usando el reloj del micro. Usando un micro con una base de tiempo de cristal, probablemente podría sobrevivir con mensajes GPS de 1Hz y aún así obtener mucho mejor que los tiempos de precisión de milisegundos estampados en los mensajes de rango. Una persona competente en sistemas embebidos probablemente también podría lograr esto en ensamblador en un micro inferior, pero usted mencionó que recién está comenzando. Podrías mirar un micro más potente que puede ejecutar Linux, y probablemente encontrar una solución preexistente para sincronizar el reloj de Linux con el GPS.

JustJeff
fuente
Más fácil que construir un reloj en tiempo real en la MCU y sincronizarlo usando el GPS es simplemente usar cualquiera de los periféricos del temporizador / contador para medir el número de ciclos entre el mensaje GPS y el mensaje del telémetro, y agregar esa información en tiempo delta a El flujo de datos.
Ben Voigt
3

Lo que probablemente haría es multiplexar los datos en serie en un nuevo flujo de datos en serie a una velocidad más alta, con una intercalación estática. Luego alimente el flujo de datos a través de USB-UART a la computadora. De ese modo, sabría que el primer byte es del dispositivo 1, el segundo byte del dispositivo 2, el tercer byte del dispositivo 3 y en este caso un cuarto byte como CRC o número de secuencia. Agregue un par de bytes de inicio del marcador de cuadro para sincronizar en el flujo de datos, rellenando bytes si no hay datos disponibles y ya está. Es posible que no conozca el tiempo absoluto, pero sí sabe que el tiempo relativo entre los distintos fragmentos de datos.

jippie
fuente
1

También iría con un microcontrolador para recibir los datos de RS, sellarlo y enviarlo a la PC. No puede hacer ningún trabajo crítico de sincronización de E / S con una PC con Windows (excepto con una tarjeta de sonido, tal vez), porque el software y los controladores cambian todo el tiempo a medida que los controladores se actualizan a sus espaldas.

Pero lo primero que haría es obtener un analizador lógico USB, puede comprar uno por menos de USD100, tomar algunos mensajes del receptor GPS y verificar exactamente cuándo se recibe cada byte. Use esa información para probar / calcular exactamente qué tan precisa es la sincronización de los datos en primer lugar: por ejemplo, exactamente qué y cuándo transmite la caja GPS. Luego, puede determinar qué precisión se puede lograr y cuánto esfuerzo estaría dispuesto a hacer para alcanzar un cierto nivel de precisión.

ingrese la descripción de la imagen aquí

Arriba, una imagen de un analizador lógico USB (¿Saleae?).


[Editar] Jaja, usar la tarjeta de sonido podría ser una forma divertida de hacer que realmente funcione; puede conectar los datos UART a la entrada de la tarjeta de sonido (a través de algunas resistencias y condensadores) y escribir software para detectar cada borde en la transmisión en serie, ¡lo que le brinda una precisión de sincronización hermosa! Ok, realmente no estoy sugiriendo esto en serio, ¡solo por algunas risas!

PkP
fuente