Moin Zusammen,
Ich dachte wie reden mal etwas ueber den RP2040, also den Controller auf
dem Pi Pico. Den Controller gibt es uebrigens bei Reichelt einzeln fuer
1Euro.
Auch wenn man noch ein externes Flash braucht, fuer das gebotene ist er
damit sehr sehr preiswert.
Ich hab mir aus Spass mal einen besorgt und programmiere den mit einem
selbst aufgebauten System, also mit make und ohne die absurde
Monsterumgebung
vom Hersteller. Download ueber JLink. Also sehr traditionell, sogar mit
Emacs. .-)
Spass bedeutet das ich derzeit kein konkretes Projekt damit vorhabe, es
geht erstmal darum mit einem Dualcore zu spielen.
Das funktioniert auch schon super. Soll heissen, SIO/GPIO, RS232, I2C,
SPI und zweiter Core laufen.
Das mit dem zweiten Core ist natuerlich schon irgendwie cool. Ich hab
damit derzeit ein kleines 128x64 Oled im Hintergrund laufen.
Was mich interessieren wuerde, wofuer wuerdet ihr eigentlich einen
zweiten
Core verwenden? Also wie Software aufteilen? Man hat immer ein bisschen
den Eindruck: Ach dafuer ist der zweite Core jetzt zu schade, fuer den
brauch ich noch eine besondere Aufgabe. :-D
Dann wuerde ich denjenigen die das Teil noch nicht kennen, aber dafuer
viele andere Microcontroller, mal empfehlen das Datenblatt zu lesen. Das
ist eigentlich eine interessante Lektuere. Zum einen hat man den
Eindruck als wenn die Peripherie im Vergleich zum ueblichen was man so
kennt relativ arm/einfach ist. Andererseits gibt es aber auch einige
komplett neue Ideen.
Ein Beispiel: Es gibt von den Systicks mal abgesehen nur einen Timer und
der ist auch noch relativ doof. Dafuer ist er aber 64Bit breit.
(vermutlich kein Ueberlauf solange ihr lebt)
Ich hab ein bisschen den Eindruck als wenn der Controller von einem
Programmierer und nicht von einem Hardwareentwickler entworfen wurde.
Auf jeden Fall ein interessantes Konzept. Nicht besser oder schlechter,
anders!
Olaf
> Was mich interessieren wuerde, wofuer wuerdet ihr eigentlich einen> zweiten Core verwenden?
Ich spiele mit der Idee, mit dem RP2040 einen SDR aufzubauen, und die
beiden Cores würde ich nutzen, um echt parallel das I und Q-Signal
gleichzeitig zu verarbeiten.
Aber sicher gibt's auch Anwender, die die beiden Cores dazu nutzen, 2
LEDs unabhängig voneinander blinken zu lassen... :-)
Olaf schrieb:> Ich hab mir aus Spass mal einen besorgt und programmiere den mit einem> selbst aufgebauten System, also mit make und ohne die absurde> Monsterumgebung> vom Hersteller.
Die ist zwar tatsächlich einigermaßen monströs, aber nicht sinnlos.
Irgendwie muss man halt den Vendor-LockIn schaffen, gelle?
> es> geht erstmal darum mit einem Dualcore zu spielen.
Das ist doch recht langweilig. Viel interessanter sind die PIOs.
> Was mich interessieren wuerde, wofuer wuerdet ihr eigentlich einen> zweiten> Core verwenden?
Wenn ich mehr Rechenpower brauche, als ein Core liefern kann. Für was
denn sonst?
> Ein Beispiel: Es gibt von den Systicks mal abgesehen nur einen Timer
Das stimmt nun schonmal garnicht. Ich glaube, du brauchst noch die eine
oder andere Iteration beim DB-Lesen...
Das dazu noch kaum was im Netz gibt, dachte ich es interessiert
vielleicht
jemanden wie man etwas mit einem Jlink reinladen kann.
Einfach das hier ins Makefile eintragen:
1
#Das Binaerfile mit dem JLink in das Flash am RP2040 schreiben
Wie ihr seht benutze ich eine relativ neue Version der Firmware. Aeltere
Versionen funktionieren entweder garnicht oder sind buggy.
GDB steht aber noch aus. Wird bestimmt auch interessant weil man ja zwei
cores hat.
Ausserdem bedenkt, nicht jeder alte JLink kann mit dem RP2040 umgehen!
Bei Segger gibt es irgendwo eine Liste welche Hardwareversion ihr
braucht.
> Das ist doch recht langweilig. Viel interessanter sind die PIOs.
Jaja, ich weiss. Ich kenne das Konzept vom 68332. Darum kuemmere ich
mich schon noch. .-)
> Das stimmt nun schonmal garnicht. Ich glaube, du brauchst noch> die eine oder andere Iteration beim DB-Lesen...
Das will auch erstmal nicht widersprechen!
Aber 64Bit Timer ist doch schonmal cool oder? Ich hab mich bisher oft
gefragt wieso die woanders meist nur 16 oder 32Bit sind. So ein paar
Register machen den Verilogcode doch nicht fett.
Olaf
> zweiten Core
Es soll schon eine Weile Controller geben, die sogar 3 Cores haben.
Und die Cores nicht blos mickrigeARM M0 sind.
Die koennen nicht mal 32 bit mit 32 bit zu 64 bit multiplizieren.
Damit kannst du
> mit dem RP2040 einen SDR aufzubauen
naemlich vergessen.
Cartman schrieb:> Es soll schon eine Weile Controller geben, die sogar 3 Cores haben.> Und die Cores nicht blos mickrige ARM M0 sind.> Die koennen nicht mal 32 bit mit 32 bit zu 64 bit multiplizieren.
Leistung ist relativ! Es wurden schon SDRs auf AVRs programmiert. Da
wirkt dann ein Dual-Core mit M0 und 133 MHz doch wie ein Bolide.
Unabhängig davon findet man auch µC, da wirkt dann ein Cortex-M4
mickrig...
> Leistung ist relativ!
Yep, ich hab schon schon andere Kisten programmiert.
Aber man muss den Preis und die gute Verfuegbarkeit sehen.
Und ja die GPIOs sind auch interessant!
Olaf
Olaf schrieb:> Aber man muss den Preis und die gute Verfuegbarkeit sehen.> Und ja die GPIOs sind auch interessant!
Es sind nur leider zu wenige. Wenn man ein paralleles LCD anschließt,
muss man sich auf 12bpp beschränken, um wenigstens noch 10 Pins frei zu
behalten. Naja, einige LCDs kommen ohne HSYNC und VSYNC aus, die
brauchen nur DE zum synchronisieren, mit solchen Displays kommt man dann
auf 12 freie GPIOs. Auch immer noch ein bissel mager für viele
Anwendungen.
Geil ist aber immerhin, dass das Teil sowohl die Hardware hat, um solche
LCDs anzusteuern (PIO sei dank) als auch genug RAM, um einen echten
Framebuffer zu realisieren (wenn auch nur mit 12bpp und relativ
bescheidener Auflösung).
Und das allerbeste: die komplette Displayeinheit kann völlig unabhängig
von den MCU-Kernen laufen.
Frage: Der RP2040 hat im Bootrom eine Floating Point Library.
Weiss jemand zufällig warum das gemacht wurde?
Diejenigen, die eine Software Floating Point Lib brauchen, hätten es ja
direkt in den Code linken können. Hat jemand Infos / Ideen?
> Frage: Der RP2040 hat im Bootrom eine Floating Point Library.> Weiss jemand zufällig warum das gemacht wurde?
Wenn ich raten soll wuerde ich sagen, der Platz war halt da und sie
wussten nicht was sonst damit machen. :-)
Ich denke das passt zu meiner Vermutung das der gesamte Controller eher
von einem Softwareentwickler als einem Hardwaremenschen designt wurde.
Ich bin mal gespannt ob es irgendwann rauskommt wie man dieses Bootrom
loescht und durch was eigenes ersetzt. Es wird ja sicherlich auch nur
ein kleines Flashrom sein.
Olaf
>Ich bin mal gespannt ob es irgendwann rauskommt wie man dieses Bootrom>loescht und durch was eigenes ersetzt.
Ein ROM kann man schon aufgrund der Definition "Read Only Memory" nicht
löschen.
> Ein ROM kann man schon aufgrund der Definition "Read Only Memory" nicht> löschen.
Woher willst du wissen ob das echt ein Maskenprogrammiertes ROM ist
und nicht nur ein Flashrom wo man uns ein paar Details verschweigt?
Das ist in der Branche ja durchaus nicht unueblich und ich meine
es gibt auch bereits unterschiedliche Versionen des Inhalts.
Olaf
> Frage: Der RP2040 hat im Bootrom eine Floating Point Library.> Weiss jemand zufällig warum das gemacht wurde?
Hauptgrund wohl, dass allen optimierte FP-Routinen zur Verfügung stehen.
Diese können ggf (oder in späteren Revisionen) undokumentierte Features
der CPU zur Beschleunigung nutzen. Selbst wenn irgendwann mal eine
komplette FPU implementiert wird, braucht man nur die Routinen anpassen
und alle Programme benutzen automatisch (ohne neucompilieren) die neue
FPU.
Olaf schrieb:> Woher willst du wissen ob das echt ein Maskenprogrammiertes ROM ist
Ich meine gelesen zu haben, dass es maskenprogrammiert ist
(finde gerade die Stelle nicht).
Der Sourcecode des Bootrom liegt übrigends unter
https://github.com/raspberrypi/pico-bootrom
Olaf schrieb:> Was mich interessieren wuerde, wofuer wuerdet ihr eigentlich einen> zweiten> Core verwenden? Also wie Software aufteilen? Man hat immer ein bisschen> den Eindruck: Ach dafuer ist der zweite Core jetzt zu schade, fuer den> brauch ich noch eine besondere Aufgabe. :-D
Dann schau dir mal die dsPIC33CH Serie an:
https://www.microchip.com/en-us/product/dsPIC33CH256MP508
Diese Teile sind beispielsweise für BLDC-Motorsteuerungen interessant,
wo der Slave-Kern die Kommutation und PWM und Back-EMF Auswertung macht,
während der Master die Kommunikation mittels CANopen oder J1939 macht.
Jeder Kern hat seine eigene Peripherie, und Du kannst jeden Pin einem
Kern zuordnen. Das ganze wurde dadurch möglich, dass die
Halbleiterstrukturen immer feiner wurden, aber die Chipgröße durch die
IO-Pads ringsrum festgelegt sind. Den Platz kann man ohne Mehrkosten
nutzen.
fchk
Hier hast sich jemand mal die Muehe gemacht das PIO-System
zu erklaeren:
https://www.youtube.com/watch?v=yYnQYF_Xa8g
Ich sag mal so, ein bemerkenswert kreativer Wahnsinn. :-D
Olaf
Olaf schrieb:> Woher willst du wissen ob das echt ein Maskenprogrammiertes ROM ist> und nicht nur ein Flashrom wo man uns ein paar Details verschweigt?
Der RP2040 ist in 45nm Technologie gefertigt. Der 45nm Knoten hat den
Nachteil, dass es nicht mehr so einfach möglich ist, Flash-Memory in den
Prozess zu integrieren. Flash ist mit erheblich mehr Maskenebenen und
damit Kosten verbunden. Das war bei 130/180nm noch anders.
Durch die Kombination von 45nm Logic-Prozess für die MCU und einem
externen Flash lässt sich ein Sweet-Spot im Kosten/Performance trade-off
erreichen. Das haben zuerst Gigadevice und Espressif erkannt. Da
Rpi-Organisation ist auch auf den Zug aufgesprungen. Der Rest der
westlichen Konkurrenz wartet noch auf einen Wunder-Speicher oder
verschläft den Markt einfach.
> Der RP2040 ist in 45nm Technologie gefertigt.
Eine interessante Erklaerung!
> Durch die Kombination von 45nm Logic-Prozess für die MCU und einem> externen Flash lässt sich ein Sweet-Spot im Kosten/Performance trade-off> erreichen. Das haben zuerst Gigadevice und Espressif erkannt.
Renesas hatte schon vor >10Jahren MCU die kein internen Flash hatten und
sich das reingelesen haben und Nxp hat es zumindest beim LPC4370 auch so
geloest das der Code ueber QSPI im externen Flash laeuft.
Aber diese Methode kranken natuerlich ein wenig daran den Source vor
fremden Blicken zu schuetzen. Das mag privaten Bastlern ja egal sein,
aber in der Industrie ist das schon eher problematisch.
BTW: Den RP2040 haben manche Leute ja geradezu dramatisch (bis zu
400Mhz) uebertaktet. Das funktioniert mit meinem Exemplar hier auch
(zumindest mit 200Mhz). Es funktioniert auch gut und stabil. Es
funktioniert auch indem man seinen Code mit dem J-Link reinlaedt und
danach resetet. Aber wenn der Core dann auch nur mit 150Mhz laeuft dann
kann der J-Link zwar jederzeit etwas neues reinladen, aber der Reset
ueber den J-Link geht nicht mehr. Das muss man dann einen Powercycle
durchfuehren.
Nur mal so als Tip falls jemand in der Richtig experementiert und sich
wundert.
Richtig schlecht ist der RP2040 im uebrigen wenn man Lowpower braucht.
Ich glaub unter 1mA sleept der nicht. Vielleicht ein Nebeneffekt der
45nm.
Olaf
Hier mal was interessantes.
Ich hab das Teil jetzt uebertaktet auf 200Mhz laufen. Ohne besondere
Gruende, erstmal nur weil das eine schoen gerade Zahl ist. :-)
Ausserdem hab ich die PIO laufen auch wenn es etwas Nerven gekostet hat:
Das laeuft jetzt in der Pio:
1
setpindirs,1
2
again:
3
setpins,1[1];1Takt+1Wartetakt
4
setpins,0;1Takt
5
jmpagain;1Takt
Das ergibt erstaunlich saubere 50Mhz am Ausgang. Es gibt sogar noch
einen
Trick mit dem man auf 100Mhz kommen muesste. (man kann den jmp befehl
einsparen)
Interessant ist aber das die Portausgaenge rattenschnell sind und diese
Pegel richtig schoen ausgeben. So fuer Breadboard und etwas Draht
rumtueddeln ist das nicht mehr der richtige Controller...
Olaf
Olaf schrieb:> BTW: Den RP2040 haben manche Leute ja geradezu dramatisch (bis zu> 400Mhz) uebertaktet. Das funktioniert mit meinem Exemplar hier auch> (zumindest mit 200Mhz). Es funktioniert auch gut und stabil. Es> funktioniert auch indem man seinen Code mit dem J-Link reinlaedt und> danach resetet. Aber wenn der Core dann auch nur mit 150Mhz laeuft dann> kann der J-Link zwar jederzeit etwas neues reinladen, aber der Reset> ueber den J-Link geht nicht mehr. Das muss man dann einen Powercycle> durchfuehren.> Nur mal so als Tip falls jemand in der Richtig experementiert und sich> wundert.
Das kann ich nicht bestätigen. Ich benutze zum Bilden von Programmen den
Standardweg mit cmake und nmake unter Windows. Zum Debuggen benutze ich
Segger Embedded Studio mit einem externen Projekt (wie das da heisst).
Das klappt mit einem JLink edu mini problemlos ohne Reset und
Powerzyklus. Auch der 2. core lässt sich damit debuggen. Ich hab auch
mal den Takt auf 200MHz gesetzt ohne dass sich das von dir geschilderte
Verhalten zeigte.
> Mit dem PIO kann man nicht nur schnell einen Pin wackeln lassen, da kann> man mit Highspeed noch sinnvolle Sachen machen wie ADC einlesen.
Ich weiss. War ja auch erstmal der erste Test. Bedenke das ist alles von
Hand gestrickt ohne deren absurdes SDK.
Wenn ich das richtig sehen dann muesste man mit dem Teil auch ein sehr
schnelles Slave-Interface hinbekommen. Also den RP2040 als
Peripherie-Baustein an einer anderen CPU nutzen wo er entsprechend /WR
Daten uebernimmt und auf /RD bereitstellt. Das ist ja etwas wo sich
sonst auch sehr schnelle Controller schwer tun und man schnell beim FPGA
landet.
Olaf
Olaf schrieb:> Das ergibt erstaunlich saubere 50Mhz am Ausgang. Es gibt sogar noch> einen> Trick mit dem man auf 100Mhz kommen muesste. (man kann den jmp befehl> einsparen)
.wrap_target
set pins, 1
set pins, 0
.wrap
Ich habe den RP2040 mal zur Ansteuerung von 64x64 und 128x128 LED
Displays mit HUB75 Anschluss hergenommen. Mit PIO und DMA braucht der
nicht mal 1% seiner Rechenleistung zur Ansteuerung mit 24bit RGB bei
über 50Hz Bildrate. Software habe ich mal hier
https://github.com/pitschu/RP2040matrix-v2 abgelegt.
> Displays mit HUB75 Anschluss hergenommen.
Erstaunlich, ein neuer "Standard". :-) War bisher an mir vorueber
gegangen.
> Mit PIO und DMA braucht der> nicht mal 1% seiner Rechenleistung zur Ansteuerung
Ja, die PIO ist schon erstaunlich sinnvoll. Ich hab mich gestern erst
geaergert das der Decoder in meinem RTB2004 keine RS232 mit 100MBit
dekodieren kann. :-D
Und in dem Zusammenhang so nochmal erwaehnt wie cool schnell die
Portausgaenge sind!
Aber natuerlich will man immer mehr. Daher ist es vielleicht etwas
schade das man pro PIO nur 32Befehlswoerter hat.
Mir geht im uebrigen gerade ein aehnliches Projekt durch den Kopf. Ich
wuerde gerne das alte LCD meines HP48 ersetzen, also etwas kompatibles
zum LCD-Treiber schreiben, dafür waer die PIO super, und dann an der MCU
ein anders Display anschliessen. Allerdings mach ich mir da natuerlich
Sorgen wegen dem hohen Stromverbrauch des RP2040, na mal sehen...
Olaf
Olaf schrieb:> Aber natuerlich will man immer mehr. Daher ist es vielleicht etwas> schade das man pro PIO nur 32Befehlswoerter hat.
Ja, das ist leider tatsächlich für viele Zwecke etwas eng. Es läuft oft
darauf hinaus, dass man die Aufgabe in zwei Teile zerlegen muss, einen
Teil, den die PIO erledigt und einen Teil, den ein MCU-Kern erledigt
(ggf. mit DMA als "Buffer").
Allerdings ist vieles, von dem man im ersten Moment annehmen würde, dass
das mit der PIO nicht realisierbar wäre, dann doch mit Tricks und "um
die Ecke denken" doch noch darauf zu verlagern, ohne das 32-Worte-Limit
zu reissen.
Das ist halt die hohe Schule der Beherrschung der Maschine. Muss man
lernen. Einen anderen Weg gibt's nicht. Schön und hilfreich ist hier,
dass die Maschine sehr klein und sehr überschaubar ist. Das erleichtert
das Erlernen ihrer Möglichkeiten ungemein. Dieses Wissen allein kann
allerdings nicht die Kreativität liefern, die nötig ist, um die
begrenzten Möglichkeiten dieser Maschine dann auch optimal nutzbar zu
machen.
c-hater schrieb:> Das ist halt die hohe Schule der Beherrschung der Maschine. Muss man> lernen. Einen anderen Weg gibt's nicht. Schön und hilfreich ist hier,> dass die Maschine sehr klein und sehr überschaubar ist. Das erleichtert> das Erlernen ihrer Möglichkeiten ungemein. Dieses Wissen allein kann> allerdings nicht die Kreativität liefern, die nötig ist, um die> begrenzten Möglichkeiten dieser Maschine dann auch optimal nutzbar zu> machen.
So ein Geschwafel!
2⁵ schrieb:> Leistung ist relativ! Es wurden schon SDRs auf AVRs programmiert. Da> wirkt dann ein Dual-Core mit M0 und 133 MHz doch wie ein Bolide.> Unabhängig davon findet man auch µC, da wirkt dann ein Cortex-M4> mickrig...
Der RP2040 hat mehr als genug Leistung für einen SDR
https://www.dropbox.com/s/jzkygltnhfe6gb9/usdx_pico_ssb_rx.mp4?dl=0
Olaf schrieb:> Was mich interessieren wuerde, wofuer wuerdet ihr eigentlich einen> zweiten> Core verwenden?
Um die Frage zu beantworten: Ohne sehr speziellen Anforderungen, würde
ich ein RTOS benutzen, das die Threads auf beiden cores verteilt.
avr schrieb:> Um die Frage zu beantworten: Ohne sehr speziellen Anforderungen, würde> ich ein RTOS benutzen, das die Threads auf beiden cores verteilt.
ich habe meinen Pico jetzt auch mal ausgepackt. Die Unterstützung in
PlattformIO ist mittlerweile gut und es gibt blöderweise gleich zwei
Arduino Cores.
Der offizielle hat gleich ein RTOS eingebaut, RTX5 von Keil, weil
Arduino CC da den Mbed Core verwendet hat. Damit ist die Verwendung von
Threads & Co sehr einfach, habe ein Beispiel auf github:
https://github.com/JojoS62/Test-pico-SSD1306-mbed
Aber ob und wie der zweite Kern damit genutzt werden kann habe ich noch
nicht untersucht.
