Verstehen der USB-Verarbeitung und Abfrageverzögerung im USB-Host-Controller

Ich mache Messungen im Zusammenhang mit der USB-Verzögerung mit dem USB-UART-Konverterchip (CP2102 Silicon Laboratory Chip). Ich sende ein Array von Daten, wenn 0xeees empfangen wird, gibt der Mikrocontroller das Byte zurück. Ich nehme Zeitstempel zwischen dem Moment, an dem ich mit dem Senden der Daten beginne, bis ich die 0xee. Um die Verarbeitungszeit am CP2102-Chip herauszufinden, habe ich die Chip-Ack-Verzögerung gemessen (es ist die Zeit zwischen dem Punktpaket und dem vom Chip empfangenen sofortigen Ack-Paket). Der USB-UART-Chip ist ein Massengerät mit zwei Endpunkten (IN und OUT) mit einer maximalen Paketgröße von 64 Bytes, es wird USB 2.0 mit voller Geschwindigkeit (12 Mbit / s) verwendet. Ich nehme 500 Proben für jede Datengröße (1 Byte wird 500 Mal gesendet und Messungen werden durchgeführt, ebenso 2 Bytes bis 127 Bytes).

Ich habe drei Diagramme gezeichnet, eines für total_delay, chip_ack_delayund total_delay_without_uart_delay_chip_ack_delay = total_delay - chip_ack_delay - 86.6*data_sizeDiese Verzögerung sollte die Verarbeitungsverzögerung und die USB-Abfrageverzögerung am Hostcomputer darstellen. Ich verwende einen Linux-PC mit Ubuntu 16.04, die UART-Baudrate beträgt 115200 (daher 86,6 Mikrosekunden pro Byte). Es ist verständlich, dass die Chip-Ack-Verzögerung zunimmt, wenn die Paketgröße mehr als 64 Byte beträgt, da er auf zwei Transaktionen warten muss. Ich bin nicht in der Lage, den zweiten Plot zu interpretieren. Er zeigt, dass die hostseitige Abfrage und die Verarbeitungsverzögerung abnimmt, wenn die Paketgröße mehr als 64 Bytes beträgt. Kann jemand erklären, wie dies zu interpretieren ist? Oder übersehe ich hier etwas?

Übrigens habe ich die Chip-Ack-Verzögerung mit dem USBmon-Protokoll gemessen. In der Grafik ist die x-Achse die Datengröße, die y-Achse der MATLAB-Boxplot, der den Wertebereich der Verzögerung zeigt, der für eine bestimmte Datengröße gemessen wurde.

Geben Sie hier die Bildbeschreibung ein

Um das Timing zu verstehen, müssen Sie sich darüber im Klaren sein, dass Sie es mit der folgenden Kette zu tun haben: Host-App -> Host-Treiber -> USB-Protokoll -> UART-Konvertierung -> UART-Übertragung > MCU-UART-Treiber > MCU-App sucht nach EE-Marker -> MCU-UART Übertragung -> UART-zu-USB-Konvertierung -> USB-Protokoll -> USB-Hosttreiber -> Hostanwendung. Es könnte viele Macken in der Interaktion/Synchronisation zwischen all diesen Grenzen entlang dieser Pipeline geben.
Außerdem müssen Sie etwas mehr über das USB-Protokoll, auch bekannt als SIE - Serial Interface Engine, lernen. Was meinst du mit "Punktpaket" und "sofortiges Bestätigungspaket vom Chip empfangen"? Das sofortige ACK-Paket kommt in weniger als 1,7 us vom Chip, andernfalls erkennt der Host einen "Transaktionsfehler".
@Al Ich habe genau das Setup, wie du es erklärt hast. Ich subtrahiere die Verzögerung im Zusammenhang mit der UART-Transaktion, die 86,6 Mikrosekunden / Byte beträgt, und die Chip-Ack-Verzögerung. Die MCU-App ist sehr einfach, ich habe Logik in den Uart-Interrupt-Handler geschrieben. Sobald das Byte empfangen wird, vergleiche ich mit, 0xeeob es übereinstimmt, und gebe das Byte wieder. In Bezug auf den Zeitpunkt nehme ich einen Zeitstempel, bevor ich Daten an die serielle Schnittstelle schreibe, wieder nehme ich einen Zeitstempel, nachdem ich ein Echo empfangen habe. Ich subtrahiere den alten Zeitstempel vom neuen. In Bezug auf die USB-Stack-Verzögerung verstehe ich, dass Stack und Treiber eine gewisse Verzögerung hinzufügen, aber das sollte konstant sein.
Muss ack innerhalb von 1,7 us liegen? Ich bin mir nicht sicher, ob USBmon viel Verzögerung zeigt, bevor die Bestätigung empfangen wird. Ich kann ein USBmon anschließen, wenn Sie einen Blick darauf werfen möchten.
Ich spreche vom USB-Protokoll ACK auf USB-Paketebene. Ich weiß nicht, welches "ack" Sie meinen, deshalb habe ich vorgeschlagen, die Terminologie genauer zu beschreiben, wenn Ihr Fragentitel "USB-Verzögerungen" lautet und Sie einige unbekannte Begriffe wie "Punktpakete" einwerfen.
Ich spreche von Acks im USBmon-Protokoll unter Linux. Diese werden gesendet, sobald die vollständigen Daten übertragen wurden. Ich sehe keine Bestätigungen für jedes übertragene USB-Paket. Nicht für alle 64 Bytes. Es wird vom Slave gesendet, sobald die vollständigen Daten empfangen wurden, obwohl es größer als 64 Bytes ist.

Antworten (1)

Das Datenblatt des CP210x erwähnt große FIFOs sowohl auf der Sende- als auch auf der Empfangsseite.

Ich vermute stark, dass sie auch die Auslastung von USB (und Host-CPU) optimieren, indem sie UART-Daten in größeren USB-Paketen "sammeln".

Dies würde bedeuten, dass Daten zurückgehalten werden, bis entweder 64 Bytes im FIFO sind oder der Empfänger für einige Bitzeiten nicht aktiv war.

Beachten Sie, dass 64-Byte-Massenpakete etwas Besonderes sind: Sie beenden eine Transaktion im Host nicht (es sei denn, ein Puffer war zu klein).

Sie können tatsächlich einen "hohen Einbruch" für die 64-Byte-Transaktionen sehen, da diese als ein 64-Byte-Paket gefolgt von einem Null-Byte-Paket ausgeführt werden könnten.

Randbemerkung: Es kann sich lohnen, die Timings mit einem USB 2.0-Hochgeschwindigkeits-Hub zwischen dem PC-Host und dem CP210x erneut zu überprüfen. Diese Konfiguration könnte die verwenden0,25 ms0,125 ms Microframe-Timing in hoher Geschwindigkeit verfügbar.

Ich habe keinen Hardware-Sniffer, ich messe alle Timings in der Software. Meinen Sie damit, dass der Host-Controller einige Zeit auf die nächsten Bytes wartet, bevor er ein USB-Paket sendet, wenn es weniger als 64 Bytes umfasst?
Das Microframe-Timing im HS-Modus beträgt 0,125 ms und nicht 0,25.
Ich glaube nicht, dass einer der CP210x-Chips den Hochgeschwindigkeitsmodus unterstützt. Das Datenblatt gibt nur die volle Geschwindigkeit an. Die USB-Rahmenbreite in voller Geschwindigkeit beträgt 1 ms, ich bin mir nicht sicher, ob die Rahmenbreite für den Fall von Massenendpunkten eine Rolle spielt.
Verstehen der USB-Verarbeitung und Abfrageverzögerung im USB-Host-Controller
AntwortenHierDatenschutz-Bestimmungen1y, 0v