Raspberry Pi RP2040: Hände

Die Veröffentlichung des Raspberry Pi Pico-Boards mit RP2040-Mikrocontroller der Raspberry Pi Foundation hat in den letzten Monaten in der Maker-Community große Wellen geschlagen. Viele haben gezeigt, wie insbesondere die beiden programmierbaren I/O-Zustandsmaschinenperipheriegeräte (PIO) zur Erstellung von DVI-Videogeneratoren und anderen digitalen Peripheriegeräten verwendet werden können.

Neben dieser Aufregung stellt sich die Frage, ob dies für diejenigen unter uns, die STM32, SAM und andere Cortex-M-basierte MCUs verwenden, zu größeren Umwälzungen führen wird. Wäre der RP2040 vielleicht eine sinnvolle Option für einige unserer Projekte? Da es sich beim RP2040 um eine MCU mit zwei Cortex-M0+-Prozessoren handelt, erscheint es nur fair, sich mit den Angeboten eines der aktuellen Schwergewichte im Bereich der 32-Bit-ARM-MCUs zu messen: ST Microelectronics.

Hat es der Pipsqueak der Raspberry Pi Foundation geschafft, den Ingenieuren von ST zu zeigen, wie es geht, oder sollten erstere einige ihrer Annahmen noch einmal überdenken? Und wie schwierig wird es sein, Low-Level-Code von STM32 auf RP2040 zu portieren?

Um es kurz zu machen: Nachdem der RP2040 meine Aufmerksamkeit erregt hatte, dachte ich, es könnte interessant sein, mein C++-basiertes STM32-Framework auf diese neue MCU zu portieren. Allerdings nicht so sehr für die dualen Cortex-M0+-Kerne, da ich STM32H7-Dual-Core-MCUs (M4 und M7) herumliegen habe, die die Fülle eines RP2040 deutlich übertreffen und viel mehr I/O übrig haben. Was mich am meisten faszinierte, war dieses State-Machine-Peripheriegerät (PIO) im RP2040, das einen genaueren Blick wert schien.

Aufgrund meiner Erfahrung mit STM32 dachte ich, ich könnte schnell einige Dateien portieren, einen neuen „RP“-Architekturzweig im Projekt erstellen und mich auf den Weg zu den Rennen machen. Cortex-M ist Cortex-M, oder? Das übliche Verfahren bei einer neuen ARM-basierten MCU besteht darin, die Datenblätter, das Referenzhandbuch und die CMSIS-Gerätedateien abzurufen. Danach kann man den Low-Level-Code problemlos anpassen, um das neue Peripherie-Benennungs- und Registerlayout zu verwenden, während die Core-Level-Geräte (SysTick, NVIC usw.) gleich bleiben.

Vielleicht war es naiv, dass ich ein Raspberry Pi Pico-Board bestellt hatte, bevor ich überhaupt nach CMSIS-Unterstützung gesucht oder einen Blick auf das Referenzhandbuch geworfen hatte. Zu meiner Überraschung stellte ich fest, dass CMSIS-Unterstützung oder gar Interoperabilität mit dem Rest des Cortex-M-Ökosystems noch nicht auf dem Radar war. Dennoch ist die SVD-Datei für die RP2040-MCU im „Pico SDK“ enthalten, aus der der Geräte-Header generiert werden kann. Dank Chris Hockubas Bemühungen, CMSIS mit dem RP2040 zu booten, hatte ich schließlich gemeinsam eine funktionierende Lösung.

Bei einem STM32-Projekt sind einige Dinge erforderlich, damit ein Bare-Metal-Projekt auf einer Ziel-MCU funktioniert. Dazu gehören der Startcode, der einige grundlegende Einstellungen der Umgebung durchführt, sowie die Vektortabelle für Interrupt-Handler. Außerdem gibt es das Linker-Skript, um sicherzustellen, dass alle Bits am richtigen Speicheroffset landen. Dies ist alles ziemlich minimal, da die MCU beim Booten das Firmware-Image vom Flash-ROM unter der Standardadresse lädt.

Die erste Hürde beim RP2040 besteht darin, seinen verketteten Bootloader-Prozess zu verstehen. Ähnlich wie früher bei bootfähigen Disketten oder einer Festplatte/SSD in einem PC wird das externe QSPI-Flash-ROM von der MCU im Wesentlichen als potenzielles Startgerät behandelt. Der Bootloader der ersten Stufe ist in die MCU im Boot-ROM integriert, Adresse 0x0000 0000, der beim Booten die QSPI-Schnittstelle überprüft, um zu versuchen, 256 Bytes daraus zu laden. Dies wird auf eine gültige CRC32-Hash-Übereinstimmung überprüft und bei Übereinstimmung davon ausgegangen, dass es sich um den Bootloader der zweiten Stufe handelt.

Es gibt viele Dinge, die dieser Bootloader der zweiten Stufe tun könnte, und einige, die erforderlich sind. Es genügt vorerst zu sagen, dass dieser ganze Prozess mit dem RP2040 im Vergleich zu einigen berühmten STM32-Klonen – wie den „I-can-t-glaub-it's-kein-echten“ STM32-Klonen von GigaDevices –, die ebenfalls SPI-ROMs verwenden, ein Problem darstellt nicht so intuitiv, gut dokumentiert oder transparent, wie es sein könnte, mit vielen Stolpersteinen.

Ich musste ziemlich lange im RP2040-Datenblatt herumstöbern und herumfragen, um herauszufinden, wie der Peripherietaktmanager in STM32 der RP2040-Systemarchitektur zugeordnet ist. Wie sich herausstellt, heißt die Version des RP2040 RESETS und funktioniert grundsätzlich umgekehrt: Sie müssen die Reset-Bedingung für einen Block zurücksetzen, um die Uhr dafür zu aktivieren. Um den GPIO-Takt zu aktivieren, müssen Sie Bit 8 in RESETS_RESET (PADS_BANK0) umschalten.

Das habe ich herausgefunden, ich habe mir den Abschnitt über GPIO-Peripheriegeräte in der Dokumentation angesehen (Abschnitt 2.19). Eines fällt sofort auf: Das ist völlig anders als STM32, AVR, SAM und die meisten anderen GPIO-Peripheriegeräte, die ich je gesehen habe.

Während die meisten Chips ein oder zwei Register pro Funktion haben und Sie Bits hineinschieben, um diese Funktion für einen bestimmten Pin zu aktivieren, verfügt der RP2040 über ein Register pro Pin und Sie verschieben Bits an eine Stelle, die die Funktion vorgibt. Es ist eine einzigartige Wahl und ich musste einen benutzerdefinierten Code schreiben, um die Speicheradresse der Steuerregister für jeden Pin nachzuschlagen.

Nach all diesen Anstrengungen wird es doch sicher klappen, oder?

Wie bereits erwähnt, muss sich der Bootloader der zweiten Stufe am Anfang des Firmware-Images befinden. Da ich dachte, dass es sich hierbei um generischen Code handeln musste, nahm ich einfach den gebrauchsfertigen ASM-Code, der vom offiziellen PicoSDK beim Erstellen des Blinky-Beispiels ausgespuckt wurde. Nachdem dies zum RP2040-Nodate-Port hinzugefügt wurde, konnte das Blinky-Beispiel ohne Probleme erstellt werden.

Die nächste Herausforderung bestand darin, die resultierende ELF-Binärdatei auf den RP2040 zu flashen, da es keinen integrierten SWD-Adapter im ST-Link-Stil auf dem Raspberry Pi Pico-Board gibt und als Dual-Core-Cortex-M-MCU ein Multi-Drop-SWD erforderlich ist Adapter. Bisher sind die einzigen Multi-Drop-SWD-Adapter, die ich habe, auf STM32H7-Nucleo-Boards integriert. Daher habe ich mich entschieden, den benutzerdefinierten OpenOCD-Fork zu verwenden, der von der Raspberry Pi Foundation erstellt wurde, und ihn auf einem Raspberry Pi SBC auszuführen.

Nachdem das alles erledigt war, habe ich die Firmware erfolgreich auf den RP2040 geflasht und … absolut nichts bekommen. Bei einer flüchtigen Betrachtung stellte sich heraus, dass der Code nie über den anfänglichen Bootloader hinaus in die eigentliche Firmware im SPI-ROM gelangte. Ob dies auf ein Problem im Zusammenhang mit dem Bootloader ASM der zweiten Stufe zurückzuführen ist, auf etwas in den experimentellen RP2040-CMSIS-Dateien, die ich von jemand anderem ausleihen musste, oder auf etwas ganz anderes, ist derzeit schwer zu sagen.

Nachdem wir einige Stunden damit verbracht hatten, den Bare-Metal-RP2040 mit zusammengewürfelten CMSIS- und Second-Stage-Bootloader-Dateien zum Laufen zu bringen, schien es der richtige Zeitpunkt zu sein, ein paar Schritte zurückzutreten und eine Neubewertung vorzunehmen. Seit meiner ersten Evaluierung des RP2040 wurde die CMSIS-Funktionsanfrage im Pico SDK-Tracker erfreulicherweise mit dem Vorschlag aktualisiert, dass die offizielle CMSIS-Unterstützung mit der Version 1.2.0 des Pico SDK hinzugefügt werden könnte.

Ich halte es für sinnvoll, dass jeder, der sich mithilfe branchenüblicher Tools mit dem RP2040 vertraut machen möchte, auf diese Veröffentlichung wartet. Sobald es fällt, werde ich wahrscheinlich zuerst das Nodate Blinky-Beispiel noch einmal durchgehen und mir dann schließlich das PIO-Peripheriegerät ansehen. Nachdem ich mich über die Zwei-Zustands-Maschinen-Architektur informiert habe, scheint sie interessant genug zu sein. Nicht so leistungsstark wie ein CPLD oder FPGA, aber dennoch äußerst nützlich.

Das einzelne RP2040-„Datenblatt“ (eher ein Referenzhandbuch und ein zusammengefügtes Datenblatt) scheint manchmal zu vergessen, dass es eigentlich die MCU abdecken soll, und wird zu einem Pico SDK-Tutorial. Während es für diejenigen nützlich ist, die das SDK verwenden möchten, ist es für diejenigen, die ihre eigene Implementierung schreiben, deutlich weniger nützlich.

Von der komplizierten GPIO-Peripherie, dem komplizierten Multi-Core-Boot-Prozess und der zusätzlichen Hürde, einen Bootloader der zweiten Stufe zusammen mit einem intransparenten externen ROM integrieren zu müssen, ist vieles davon ziemlich ermüdend. Sie werden das offizielle SDK verwenden wollen.

Wenn man sich einmal an diese Designoptionen gewöhnt hat, kann es sein, dass sie nicht mehr so ​​störend wirken. Oder vielleicht geht es einfach nur darum, den RP2040 in die Standard-Toolchain einzubinden. Schließlich ist jede neue MCU eine Art Lernerfahrung.