Sondeo del sensor a través de la interfaz serial USB-RS485 bloqueada a 16 ms, aunque debería ser más rápida

Navega tus respuestas
8

Tengo una configuración, conectando una placa de sensores IMU de Razor , con una RS-485 Breakout , a un tablero de Interfaz serial USB-RS485 a través de un cable USB en mi computadora portátil. Ejecuto un software en la computadora portátil (Max / MSP) que envía mensajes de sondeo al sensor, espera los datos de respuesta y, al recibir la respuesta, se activa automáticamente un nuevo mensaje de sondeo. Es un bucle constante:

  1. enviar un mensaje de sondeo
  2. esperar una respuesta
  3. en respuesta vaya a 1.

Quiero que este sondeo sea lo más rápido posible, ya que tendré que conectar 21 de estos sensores al mismo bus RS485. El firmware del Razor está programado con el IDE de Arduino , y de acuerdo con el código, solo debe haber un retraso de ~ 2 ms entre el mensaje de sondeo y el Escritura de la respuesta. El firmware también gasta 12 ms cada 20 ms en la asignación y cálculo de sensores. Este cálculo a veces retrasa la respuesta al sondeo. Soy consciente de eso y todos los resultados son en consecuencia.

Mi problema en este momento es que el sondeo del sensor está atascado a una velocidad de actualización de un promedio de 15 milisegundos. Miré los datos con mi pequeño usb-oscillosope e hizo un diagrama (> PDF).

Mi osciloscopio se asienta directamente en la interfaz USB-RS485 y ve cómo se apaga el sondeo y aparece el mensaje de respuesta. El retraso entre estos dos se encuentra entre 2 y 13 ms. Esta diferencia se explica por el hecho de que a veces la afeitadora está ocupada haciendo sus cálculos de sensores matemáticos. El hecho extraño es que, aunque las respuestas vienen con diferentes retrasos, el sondeo siempre parece salir en el mismo intervalo de aproximadamente 15 ms.

También implementamos la misma configuración con

  • codificando el firmware en C y programando el Razor con avr-dude
  • haciendo el sondeo de software en el código Python
  • en Mac OSX y PC con Windows 7

Todas las combinaciones posibles dieron como resultado el mismo intervalo de 15 ms. Entonces, el problema no está en el código Arduino, ni en Max / MSP. Tengo la sospecha de que el problema podría deberse a la interfaz serial USB-RS485 y / o al controlador FTDI necesario.

¿Este problema le suena familiar a cualquiera?

    
pregunta evsc

2 respuestas

5

Se debe al temporizador de latencia de 16 ms del controlador FTDI y al hecho de que mis respuestas de sondeo no fueron lo suficientemente largas para llenar el búfer de 64 bytes para activar automáticamente el vaciado del búfer. Lea AN232B-04_DataLatencyFlow.pdf si está interesado, o simplemente vaya a su Administrador de dispositivos y cambie la configuración en sus propiedades de puerto serie USB.

    
respondido por el evsc
2

Sin conocer muchos detalles (que realmente no quiero saber), culparía al adaptador USB a RS-485. Tuvimos un problema similar en un procesador Intel Q7 que ejecuta Linux con uno de esos adaptadores.

Estábamos usando el adaptador temporalmente hasta que nuestro hardware personalizado estuviera listo. Nuestro hardware personalizado utiliza un enlace PCIe y un FPGA para hacer la misma interfaz RS-485 (y mucho más). El software se mantuvo igual para el adaptador y nuestro hardware personalizado. Cuando cambiamos al hardware personalizado, el problema desapareció.

    
respondido por el user3624

Lea otras preguntas en las etiquetas

¿Es posible probar la seguridad de una batería de ion litio? ¿Cómo? ¿Cómo puedo hacer un recinto atractivo para mi circuito?