Sensorabfrage über die serielle USB-RS485-Schnittstelle bleibt bei 16 ms hängen, obwohl sie schneller sein sollte

Ich habe ein Setup, bei dem eine Razor IMU- Sensorplatine mit einer RS-485-Breakout- Platine über ein USB-Kabel mit einer seriellen USB-RS485-Schnittstelle an meinen Laptop angeschlossen wird. Ich führe auf dem Laptop eine Software aus (Max / MSP), die Abrufnachrichten an den Sensor sendet, auf die Antwortdaten wartet und beim Empfang der Antwort automatisch eine neue Abrufnachricht auslöst. Es ist eine konstante Schleife:

1. Senden Sie eine Abrufnachricht
2. Warten Sie auf eine Antwort
3. bei Antwort gehe zu 1.

Ich möchte, dass diese Abfrage so schnell wie möglich erfolgt, da ich 21 dieser Sensoren an denselben RS485-Bus anschließen muss. Die Firmware auf dem Razor ist mit der Arduino IDE programmiert , und laut Code sollte zwischen der Abrufnachricht und dem Schreiben der Antwort nur eine Verzögerung von ~ 2 ms liegen. Die Firmware benötigt außerdem alle 20 ms 12 ms für die Sensorzuweisung und -berechnung. Diese Berechnung verzögert manchmal die Antwort auf die Abfrage. Ich bin mir dessen bewusst und alle Ergebnisse sind dementsprechend.

Mein aktuelles Problem ist, dass die Abfrage des Sensors mit einer Aktualisierungsrate von durchschnittlich 15 Millisekunden feststeckt. Ich habe mir die Daten mit meinem kleinen USB-Oszilloskop angesehen und ein Diagramm erstellt (> PDF).

Mein Oszilloskop befindet sich direkt auf der USB-RS485-Schnittstelle und sieht, dass die Abfrage erlischt und die Antwortnachricht eingeht. Die Verzögerung zwischen diesen beiden liegt zwischen 2 und 13 ms. Dieser Unterschied ist damit zu erklären, dass der Rasierer manchmal damit beschäftigt ist, seine sensorisch-mathematischen Berechnungen durchzuführen. Die seltsame Tatsache ist, dass, obwohl die Antworten mit unterschiedlichen Verzögerungen eingehen, die Abfrage immer im gleichen Intervall von etwa 15 ms zu erfolgen scheint.

Wir haben das gleiche Setup auch mit implementiert

• Codierung der Firmware in C und Programmierung des Razor mit avr-dude
• Software-Polling in Python-Code durchführen
• unter Mac OSX und PC Windows 7

Alle möglichen Kombinationen ergaben das gleiche Intervall von 15 ms. Das Problem liegt also weder im Arduino-Code noch in Max / MSP. Ich habe den Verdacht, dass das Problem an der seriellen USB-RS485-Schnittstelle und / oder dem erforderlichen FTDI-Treiber liegen könnte.

Kommt Ihnen dieses Problem bekannt vor?

Dies liegt am 16-ms-Latenzzeit-Timer des FTDI-Treibers und an der Tatsache, dass meine Abfrageantworten nicht lang genug waren, um den 64-Byte-Puffer zu füllen und die Pufferentleerung automatisch auszulösen. Lesen Sie bei Interesse AN232B-04_DataLatencyFlow.pdf oder gehen Sie einfach zu Ihrem Geräte-Manager und ändern Sie die Einstellungen in Ihren USB-Serial-Port-Eigenschaften.

Ohne viele Details zu kennen (die ich nicht wirklich wissen möchte), würde ich den USB-zu-RS-485-Adapter beschuldigen. Wir hatten ein ähnliches Problem auf einem Intel Q7-Prozessor unter Linux mit einem dieser Adapter.

Wir haben den Adapter vorübergehend verwendet, bis unsere benutzerdefinierte Hardware bereit war. Unsere benutzerdefinierte Hardware verwendet eine PCIe-Verbindung und ein FPGA, um dieselbe RS-485-Schnittstelle (und vieles mehr) zu verwenden. Die Software blieb für den Adapter und unsere benutzerdefinierte Hardware gleich. Als wir auf die benutzerdefinierte Hardware umgestiegen sind, ist das Problem behoben.