Tengo una configuración que conecta una placa de sensor Razor IMU , con una placa de conexión RS-485 , 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, se activa automáticamente un nuevo mensaje de sondeo. Es un bucle constante:
- enviar un mensaje de votación
- espera una respuesta
- en respuesta vaya a 1.
Quiero que esta encuesta sea lo más rápida posible, ya que tendré que conectar 21 de estos sensores al mismo bus RS485. El firmware de la Razor se programa con el IDE de Arduino , y de acuerdo con el código, solo debe haber una demora 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 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 tasa de actualización promedio de 15 milisegundos. Miré los datos con mi pequeño usb-osillosope e hice un diagrama (> PDF).
Mi osciloscopio se encuentra directamente en la interfaz USB-RS485 y ve que el sondeo se apaga y entra el mensaje de respuesta. El retraso entre estos dos se encuentra entre 2 y 13 ms. Esta diferencia es explicable con el hecho de que a veces la maquinilla de afeitar está ocupada haciendo sus cálculos matemáticos de sensores. El hecho extraño es que, a pesar de que las respuestas llegan con diferentes retrasos, la encuesta 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 Razor con avr-dude
- haciendo el sondeo de software en 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á ni en el código Arduino ni dentro de Max / MSP. Sospecho que el problema podría deberse a la interfaz serial USB-RS485 y / o al controlador FTDI necesario.
¿Este problema le suena familiar a alguien?
Respuestas:
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 como 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.
fuente
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 estaba listo. Nuestro hardware personalizado utiliza 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ó.
fuente