¿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?

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?

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.

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.

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.

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.

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!