Hallo Leute Habe mir heute den Raspi Pico mal näher angesehen und alle Möglichen Berichte gelesen. Eigentlich bin ich genauso schlau wie vorher. Konnte leider keine klare Antwort dazu finden. Vielleicht kann mir jemand weiter helfen. Kann man mit dem Raspi Pico in C programmieren und wie geht das? LG B.
Der Bastler schrieb: > Konnte > leider keine klare Antwort dazu finden. https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf … was ist unklar?
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.
c-hater schrieb: > Sorbit schrieb: > >> Man kann mit dem RASPI nicht in C programmieren. > > Doch, natürlich könnte man das Das ist halt das Problem, wenn die konkret zuzuordnenden Hardwarebezeichnungen nicht genutzt, und stattdessen selbstgewählte, maximal unscharfe Begriffe verwendet werden. Tatsächlich war im Eingangsbeitrag vom „Raspi Pico“ die Rede und es wurde gefragt, ob man damit in C programmieren könne. Insofern passt die Aussage von Sorbit schon – wenn auch die verwendete Bezeichnung („RASPI“ – das ist kein …tes Akronym, BTW) fehlerhaft war. Allerdings ist anzunehmen, dass es dem TE tatsächlich um die Programmierung des „Raspberry Pi Pico“ (man beachte die elegante Eindeutigkeit der offiziellen Bezeichnung!) in C ging, und nicht um die C-Programmierung mit dem Raspberry Pi Pico. Die Formulierung könnte natürlich auch tatsächlich so gewollt gewesen sein – dann ist’s einer den besseren Trollversuche :)
:
Bearbeitet durch User
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: > 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. Nö. Den RP2040 kann man u.a. mit der Arduino IDE normal in C bzw. C++ progrmmieren. https://www.heise.de/tests/Raspberry-Pico-mit-der-Arduino-IDE-programmieren-6001575.html Es gibt auch andere IDEs oder gar für die ganz harten Jungs Kommandozeilenkompiler mit make.
:
Bearbeitet durch User
Rudolph R. schrieb: > Meine Empfehlung wäre da VSCode mit PlatformIO und wizio-pico: > https://github.com/Wiz-IO/wizio-pico Was ist denn Wizio? Das readme ist nur bedingt aussagekräftig und die Tiraden gegen das Pico-Team helfen nicht wirklich.
Tim . schrieb: > Rudolph R. schrieb: >> Meine Empfehlung wäre da VSCode mit PlatformIO und wizio-pico: >> https://github.com/Wiz-IO/wizio-pico > Was ist denn Wizio? Das readme ist nur bedingt aussagekräftig und die > Tiraden gegen das Pico-Team helfen nicht wirklich. Ich kann deine Bedenken nicht nachvollziehen! Da steht doch explizit "READ WIKI". Klick Link ... Oh ...
1 | Welcome to the wizio-pico WIKI |
2 | A lyrical digression |
3 | ... |
Tim . schrieb: > Rudolph R. schrieb: >> Meine Empfehlung wäre da VSCode mit PlatformIO und wizio-pico: >> https://github.com/Wiz-IO/wizio-pico > > Was ist denn Wizio? Oh, ok, die Frage ist berechtigt wenn man PlatformIO noch nicht kennt. PlatformIO hat Module, eben "Platforms", zum Beispiel "Atmel AVR", "Espressif 32", "GD GD32", "Nordic nRF52" oder "ST STM32" und noch einige andere. Diese Module stellen den Support für die Plattform zur Verfügung, Compiler, Tools und so weiter, je nach Modul für unterschiedliche "Frameworks". Die "Frameworks" sind "Arduino", "CMSIS", "Mbed", "Stm32cube", "Zephyr"... Und das Wizio-Pico ist jetzt so eine Plattform und erlaubt sowohl Arduino als auch Baremetall (mit dem PICO-SDK) Programmierung des RP2040.
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.
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
Stefan ⛄ F. schrieb: > Wenn du den Raspberry Pi Pico programmieren > willst, dann brauchst du den immer dazu. Glaube, TE bezieht sich darauf, dass in der Schnellstart-Einleitung am Anfang von einem Raspberry Pi mit Raspberry Pi OS als Entwicklungsrechner ausgegangen wird. Das braucht man natürlich nicht – jeder andere Rechner mit einem USB-Anschluss tut den Job genauso. Allerdings scheinen dem TE da auch noch einige grundlegende Zusammenhänge zu fehlen, so dass der Eindruck entsteht, den Sorbit so schön zusammengefasst hat.
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...
Rudolph R. schrieb: > Und das Wizio-Pico ist jetzt so eine Plattform und erlaubt sowohl > Arduino als auch Baremetall (mit dem PICO-SDK) Programmierung des > RP2040. Ok, danke für die Erklärung. Ist es die einzige RP2040 unterstützung für platform.io oder gibt es noch andere Optionen?
Tim . schrieb: > Ok, danke für die Erklärung. Ist es die einzige RP2040 unterstützung für > platform.io oder gibt es noch andere Optionen? Das findet man heraus wenn man in PlatformIO im "Board Explorer", zu finden als "Boards", nach dem Gewünschten sucht, in dem Fall "RP2040". Es gibt noch "Raspberry Pi RP2040" als Plattform, das unterstützt allerdings nur Arduino als Framework. Das nutzt ArduinoCore-mbed und dort wurde die Funktion spi_init() vom Pico-SDK in _spi_init() umbenannt. Wenn man SPI über DMA machen möchte findet man sowas heraus, das geht mit der seltsamen SPI-Klasse von dem https://github.com/arduino/ArduinoCore-mbed nämlich nicht. Dabei ist das der offizielle Arduino Core, DMA kennen die nicht. Und wegen einem Bug in Common.h, vererbt aus https://github.com/arduino/ArduinoCore-API muss man stdbool.h includieren vor dem Arduino.h, mal schauen, wann das durch die ganzen Abhängigkeiten soweit durchgereicht ist, dass der "Fix" in Common.h in "Raspberry Pi RP2040" angekommen ist.
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: > Teile der Peripherie sind nur eingeschränkt brauchbar. > Jeder vernünftige Mensch hält da Abstand. Das heißt vernünftige Menschen wechseln das Hobby? Oder sponsorst du jedem der Bedarf hat nen paar STM32 & Co?
M3 schrieb: > Das SDK ist nicht mal ansatzweise vollständig und der präsentierte > Code nicht verständnisfördernd. Das hat früher auch niemanden abgehalten und es gibt auch immer noch genug andere Controller da draußen bei denen das auch nicht so ist. Es gibt zum Beispiel immer noch Leute die das ASF von Atmel verwenden, das Hauptziel von dem Sumpf scheint gewesen zu sein möglichst viel an Funktionalität zu verheimlichen. Dagegen kann man sowas wie gpio.c aus dem Pico-SDK schon gut lesen. M3 schrieb: > Die Dokumentation ist im gleichen schlechten Zustand. > Teile der Peripherie sind nur eingeschränkt brauchbar. Welche Teile denn zum Beispiel? Mehr als GPIO und SPI habe ich mit dem RP2040 bisher praktisch nicht gemacht.
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.
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?
Nuff schrieb: > Schlechte Dokumentationen und / oder auch exotische > Entwicklungsumgebungen haben schon so manches, möglicherweise > brauchbares Produkt zu Fall gebracht. VSCode heutzutage als exotisch zu bezeichnen, ist zumindest gewagt. Was genau an der Doku so furchtbar schlecht wäre, wurde ja leider auch noch nicht konkret erwähnt – zumindest für mich gab’s da noch keine Stolperstellen. Pepe schrieb: > Hat der ausser dem raspberry hype etwas was die anderen nicht haben? Preis, Verfügbarkeit, Community, einige Hardwaredetails … wo du grad so den ESP32 ansprichst: dessen Doku ist ja nun auch nicht direkt als überragend bekannt …
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. Auch wenn hier einige immer gegen ST und seine Kundenbindung wettern: die IDE ist sehr gut und die MCU Auswahl ist riesig. Von kleinen M0 mit 2 kB RAM / 16 kB Flash bis zu H7 mit allem. Für M0 war der Keil Compiler allerdings immer besser, hat deutlich kompakteren Code erzeugt. Den ARMCC gibt es jetzt auch online, ich weiß aber nicht wieweit der frei genutzt werden kann. Der ersetzt auch die alte Mbed Online Lösung, hatte ich letzte Woche mal ausprobiert. Läuft erstaunlich gut und schnell, man merkt nicht das man im Browser arbeitet. Mit WebUSB kann man darüber auch flashen und debuggen.
> 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.
M3 schrieb: > Einfach einen Schritt nach dem anderen. > Und der erste Schritt wäre ein M0. ich möchte damit nur sagen das es blöd ist sich in eine IDE einzuarbeiten und für den nächsten Schritt dann auf eine andere wechseln zu müssen. Gut, man kann den Keil Compiler natürlich auch käuflich erwerben. Und ein M3 ist kein Unterschied in der C Programmierung zum M0. Aber es gibt noch keinen RP M3 und daher ist das für die ursprüngliche Frage auch irrelevant. Keil (Online) hat auch kein Support Package für den RP2040, ist also viel Fummelei wenn man den da Nutzen möchte. https://community.arm.com/support-forums/f/keil-forum/48725/raspberry-pi-rp2040---is-the-keil-mdk-support-considered
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.
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.