RPi GPIO-Geschwindigkeitsproblem in Bare Metal

Der Hauptschuldige ist eine Kombination aus Hardware-/Peripheriebeschränkungen und Taktkonfiguration. Obwohl ich nicht speziell mit BCM Baremetal arbeiten musste, sind dies häufige Probleme von Baremetal-Projekten auf jeder komplexen Architektur.

Als Hinweis auf die Einschränkungen der GPIO-Ausgangstreiber können Sie sehen, dass bei fester Verdrahtung als Hardware-Taktausgang die maximale Ausgangsfrequenz 125 MHz beträgt

Von Seite 106 des von Ihnen bereitgestellten BCM-Peripheriedatenblatts

Betriebsfrequenz : Die maximale Betriebsfrequenz der Allzweck-Taktgeber beträgt ~125 MHz bei 1,2 V, wird jedoch reduziert, wenn die GPIO-Pins stark belastet sind oder eine kapazitive Last haben.

Dies steht im Zusammenhang mit der Konfiguration des GPIO-Peripheriegeräts, um den Peripherietakt direkt ohne Softwareumschaltung auszugeben.

Ich würde sagen, dass es vernünftig ist zu erwarten, dass selbst wenn die Uhren richtig konfiguriert sind und die CPU mit maximaler Geschwindigkeit läuft, Sie aufgrund von Hardwarebeschränkungen nicht erwarten können, dass ein GPIO schneller umschaltet.

AKA, nur weil das Peripheriegerät Ihren Softwarebefehl rechtzeitig verriegeln kann, bedeutet das nicht, dass die physischen Ausgangstreibertransistoren, die groß und kräftig sind und eine Menge Eigenlast aufweisen, so schnell schalten können, wie Ihr Code ausgeführt werden kann. Wenn Sie Tests durchführen, müssen Sie unbedingt ein Oszilloskop mit ausreichender analoger Bandbreite und hochwertigen Tastköpfen verwenden, da Sie mit dem Messsystem auch Ihr Ergebnis verändern. Ein Logikanalysator ist möglicherweise nicht ausreichend, eine langsame Anstiegsgeschwindigkeit ist bei schwellenwertbehafteten Eingängen nicht erkennbar.

So gehen Sie vor

Es scheint, dass Sie, wenn Sie GPIO so schnell wie nötig ansteuern möchten, für Taktzwecke diese eingebauten Taktausgangspins des Peripheriegeräts verwenden sollten. Diese werden über Register konfiguriert

CM_GP0CTL CM_GP0DIV(Wiederholen Sie dies für GP-Taktausgänge 1 und 2)

Abhängig von den Ergebnissen ermitteln Sie dann die maximale Schaltfrequenz für Ihr Hardwaresystem unter Berücksichtigung der maximalen GPIO-Last und der VDD Ihrer PIO-Schaltung.

Wenn die Taktausgabe langsamer als für Ihre nominellen Teilereinstellungen erwartet ist, weist dies darauf hin, dass Sie die Systemuhr, das Taktrouting und die PLLs nicht richtig konfiguriert haben.

Sobald Sie diese Meinungsverschiedenheit identifiziert haben, können Sie Ihren Bare-Metal-Bootstrap-Code optimieren, um die PLLs zu konfigurieren und zu sehen, ob ein softwaregesteuertes Umschalten so schnell wie der hardwaregesteuerte Taktausgang ausgeführt werden kann, und von dort aus weitergehen.

Zusätzliche beitragende Faktoren können in den Befehls- und Daten-Caches liegen, die eine Softwarekonfiguration erfordern, wenn Sie nicht in der Lage sind, das Umschalten der Software mit der Hardwaregrenze allein durch PLL auszurichten, wäre dies der nächste Ort, an dem ich suchen würde.

Bin gerade durch einen Crosspost auf diese Frage gestoßen.
Das Hauptproblem, das nicht in allen obigen Kommentaren behandelt wird, ist die Busgeschwindigkeit. Der Prozessor läuft möglicherweise mit 3 GHz, die Busse auf dem Chip jedoch nicht. Der Bus auf der ARM-Seite ist viel langsamer als 3 GHz. Der Bus zum GPIO ist noch langsamer und läuft mit der GPU-Geschwindigkeit. Hinzu kommt der Zeitverlust für das Überqueren der Taktdomäne und die Tatsache, dass die Busse eine gemeinsame Ressource zwischen den ARM-Kernen und der GPU sind. Außerdem verwendet der Chip das AXI-System, das über eine Schreibbestätigung verfügt, sodass der Prozessor auf das Eintreffen der Schreibbestätigung warten kann, was der doppelten Busdurchlaufzeit entspricht. In der Businfrastruktur dauert es mehrere Taktzyklen, um das Signal von einer Seite des Busses zur anderen zu übertragen (aber es ermöglicht mehrere Transaktionen gleichzeitig auf dem Bus).