Hallo, ich möchte Programme in C und Assembly für den Pico schreiben. Dazu habe ich VS Code unter Windows 10 eingerichtet so wie es hier beschrieben steht: https://datasheets.raspberrypi.org/pico/getting-started-with-pico.pdf Das kompilieren der Testprogramme hat auch erfolgreich funktioniert, aber wie erstelle ich jetzt mein eignes Projekt. Es scheint irgendwie so, dass ich CMake lernen muss und unter jedem neu angelegten Projekt ein pico-sdk-import.cmake und CMakeLists.txt einbinden muss welches ich nach jeder Änderung am Projekt bearbeiten muss. Liege ich mit der Annahme erstmal richtig?
c-hater schrieb: > Meme schrieb: > >> Es scheint irgendwie so, dass ich CMake lernen muss > > Darauf läuft es hinaus, ja. Und, das möchte ich noch ergänzen: Das Buildsystem strotzt nur so von Fehlern. Es wurde ganz sicher zumindest unter Windows niemals ernsthaft getestet. Es ist dort gerade hinreichend funktional, um exakt 1 (in Worten: EINEN) build hinzubekommen. Nur die Examples darf man auch mehrfach bauen. Naja, zumindest solange man nichts an den Quelltexten ändert. Es genügt bereits eine eingefügte Kommentarzeile in irgendeiner C-Source, damit auch dort derselbe Effekt eintritt: läßt sich nicht mehr bauen. Erst die komplette Löschung des build-Verzeichnisses und erneutes Configure ermöglicht dann wieder genau EINEN Build. Krank, absolut krank. Da haben die Herren CLI-Frickler mal wieder das abgeliefert, was sie am Besten können: kompletten Bullshit. Portabel? Da lach' ich drüber. Und, unnötig zu erwähnen, natürlich ist auch die Fehlermeldung vollkommener Bullshit: [build] ninja: error: FindFirstFileExA(c/:/users/... Erstmal: Ja, das weist auf einen bekannten und angeblich ausgemerzten Fehler hin. Zweitens: Warum passiert das beim ersten Build nicht, sondern erst beim zweiten? Zusammenfassung: Bis dieser Scheiß ernsthaft benutzbar wird, geht sicher noch einige Zeit in's Land...
Beitrag #6587136 wurde von einem Moderator gelöscht.
c-hater-hater schrieb im Beitrag #6587136: > [ ] Dir ist klar, dass so ziemlich jede GUI-IDE im Hintergrund einen > CLI-Build mit den üblichen Tools laufen hat. > [x] Nicht. Doch, natürlich ist mir das klar. Ich bin halt nur gewohnt, dass die dann auch tatsächlich funktionieren... > Nein, in erster Linie weist das darauf hin dass du die Anleitung nicht > gelesen hast. Da liegst du definitiv falsch. Wie schon gesagt: ein Build funktioniert ja, auch mehrere, solange sich nichts an den Quellen ändert (weil dann natürlich nicht wirklich mehr irgendwas passiert). Das Problem tritt erst auf, sobald sich an irgendeiner Quelle tatsächlich etwas ändert, und sei es auch nur eine zusätzliche Kommentarzeile... > Aber substanzloses Gelaber ist man ja gewohnt von dir. Du bist so substanzlos, wie es nur geht!
c-hater schrieb: >> Nein, in erster Linie weist das darauf hin dass du die Anleitung nicht >> gelesen hast. > > Da liegst du definitiv falsch. Du sollst nmake verwenden, nicht ninja. c-hater schrieb: > Du bist so substanzlos, wie es nur geht! Wow, deine Argumentation ist gewohnt überragend.
c-hater-hater schrieb: > Du sollst nmake verwenden, nicht ninja. Das sagt die Doku so nicht. Die bietet das nur als Alternative an. Für den Fall, dass man einen Sockenschuss hat und unbedingt auf der Kommandozeile bauen will statt die komfortable CMake-Integration der VSCode-IDE zu benutzen... Die übrigens unter Linux tatsächlich funktioniert, das habe ich natürlich ebenfalls ausprobiert...
c-hater schrieb: > Das sagt die Doku so nicht. Die bietet das nur als Alternative an. Du kannst also tatsächlich nicht lesen. c-hater schrieb: > Für den Fall, dass man einen Sockenschuss hat und unbedingt auf der > Kommandozeile bauen will statt die komfortable CMake-Integration der > VSCode-IDE zu benutzen... Mal abgesehen davon, dass natürlich VSCode auch die Kommandozeile als Backend nutzt: > If you do not change the "Cmake: Generator" Visual Studio will default to > ninja and the build might fail. c-hater, der menschgewordene Dunning-Kruger-Effekt.
c-hater-hater schrieb: >> If you do not change the "Cmake: Generator" Visual Studio will default to >> ninja and the build might fail. > > c-hater, der menschgewordene Dunning-Kruger-Effekt. Oh Gott, lass Hirn wachsen. 1. Es geht um Visual Studio Code, nicht Visual Studio. Das sind zwei völlig verschiedene Sachen. 2. Dein Zitat stammt nicht aus der Doku zum RasPi Pico sondern aus irgendwelchen Microsoft-Verlautbarungen zum Visual Studio. 3. Der Build funktioniert. Aber eben nur genau einmal wirklich.
c-hater schrieb: > 1. Es geht um Visual Studio Code, nicht Visual Studio. Das sind zwei > völlig verschiedene Sachen. Ach ne, sag bloß. Hättest du die Raspberry-Doku gelesen (wurde im Eingangsposting sogar verlinkt), wüsstest du, dass die VSCode dort ständig als "Visual Studio" bezeichnen. c-hater schrieb: > 2. Dein Zitat stammt nicht aus der Doku zum RasPi Pico sondern aus > irgendwelchen Microsoft-Verlautbarungen zum Visual Studio. Doch. "getting-started-with-pico.pdf" (eingangs verlinkt), Seite 40, "8.2.4. Building "Hello World" from Visual Studio Code". Du hast die Doku also tasächlich nicht gelesen. c-hater schrieb: > 3. Der Build funktioniert. Aber eben nur genau einmal wirklich. Ja, weil du die Doku nicht gelesen hast. Hättest du das getan, würde er immer funktionieren. Blamierst du dich eigentlich absichtlich?
Das hier sieht ziemlich gut aus: https://github.com/Wiz-IO/wizio-pico Im Gegensatz zu dem was von der Raspberry Foundation kam bestand die Installation nur darin einen Link in PlatformIO zu installieren und das Beispiel hat sofort ohne zu Murren compiliert. Jetzt wäre nur mal praktisch wenn man das Programm neu flashen könnte ohne das Board vom USB trennen zu müssen... Und natürlich auch ohne irgendwelche Taster drücken zu müssen. So über den vorhandenen USB, ohne an die Debug-Pins noch was anderes anklemmen zu müssen.
Habe ich gerade gelesen daß Segger's jlink diese microcontroller unterstützt. Die Pressrelease spricht auch über den Embedded Studio. Da ich Embedded Studio für andere ARM (STM) microcontroller benutze habe ich gedacht daß auch so en "RPi Pico" package gibt... bis jetzt nichts... VSCode soll aber funktionieren. Mal sehen wann Reichelt die Platinchen liefert :)
Alex P. schrieb: > Mal sehen wann Reichelt die > Platinchen liefert :) Wenn ich dir einen Rat geben darf: Reichelt hat den Preis auf 4,95€ gesetzt, und es ist „z.Zt. ausverkauft“. Sertronics/Berrybase hat über 4k davon auf Lager, und verkauft die für 4,10€.
:
Bearbeitet durch User
So, ein RPi Pico Platinchen liegt bei mir. But Embedded Studio scheint nicht mir helfen zu wollen: Laut diese 2 Posts: https://forum.segger.com/index.php/Thread/7900-Embedded-Studio-RP2040-Support/ https://www.segger.com/news/?tx_news_pi1%5Baction%5D=%20detail&tx_news_pi1%5Bcontroller%5D=News&tx_news_pi1%5Bnews%5D=413&cHash=2e47bb69304c494dcdc13d70e0a93f15 Ist die Unterstützung da. Aber wenn ich den Package Manager in EMbedded Studio 4.52, gerade installiert, auf mache, gibt es kein Packet für den RP2040. Ich hab Aktualisiert (den Knopf da im Package Manager, die Liste auch), markiert "Dsiplay ALL" und "Include evaluation and full packages"... nix. (irgendwo ist geschrieben daß für den RP204 einen J-Link v11 nötig wäre... ist das auch wahr ? :/ Wofür ist meine v 9 noch nutzlich ? PIC32 geht nicht mehr, irgend einen updated FW hat die kompatibilität mit MPLABX zerstört, STMs gehen noch, RISCV geht nich... RP2040 wahrscheinlich auch net.... das Ding war nicht besonders billig... :(... CMake ich sehe dich (leider) in meiner Zukunf... /rant
:
Bearbeitet durch User
Wirf das > RPi Pico Platinchen in den Rundordner. Viel Hype um nichts. Wenn ein ARM M0 reicht, greife ich zu STMD32F030. Um den hat keiner viel Aufhebens gemacht. Bekommt/Bekam man in 10er Stueckzahlen fuer 70 ct aus China. Fuer die gibt/gab es auch eine freie Version des Keilcompilers. > einen updated FW hat die kompatibilität mit MPLABX zerstört Meinen noch viel aelteren V8 hat es neulich auch dahingerafft. Aber dank Samba und einer frischen Firmware gehts im wieder gut. Die V9 verwendet doch einen STM32F205?
... schrieb: > Wenn ein ARM M0 reicht, greife ich zu STMD32F030. > Um den hat keiner viel Aufhebens gemacht. Vermutlich gemeint eher: STM32F030. Von einem STMD32F030 hat nichtmal Google jemals irgendwas gehört. (Könnte sich nach diesem Thread natürlich ändern ;o) Vielleicht, weil er keine zwei Kerne hat und auch keine 8 zusätzlichen CoProzessoren für schnelles Pin-Geklimpere. Vielleicht aber auch deshalb, weil er sehr viel weniger RAM, Flash und Takt hat als der Pico. Vielleicht aber auch deshalb, weil er nicht als fertiges Platinchen daherkommt, was einerseits quasi sofort auf Prototypen-Boards jeder Art benutzbar ist, andererseits aber auch problemlos als Modul auf ein Träger-PCB gelötet werden kann. Sehr wahrscheinlich ist es aber das Zusammentreffen all dieser Punkte, warum das Teil keine besondere Erwähnung wert war, der Pico hingegen schon. Der Pico ist schon ein sehr nettes kleines übersichtliches Teil mit sehr viel Leistungspotential, für das man sonst eher im M3- oder M4-Bereich einkaufen müsste.
Ich fürchte, dass der Raspberry Pico so ein Unicum wird, wie der Propeller. Aber warten wir mal ab.
Das Ding ist nun seit ein paar Tagen auch in der Türkei erhältlich und eigentlich wollte ich gleich ein paar bestellen; aber dann habe ich davon Abstand genommen. Ich möchte mal sehen, ob die nackten Chips irgendwann mal bei Digikey & Co. erhältlich sein werden. Denn Boards, die ich in der Vergangheit mit einem euphorischen "Toll!" bestellt hatte, habe ich genug in der Schublade :)
Mehmet K. schrieb: > Ich möchte mal sehen, ob die nackten Chips > irgendwann mal bei Digikey & Co. erhältlich sein werden. Mit dem Chip versehene Boards sind jedenfalls schonmal vier bei Digikey gelistet. Das Problem mit dem Chip ist sein Package – das ist nicht so wirklich bastler-/handlötfreundlich, und Flash ist ja auch noch extern angebunden, so dass es schon keine zu schlechte Idee war, das zunächst fertig auf dem Breakout-Board, das der Pico ja nunmal irgendwie ist, rauszubringen.
Moin, - Mehmet K. schrieb: > Denn Boards, > die ich in der Vergangheit mit einem euphorischen "Toll!" bestellt > hatte, habe ich genug in der Schublade :) Verwandte Seele! Gruesse Th.
Beitrag #6638070 wurde von einem Moderator gelöscht.
Beitrag #6638082 wurde von einem Moderator gelöscht.
Beitrag #6638129 wurde von einem Moderator gelöscht.
Mehmet K. schrieb: > Ich möchte mal sehen, ob die nackten Chips irgendwann mal bei Digikey & > Co. erhältlich sein werden. Ich gehe jedenfalls ganz fest davon aus, denn anders gefragt: Warum sollten sie den nackten Chip nicht vermarkten? Im Gegensatz zu den Broadcom-CPUs auf den Raspberry Pis liegt es doch diesmal komplett in deren Hand, ob überhaupt und wenn ja, an wen sie die Dinger verkaufen und nachdem das Teil jetzt wohl so spottbillig zu produzieren ist ("bonding and packaging is more expensive than the die itself") sind doch jetzt die hauptsächlichen Kosten die Entwicklungskosten. Die wiederum werden aber nicht geringer wenn sie den Controller für sich behalten, im Gegenteil: Je mehr sie davon verkaufen, desto eher holen sie die wieder rein.
> an wen sie die Dinger verkaufen
Es sind schlappe M0. Die koennen nicht mal 32 bit mit 32 bit
zu 64 bit multiplizieren. Wer will sowas schon.
Jeder M3. und erst recht M4 oder M7 rauchen die in der Pfeife,
... schrieb: > Die koennen nicht mal 32 bit mit 32 bit zu 64 bit multiplizieren. Na und? Das braucht man eh relativ selten.
Beitrag #6638810 wurde von einem Moderator gelöscht.
Beitrag #6638824 wurde von einem Moderator gelöscht.
Beitrag #6638830 wurde von einem Moderator gelöscht.
... schrieb im Beitrag #6638810: > Jede Multiplikation in der nativen Wortbreite braucht das. > Selten ist was anderes. Komisch dass das schon 4 bit Taschenrechner ohne Problem schafften. Mein kleiner Sohn kann es auch, indem er die Zahl in Dezimale Ziffern zerlegt. Auch der muss sich keine 64 Bit merken können. Du tust ja gerade so, als sei es für den Cortex M0 unmöglich, zwei 32 bit Zahlen zu multiplizieren. Wenn man das wirklich mal braucht, dann kann man es auch tun. Ist zwar langsamer aber geht. Und da man das nur selten braucht, kann man (nur du nicht) auch meistens damit leben. Bist so ein hardcore Assembler Programmierer, der andere Sprachen ablehnt? Das würde diese Sichtweise erklären. ARM Cortex wurde nicht für Assembler optimiert.
Beitrag #6638950 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Bist so ein hardcore Assembler Programmierer, der andere Sprachen > ablehnt? Das würde diese Sichtweise erklären. Das ist doch Quatsch. Assemblerprogrammierer machen es erst möglich, dass C-only-Fritzen eine 32x32->64-Multiplikation überhaupt gebacken bekommen. Und das ist lustigerweise sowohl dann der Fall, wenn das Target das in Hardware kann, als auch dann, wenn es das nicht kann und man das aus weniger mächtigen Operationen zusammenbauen muss. Wo glaubst du denn, wo diese Fähigkeit in C herkommt, wenn nicht aus der Kompetenz von Leuten, die die Hardware und auch deren Assembler beherrschen? Glaubst du an den Allmächtigen C-Gott, der das einfach mal so aus dem Nichts möglich macht? Dann passt du wirklich in dieses Forum...
c-hater schrieb: > Glaubst du an den Allmächtigen C-Gott, der das einfach mal > so aus dem Nichts möglich macht? Nein, aber ich glaube auch nicht an den Allmächtigen Assembler-Gott. Dafür habe ich selbst genug in Assembler Programmiert (Mikrocontroller und Treiber für DOS) und da beurteilen zu können. Ich finde, du solltest mal aufhören, auf Programmierer für bestimmte Programmiersprachen herum zu hacken. Das sind nur Werkzeuge, keine Religionen und sie bestimmen auch nicht über das Schicksal der Menschheit. Das du C nicht magst ist deine Sache und du hast es uns reichlich oft kund getan. Nur interessiert uns dein persönlicher Geschmack diesbezüglich so wenig, wie deine Vorlieben für bestimmtes Essen oder Klamotten. Wenn ich mal Meinungen einholen würde, welche Programmiersprache für ein gewisses Projekt wohl die sinnvollste sein mag, würde ich alle greifbaren Leute fragen nur dich nicht. Denn deine Antwort kenne ich seit Jahren.
@c-hater > Das ist doch Quatsch. Assemblerprogrammierer machen es erst möglich, > dass C-only-Fritzen eine 32x32->64-Multiplikation überhaupt gebacken > bekommen. die Quellen des Berkleys Softfloats hast du dich nie angeschaut, oder ? Eventuell muss du dir eine kopie des "The C Book" zulegen und rein lesen, ist alles da... vielleicht ist nicht "modern", aber die Sprache ist schon mächtig und für Guten oder nicht gibts für fast jeden Prozessor.
Gibt es eigentlich schon was zum Thema CMSIS? Ich würde ja gerne mal einen SysTick_Handler() benutzen wie ARM sich das gedacht hat...
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.