Erfahrungsaustausch zum RasPi Pico (RP2040)

[mumpf]

Hi, angeregt durch diese Aussage

Mein Prototyp wächst und gedeiht.
Mein Multicore-Konzept trägt auch soweit ich das bisher testen konnte: der KNX Stack und die KNX-Applikation laufen auf dem Core0. Die Sensoren laufen auf dem Core1.
Somit sind blockierende Zugriffe auf den I2C z.B. egal.

wollte ich ein paar Fragen zum RP2040 los werden, wollte aber nicht den anderen Thread zumüllen. Bei meinen kläglichen Versuchen mit dem RP2040 bin ich noch lange nicht so weit, einzelne Cores nutzen, deswegen dachte ich, dass man hier mal Erfahrungen teilen könnte, die "Projektübergreifend" den RP2040 betreffen.

Was kann ich bieten? Dank der Vorarbeiten von Ing-Dom konnte ich den KNX-Stack von Thomas thesing in PlatformIO mit dem Arduino-Framework zum laufen bringen (beim Prog-Button hakt es noch, aber das finde ich noch raus). Bei Interesse kann ich das gerne ausführen. Sind viele Sachen dabei, die noch nicht in PIO integriert sind.

Gibt es noch jemand, der mit PlatformIO arbeitet? Vielleicht können wir uns über die "richtige" platformio.ini austauschen?

Und wie macht man das mit 2 Cores? Da bräuchte ich einen Tipp bzw. ein Beispiel, aus dem ich lernen könnte...

Ing-Dom: Ursprünglich wollte ich Dich direkt per PN fragen, aber ich finde, solche Sachen sind vielleicht auch für andere Interessant, deswegen ein neuer Thread.

Gruß, Waldemar

[Ing-Dom]

Ing-Dom: Ursprünglich wollte ich Dich direkt per PN fragen, aber ich finde, solche Sachen sind vielleicht auch für andere Interessant, deswegen ein neuer Thread.

Kann ich nur befürworten.

Ich gehe davon aus dass der inoffizielle PiPico Core von Earle F. Philhower genutzt wird.

Dann gibts hier https://arduino-pico.readthedocs.io/...en/latest/pdf/ viele Infos dazu. Kap. 4 zu PlatformIO (nutze ICH nicht - ich arbeite mit VSC).


Zu Multicore wäre das Kapitel 16 aus dem obigen PDF lesenwert. Und natürlich die Doku vom SDK: https://datasheets.raspberrypi.com/p...pico-c-sdk.pdf


Am Ende ist es ganz einfach:
man definiert eine nicht endende Funktion und startet diese:

multicore_launch_core1(loop_core1);

Entscheidend ist natürlich der Datenaustausch. Dazu gibts verschiedene Mechanismen, z.B. threadsichere FIFO Buffer.
Oder ganz basic, mutex (das nutze ich).

Was aber wichtig zu wissen ist: Der Zugriff auf variablen bis 32bit ist thread-safe, wenn ich also in einem core sensordaten abfrage und im anderen verarbeite, kann ich die einfach in einem int oder double speichern und mich darauf verlassen dass ein einzelner wert immer korrekt ist. Bei größeren Datenstrukturen ist das nicht der Fall.


Ich persönlich bin bisher am Debugging gescheitert und wäre da an Austausch interessiert. Man kann ja einen RP2040 mit einem PiPico mit der "Picoprobe" FW debuggen, aber für ein Vorgehen bei Nutzung des Arduino Cores habe ich noch keine Anleitung gefunden. Die, die es gibt gehen von einer Nutzung des SDK aus (cmake)...

[mumpf]

Hi,

danke erstmal für die erste ausführliche Antwort. Ich komme gerade von Conrad, hab mir da 2 Pico gekauft, einen für ne picoprobe, den anderen als Reserve (weil ich mich geärgert habe, dass ich nicht gleich 2 Pico gekauft habe). Debuggen ist somit als nächstes auch bei mir dran, werde nachher noch mehr dazu schreiben.

Ich nutze auch den Core von Philhower. Dane für den Link zur Doku, evtl. hatte ich das schon gesehen, muss ich noch verifizieren. Komplett gelesen hab ich es noch nicht.

PlatformIO (nutze ICH nicht - ich arbeite mit VSC).

Nur interessehalber: Du nutzt VSC mit Arduino extension, oder? Gibt es einen Grund, nicht PIO zu nutzen? Anders gefragt: Machst Du es nicht, weil Du keine Erfahrungen damit hast oder weil Du schlechte Erfahrungen gemacht hast?

Die Infos zum Multicore (Kapitel 16) werde ich mir heute Abend "reinziehen". Die Kommunikation ist mir prinzipiell klar, ich frage mich, wie man einem Stück Coding sagt, auf welchem Core es laufen soll. Aber das werde ich sicher im Kapitel 16 finden.

Debugging kommt bald (mach Dir keine großen Hoffnungen, ich hab nur Teilerfolge), muss erstmal meinen Kleinen vom Kindergarten abholen.

Bis dann,
Waldemar

P.S.: Bin gespannt, wie lange das ein Thread sein wird, in dem nur wir beide uns unterhalten...

[mumpf]

So, zum Thema Debugging:

Ich hatte ursprünglich mit dem offizellen Core für den RP2040 (mit PIO) angefangen. Da das Blink-Beispiel programmiert und versucht, es zu debuggen. Ich habe den Segger JLink EDU mini, und weil PIO für den Core auch JLink zuließ, hab ich es einfach probiert. Der Debugger kam zwar hoch, aber während er sagte, dass er bei einem Breakpoint an der init() steht, blinkte mein Board fröhlich vor sich hin. Das war es also nicht.

Das nächste, was ich probiert hatte, war https://github.com/majbthrd/pico-debug, der implementiert einen CMSIS-DAP Debugger auf dem 2. Core, so dass man damit den 1. Core debuggen kann. Und da PIO auch CMSIS-DAP unterstützt, dachte ich das wäre eine gute Idee. Wobei dann natürlich nur single-core Anwendungen debugbar sind, ferner fällt der Serial für die Console weg, weil der Debugger den USB braucht. Ich bin hier so weit gekommen, dass PIO den CMSIS-DAP-Debugger gefunden hat, aber noch vor der Debug-Session abgebrochen ist. Da hab ich dann aufgegeben.

Bei meinen Recherchen bin ich dann noch auf die Info gestoßen, dass man für JLink und RP2040 unbedingt die neueste Version der SEGGER-Software (der Windows-Treiber) haben sollte. Nach einem Update habe ich nochmal Variante 1 versucht und das funktionierte dann. Das ist der Teilerfolg. Ich konnte mit

• offiziellem Core für den RP2040
• PIO in der neusten Version
• SEGGER Software in der neusten Version
• JLink-Probe

den Pico debuggen, allerdings nur einen Kern (ich sehe nur einen, der 2. taucht im Callstack-Fenster gar nicht auf).

Erst dann (leider) habe ich gesehen, dass Du die Portierung für den Philhower-Core gemacht hast, primär hier wohl wegen der EEPROM-Emulation (vermute ich). Leider ist dieser Stack noch nicht in PIO integriert, aber es gibt einen PR und ein frei verfügbares Beispiel (https://github.com/maxgerhardt/pio-p...philhower-test). Hab erstmal den gebaut (das hat alleine 20-30 Minuten gedauert) und damit das Blink-Beispiel zum Laufen gebracht.
Dann den knx-Stack gebaut, mit knx-demo geflasht und es läuft, bis auf den PROG-Button. Die Prog-LED hab ich dann über die ETS blinken lassen, so dass ich dann final das 3. und komplizierteste Blink-Beispiel hatte. Leider unterstützt der inoffizielle core nur picoprobe zum debuggen, deswegen habe ich jetzt 2 neue Pico.

Also:
Positiv - ich konnte schon den RP2040 debuggen.
Negativ - noch nicht auf der Zielarchitektur, da bin ich aber dran.

Ich weiß derzeit nur nicht, wie Dir das mit VSC+Arduino helfen kann, weil dort ja die ganze Toolchain mit gdb, anpassung an VSC usw. nicht vorhanden ist. Und das stellt ja PIO zur Verfügung, sprich da kenne ich mich nicht aus.

Ich werde trotzdem berichten, wie es weiter geht, vielleicht kann man Dich ja noch zu PIO überreden.

Gruß, Waldemar

[mumpf]

Zu Multicore wäre das Kapitel 16 aus dem obigen PDF lesenwert.

Vielen Dank - ich verstehe gar nicht, warum ich das PDF nicht gefunden habe. Das entsprechende pio-test-Projekt habe ich ja gefunden. Mir fehlten eigentlich nur die 2 Zeilen:

By adding a setup1() and loop1() function to your sketch you can make use of the second core. Anything called from within the setup1() or loop1() routines will execute on the second core.

Alles andere ist zwar nicht trivial, aber wird schon. Jetzt muss ich mal meine picoprobe löten und dann sehen wir weiter.

Gruß, Waldemar

[mumpf]

Noch eine weitere Frage zum RP2040, hab dazu auch nichts gefunden.

Wird wirklich immer der Sketch beim Start komplett vom Flash ins Ram kopiert? Oder läuft der Programmcode (einen passenden instructuion cache vorausgesetzt) eigentlich vom Flash?

Hintergrund: Eigentlich will ich ja mein Logikmodul auf den RP2040 kopieren und langfristig noch mehr/komplexere Logiken haben. Dafür brauche ich aber mehr KO und damit mehr RAM. Wenn ich jetzt mit dem SAMD vergleiche, da lief der komplette Sketch im Flash, die Parameter waren im Flash, im Ram brauchte ich nur die KOs, Heap und Stack zu halten. Somit hatte ich 256k Flash + 32k RAM = 288k zur Verfügung.

Wenn im RP2040 alles im Ram vorgehalten wird, dann hab ich nur 264k und das wars. Das wäre sogar schlechter als beim SAMD (außer die binaries werden kleiner, was ich aber bei gleichem Kern M0+ nicht erwarte).

Weißt Du da was bzw. hast Du einen Tipp, wo ich das nachlesen kann? Ich hab mal versucht, das Datasheet zu lesen, aber da bin ich ehrlich gesagt überfordert.

Gruß, Waldmar

[Ing-Dom]

Nur interessehalber: Du nutzt VSC mit Arduino extension, oder? Gibt es einen Grund, nicht PIO zu nutzen? Anders gefragt: Machst Du es nicht, weil Du keine Erfahrungen damit hast oder weil Du schlechte Erfahrungen gemacht hast?

keine Erfahrung mit Plattform IO. Ich hab lange (zu lange) mit der Arduino IDE entwickelt und war dann mit VSC sehr happy, auch weil dann das debuggen vom SAMD so gut geklappt hat. Man kann sich wenn man sowas hobbymäßig macht ja nicht immer alles anschauen und gegeneinander abwägen, dafür fehlt dann die Zeit.

Mir fehlten eigentlich nur die 2 Zeilen:

gut, DAS ist sozusagen der Arduino Ansatz, extrem simpel nutzbar, aber stark eingeschränkt. Daher nutze ich die SDK Funktion um meinen 2. Core zu starten, weil ich meinen Loop1 erst starten will, wenn das Setup (das am Core0 läuft) fertig ist. Aber kann man natürlich auch lösen.

Wird wirklich immer der Sketch beim Start komplett vom Flash ins Ram kopiert? Oder läuft der Programmcode (einen passenden instructuion cache vorausgesetzt) eigentlich vom Flash?

Nein nein, Natürlich wird NICHT der Programmcode ins RAM kopiert, und schon gar nicht alles auf einmal
Es ist ja auch nur ein Cortex M0, also Harvard Architektur. Die Instruktionen werden über den XIP gecashed, weil sonst selbst der QSPI Flash zu lahm wäre. Der XIP hat 16k.
Du brauchst dich darum 0,0 kümmern. Programmcode liegt im Flash und nimmt dir keinen Ram weg. Außer für spezielle Funktionen aus dem SDK wie z.B. das schreiben das Flashes.

Mit einem 16MB Flash der unterstützt wird hast du praktisch gesehen unendlich viel Möglichkeiten was Parameter angeht.

Erst dann (leider) habe ich gesehen, dass Du die Portierung für den Philhower-Core gemacht hast, primär hier wohl wegen der EEPROM-Emulation (vermute ich)

Nein, die EEPROM Simulation war es nicht. Die bekäme ich auch selbst hin, und muss ich sowieso mal noch anpassen denn 4k sind definitiv zu wenig.
Zum offiziellen Core hab ich kaum Doku gefunden, das hat mich extrem gestört. Und dann war mir mbed einfach ne Nummer zu fett.

[Ing-Dom]

achja, wenn du das mit dem debuggen mit picoprobe und plattform IO hinbekommst wäre das schon was wo ich mir mal plattform IO anschauen würde.
Das schöne an VSC Projekten ist halt, die kompilieren auch mit der IDE... ich finde es gut, wenn die Einstiegshürden in Projekte gering sind (im Sinne von Mitstreiter gewinnen).

[mumpf]

Hi,

keine Erfahrung mit Plattform IO.

das ist gut, zumindest besser als schlechte Erfahrungen . Ich bin zwar noch nicht so lange dabei, aber für mich war die Arduino IDE keine, die den Namen verdient. Und VSC war natürlich besser, aber nachdem ich PIO versucht habe, wollte ich nicht wieder zurück. Und mir geht es genau so wie Dir, um zu wechseln, fehlt mir die Zeit. Kann ich somit vollkommen nachvollziehen.

Natürlich wird NICHT der Programmcode ins RAM kopiert, und schon gar nicht alles auf einmal

OK, das beruhigt mich. Konnte mir auch nicht anders vorstellen, aber fand es nirgendwo bestätigt. Dann hab ich ja jetzt wirklich genug RAM für eine große Logik-Applikation.

und muss ich sowieso mal noch anpassen denn 4k sind definitiv zu wenig.

Das wäre auch meine Frage, wie man das sinnvoll erweitern kann. Ich brauche jetzt schon 10k für die Parameter, ohne Address- und Association-Table. Wenn Du da was machst, wäre es toll, wenn die Größe wählen könnte oder gleich auf 32k oder so erhöhen.

achja, wenn du das mit dem debuggen mit picoprobe und plattform IO hinbekommst wäre das schon was wo ich mir mal plattform IO anschauen würde.

Da stecke ich zurzeit fest. Ich kann auf meinem Win-Rechner den Treiber für den picoprobe nicht installieren. Such noch nach einem Grund. Heute komme ich sowieso nicht weiter...

Das schöne an VSC Projekten ist halt, die kompilieren auch mit der IDE...

Das schöne an PIO-Projekten ist, dass sie alle Abhängigkeiten selbst installieren können. Das ist schon cool, und verringert die Einstiegshürde eher...

Ich mach mal weiter und falls ich erfolgreich bin, können wir vielleicht mal eine Online-Session machen. Ich könnte Dir das zeigen (wenn Du willst).

Gruß, Waldemar

[Ing-Dom]

Das schöne an PIO-Projekten ist, dass sie alle Abhängigkeiten selbst installieren können. Das ist schon cool, und verringert die Einstiegshürde eher...

das ist wirklich cool. Ich hab schon überlegt ob ich alle Libs mit ins Repo packe..

OK, das beruhigt mich. Konnte mir auch nicht anders vorstellen, aber fand es nirgendwo bestätigt. Dann hab ich ja jetzt wirklich genug RAM für eine große Logik-Applikation

Ist ja beim SAMD21 auch nichts anderes. Nur hängt der Flash an einem internen Datenbus...

Das wäre auch meine Frage, wie man das sinnvoll erweitern kann. Ich brauche jetzt schon 10k für die Parameter, ohne Address- und Association-Table. Wenn Du da was machst, wäre es toll, wenn die Größe wählen könnte oder gleich auf 32k oder so erhöhen.

Wählbar wäre natürlich sinnvoll. Ich würde das wenn dann auch gerne direkt in den core integrieren, wäre auch nicht mein erster PR und mit dem Earle kann man reden.
Ich frage mich allerdings ob EEPROM-Emulation wirklich sinnvoll ist und man nicht eher den weg gehen sollte Flash direkt einzubinden.. aber das im ganzen Stack zu ändern ist mir ne Nummer zu groß.

Ich mach mal weiter und falls ich erfolgreich bin, können wir vielleicht mal eine Online-Session machen. Ich könnte Dir das zeigen (wenn Du willst).

klingt gut.

[mumpf]

So, kurzer Zwischenstand:

Ich darf auf meinem Rechner keine unsignierten Treiber installieren und die "Selbstsignierung" ist verboten (liegt daran, dass es ein fremdverwalteter Rechner ist). Picoprobe ist so auf dem Rechner nicht nutzbar.
=> Ich werde das Ganze jetzt erneut auf einer VM durchbauen und da testen .

Gruß, Waldemar

[mumpf]

Zwischenstand: Nach einer kleine Pause wegen Arbeit und Stammtisch Wiesbaden hab ich jetzt eine VM, auf der ich alles installieren konnte + durfte. Alles baut durch, aber ich kann nicht über USB Flashen. Scheinbar werden die USB-Ports von der VM nicht sauber durchgereicht. Nächste Baustelle... .

Werde weiter berichten.

Gruß, Waldemar

[mumpf]

Übrigens...

Ich frage mich allerdings ob EEPROM-Emulation wirklich sinnvoll ist und man nicht eher den weg gehen sollte Flash direkt einzubinden.. aber das im ganzen Stack zu ändern ist mir ne Nummer zu groß.

Ich stimme Dir hier zu, sehe mich aber ebenfalls außerstande, das irgendwie zu realisieren. Deswegen ich eine EEPROM-Emulation zwar die 2. Wahl, aber besser als gar nichts.

Irgendwann musst Du mir dann nochmal erzählen, wie Du das mit Firmwareupgrade über KNX machst. Ich baue mir zwar meine Sensoren immer so ein, dass ich unter einer Abdeckung noch einen JTAG-Kabel habe, so dass ich auch in eingebautem Zustand flashen kann, aber selbst dafür bin ich manchmal zu Faul. Und bei 20 Geräten wäre es schön, wenn man einfach mal jede Nacht mal ein update machen kann. Und wenn man es noch so hin bekommt, dass der KNX-Stack nicht dabei ist (so oft ändert sich ja daran nichts - zumindest nicht für die eigene Anwendung), dann sollte das vielleicht auch vertretbar schnell gehen (<30 Minuten). Aber das ist Zukunftsmusik, jetzt muss erstmal debugging klappen...

Gruß, Waldemar

[willisurf]

Scheinbar werden die USB-Ports von der VM nicht sauber durchgereicht

Welche VM benutzt Du denn. Ich meine mich zu erinnern, das ich bei VirtualBox ein Extension Pack installieren musste.

[mumpf]

Ich nutze VMWare (was anderes darf ich nicht auf dem Rechner). Und die VMWare-Tools sind auch schon aktuell. Aber ich versuche mich ins Portsharing gerade reinzulesen. Ich sehe die beiden Pico durchaus als COM3 und COM4, PlatformIO findet die auch, aber der USB-Flasher rp2040load 1.0.1 findet die nicht. Wollte da mal nachlesen, ob ich da noch was einstellen kann. Ist nicht so zufriedenstellend, wenn man sich dann nicht mal auf die USB-Ports verlassen kann. Frustrierend ist, dass ich gar nicht an der Stelle weiter komme, die mich eigentlich interessiert, nämlich das Debuggen.
Umgekehrt: Erst wenn irgendwo Fehler passieren, lernt man ja so richtig, was da passiert und weiß dann später, wo man reinschauen muss. Insofern ist das nicht wirklich schlecht und ich tauche gerne mal tiefer in irgendein Problem ein.
Aber derzeit ist es immer so, dass wenn ich ein Problem löse, kommt sofort das nächste in der Kette, es sollte nicht toolchain sondern problemchain heißen.

Aber Danke für Deinen Tipp.

Gruß, Waldemar