Raspi Pico -taugt der was und in C programmieren?

https://www.youtube.com/watch?v=B5rQSoOmR5w

und Anderes auf YT.

https://github.com/raspberrypi/pico-sdk

Man kann mit dem RASPI nicht in C programmieren.
Man kann für ihn aber Programme in c programmieren.

Sorbit schrieb:

> Man kann mit dem RASPI nicht in C programmieren.

Doch, natürlich könnte man das, wenn auch nicht mit dem Raspi alleine. 
Mit einem Display, einer Tastatur und einer SD-Card als Peripherie 
könnte man aber tatsächlich auch in C darauf programmieren.

Macht nur wenig Sinn, weil ein Cross-Compiler-Umgebung auf einem PC 
weitaus komfortabler und schneller ist.

Es ist kein Trollversuch sondern einfach nur die Frage.
Habe bisher immer mit dem Atmega 8 gebastelt und ihn mit C programmiert. 
Dazu nutze ich das (ehemalige) AVR Studio 7.0 und schreibe meine 
Programme mit C. Beim Raspi und Raspi Pico geht ja alles mit Python. 
Leider wollte ich mir keine zweite Sprache antun. Beim AVR geht ja viel 
mit ISP und meinem MK2. Doch die Frage ist, wie erfolgt die 
Programmierung Raspi Pico mit USB? Welche Umgebung muss ich nutzen? geht 
das auch mit AVR Studio oder brauche ich dazu wieder neue Hardware?

Sorbit schrieb:
> Man kann mit dem RASPI nicht in C programmieren.
> Man kann für ihn aber Programme in c programmieren.

Da habe ich mich wohl falsch ausgedrückt. Sollte natürlich "man kann für 
ihn aber in C programmieren"

Jack V. schrieb:
> https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf

In diesem Teil wird sehr viel mit dem Raspi gemacht. Braucht man den 
immer dazu? oder kann man wie beim Atmega IO oder Display anschliessen 
und eine Funktion oder Anzeige damit programmieren?

Jack V. schrieb:
> https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf
> https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf
>
> … was ist unklar?

Das "pico-sdk" kann/muß man dazu nutzen, um überhaupt nähere 
Informationen zur Funktion des RP2040 zu bekommen, da die Dokumentation 
(Datenblatt) unzureichend ist. Ansonsten lasse ich die Finger von dem 
intransparenten Kram.

Der Bastler schrieb:
> Doch die Frage ist, wie erfolgt die
> Programmierung Raspi Pico mit USB? Welche Umgebung muss ich nutzen? geht
> das auch mit AVR Studio oder brauche ich dazu wieder neue Hardware?

Im Prinzip kannst Du die Arduino IDE nehmen, und damit den üblichen 
"Brei" erzeugen.
Vorteil: Du mußt Dich kaum mit dem RP2040 auseinandersetzen und es wird 
keine zusätzliche Hardware benötigt.
Nachteil: es wird mit langsamem Compiler viel Code erzeugt, ohne große 
Möglichkeit zu debuggen. Die speziellen Fähigkeiten des RP2040 bleiben 
verborgen.

Einen anderen Ansatz findest Du zum Beispiel hier: 
https://www.eevblog.com/forum/microcontrollers/rp2040-baremetal-starter-project/msg3909527/#msg3909527
Als Hardware brauchst Du dazu einen SWD-Programmierer Jlink EDU mini zum 
Beispiel. Du mußt einiges an Zeit investieren - egal wie Du es angehst.

Der Bastler schrieb:
> Beim Raspi und Raspi Pico geht ja alles mit Python.
> Leider wollte ich mir keine zweite Sprache antun.
> Beim AVR geht ja viel mit ISP und meinem MK2.

Kannst du diese drei Zeilen bitte nochmal lesen, darüber sinnieren und 
dann uns den Sinn erklären?

Du hast wohl Schwierigkeiten, dich klar auszudrücken. Entsprechend fällt 
es uns und den Suchmaschinen schwer, die passende Antworten zu geben.

Ich denke du möchtest den Raspberry Pi Pico in C Programmieren, und das 
Programmieren auf deinem PC erledigen. Kannst du 100% sicher machen.

> Doch die Frage ist, wie erfolgt die Programmierung Raspi Pico mit USB?

Der hat einen Bootloader, also einfach dran stecken und Knöpfchen 
drücken.

> Welche Umgebung muss ich nutzen?

Im Grunde genommen kannst du jede Entwicklungsumgebung verwenden, die 
separat installierte C Compiler und Bibliotheken nutzen kann. Da fallen 
mir spontan diese ein: Eclipse, Netbeans, Qt Creator, Visual Studio 
Code, Arduino IDE. Es gibt sicher noch mehr.

Hier ein Video, dass die Programmierung in Visual Studio Code vorführt: 
https://www.youtube.com/watch?v=B5rQSoOmR5w

Und hier eine Hilfe für die einfachere Arduino IDE, die dir zumindest 
anfangs wohl eher gefallen wird: 
https://draeger-it.blog/raspberry-pi-pico-in-der-arduino-ide-programmieren/
Für weitere Doku solltest du danach auf http://arduino.cc vorbei 
schauen.

> geht das auch mit AVR Studio oder brauche ich dazu wieder neue Hardware?

Nein es ist kein AVR. Neue Hardware ist nicht nötig, weil das Ding einen 
USB Bootloader enthält.

> In diesem Teil wird sehr viel mit dem Raspi gemacht.
> Braucht man den immer dazu?

Du drückst dich seltsam aus. Wenn du den Raspberry Pi Pico programmieren 
willst, dann brauchst du den immer dazu. Wie willst du dein Programm 
sonst testen?

> oder kann man wie beim Atmega IO oder Display anschliessen
> und eine Funktion oder Anzeige damit programmieren?

Nicht "oder" sondern "und". Natürlich kannst du an die I/O Pins des 
Raspberry Pi Pico so ziemlich alles anschließen, was du willst.

Wirre hoch 3

Stefan ⛄ F. schrieb:
>> In diesem Teil wird sehr viel mit dem Raspi gemacht.
>> Braucht man den immer dazu?
>
> Du drückst dich seltsam aus. Wenn du den Raspberry Pi Pico programmieren
> willst, dann brauchst du den immer dazu. Wie willst du dein Programm
> sonst testen?

Raspi != Raspberry Pi Pico

m.n. schrieb:

> Das "pico-sdk" kann/muß man dazu nutzen, um überhaupt nähere
> Informationen zur Funktion des RP2040 zu bekommen, da die Dokumentation
> (Datenblatt) unzureichend ist.

Unsinn. Es ist im Gegenteil so, dass das C-SDK nur einen Teil der 
Features der RP2040-Hardware unterstützt. Will man also mehr als 
Blocking-Gedaddel knapp über Arduino-Niveau, kommt man nicht darum 
herum, sich mit der Hardware, also dem RP2040-DB zu beschäftigen.

Sprich: es fehlt im SDK insbesondere ein asynchrones (non-blocking) API 
für die Standard-Peripherie. Von UART über SPI und I2C bis hin zu ADC.

Für UART ist immerhin eine interruptbasierte Notlösung vorhanden. 
Wirklich schön ist die aber nicht. Macht halt das, was mit Interrupts 
möglich ist.

Richtige Unterstützung für schnelles, asynchrones IO muss man sich 
selber basteln (vorzugsweise unter Zuhilfenahme des recht ordentlich 
gelungenen DMA-API und der APIs der jeweiligen Peripherie).

Ein generelles Konzept für sowas wäre sehr wünschenswert gewesen und 
hätte das SDK deutlich über Arduino-Niveau gehoben, ist aber eben leider 
nicht vorhanden. Mein Eindruck von dem SDK ist: es wurde vor allem mit 
der Absicht entwickelt, dass halt der Arduino-Gammel darauf aufsetzen 
kann...

c-hater schrieb:
> Unsinn. Es ist im Gegenteil so,

Da ist sie wieder, Deine Leseschwäche.

> also dem RP2040-DB zu beschäftigen.

.. das leider zu dünn geraten ist. Wesentliche Sachen muß man zwischen 
den Zeilen Lesen und mit Hardware testen, ob man sie richtig verstanden 
hat.

In einigen Beiträge sind dafür, andere dagegen. Das scheint nicht ganz 
so einfach zu sein wie ich es mir erhofft hatte.
Um das Thema zu beenden, das ganze hat für mich keinen Sinn, zu 
kompliziert für mich als Anfänger, keine Unterstützung von der Hardware, 
Unklare Erklärungen im Datenblatt oder einfach nicht vorhanden.
Fazit für mich: Lass die Finger da von sonst hast du genügend Zeit dich 
zu Ärgern.

Der Bastler schrieb:
> Das scheint nicht ganz
> so einfach zu sein wie ich es mir erhofft hatte.

Und das ist ein Grund, den Kopf ins Korn zu stecken und die Flinte in 
den Sand zu werfen?

Jedenfalls haben diese Boards und auch der lose Chip den unschlagbaren 
Vorteil, dass sie nicht nur billig sondern auch verfügbar sind.

> Und das ist ein Grund, den Kopf ins Korn zu stecken und die Flinte in
> den Sand zu werfen?

Ja sicher.
Scheinbar ist er ja bislang auch ohne "Ar*no" ausgekommen.

Mein Gott, willst Du das Ding einfach Mal ausprobieren, oder Deine 
Existenz darauf aufbauen?
Installiere das SDK und einen Editor Deiner Wahl und los geht es. Du 
hast doch nun wirklich genug Informationen bekommen.

M3 schrieb:
> Scheinbar ist er ja bislang auch ohne "Ar*no" ausgekommen.

Hat das was mit dem " Pico ---- und in C programmieren" zu tun?

> Hat das was mit dem " Pico ---- und in C programmieren" zu tun?

Genau das hier:
> Habe bisher immer mit dem Atmega 8 gebastelt und ihn mit C programmiert.
> Dazu nutze ich das (ehemalige) AVR Studio 7.0 und schreibe meine
> Programme mit C.

Mein Eindruck:
Das SDK ist nicht mal ansatzweise vollständig und der präsentierte
Code nicht verständnisfördernd.
Die Dokumentation ist im gleichen schlechten Zustand.
Teile der Peripherie sind nur eingeschränkt brauchbar.

Jeder vernünftige Mensch hält da Abstand.

Dem TO gebührt Respekt, nicht auf solchen Hype hereinzufallen.

M3 schrieb:
> Das SDK ist nicht mal ansatzweise vollständig und der präsentierte
> Code nicht verständnisfördernd.
> Die Dokumentation ist im gleichen schlechten Zustand.
> Teile der Peripherie sind nur eingeschränkt brauchbar.

Könnte das vielleicht auch daran liegen, daß es Dich einfach 
überfordert, so rein vom Verständnis her?

Oder kannst Du konkrete Beispiele nennen, an denen die Dokumentation 
unvollständig ist, so daß die Peripherie "nur eingeschränkt" brauchbar 
ist?

Der Bastler schrieb:
> In einigen Beiträge sind dafür, andere dagegen. Das scheint nicht
> ganz
> so einfach zu sein wie ich es mir erhofft hatte.
> Um das Thema zu beenden, das ganze hat für mich keinen Sinn, zu
> kompliziert für mich als Anfänger, keine Unterstützung von der Hardware,
> Unklare Erklärungen im Datenblatt oder einfach nicht vorhanden.
> Fazit für mich: Lass die Finger da von sonst hast du genügend Zeit dich
> zu Ärgern.

Richtige Entscheidung 👍
Achim, bleib besser bei Attiny 841 - was macht der SPI 🤷‍♂️

> Könnte das vielleicht auch daran liegen, daß es Dich einfach
> überfordert, so rein vom Verständnis her?

Unvollständige Dokumentationen überfordern immer mein Verständnis.

Ansonsten habe ich in den letzten Jahren einige LPC4370 verbaut.
Bei denen sitzt in der Peripherie mitunter noch ein Cyclone 2 o. 10.
Mitunter, wenn es gebraucht wird, auch kleine Festkomma-DSP von TI.
Besonders schick: Man kommt auch an das interne RAM per Hostinterface.
So ein LPC4370 hat ja auch 2 recht schnelle M0 Kerne. Aber eben auch
noch einen M4-Kern. Das ist nun genau das was ich brauche.
Vor Jahren habe ich mich auch schon mal am IXP425 versucht.
Der konnte schon recht zeitig 533 MHz CPU-Takt.

Eine Überforderung kann ich da nicht erkennen.

Ich bin für den Pico nicht in der Zielgruppe.
Gäbe es ihn nicht, würde ich ihn auch überhaupt nicht vermissen.
Er ist für mich wie eine Antwort auf eine nie gestellte Frage.

Aber wer soll eigentlich die Zielgruppe sein?


> an denen die Dokumentation unvollständig ist

Das erwarte ich vom Qualitätsmanagement des Herstellers.
Der hat aber offenbar keins.


> Oder sponsorst du jedem der Bedarf hat nen paar STM32 & Co?

Frag das doch ST selber. Ich habe da schon einiges bekommen.

M3 schrieb:
> Genau das hier:
Ich sehe da nichts von Arduino....

Schlechte Dokumentationen und / oder auch exotische 
Entwicklungsumgebungen haben schon so manches, möglicherweise 
brauchbares Produkt zu Fall gebracht.
Wäre schade um den RP2040.

Nuff schrieb:
> Schlechte Dokumentationen und / oder auch exotische
> Entwicklungsumgebungen haben schon so manches, möglicherweise
> brauchbares Produkt zu Fall gebracht.
> Wäre schade um den RP2040.

Warum?
Hat der ausser dem raspberry hype etwas was die anderen nicht haben?
Ich denke ein ESP32 schlägt den 2040 multidimensional.

Pepe schrieb:
> ein ESP32 schlägt
Das hat zwar alles nichts mehr mit der Frage des TE zu tun, aber gerade 
der ESP32 kam von Anfang an mit einem vollständigen SDK und guter 
Dokumentation?

Was genau gibt es denn an der Doku zum Pico zu bemaengeln?

Sie ist zwar fuer jemanden der es gewohnt ist normale Datenblaetter
anderer MCUs zu lesen, etwas ungewoehnlich geschrieben, aber durchaus
lesbar und ich hab bisher alles gefunden was ich finden wollte.

Ich koennte mir sogar vorstellen das insbesondere Anfaenger mit dem
Stil des Pico Datenblatts besser klarkommen.

Wie ich ja schonmal sagte, der gesamte Pico und auch seine Doku, macht 
eher den Eindruck als wenn er aus der Sicht eines Softwaremenschen 
entwickelt und dokumentiert wurde und nicht von Hardwaremenschen die in 
Verilog oder Transistoren denken. :)
Das ist nicht unbedingt besser als der klassische Ansatz, aber 
interessant anders.

Olaf

Muss mann denn von Anfang an alle Funktionen des Chips beherrschen? 
Musst du alle Funktionen deines PC beherrschen?

Mit Arduino ist er sehr einfach zu benutzen. Alles was in Arduino 
vorgesehen ist funktioniert, damit kann man schon viele tolle Sachen 
basteln.

Qualitativ mag die Doku und Software weit hinter anderen etablierten 
Marken zurück liegen. Doch dafür ist das Ding billig und gut verfügbar. 
Damit kann derzeit nach meinem Kenntnisstand keine andere Marke 
mithalten.

Beim ESP2866 lief es nicht anders. Datenblatt und SDK waren anfangs 
sogar noch viel schlechter, doch die pfiffigen Arduino Leute (und andere 
parallel dazu) haben recht schnell das Beste draus gemacht, was damals 
ging. Erst danach wurde der Chip in Hobby Kreisen so richtig 
interessant. Ohne diese 3rd party Frameworks wäre Espressif womöglich 
verhungert.

> Muss mann denn von Anfang an alle Funktionen des Chips beherrschen?

Das ist eine Fragestellung die mich auch immer wieder verwundert. Ich 
bin es gewohnt Controller zu programmieren deren Datenblaetter mehrere 
Tausend Seiten haben koennen. (z.B auch den hier im Thread genannten 
LPC4370 wegen seines ADCs)
Aber man muss sich ja immer nur mit dem Teil beschaeftigen den man 
gerade braucht!

> Qualitativ mag die Doku und Software weit hinter anderen etablierten
> Marken zurück liegen.

Wie schon gesagt, ich sehe das nicht so. Er ist nur anders.

>Doch dafür ist das Ding billig und gut verfügbar.

Er ist vor allem wegen PIO und Dual-MCU mal interessant anders. Gerade 
als Bastler macht man das doch wegen der intellektuellen 
Herausforderung. Da ist der PICO schon interessant.
Ich bin auch mal sehr gespannt welchen Eindfluss die PIO auf neue 
Controller anderer Hersteller haben wird. Das Konzept ist ja nicht neu. 
Ich kenne es z.B schon von der TPU eines 68332 und es gab IMHO auch noch 
1-2 andere Implementationen von sowas. Aber der Pico hat sowas 
ploetzlich einer breiteren Masse zur verfuegung gestellt und ja ich will 
das auch bitte schoen demnaechst in einen neuen STM32 so vorfinden.

Wenn ich etwas bemaengel dann das die PIOs PIO heissen. Jeder der noch 
eine Z80PIO kennt ist das erstmal etwas verwundert. :-D

Olaf

https://www.freertos.org/smp-demos-for-the-raspberry-pi-pico-board.html


Wieso komplett selbständig darauf herumfrickeln?

Die Kiste hat 133MHz, damit gab's früher schon Windows 95. Wieso also 
nicht direkt auf FreeRTOS setzen?

Heiner schrieb:
> was macht der SPI
Display geht, bin bei Sonderzeichen.
Ansonsten habe ich keinerlei Absicht was mit Raspi Pico zu machen.
Lese zwar mit bin aber nicht ich.
achim

Onkel Ted schrieb:
> Wieso also nicht direkt auf FreeRTOS setzen?

Als ehemaliger ATmega Programmierer hat man erstmal keine Erfahrung mit 
FreeRTOS. Immer schön einen Schritt nach dem anderen machen, nicht zu 
viele Baustellen gleichzeitig aufreißen.

Der Bastler schrieb:
> Das scheint nicht ganz
> so einfach zu sein wie ich es mir erhofft hatte.

Du hast kein Ziel, darum ist Dir der Weg zu steinig.
Dann lass es bleiben.

Für andere ist der RP2040 eine lieferbare Option, anstatt ein Jahr auf 
fehlende µCs zu warten.

Pepe schrieb:
> Ich denke ein ESP32 schlägt den 2040 multidimensional.

Ugh, Tiefschlag, ausgerechnet ESP32, das war am Anfang richtig finster.

Ein brauchbarer Kandidat für den TO könnte der STM32F030 sein.
Die konnte man vor einiger Zeit noch als 10er Pack aus China
für 7 Euro beziehen. Dazu die passenden SSOP20 Adapter.
Mittlerweile leider 3 x so teuer. Aber es gibt für den STM32F030
immerhin genügend Anbieter z.B. auf Ebay.

Ein Nucleoboard ist für den Typ ebenfalls verfügbar und wegen
des dort enthaltenen SWD-Adapters auch sehr empfehlenswert.
Es erleichtert auch die ersten Schritte ungemein, ein
garantiert lauffähiges Board benutzen zu können.

Lesen wird der TO einiges müssen:
Das Datenblatt von ST,
das Referenzmanual von ST,
das M0-Referenzmanual von ARM und
natürlich die Errata.

Dann braucht er nur noch einen Compiler, und kann wie mit seinen
ATMEGA-8 loslegen.

Nachtrag:

Es gibt wohl von ST eine freie Lizenz für die Entwicklungsumgebung
von Keil für die ST M0-Serie. Die ist schon wegen des darin
enthaltenen Debuggers für den Anfänger sehr empfehlenswert.
Das wäre für den TO gegenüber dem "debuggerlosen" ATMEGA-8
auch ein echter Fortschritt.

> Das ist nur blöd wenn man dann einen M3 oder größer verwenden möchte.

Irgendetwas ist immer.
Einfach einen Schritt nach dem anderen.
Und der erste Schritt wäre ein M0.

IAR kennt den RP2040 seit EWARM Version 9.10.2

Die auf 32 kByte Codegröße beschränkte "Kickstart"-Version gibt "für 
lau", andere werden dann .. empfindlich teuer.

Oh, und es gibt sogar ein Video dazu!

https://www.iar.com/knowledge/learn/programming/getting-started-with-the-raspberry-pi-pico-and-iar-embedded-workbench-for-arm/

> Die auf 32 kByte Codegröße beschränkte "Kickstart"-Version gibt "für
> lau"

Naja, die reicht ja dann für den kleinen STM32F030 auch.
Und mit etwas Beschränkung auf für den STM32F103.

Den Debugger vom Keil halte ich allerdings für geringfügig besser
weil übersichtlicher.

> die ursprüngliche Frage
hat sich für den TO ohnehin erledigt.

> Um das Thema zu beenden, das ganze hat für mich keinen Sinn, zu
> kompliziert für mich als Anfänger, keine Unterstützung von der Hardware,

Aber es gibt ja oberhalb des ATMEGA8 noch genug 32 bit Luft
um da seine Nase hineinzustecken und trotzdem bei seinem
für ihn bewährten Umgang mit Datenblatt und Controller zu bleiben.

> sich in eine IDE
> einzuarbeiten und für den nächsten Schritt dann auf eine andere wechseln
> zu müssen

Ach?
Die wesentlichen Bestandteile der IDEs sind doch praktisch dieselben.
Von den Keil-Extensions(Packs) vielleicht mal abgesehen.
Die muss man ja nicht benutzen. Das würde der TO sicher anfangs auch
nicht tun.
Kennt man eine, findet man das gesuchte bei der anderen auch.
Ansonsten sind es beides kommerzielle Produkte mit eben
auch einer kommerziell guten Dokumentation die man lesen muss.

Wenn man mit Xilinx ISE umgehen konnte, war der Sprung zu
Alteras Quartus auch nur ein kleiner Hüpfer.

M3 schrieb:
>> Die auf 32 kByte Codegröße beschränkte "Kickstart"-Version gibt "für
>> lau"
> Und mit etwas Beschränkung auf für den STM32F103.

Ein "Hello World" auf USB-Serial braucht (mit HAL) etwa 20 kB davon.

> Ein "Hello World" auf USB-Serial braucht (mit HAL) etwa 20 kB davon.

Ich glaube nicht, dass der TO mit der HAL oder USB anfangen wird.
Der STM32F030 hätte auch keine USB-Peripherie.

Vielleicht einmal probieren. Um festzustellen, dass sein bisher
durch Lesen und Erfahrung erworbenes Wissen wieder einmal nichts
mehr nützt, um dann ohne HAL weiterzumachen.

Die Beschränkung der Grösse des Flashs beim kleinen STM32F030
tut da ihr übriges. Die will man vielleicht nicht mit aufgeblähtem
HAL-Code füllen, um am Ende das eigentlich zu lösende Problem
nicht mehr unterbringen zu können.

Insoweit ist die Information mit den 20 kB ja ganz interessant
aber ansonster relativ nutzlos.

M3 schrieb:
> Insoweit ist die Information mit den 20 kB ja ganz interessant
> aber ansonster relativ nutzlos.

Ich wollte die oben genannte "Beschränkung für den STM32F103" 
konkretisieren. Damit man ein Gefühl davon bekommt, wie viel von den 32 
kB für eigenen Code übrig bleiben, wenn man USB verwendet.