[RPI Pico] Entwickeln mit C unter Windows

Meme schrieb:

> Es scheint irgendwie so, dass ich CMake lernen muss

Darauf läuft es hinaus, ja.

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...

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?

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.

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.

> 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.

... 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.

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.