Wie kann ich die Latenz ermitteln, die mit der Übertragung von Daten auf einem USB-zu-EIA-485-Konverter verbunden ist?
Der Konverter ist ein USOPTL4 von B&B Electronics, der den FTDI-Chip verwendet, und ich weiß, dass es eine Durchsatzlatenz gibt, wenn meine Windows-Anwendung WriteFile aufruft und Daten tatsächlich übertragen werden.
Die gleiche Frage gilt auf der Empfangsseite der Dinge. Ich weiß, dass es eine Latenz gibt, wenn der FTDI die seriellen Daten empfängt und sie dem Betriebssystem zum Lesen zur Verfügung stellt.
Hat jemand diese Latenzen erfolgreich gemessen?
"Wie könnte ich die Latenz ermitteln"?
Typische Latenzen ermittle ich mit einem Oszilloskop.
Ich untersuche den Quellcode und die Hardware, um eine konservative Schätzung der Worst-Case-Latenz zu erhalten.
typische Latenz
Wenn ich die typische Sende- und Empfangslatenz eines bestimmten Setups messen müsste, würde ich mit der einfachsten Messung beginnen: typische Round-Trip-Verzögerung. Vielleicht wäre so etwas relativ einfach einzurichten:
Die Software auf dem Arduino wartet eine zufällige Zeit, schaltet alle LEDs aus, wartet eine weitere zufällige Zeit und beginnt dann mit dem Einschalten der ersten LED.
Sie schließen das O'scope an die 2 LEDs an und messen die typische Verzögerung zwischen dem Einschalten der ersten LED und dem Einschalten der zweiten LED.
Worst-Case-Latenz
Ein Echtzeitsystem muss eine begrenzte Worst-Case-Latenz haben. Leider scheint das mit Windows nicht möglich zu sein – selbst wenn Sie den Quellcode für Windows bekommen könnten, könnte ein Gerätetreiber-Patch nächste Woche weitere 2 Millisekunden an Latenz im schlimmsten Fall hinzufügen.
Einige Echtzeit-Betriebssysteme unterstützen USB – insbesondere unterstützt EMC unter Linux unter RTAI USB – hidcomp , benutzerdefiniertes USB-Eingabegerät mit emc usw. USB hat scheinbar „isochrone Übertragungen“ und „Unterbrechungsübertragungen“. Sie könnten nützlich sein, um die Worst-Case-Latenz zu begrenzen. Leider scheint niemand USB für Echtzeitaufgaben zu vertrauen: Von EMC2 unterstützte Hardware , Echtzeit-USB-Steuerung? , USB-Probleme usw.
Daher verwendet EMC2 immer noch parallele Ports, um die Worst-Case-Latenz zu ermitteln. Andere Kommunikationsprotokolle mit niedriger Latenz verwenden eine Vielzahl von Hardware, einschließlich Ethernet-Hardware.
Nun, was versuchst du zu tun?
Was Sie feststellen werden, ist, dass jede Ebene in diesem Stapel eine variable Menge an scheinbar zufälliger Latenz hinzufügt. Während sie normalerweise unter 1 ms liegen kann, ist sie wahrscheinlich gelegentlich viel viel größer als das.
Das Betriebssystem selbst wird eine zufällige Multitasking-Scheduler-Latenz haben. Das können 0-50 ms sein (oder mehr auf spezialisierten oder schlecht konfigurierten Systemen). Wenn Sie versuchen, etwas mit sehr engen Timing-Beschränkungen zu tun, müssen Sie dies wahrscheinlich in einem benutzerdefinierten Gerätetreiber im Kernel-Space tun, um das Timing vorzunehmen.
Danach ist USB kein sehr latenzfreundlicher Bus. Das Warten darauf, dass USB die Daten sendet, wird eine kleine zufällige Latenz hinzufügen. Die Leseseite ist eigentlich etwas schlechter ... da der USB-Root angeschlossene Geräte abfragen muss, um zu sehen, ob sie Daten haben. Ich kann Ihnen nicht viel über die Reichweiten dieser Verzögerungen sagen ... vielleicht kann jemand anderes hier helfen. Es ist jedoch wahrscheinlich ziemlich variabel, je nachdem, ob Sie eine Verbindung über einen Hub herstellen und wie viele andere Geräte angeschlossen sind. Wenn Sie es also selbst messen, sollten Sie mindestens ein paar USB-Gerätekombinationen ausprobieren. Probieren Sie es mit angeschlossenen und aktiven Webcams und USB-Sticks aus, über einen Hub und direkt usw.
Chris Stratton
davidcary