Hallo, diese Frage ist nur die gerichtet, die wirklich schon mit dem Raspberry Pico/RP2040 gearbeitet haben. Es geht um die PIOs auf dem RP2040. Eigentlich wollte ich in meinem Projekt ein STM32F103 (das selbe wo ich viele Schiebregister benutzten werde) verwenden und 40 Pinne klassisch über 40 IO-Pinne auslesen. Jedoch spiele ich langsam mit dem Gedanken einen RP2040 zu nehmen und fünf 8-Bit PISO-Schieberegister zu nehmen (z.B. 74HC165). Der RP2040 ist mit etwas mehr als 1€ viel günstiger als ein STM32F103 (selbst mit den zuätzlichen Flash, weil wenn brauche ich auch einen der größeren der über 10€ kosten würde) und es macht auch Leiterbahnen plazieren einfacher (und die Verfügbarkeit vom RP2040 ist besser. Bis vor paar Monaten waren die STM32F103 ja kaum zu bekommen wie viele andere MCUs). Diese PISOs will ich in Reihe hängen und mit den PIOs im RP2040 will ich diese auslesen. Würde das gehen (ohne große Probleme) und würde das große einbusen bei der IO Geschwindigkeit haben? Auf der anderen Seite habe ich auch von Projekten gelesen, wo mit den PIOs VGA und gar DVI ermöglicht wurden.
David G. schrieb: > diese Frage ist nur die gerichtet, die wirklich > schon mit dem Raspberry Pico/RP2040 gearbeitet haben. Schöne Ansage, wird dir hier nichts nützen… ;-) > Würde das gehen (ohne große Probleme) Selbst ohne kleine Probleme! ;-) Die zwei PIOs haben je vier SMs welche völlig unabhängig laufen. Da die Schieberegister alle gleich angesteuert werden, kannst du ein PIO-ASM Programm schreiben und das auf jeder SM laufen lassen. > und würde das große einbusen bei der IO Geschwindigkeit haben? Keinerlei Einbußen. Die PIOs können mit dem vollen Systemtakt laufen. Die dazugehörigen FIFO-Inhalte lassen sich per DMA direkt ins RAM transferieren. Ich behaupte einfach mal das du noch nicht einmal mit Assembler-Programmierung und ›Bit-Banging‹ ansatzweise die Geschwindigkeit erreichen würdest.
Also im Prinzip SPI? Das kann der RP mit 62,5 MHz und DMA, also schneller als viele andere uC.
Und im Gegensatz zum F103 hat der RP2040 sogar zwei Cores... eine sehr feine Sache. Einzig die Grundschaltung (wegen des Flashs) ist ein wenig "komplizierter" als die des F103.
J. S. schrieb: > Das kann der RP mit 62,5 MHz und DMA, also > schneller als viele andere uC. Wegen der SPI FIFOs (8 x 16 Bit) kann man DMA auch weglassen. Rene K. schrieb: > Und im Gegensatz zum F103 hat der RP2040 sogar zwei Cores... eine sehr > feine Sache. Dann erzähl doch mal, wofür Du den 2. Kern verwendet hast, ohne daß der 1. Kern diese Dinge miterledigen konnte ;-)
m.n. schrieb: > J. S. schrieb: >> Das kann der RP mit 62,5 MHz und DMA, also >> schneller als viele andere uC. > > Wegen der SPI FIFOs (8 x 16 Bit) kann man DMA auch weglassen. > > Rene K. schrieb: >> Und im Gegensatz zum F103 hat der RP2040 sogar zwei Cores... eine sehr >> feine Sache. > > Dann erzähl doch mal, wofür Du den 2. Kern verwendet hast, ohne daß der > 1. Kern diese Dinge miterledigen konnte ;-) Für meinen WS2812 Controller... Ein Kern kümmert sich ausschließlich um die Grafikberechnung und die Ausgabe der Pixel und der andere Kern übernimmt die Abarbeitung der Alexa Integration und des Webservers.
m.n. schrieb: > Wegen der SPI FIFOs (8 x 16 Bit) kann man DMA auch weglassen. Während der DMA läuft kann die CPU ja schon weiter rechnen, warum sollte man das nicht nutzen?
J. S. schrieb: > m.n. schrieb: >> Wegen der SPI FIFOs (8 x 16 Bit) kann man DMA auch weglassen. > > Während der DMA läuft kann die CPU ja schon weiter rechnen, warum sollte > man das nicht nutzen? Vor allem kann man die DMA Controller derart programmieren, das sie sich selbst am Laufen halten wenn man die maximale Abtastrate braucht. OHNE CPU Interaktion!
J. S. schrieb: > Während der DMA läuft kann die CPU ja schon weiter rechnen, warum sollte > man das nicht nutzen? Zum Ausgeben kann man die Daten direkt ins TX-Register schreiben, als zunächst den DMA-Puffer vorzubereiten und dann die Ausgabe zu aktivieren. Das Einlesen erfolgt parallel zur Ausgabe, da ja der Takt erzeugt werden muß. Diese Daten laden im RX-FIFO und können dort abgeholt werden. Senden und Empfangen laufen auch ohne DMA im Hintergrund ab und ist für den TO daher kein unbedingtes Muss. DMA wird interessant, wenn größere Felder übertragen werden sollen. Mit lvgl zum Beispiel ;-)
m.n. schrieb: > Das schafft auch ein Kern alleine. Ja selbstverständlich... aber auf Kosten der Wiederholrate der WS2812... nicht wegen der Ausgabe, sondern wegen der Berechnung des Inhaltes - So ist das gesondert. Dafür würde es dann wieder einer Statemachine bedürfen, und die kostet auch wieder Zeit.
Ist ja in Ordnung ;-) Meist ist der Hinweis auf die beiden Kerne ein Scheinargument, weil sie garnicht benötigt werden. Der Umgang damit will auch gut überlegt sein.
Oh Man, da fragt man nur was mit dem PIO und Schieberegister und dann beginnt das in einem Krieg über ein Kern oder zwei Kerne. Aber nachdem ich hier das alles gelesen habe, habe ich mich entschieden den RP2040 zu nehmen. Mit dem Kernen gebe ich einfach mal meinen Senf dazu: Erst muss man sich die Frage beantworten: Kann man über haupt meinen Task auf mehr als einen Kern aufteilen? Wenn nein, keine weitere Diskusion. Wenn ja, dann kann man diskutieren. Theoretisch kann man alles mit Taktfrequenz erschlagen, aber wenn man auf dem Markt guckt, warum gibt es so viele Mehrkern MCUs, MPUs und SOCs.
Angehängte Dateien:
-
Unbenannt.png
3,3 KB
David G. schrieb: > Oh Man, da fragt man nur was mit dem PIO und Schieberegister und dann > beginnt das in einem Krieg über ein Kern oder zwei Kerne. Oh gott, das war doch kein Krieg :-D Das war eine ernst gemeinte, und wohlig formulierte Frage von m.n. - welche ich beantwortete. Er hat mit seiner Meinung auch völlig recht. Mehrere Kerne: da wo sie passen! Bei mir hat das super gepasst. David G. schrieb: > Theoretisch kann man alles mit Taktfrequenz erschlagen, aber wenn man > auf dem Markt guckt, warum gibt es so viele Mehrkern MCUs, MPUs und > SOCs. Ja das ist und war auch das Problem bei Rechnern allgemein, die Abarbeitung wird immer effizienter, so das eine hohe Taktzahl sich nicht mehr positiver auswirkt. Im Grunde geht es nun nicht mehr nach oben, sondern in die Breite - und das ist gut so. Das fordert natürlich ein gewisses Umdenken in einigen belangen. Aber das auch das schafft man... Das ist wieder Umstieg von C auf C++... Wenn man jahrelang C geschrieben hat, fällt einem die Denkweise zur OO-Programmierung relativ schwer. Wenn ich mir so die Laufbahn meines Homeservers anschaue - früher waren es mal 4 Kerne mit hohem Takt... heute siehe Bild mit niedrigem Takt - rate mal was deutlichst besser performt?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.