Tengo una configuración, conectando una placa de sensor Razor IMU , con una placa RS-485 Breakout , a una 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, activa automáticamente un nuevo mensaje de sondeo. Es un bucle constante:
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 de Razor está programado con el IDE de Arduino y, según el código, solo debe haber un retraso de ~2 ms entre el mensaje de sondeo y la escritura de la respuesta. El firmware también gasta 12 ms cada 20 ms en la asignación y el cálculo del sensor. 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 en una tasa de actualización promedio de 15 milisegundos. Miré los datos con mi pequeño oscilosope usb e hice un diagrama (> PDF).
Mi osciloscopio se encuentra directamente en la interfaz USB-RS485 y ve que se apaga el sondeo y entra 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 maquinilla de afeitar está ocupada haciendo los cálculos matemáticos del sensor. El hecho extraño es que, aunque las respuestas llegan con diferentes retrasos, el sondeo siempre parece salir en el mismo intervalo de unos 15 ms.
También implementamos la misma configuración con
Todas las combinaciones posibles dieron como resultado el mismo intervalo de 15 ms. Entonces, el problema no está ni en el código Arduino, ni dentro de Max/MSP. Tengo la sospecha de que el problema puede deberse a la Interfaz Serial USB-RS485 y/o al controlador FTDI necesario.
¿Este problema le suena familiar a alguien?
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 las propiedades de su puerto serie USB.
Sin saber 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 ejecutaba Linux con uno de esos adaptadores.
Estuvimos usando el adaptador temporalmente hasta que nuestro hardware personalizado estuvo listo. Nuestro hardware personalizado usa un enlace PCIe y un FPGA para hacer la misma interfaz RS-485 (y mucho más). El software siguió siendo el mismo para el adaptador y nuestro hardware personalizado. Cuando cambiamos al hardware personalizado, el problema desapareció.
Kellenjb
evsc
Kellenjb
evsc