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
|
2 | download: $(BUILD)/$(BIN).bin |
3 | /opt/SEGGER/JLink_V760b/JLinkExe -if SWD -commanderscript ./burn.jlink |
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
Ich nutze den hiermit und auch die die PIO Umgebung. Und natürlich mit VGA Anschluß. https://geoffg.net/Downloads/picomite/PicoMite_Firmware.zip
> zweiten Core 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. 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
Angehängte Dateien:
-
PortSpeed.gif
39 KB
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 | set pindirs, 1 |
2 | again: |
3 | set pins, 1 [1] ; 1Takt + 1Wartetakt |
4 | set pins, 0 ; 1Takt |
5 | jmp again ; 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.
das Beispiel hatte ich schonmal gepostet: https://forum.lvgl.io/t/100-mhz-oscilloscope-with-raspberry-pi-pico-lvgl-v8-and-micropython/5669 Mit dem PIO kann man nicht nur schnell einen Pin wackeln lassen, da kann man mit Highspeed noch sinnvolle Sachen machen wie ADC einlesen. Was andere µC allerdings auch mit Speicher- oder Kamerainterfaces können.
> 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 weiss, hab ich jetzt auch laufen. Aber ich dachte das ist zu banal um es jetzt gross rumzuerzaehlen. .-) Olaf
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.