¿Qué puedo hacer para reducir la latencia de estos puertos serie que están conectados a un PC mediante un adaptador de serie a USB?

Question

Creo que he descubierto accidentalmente una necesidad en mi vida para los sistemas embebidos. Lo cual es genial. Y un poco aterrador. Y necesito ayuda.

Antecedentes : Me contrataron para construir una aplicación GUI que toma escaneos de dos SICK LMS-291 y los integra con un GPS de precisión inferior a una pulgada, para que sepa dónde se ha producido cada exploración. Como programador web ingenuo que soy, entendí que la sincronización sería importante, ¡pero no me di cuenta de que también sería difícil! Si no sabes cuándo ocurrió cada punto GPS y cada escaneo, no puedes averiguar dónde ocurren los escaneos. Oops.

Habían especificado windows 7 como plataforma, así como comprado un 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 informático, algo impedía que los escaneos llegaran a tiempo. El LMS escupe 75 escaneos por segundo, es decir, a 13,32 m/escaneo. Mi programa no los recibe de manera oportuna. Los recibe cada 100 milisegundos más o menos, en grupos de 7 u 8 o 10 o algo así. Además, a veces no aparecen suficientes escaneos, o se estropean. O bien este adaptador SeaPort sólo envía diez veces por segundo (¿es posible? No sé cómo funciona el USB) o bien Windows no comprueba el búfer (debe haber un búfer en alguna parte, ¿no?) con suficiente frecuencia.

Actualidad : Esto lleva a algunas inexactitudes con las que el cliente está básicamente de acuerdo. Sin embargo, yo no lo estoy, y ya que tengo la oportunidad de hacer un trabajo similar para el cliente (¡integrando más entradas de sensores!), me gustaría averiguar cómo hacerlo bien, por ejemplo, dada la precisión del GPS, ser capaz de dar garantías sobre la precisión y exactitud de las ubicaciones de los escaneos.

¿Qué aspecto tiene eso? Necesito una interfaz de usuario, y ser capaz de comprobar la entrada de estos tres dispositivos cada 13,32 milisegundos. Si utilizo FreeRTOS con, digamos, Nano-X para la interfaz gráfica de usuario, ejecutado en un ordenador portátil que ellos proporcionan, ¿suena eso como una solución sana? ¿Es posible que el adaptador RS-422 a USB esté causando estos retrasos, y que el uso de Windows esté bien para este propósito?

Answer 1

El problema es casi ciertamente en el buffering USB relacionado con el convertidor USB-RS422. El USB tiene una latencia variable y bastante alta.

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

También puedes modificar la tasa de sondeo del USB, aunque esto depende bastante del sistema operativo anfitrión (¿en qué plataforma estás?).

---

Por si sirve de algo, he mirado en el sitio web de sealevel system, y está masivamente infectado de mierda de marketing. Literalmente pasan como 10 páginas y múltiples libros blancos en decir "usamos un hub USB internamente, en lugar de hacer MCU multiplexación".

¡Hey SeaLevel! Eso es lo que hace también la barata interfaz de 4 puertos USB-serial de 50 dólares que compré en e-bay en China. No eres especial, aunque escribas media docena de insulsos libros blancos tratando de hacer creer que lo eres.

¿Has intentado forzar esas cosas para que usen los drivers FTDI? Yo apostaría a que sólo utilizan el estándar FTDI FT232 o similar. ¿Puedes abrir la caja de uno de ellos y hacer fotos?

---

Si realmente quieres girar tu propio hardware, por diversión o por oportunidades educativas, te sugiero encarecidamente que no intentes hacerlo todo en el hardware. Ya que necesitas simplemente correlacionar en el tiempo las tres señales, todo lo que realmente necesita algo que pueda escuchar en tres líneas seriales (dos RS422, una RS232 (el GPS)), que marque el tiempo de los datos y los envíe al ordenador principal.

Una vez que los datos tienen un sello de tiempo, eres libre de tener toda la latencia del buffer que quieras, ya que siempre puedes mirar los sellos de tiempo.

Siendo realistas, si no tienes una base en hardware, diseñar algo con suficiente crujido para dibujar una bonita interfaz gráfica es toda una empresa.

Personalmente, yo probablemente lanzaría una MCU ARM bastante gruesa en el problema de la memoria intermedia, y terminaría con ella. A pesar del hecho de que es un Arduino, el Arduino Due tiene un montón de SRAM, y es más que lo suficientemente rápido para lo que necesita (y hay un montón de apoyo, que siempre es agradable).
Alternativamente, la serie STM32 tiene un rendimiento similar, y está más destinada a usuarios "avanzados" (léase, hay menos, o ningún ejemplo de referencia). ST hace un montón de bastante agradable, placas de evaluación extremadamente baratas también.

Con el Due, tienes un puerto USB nativo, para el que puedes desarrollar tu propio controlador CDC si quieres. Algunos de los las placas STM32 también tienen USB nativo.

Answer 2

Si entiendo la pregunta, esto se reduce a tomar los mensajes de tiempo/lugar del GPS a través de una línea serie, y correlacionar los mensajes de datos de alcance recibidos a través de otras líneas serie. Lo ideal sería que los mensajes del telémetro tuvieran su propia marca de tiempo, y si se pudieran sincronizar todos los relojes, se podría precisar la ubicación donde el rango se tomó interpolando la marca de tiempo del rango entre los dos mensajes gps con las marcas de tiempo más cercanas. Pero por supuesto, no tienes eso.

Se me ocurren un par de soluciones, todas en la línea de utilizar un microcontrolador para hacer la correlación de datos en tiempo real, y el bombeo de la salida de que en el PPC para fines de visualización. Básicamente, el microcontrolador está ahí para hacer frente a los problemas de sincronización.

Así que para una solución más simple, todo lo que necesitas es alguna manera de recoger todos los mensajes de las diferentes líneas de serie, y combinarlos en un solo flujo, en el orden en que fueron recibidos, y bombear eso en el PC. Puedes deducir que cualquier mensaje del telémetro entre dos mensajes del GPS ocurrió en algún momento entre esos dos mensajes.

Esto le da un grado de incertidumbre, por supuesto, que depende de la frecuencia de los mensajes del GPS. La contrapartida es que, a medida que se aumenta la frecuencia de los mensajes GPS (para obtener una correlación más precisa), aumentan las exigencias al microcontrolador y al enlace en serie con el PC. En un extremo, el enlace en serie se satura con mensajes GPS con un mensaje de rango ocasional. Obviamente, la mayoría de esos mensajes GPS no son necesarios. La ventaja de esta solución, sin embargo, es que el micro tiene muy poco que hacer, desde el punto de vista del software. Podrías hacerlo todo en un simple bucle de lenguaje ensamblador, sin necesidad de un sistema operativo.

Para una solución más compleja, se puede formar un reloj local en el micro, y utilizar el GPS para sincronizar que para que cuando recibas un mensaje de rango, puedas obtener una marca de tiempo usando el reloj del micro. Usando un micro con una base de tiempo de cristal, probablemente podrías arreglártelas con mensajes GPS de 1Hz y aún así obtener tiempos de precisión mucho mejores que los milisegundos estampados en los mensajes de alcance. Una persona competente en sistemas embebidos probablemente también podría hacer esto en ensamblador en un micro de gama baja, pero has mencionado que estás empezando. Podrías buscar un micro más potente que pueda ejecutar linux, y probablemente encontrar una solución preexistente para sincronizar el reloj de linux con el GPS.

Answer 3

Lo que probablemente haría es multiplexar los datos en serie en un nuevo flujo de datos en serie a mayor velocidad, con un intercalado estático. Luego alimentar el flujo de datos a través de USB-UART al ordenador. De esta manera sabrías 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. Añade un par de bytes de marcador de inicio de trama para sincronizar el flujo de datos, bytes de relleno si no hay datos disponibles y ya está. Puede que no sepas el tiempo absoluto, pero sí el tiempo relativo entre los distintos trozos de datos.

Answer 4

También me decantaría por un microcontrolador que reciba los datos de la RS, los marque con la hora y los envíe al PC. No puedes hacer ningún trabajo crítico de sincronización de E/S con un PC con Windows (excepto con una tarjeta de sonido, quizás), porque el software y los controladores están cambiando todo el tiempo ya que los controladores se actualizan a tus espaldas.

Pero lo primero que haría es conseguir un analizador lógico USB, puedes comprar uno por menos de 100 dólares, tomar algunos mensajes del receptor GPS y comprobar exactamente cuándo se recibe cada byte. Utiliza esa información para probar/calcular exactamente cómo es la sincronización de los datos en primer lugar: por ejemplo, exactamente qué y cuándo transmite la caja del GPS. Entonces podrás calcular la precisión que se puede alcanzar y el esfuerzo que estarías dispuesto a hacer para llegar a un determinado 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; podrías conectar los datos de la UART a la entrada de la tarjeta de sonido (a través de algunas resistencias y condensadores) y escribir un software para detectar cada borde en el flujo serial, ¡dando una hermosa precisión de tiempo! Ok, no soy realmente sugiriendo esto en serio, ¡sólo para reírse un poco!