Zum Übertragen von AVR C-Programmen in eine Arduino-IDE reicht es aus, die .c-Datei in .ino umzubenennen und ggf. die notwendigen .h-Dateien hinzuzufügen. Das wird anstandslos verarbeitet. Nun habe ich fertige Projekte, die zum Beispiel in einer Segger-IDE laufen, die ich als Arduino Projekt für das RP2040 Pico-Board umstellen möchte. Da scheinen zwei Welten aufeinander zu treffen, denn es geht so gut wie garnichts. Ein Beispielprogramm ist angehängt, bei dem als allererstes RESETS_CLR nicht bekannt ist. Klammert man die betreffenden Zeilen aus, sind BUSCTRL und dann auch DMA völlig unbekannt. Meine Versuche, die passenden .h-Dateien zu finden und zu verwenden, blieben erfolglos. Eine RP2040.h mit sämtlichen Definitionen einzubinden, wird kräftig angemeckert und führt teilweise auch zu Fehlermeldungen. Vom Pico-SDK finde ich zwar Funktionen wie block_reset() und block_unreset(), was aber bedeuten würde, sehr viel umzuschreiben. Das ist keine Lösung. Hat jemand Erfahrung, wie man die fertigen Quelldateien 1:1 unter der Arduino-IDE verwenden kann?
:
Bearbeitet durch User
Mi N. schrieb: > Hat jemand Erfahrung, wie man die fertigen Quelldateien 1:1 unter der > Arduino-IDE verwenden kann? Falscher Weg. Benutze statt dessen das C/C++-SDK der Raspi-Foundation. Arduino ist eigentlich sogar grundsätzlich ein Irrweg. War es, seitdem es den Due gab. Schon dessen Features kann man nur in sehr homöopathischen Dosen nutzen. Und bei jedem anderen stärkeren HW-Basis als der ursprünglichen AVR8-Basis sieht das im Prinzip ganz genauso aus.
>Arduino ist eigentlich sogar grundsätzlich ein Irrweg.
Da bist du vermutlich grundsätzlich auf dem Holzweg.
in der Segger IDE muss doch angezeigt werden woher die Symbole kommen, aus dem pico SDK ja offensichtlich nicht.
Segger war ja nur ein Beispiel für einen 'normalen' Compiler, wo man alles selbst in der Hand hat. Mi N. schrieb: > Eine RP2040.h mit sämtlichen Definitionen einzubinden, wird kräftig > angemeckert und führt teilweise auch zu Fehlermeldungen.
Gibt es bei der Arduino-IDE vielleicht irgendeine Möglichkeit, für einzelne .ino-Dateien die #include-Dateien abzuschalten?
Wenn du ohne das Build-System vom SDK kompilieren möchtest, dann wird das ein Heidenaufwand weil scheinbar "unendlich" viele Include-Pfade mit angegeben werden müssen. Ich habe mir mal mit dem SDK ein Projekt für Eclipse generieren lassen und die Liste der Pfade war elendig lang. Hat mich auch geärgert weil ich auch was "händisch" machen wollte. Ich würde auf die Ardino-IDE verzichten bzw. du musst wohl irgendwie herausbekommen, was für Pfade die Segger IDE nutzt. Und wie man die dann dem Arduino Zeugs unterjubelt.... schulterzuck. Die Arduino-IDE ist für solch Sonderlocken scheinbar nicht gemacht. Ist eben ein Spielzeug.
:
Bearbeitet durch User
Also mich verwirrt ja bei dem Ansinnen schon das RP2040 klassisches C zu sein scheint und Arduino eigentlich C++. Von den feinen Unterschieden der SDKs und Buildsysteme in Kombination mit dem Durchschnittsuser der zu faul ist das zu lernen reden wir da noch gar nicht. > Wenn du ohne das Build-System vom SDK kompilieren möchtest, dann wird > das ein Heidenaufwand weil scheinbar "unendlich" viele Include-Pfade mit > angegeben werden müssen. Ich hab fuer den RP2040 hier ja mal einen Link gepostet wo das jemand netterweise auf "normal" umgebaut hat. So nutze ich das auch, allerdings noch etwas angepasst auf meine persoenlichen Befindlichkeiten. Vanye
900ss schrieb: > Ich würde auf die Ardino-IDE verzichten bzw. du musst wohl irgendwie > herausbekommen, was für Pfade die Segger IDE nutzt. > Und wie man die dann dem Arduino Zeugs unterjubelt.... schulterzuck. > Die Arduino-IDE ist für solch Sonderlocken scheinbar nicht gemacht. Ist > eben ein Spielzeug. Mir geht es darum, zum Beispiel USB und WiFi zu nutzen, ohne den ganzen Klumpatsch umschreiben zu müssen. Segger war nur ein Beispiel, da hätte ich auch IAR oder Keil schreiben können. Bei all diesen IDEs kann ich selber festlegen wo, wie, was eingebunden wird. Von Hause aus bindet Segger in seine RP2040 Beispiele auch Pico-SDK Zeugs ein, was aus meiner sicht völlig daneben aber eben auch entfernbar ist. Wie schon bei z.B. STM32 möchte ich die Bezeichner verwenden, wie sie im Datenblatt festgelegt und in der Datei 'RP2040.h' zu finden sind. Konkret geht es um dieses Projekt in abgemagerter Version: http://mino-elektronik.de/progs/Pico-FM-AS6501/Pico-FM-AS65_segger.zip Meine jetzige Lösung besteht darin, die IRQn-Definitionen auszuschließen. Die Kollisionen bei den Definition löse ich durch Umbenennen der betreffenden Strukturen von 'xyz_Type' nach 'xyz_Type_X' und '_BASE' nach '_BASE_X'. Soweit ich sehe, werden diese nur lokal in der 'RP2040.h' verwendet: friedliche Koexistenz ;-) Es wird noch mehr zu beachten sein. Wir werden sehen.
Die Arduino IDE ist für soetwas denkbar ungeeignet, es ist nicht die Intention der Entwickler ein flexibles Buildsystem anzubieten. Der Anwender soll sich gar nicht mit Include/Librarypfaden und Compileroptionen herumschlagen müssen. Dazu gibt es das Arduino Buildsystem das .ino Dateien vorverarbeitet und aus includes die nötigen Pfade aus global installierten Bibliotheken errät. Siehe: https://arduino.github.io/arduino-cli/0.20/sketch-build-process/ Du verwendest die nackte CMSIS, nichtmal das pico SDK. Und das SDK verwendet auch andere low level Deklarationen, RPi geht da auch eigene Wege. Es wurden zwar CMSIS header in das SDK übernommen, aber nicht die komplett aus den SVD Dateien generierten. Arduino kompatibel und trotzdem mehr Freiheiten bietet PlatformIO, da kann man die nötigen Libraries im Projekt angeben und auch zusätzliche lokale C/C++ Dateien.
Mi N. schrieb: > Mir geht es darum, zum Beispiel USB und WiFi zu nutzen, ohne den ganzen > Klumpatsch umschreiben zu müssen. Die Ausgabe per USB läuft zusammen mit dem ursprüglichen Programm. Beachtet werden muß, daß die Interrupt-Vektortabelle im RAM liegt und der passende Eintrag beim 'init' ergänzt werden muß. So weit - so gut.
Mi N. schrieb: > Ein Beispielprogramm ist angehängt, bei dem als allererstes RESETS_CLR > nicht bekannt ist. Klammert man die betreffenden Zeilen aus, sind > BUSCTRL und dann auch DMA völlig unbekannt. RESETS_CLR RESETS_RESET_dma_Msk RESETS_RESET_busctrl_Msk usw. sind alles #defines aus dem Controller Headerfile. Ich vermute dein SDK verwendet ein anderes Headerfile wie Earle F. Philhower https://github.com/earlephilhower/arduino-pico in seinem Core Package verwendet. Wer jetzt die neue und wer eine veraltete Version der Headerfiles verwendet entzieht sich meiner Kenntnis. Vergleiche einmal die Headerfiles. Springe einmal bspw. in deinem SDK von 'RESETS_CLR' zur Definition, notiere dir den Dateinamen in dem das steht und lässt den Namen im Arduino Ordner suchen. Der muss ja vorhanden sein. Dann vergleichst beide Dateien.
:
Bearbeitet durch User
Hallo Veit, für IAR- und Segger-IDEs verwende ich die Standard 'rp2040.h'. Die folgt den Vorgaben des Datenblattes und damit kommt man gut klar. Mir ist schleierhaft, warum diese nicht auch beim Pico-SDK verwendet wird. Vielleicht aus Kompatibilitätsgründen zu anderen RasPis? Ich kenne mich da nicht aus. Bei meinem Programm ist das Zusammenspiel von PIO und DMA von wesentlicher Bedeutung. Die Definitionen des Datenblattes lassen sich direkt umsetzen und nachvollziehen. Die Funktionen sind durchgetestet. Sehe ich mir die 'dma.c' aus den Tiefen des Pico-SDKs an, würde damit alles 'vernebelt'. Für 'gewöhnliche' Arduino-Nutzer ist DMA wahrscheinlich sowieso Teufelszeug. Wie erwähnt, habe ich mir eine angepasste 'rp2040x.h' erstellt, mit der ich gut leben kann.
>für IAR- und Segger-IDEs verwende ich die Standard 'rp2040.h'.
Wenn ich mich recht erinnere, machen IAR und Segger ihre eigenen
Headerfiles als eine Art Kopierschutz. Dass das teilweise nicht schlecht
funktioniert, sieht man in diesem Thread.
Nein, die Symbole kommen aus CMSIS und wurden aus SVD files erzeugt die von ARM verwaltet werden. Nur wird im RP SDK nicht die volle Version verwendet, nur die IRQ wurden übernommen. Die CMSIS Symbole sind weder im offiziellen Arduino core noch in dem anderen von Earle Phil Hower, aber beide verwenden das Pico SDK. Es macht also mehr Sinn das SDK zu verwenden um da kompatibel zu sein, da muss man keine Verrenkungen machen um die Funktionen zu benutzen.
:
Bearbeitet durch User
Christoph M. schrieb: > Wenn ich mich recht erinnere, machen IAR und Segger ihre eigenen > Headerfiles als eine Art Kopierschutz. Dass das teilweise nicht schlecht > funktioniert, sieht man in diesem Thread. Was soll denn das? Du erinnerst Dich falsch, und wenn man weiß, was man will, kommt man damit gut zurecht. Es liegt nur nicht auf einem silbernen Tablett. J. S. schrieb: > Nein, die Symbole kommen aus CMSIS und wurden aus SVD files erzeugt die > von ARM verwaltet werden. Das ist für mich der Standard. Wenn man sich im Netz umsieht, bin ich mit dieser Meinung nicht allein. Wer möchte denn z.B. Beim STM32F407 auf die 'STM32F407xx.h' verzichten oder 100 Dateihäppchen verdauen? "Einmal hin - alles drin" ;-)
Nur haben sich die RP Macher nicht daran gehalten. So sind die SW Entwickler, jeder kocht sein Lieblingssüppchen. Oder ‚Einmal drin - alles hin‘ wie der Mann neben der schwangeren real Mitarbeiterin sagte 😎
:
Bearbeitet durch User
Christoph M. schrieb: >>für IAR- und Segger-IDEs verwende ich die Standard 'rp2040.h'. > > Wenn ich mich recht erinnere, machen IAR und Segger ihre eigenen > Headerfiles als eine Art Kopierschutz. Dass das teilweise nicht schlecht > funktioniert, sieht man in diesem Thread. Moin, ich hab mir gerade mal das "hello_multicore" Projekt angeschaut, welches in der IAR Embedded Workbench für Arm v9.50.1 als Beispiel für den RP2040 verfügbar ist. Der dort verwendete Header 'rp2040.h' sieht der Version vom pico-sdk auf GitHub zum Verwechseln ähnlich und BeyondCompare sagt sogar, dass beide Files "binary same" sind... Wie das dann als "Kopierschutz" taugen soll erschließt sich mir nicht. Aber vielleicht kannst Du ja etwas mehr Details liefern, die Licht ins Dunkel bringen :-) Gruß, Michael
Michael F. schrieb: > ich hab mir gerade mal das "hello_multicore" Projekt angeschaut, welches > in der IAR Embedded Workbench für Arm v9.50.1 als Beispiel für den > RP2040 verfügbar ist. Wie schön für Dich. Nur wird sich dieses Projekt niemand hier anschauen können/wollen. Mit einer Demo-Lizenz für 14 Tage und einer Code-Begrenzung auf 12 kB hat sich IAR ins Abseits geschossen :-( Zuvor waren es 32 KB und zeitlich unbegrenzt, womit man schon Einiges anfangen konnte. > Der dort verwendete Header 'rp2040.h' sieht der > Version vom pico-sdk auf GitHub zum Verwechseln ähnlich und > BeyondCompare sagt sogar, dass beide Files "binary same" sind... Da kann man ja gleich das Pico-SDK nehmen. J. S. schrieb: > Nur haben sich die RP Macher nicht daran gehalten. So sind die SW > Entwickler, jeder kocht sein Lieblingssüppchen. Bei Fertigsuppen sehe ich mir immer die Zutatenliste an. Ist sie zu lang, wird die Sache nicht gegessen. Es ist ja nicht jeder Lebensmittelchemiker und vertüddelt sein Leben auf E-Nummern Partys.
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/cmsis/stub/CMSIS/Device/RaspberryPi/RP2040/Include/RP2040.h Und da ist RESETS_CLR enthalten?
J. S. schrieb: > Und da ist RESETS_CLR enthalten? Du hast scheinbar schon nachgesehen zu haben. Weshalb schreibst du das Ergebnis hier nicht sondern lässt jeden Interessierten suchen? Ich habe das RESETS_CLR jedenfalls nicht gefunden.
:
Bearbeitet durch User
Hallo, Michael, bevor du alle fehlenden defines einsammelst und in ein separates Headerfile schreibst, würde ich vorschlagen, schließe dich einmal mit Earle F. Philhower auf Github kurz, schildere ihm das Problem, vielleicht hatte er das noch nicht auf dem Schirm das etwas fehlen könnte. Dann hätte man ein Problem aus der Welt geschaffen. Irgendwer ist immer der Erste. :-)
900ss schrieb: > Du hast scheinbar schon nachgesehen zu haben. Witzbold. Ich habe schon zweimal geschrieben das es nicht das volle CMSIS file ist das Mi N. verwendet hat. Damit verwundert mich die Aussage von Michael F. von IAR. Und im Core von Earle sind die Symbole auch nicht zu finden.
:
Bearbeitet durch User
J. S. schrieb: > Ich habe schon zweimal geschrieben das es nicht das volle > CMSIS file ist das Mi N. verwendet hat. Du hast auf die Unvollständigkeit der Header beim SDK und dem hingewiesen was nicht automatisch bedeutet dass RESETS_CLR fehlt. Du hättest auch noch eine Zeile mehr schreiben können da oben :)
Veit D. schrieb: > Michael, bevor du alle fehlenden defines einsammelst und in ein > separates Headerfile schreibst, Hallo Veit, eigentlich bin ich soweit fertig und hänge die derzeitige 'rp2040x.h' an. Wo es Kollisionen gab, konnte ich das befriedigend lösen. Gleich am Anfang habe ich ein '#define ARDUINO_IDE' eingefügt, was die wenigen Stellen passend korrigiert. Kennst Du vielleicht das #define, welches die Arduino-IDE selber zur Verfügung stellt? Dann wäre das wohl die bessere Wahl für beliebige Verwendung auch in anderen IDEs. Legt man sich bei den selbst verwendeten IDEs die Interrupt-Vektoren ins RAM und initialisiert sie entsprechend, könnte man diese Programme zunächst unverändert übernehmen. Dann noch 'init()' -> 'setup()' und 'main()' -> 'loop()' plus ein paar Feinheiten, dann könnte man die Umstellung schnell hinbekommen. Natürlich muß man auch aufpassen, da man "nicht allein zu Hause" ist.
Hallo Michael, ich würde nicht empfehlen das sich jeder der das benötigt in den Tiefen der Ordnerstruktur das kopiert. Ich habe mir erlaubt daraus eine Arduino typische Lib zu erstellen mit deinem Nicknamen in der library.properties. Kannste auch noch anpassen. Alle Example sind Schreibgeschützt in der IDE. Muss man extern editieren, wenn nötig. Das Paket wird wie jede andere Lib in den eigenen libraries Ordner entpackt. Dort wo auch die aus der IDE heraus nachinstallierten Libs landen. Nach IDE Neustart hat man unter Bsp. ganz unten dein Bsp. aus dem Eingangsthread was damit kompiliert. Wer die extra defines benötigt muss nur wie im Bsp. den Header inkludieren. Ich würde dennoch den Königsweg empfehlen. Und zwar das eben nicht jeder einzeln immer alles inkludieren muss, sondern das es Earle F. Philhower "einbaut" , der muss nur darüber informiert werden. Damit hat jeder es von Haus aus zur Verfügung hat. Er könnte auch gleich andere Abhängigkeiten und Überschneidungen ausmerzen bzw. vermeiden.
IDE heißt 'Integrated Development Environment', ist also nur ein Werkzeug um irgendwelchen Code zu übersetzen. Damit ist eine Abhängigkeit namentlich ARDUINO_IDE maximal ungünstig gewählt. Arduino hat etwas gut gemacht (wobei ich nicht weiß ob die das entwickelt oder übernommen haben), nämlich die Definition von Packages in denen der Arduino Core, evtl. zusätzlicher Code, die Toolchain zum kompilieren sowie weitere nötige Werkzeuge für z.B. Download auf das Target zusammengefasst sind. Welche Libraries jetzt verwendet werden hängt also vom Core ab den man verwendet, das hast du noch nicht verraten. Es gibt wie schon geschrieben den von Earle Phil Hower, aber auch den offiziellen von Arduino von Martino F. und Co. Beide müssten das define ARDUINO_ARCH_RP2040 gesetzt haben.
:
Bearbeitet durch User
Veit D. schrieb: > Ich würde dennoch den Königsweg empfehlen. Und zwar das eben nicht jeder > einzeln immer alles inkludieren muss, sondern das es Earle F. Philhower > "einbaut" , der muss nur darüber informiert werden. der pflegt aber nicht den Arduino Core sondern seinen eigenen.
Bahnhof? Bielefeld? Jetzt brauche ich nur noch ein Programm, was übersetzt, was Ihr mir sagen wollt ;-) Mit Arduino habe ich wenig am Hut. Mir geht es um einen (Aus-)Weg, Nutzern eine einfache Möglichkeit zu geben, meinen Code zu verändern. Aus meiner Sicht ist es geschickt, eine .zip mit dem Quellcode zu machen, die alles enthält. Es mag nicht optimal sein, es muß aber auch nichts installiert werden. Ist das so verkehrt gedacht?
J. S. schrieb: > Veit D. schrieb: >> Ich würde dennoch den Königsweg empfehlen. Und zwar das eben nicht jeder >> einzeln immer alles inkludieren muss, sondern das es Earle F. Philhower >> "einbaut" , der muss nur darüber informiert werden. > > der pflegt aber nicht den Arduino Core sondern seinen eigenen. Upps, habe ich da etwas falsch verstanden als ich die Tage nach dem Core gesucht hatte? Ich fand immer nur den von Earle. Ich ging davon aus das er den offiziellen Core pflegt. Wie lautet der offizielle Name den man in der Boardverwaltung suchen muss um das Arduino RP2040 Core Package installieren zu können? Welchen Core hat Michael nachinstalliert? Allerdings wird der Core von Earle zum Arduino Core sicherlich nicht inkompatibel sein. Denn den "Arduino Nano RP2040 Connect" unterstützt er auch. Deswegen wurde ich wohl auch nicht so richtig stutzig. ;-)
Mi N. schrieb: > Aus meiner Sicht ist es geschickt, eine .zip mit dem Quellcode zu > machen, die alles enthält. Es mag nicht optimal sein, es muß aber auch > nichts installiert werden. Ist das so verkehrt gedacht? Das würde alles mit der ".zip Lib" erschlagen, worin du auch noch mehr Beispiele rein tun könntest u.a. auch den Frequenzmesser.
Hallo, ich habs. "Arduino Mbed OS Nano Boards" lautet der offizielle Core zum nachinstallieren. Michael, was hast du nachinstalliert?
Hallo, für den offiziellen Core "Arduino Mbed OS Nano Boards" lautet natürlich der 'architectures' Name anders. Habe ich ergänzt. Der Code vom Eingangsthread wirft aber Fehler mit defines mit dem offiziellen Core. Keine Ahnung was man jetzt macht.
Veit D. schrieb: > ich habs. "Arduino Mbed OS Nano Boards" lautet der offizielle Core zum > nachinstallieren. > Michael, was hast du nachinstalliert? Als Board-Name taucht bei mir "Raspberry Pi RP2040 Boards (1.12.0)" auf in dem "Raspberry Pi Pico" ganz oben angewählt ist. Die Arduino Version ist 1.8.19. Damit läuft bei mir doch alles?
:
Bearbeitet durch User
Angehängte Dateien:
Hallo, im Anhang die 2 Möglichkeiten der Core Auswahl die ich aktuelle sehe. Entweder offiziellen Arduino Core für deren Board. Oder den "Earle Core" für alle anderen Varianten. Sieht danach aus als wenn du den Core von Earle F. Philhower installiert hast. Nur warum Version 1.12? Aktuell ist 3.7. Gibt es noch einen anderen RP2040 Core? Brauchst nur in der Boardverwaltung nachschauen was du installiert hast. In der Zeile "Board "Raspberry Pi Pico" gerade rüber kommste in die Boardverwaltung. Dort musst irgendwann schon einmal drin gewesen sein. Ich hatte beim Arduino Core dessen Board probiert, ist damit nicht kompatibel. Wähle ich dein verwendetes Raspberry Pi Pico aus (Earle Core) kompiliert es. Da gibt es scheinbar keinen gemeinsamen Nenner in den Headerfiles wie schon im Thread festgestellt wurde. Für dein Projekt mit RP Pi Pico muss man demnach den "Earle Core" nehmen. Habe ich das nun richtig verstanden? Wenn dem so ist, erfolgt die nochmalige Bitte, wende dich an Earle damit er für allemal und alle Zeiten die defines gerade ziehen kann, dann entfällt für den Nutzer auf Dauer unnötiger Aufwand. Auch für dich. Mach es für Ruhm & Ehre. :-) Wenn im Earle Core die offiziellen RP2040 Defines fehlen, dann sollte er die Chance haben das zu korrigieren. Was wie gesagt allen zu Gute kommt.
J. S. schrieb: > Witzbold. Ich habe schon zweimal geschrieben das es nicht das volle > CMSIS file ist das Mi N. verwendet hat. Damit verwundert mich die > Aussage von Michael F. von IAR. Moin J. S. mein Post bezog sich auf die Aussage von Christoph M., dass IAR und Segger Headerfiles als eine Art von Kopierschutz nutzen. Im von mir genannten "RaspberryPi => RP2040 => RP2040 Pico SDK Examples => hello_multicore" Beispielprojekt wird der identische "RP2040.h" Header verwendet, der auch hier zu finden ist: https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/cmsis/stub/CMSIS/Device/RaspberryPi/RP2040/Include/RP2040.h Und nein, darin ist "RESETS_CLR" - wie auch im restlichen Beispielprojekt - nicht enthalten... Ist nun die "Verwunderung" geklärt? :-) Gruß, Michael
Veit D. schrieb: > Sieht danach aus als wenn du den Core von Earle F. Philhower installiert > hast. Nur warum Version 1.12? Aktuell ist 3.7. Ja, die verwende ich. Die Installation ist womöglich 1 - 2 Jahre alt und ich suche nicht immer nach der neuesten Version, solange die installierte reicht. Vielleicht mache ich mal ein Update, wenn mir dann nicht alles um die Ohren fliegt ;-) Veit D. schrieb: > Wenn dem so ist, erfolgt die nochmalige Bitte, wende dich an > Earle damit er für allemal und alle Zeiten die defines gerade ziehen > kann, dann entfällt für den Nutzer auf Dauer unnötiger Aufwand. Auch für > dich. Mach es für Ruhm & Ehre. :-) Noch mehr als Papst, geht das überhaupt? :-) Was ich sehe ist, daß Arduino Programmierer wohl etwas anders ticken. Wenn diese Register-Definitionen wirklich von Interesse wären, wären sie längst eingebunden. Für meine Spielereien brauche ich direkte Zugriffe, brauche einen SWD-Anschluß und .lst und .map Dateien. Es ginge zwar auch ohne, wäre aber quälend mühsam und zeitintensiv. Gut, EPROMs weder programmieren noch löschen zu müssen, ist schon ein Vorteil ;-)
Immer strebend bemüht habe ich jetzt die Version 2.3.0 installiert. Diese arbeitet erfreulicherweise deutlich schneller und kennt bei pinMode jetzt auch INPUT_PULLDOWN. Die "Raspberry Pi RP2040 Boards (3.7.0)" werde ich auch noch dazupacken. Sehr erfreulich: "Go to Definition" gibt es jetzt auch, obwohl nicht zu erkennen ist, warum die Anzeige dazu manchmal sehr lange braucht.
:
Bearbeitet durch User
Du wirfst immer noch alles durcheinander. 2.3.0 ist die Version der Arduino IDE, die hat aber nichts mit den installierten Boards zu tun. Wenn du einen anderen Hammer kaufst ändern sich nicht automatisch die Nägel in deiner Schublade. Die Arduino IDE prüft aber beim Start ob es neuere Board Packages gibt und bietet dann das automatische Update an. Michael F. schrieb: > Ist nun die "Verwunderung" geklärt? :-) Es war so wie vermutet, nur weiß man immer noch nicht wo das RP2040.h mit den ganzen Registernamen herkommt, aus dem sdk eben nicht. Das hat jemand aus dem svd erzeugt, wozu auch immer. Wenn man nur eine freie IDE sucht mit der man flexibel kompilieren kann, dann ist VSCode besser als die Arduino Zwangsjacke, vor allem wenn man sowieso kein Arduino benutzen möchte.
J. S. schrieb: > Du wirfst immer noch alles durcheinander. 2.3.0 ist die Version der > Arduino IDE, Das hatte ich schon begriffen :-( > Es war so wie vermutet, nur weiß man immer noch nicht wo das RP2040.h > mit den ganzen Registernamen herkommt, aus dem sdk eben nicht. Das hat > jemand aus dem svd erzeugt, wozu auch immer. https://github.com/ataradov/mcu-starter-projects Das hat er nur für mich gemacht!
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.