¿Cómo podría determinar la latencia relacionada con la transmisión de datos en un convertidor USB a EIA-485?
El convertidor es un USOPTL4 de B&B Electronics que usa el chip FTDI, y sé que hay una latencia de rendimiento desde el momento en que mi aplicación de Windows llama a WriteFile y los datos se transmiten.
La misma pregunta se aplica al final de la recepción de las cosas. Sé que hay una latencia desde que el FTDI recibe los datos en serie y se proporciona al sistema operativo para su lectura.
¿Alguien ha medido con éxito estas latencias?
"¿Cómo podría determinar la latencia"?
Uso un osciloscopio para determinar las latencias típicas.
Investigo el código fuente y el hardware para obtener una estimación conservadora de la latencia en el peor de los casos.
latencia típica
Si tuviera que medir la latencia típica de transmisión y recepción de alguna configuración en particular, comenzaría con la medición más simple: el retraso típico de ida y vuelta. Quizás algo como esto sería relativamente fácil de configurar:
El software en el Arduino espera un tiempo aleatorio, apaga todos los LED, espera un tiempo más aleatorio y luego comienza de nuevo encendiendo el primer LED.
conecta el o'scope a los 2 LED y mide el retraso típico entre el primer LED que se enciende y el segundo LED que se enciende.
latencia en el peor de los casos
Un sistema en tiempo real debe tener una latencia limitada en el peor de los casos. Por desgracia, eso no parece posible con Windows; incluso si pudiera obtener el código fuente de Windows, un parche de controlador de dispositivo la próxima semana podría agregar otros 2 milisegundos de latencia en el peor de los casos.
Algunos sistemas operativos en tiempo real admiten USB, en particular, EMC que se ejecuta en Linux que se ejecuta en RTAI admite USB: hidcomp , dispositivo de entrada USB personalizado con emc , etc. USB tiene "transferencias isócronas" y "transferencias de interrupción" que parecen podrían ser útiles para delimitar la latencia en el peor de los casos. Por desgracia, nadie parece confiar en USB para tareas en tiempo real: ¿ Hardware compatible con EMC2 , control USB en tiempo real? , problemas de USB , etc.
Por lo tanto, EMC2 todavía usa puertos paralelos para conocer la latencia en el peor de los casos; otros protocolos de comunicación de baja latencia utilizan una variedad de hardware, incluido el hardware Ethernet.
Bueno, ¿qué estás tratando de hacer?
Lo que encontrará es que cada nivel en esa pila agrega una cantidad variable de latencia aparentemente aleatoria. Si bien por lo general puede ser inferior a 1 ms, en ocasiones es probable que sea mucho mayor que eso.
El sistema operativo en sí tendrá una latencia de programador multitarea aleatoria. Eso podría ser de 0 a 50 ms (o más en sistemas especializados o mal configurados). Si está tratando de hacer algo con restricciones de tiempo muy estrictas, es probable que deba hacerlo en un controlador de dispositivo personalizado en el espacio del kernel para hacer el tiempo.
Después de eso, USB no es un bus muy amigable con la latencia. Esperar a que el USB envíe los datos agregará una pequeña latencia aleatoria. El lado de la lectura es en realidad un poco peor... ya que la raíz USB debe sondear los dispositivos conectados para ver si tienen datos. No puedo darte mucho sobre cuáles son los rangos de estos retrasos... tal vez alguien más pueda ayudar aquí. Sin embargo, es probable que sea bastante variable dependiendo de cosas como si se está conectando a través de un concentrador y cuántos otros dispositivos están conectados. Por lo tanto, si lo mide usted mismo, asegúrese de probar al menos algunas combinaciones de dispositivos USB. Pruébelo con cámaras web y memorias USB conectadas y activas, a través de un concentrador y directo, etc.
chris stratton
davidcary