Hallo zusammen, ich nutze nun schon seit ein paar Jahren diverse AVR-Mikrocontroller, vom Attiny13 bis Atmega1284. Zur Programmierung nutze ich Microchip Studio (noch in der Version Atmel Studio 7) und komme damit auch ganz gut zurecht. Bisher habe ich hobbymäßig Dinge gemacht, für die AVRs (und meine Kenntnisse) gut ausreichend waren, z.B. einfache Schrittmotorsteuerungen, einen sehr einfachen RS232-Programmieradapter und so. Nun würde ich gerne mehr in Richtung "drahtlose Vernetzung von Sensoren und Anzeige im Browser" gehen, und ich habe das Gefühl, dass die 8 bit-AVR (bzw. wiederum meine Kenntnisse) dafür nicht wirklich gemacht sind. Klar geht alles irgendwie, aber ich fand es schon umständlich, zwei Attiny45 über 433MHz miteinander sprechen zu lassen. Meine Frage wäre nun: Was würdet Ihr als nächste Mikrocontrollerfamilie empfehlen, in der ich mich mit AVR- und Studio 7- Kenntnissen gut zurechtfinde, und die für solche Vernetzungsgeschichten gut zu gebrauchen ist? Es gibt da einfach sehr viele, und ich kenne mich jenseits meines 8bit-Tellerrandes nicht aus. Bin gespannt auf Eure Vorschläge. Danke und Grüße Nicola
So adhoc wäre wohl der ESP8266 oder der ESP32 eine Idee. 32bit und WLAN und Bluetooth (nur ESP32) an Bord. Fertige Boards sind günstig, das SDK ist sehr gut und die Community ist sehr groß, um viel Hilfe und Dokumentation zu bekommen. (Und komplett in die Arduino IDE mit Wifi-Libraries und allem integriert, aber das ist Teufelszeug :D)
Die nächst höhere Stufe nach AVR ist bei mir die STM32L0 Serie, gefolgt von STM32F3. http://stefanfrings.de/stm32/index.html Von anderen wird der RP2040 offenbar auch gerne verwendet. Für den ESP8266 habe ich viele Infos zusammen getragen: http://stefanfrings.de/esp8266/index.html
Sebastian R. schrieb: > So adhoc wäre wohl der ESP8266 oder der ESP32 eine Idee. 32bit und WLAN > und Bluetooth (nur ESP32) an Bord. > > Fertige Boards sind günstig, das SDK ist sehr gut und die Community ist > sehr groß, um viel Hilfe und Dokumentation zu bekommen. > > (Und komplett in die Arduino IDE mit Wifi-Libraries und allem > integriert, aber das ist Teufelszeug :D) Nicht unbedingt Teufelszeug, aber meine einzigen Berührungspunkte mit Arduino bisher waren das Umschreiben von Code für C bzw. Studio 7. Es wäre mir lieber, wenn ich möglichst viel von dem Wissen, das ich bisher hart durch viele Fehler :) erarbeitet habe, weiterhin nutzen könnte. Ansonsten gefällt mir der ESP32 auch ganz gut...
STM32L0: Das schaue ich mir gerne an, danke!
:
Bearbeitet durch User
Für Wifi / BT würde ich auch den ESP32 empfehlen. Andernfalls die STM32G4xx-Linie, nicht die ultra-low-power Serie wie L0. Gerade für den Anfänger ist es praktisch, dass z.B. eine FPU an Bord ist, und auch die Taktrate hoch genug gewählt werden kann, ohne dass man in Probleme kommt. Der Kostenaspekt ist im Hobby ja auch irrelevant (trinkste einemal nen Bier weniger).
Die Infineon (vormals Cypress) PSoC (vorzugsweise 5LP) sind vielleicht auch ein schöner nächster Schritt. Die Peripherie ist deutlich mächtiger, du bekommst einen Eindruck von Arbeiten mit HAL (hardware abstraction layer), Clock-Verteilung usw. Mit dem grafischen Editor der IDE ist das alles aber noch gut beherrschbar. Allerdings für wireless-Kommunikation kein großer Fortschritt. Die PSoC6-Serie hätte immerhin Bluetooth integriert. Wobei man sich z.B. in DMA einarbeiten könnte (habe ich mit diesem Controller zum ersten Mal richtig verstanden) und dann recht elegant externe Transceiver einbinden kann.
Nicola R. schrieb: > Meine Frage wäre nun: Was würdet Ihr als nächste Mikrocontrollerfamilie > empfehlen, in der ich mich mit AVR- und Studio 7- Kenntnissen gut > zurechtfinde, und die für solche Vernetzungsgeschichten gut zu > gebrauchen ist? Das wird schwierig. Wenn dir die Beibehaltung der IDE am wichtigsten ist, dann wären die Microchip-SAM D vielleicht was für dich. Damit gibt's allerdings keine günstigen Fertigboards mit WiFi, jedenfalls so weit ich weiß. Empfehlen würde ich die SAM D aber sicher nicht, insbesondere dann nicht, wenn das Studio 7 der einzige Grund ist, die Dinger zu wählen. Denn das ist (zwar nicht offiziell aber doch de facto) abgekündigt. Ansonsten würde ich klar RP2040 bevorzugen. Die dafür am besten unterstützte IDE auf Basis von "VisualStudio Code" ist allerdings deutlich anders zu benutzen als das Studio 7, obwohl dies auf VisualStudio basiert und man angesichts der Namensähnlichlichkeit anderes vermuten könnte. Aber nee: is nich, das sind völlig unterschiedliche IDEs. Die Vorteile der RP20240 sind: sehr viel Rechenpower und Resourcen für kleines Geld und es gibt auch günstige Fertigboards mit und ohne WiFi damit. Auch gut unterstützte Programmier- und Debugadapter gibt es für kleines Geld. Von deinen Kenntnissen der AVR8-Hardware wirst du übrigens praktisch nicht profitieren können, egal auf was du umsteigst.
Danke für alle Beiträge bisher. Ja, ich denke mal da muss ich mich von der gewohnten Studio-Umgebung verabschieden. Aber das wird zu verkraften sein, denke ich. Wahrscheinlich wird es ESP32 oder RP2040 werden. Bei den ESP32- Vorgängern scheint die Dokumentation ziemlich schlecht gewesen zu sein, ist das bei den aktuellen Modellen auch noch so? Das VisualStudio Code schaue ich mir gerne ebenfalls näher an. Schade, dass die AVR-Erfahrung für die genannten Mikrocontroller nicht weit trägt. Aber vielleicht hilft sie ja doch ein klein wenig, man kennt wenigstens die Grundbegriffe.
Nicola R. schrieb: > Schade, dass die AVR-Erfahrung für die genannten Mikrocontroller nicht > weit trägt Doch tut sie. Das ist wie beim Autofahren. Wenn du BMW kennst, kommst du auch schnell mit einem Mercedes zurecht. Es gibt Unterschiede aber auch viele Gemeinsamkeiten. Und vieles ist ähnlich. An eine IDE sollte man ohnehin besser nicht binden. Ich habe in 30 Jahren meiner Karriere mit mehr als 10 unterschiedlichen IDE arbeiten müssen - dazu kommen weitere fürs Hobby. Wer nicht mit der Zeit geht, geht mit der Zeit.
Monk schrieb: > Nicola R. schrieb: >> Schade, dass die AVR-Erfahrung für die genannten Mikrocontroller nicht >> weit trägt > > Doch tut sie. Das ist wie beim Autofahren. Naja, klar, eine Timer ist ein Timer, eine UART ist eine UART usw. Aber im Detail sind die Peripherien doch verschieden bis sehr verschieden. Mein Gott, viele alte AVR8ler scheuen sich davor, auf die neueren AVR8-Baureihen umzusteigen. Weil die Peripherie halt doch recht stark abweicht. Beim Umstieg auf eine andere MCU-Architektur (hier also wohl am ehesten ARM) kommt dann noch dazu, dass man auch das meiste vergessen kann, was man, über den Kern und dessen sinnvolle Nutzung wusste. Und dann noch der Schock Multicore beim ESP32 oder RP2040. Das ist wieder eine völlig neue Dimension für einen eingefleichten AVR8ler. @Nicola R: Nein, der Umstieg wird nicht einfach. Darauf solltest du vorbereitet sein. Der Monk Stefan sieht das alles ein wenig zu sehr vom Standpunkt seiner Arduino-Gülle aus. Das wirkt aber allenfalls nur dann dementsprechend, wenn man auch die AVR8 nur mit Arduino-Gülle angefaßt hat. Hast du aber nicht.
Ob S. schrieb: > Der Monk Stefan sieht das alles ein wenig zu sehr vom Standpunkt seiner > Arduino-Gülle aus. Das ist schräg, denn jahrelang wurde ich hier ermahnt, mich nicht dauernd so negativ/ablehnend gegen Arduino zu äußern. Ich bin immer noch kein Arduino Fan. Auf meiner Homepage gibt es nur wenige Artikel, in denen Arduino vorkommt.
Was spricht denn gegen AVR? Die neueren sind doch schon mit UPDI zu programmieren. Und als Peripherie den HC-12 an der UART. Damit habe ich bisher sehr gute Erfahrungen gemacht. Arduino? Nö!
Monk schrieb: > Nicola R. schrieb: >> Schade, dass die AVR-Erfahrung für die genannten Mikrocontroller nicht >> weit trägt > > Doch tut sie. Das ist wie beim Autofahren. Wenn du BMW kennst, kommst du > auch schnell mit einem Mercedes zurecht. Es gibt Unterschiede aber auch > viele Gemeinsamkeiten. Das sehe ich genauso. Natürlich unterscheiden sich die Peripherieeinheiten im Detail und deren Register. Das ist dann die Lernaufgabe. Ob S. schrieb: > Der Monk Stefan sieht das alles ein wenig zu sehr vom Standpunkt seiner > Arduino-Gülle aus Komisch, Stefan hat hier mit keinem Wort Arduino erwähnt. Und weshalb jetzt Monk? Wenn du dich nicht anders artikulieren kannst, solltest du dich vielleicht dort weiterbilden. Ist ja nicht das erste Mal. Nur weil du selber vielleicht Angst vor neuen Registern hast, mach es doch anderen nicht madig, sich mal weiterzubilden. @Nicola: ich würde es auch dem RP2040 (Raspberry Pi Pico) versuchen. Aber nicht mittels Arduinoumgebung oder Micropython. Denn die kapseln die Peripherieeinheiten so gut dass du wenig dazu lernst. Das SDK beim RP2040 ist recht gut, die Dokumentation ist OK, ginge sicher besser. Mit dem erwähnten Visual Studio Code kann man gut arbeiten wenn man es erstmal beherrscht. Ansonsten ginge mit dem SDK auch einfach ein Editor und Build in der Konsole wenn man das denn möchte. Auf die von Stefan erwähnten STM32L0 Serie solltest du auch einen Blick werfen. Beim RP2040 gibt es halt schon eine Dual-Core-CPU und was ich persönlich an den Teilen sehr gut finde sind die PIO-Einheiten. Aber da braucht man etwas Einarbeitung um die zu nutzen. Aber es ist irre was man damit machen kann. Grundsätzlich bedeutet der Umstieg, es gibt viel zu lernen. Egal was du nimmst. Aber sonst bleibst du stehen bei den AVRs. Die sind für viele Dinge ausreichend aber es ist immer gut, sich weiterzubilden. Viel Spaß :)
Nicola R. schrieb: > ich nutze nun schon seit ein paar Jahren diverse AVR-Mikrocontroller, > vom Attiny13 bis Atmega1284. Zur Programmierung nutze ich Microchip > Studio (noch in der Version Atmel Studio 7) und komme damit auch ganz > gut zurecht. Meine Empfehlung wechsel zu Visual Studio Code. So kannst du für viele unterschiedliche MC programmieren (AVR, ESP32, STM32, RP2040 ...)
Hallo zusammen, vielen Dank für die weiteren Anregungen. Ich habe mir tatsächlich mal das Visual Studio Code installiert und arbeitete mich durch ein paar Tutorials zum Thema ESP32. Das ist tatsächlich eine neue Welt, aber es scheint schon machbar. Die erster-Start-Dokumentation von espressiv ist so richtig mies, da fühle ich mich an meine Kontaktaufnahme mit Linux vor 15 Jahren erinnert. Ohne Foren lesen und YouTube kommt man nicht weit. Also ganz normal und wie fast überall! 😁 Für mein Vernetzungsprojekt würde ich den ESP mal hernehmen, dann aber noch weitere Plattformen anschauen. Macht ja auch Spaß noch etwas dazuzulernen.
Für die ESP32 sind hier viele Projekte mit Erklärung: https://randomnerdtutorials.com/projects-esp32/
Nicola R. schrieb: > Nun würde ich gerne mehr in Richtung "drahtlose Vernetzung von Sensoren Da gäbe es auch die STM32WL-Reihe, welche verschiedene Funksysteme direkt im Controller integriert, u.a. auch LoRa womit man eine hohe Reichweite bei geringem Stromverbrauch erzielen kann.
Nicola R. schrieb: > Die erster-Start-Dokumentation von espressiv ist so richtig mies Meine Erfahrung damit waren eigentlich ganz brauchbar. Ich bin hier angefangen: https://docs.espressif.com/projects/esp-idf/en/stable/esp32/index.html Die Frage ist, ob du mit dem Arduino-ESP32 Framework oder deren IDF arbeiten möchtest. Ich habe die IDF genutzt. Das fand ich gut dokumentiert und hat auch gut funktioniert. Beispiele gibt es auch genug.
900ss schrieb: > Komisch, Stefan hat hier mit keinem Wort Arduino erwähnt. In der Historie hat er aber schon eine gewisse Affinität dafür erkennen lassen. Auch wenn er im aktuellen Thread (ein bisschen) das Gegenteil behauptet. > Und weshalb jetzt Monk? Weil er sich selber neuerdings diesen Nick zugelegt hat natürlich. Du checkst rein garnix! Er ist (nach eigener Wahl) jetzt halt Monk. Wenn er das sein will, dann soll es so sein.
Ob S. schrieb: > Weil er sich selber neuerdings diesen Nick zugelegt hat natürlich. Du > checkst rein garnix! Stimmt. Für mich ist das ein Schimpfwort. Da du ständig durch Pöbelei auffällst (siehe jetzt auch die von mir zitierte Antwort von dir), ist mir das entgangen. Geht's dir besser wenn du pöbelst? Oh man..... Edit: sehr gerade Monk ist eine Fernsehserie. Na ja...
:
Bearbeitet durch User
Moin, mich wundert, dass hier VS-Code genannt wird aber nicht PlatformIO dazu gesagt wird. Damit habe ich bisher auf SAMD21 und ESP32C3 entwickelt. Früher habe ich mit STM32 auf AC6 unter Eclipse gespielt. Für STM32 ist ja die Integration von Cube sehr nützlich. Arduino kann man nutzen, aber nicht die IDE. PlatformIO kann ja auch Arduino als Framework und unterstützt je nach Framework und Platform viele Debugger und fast alle MCUs und ohne Ende fertige Boards. Wenn man kein fertiges Bord verwenden will kann man auch Alles selbst definieren. Gruß Dieter
Dieter B. schrieb: > mich wundert, dass hier VS-Code genannt wird aber nicht > PlatformIO dazu gesagt wird Ich habe das bewusst nicht empfohlen. PlattformIO ist aus meiner Sicht eine eierlegende Wollmilchsau, die alle Mikrocontroller und Mikrocontroller-Frameworks vereinen will. Wobei das darunter liegende Arduino bereits das gleiche Ziel verfolgt und Arduino im Fall von ESP32 und STM32 wiederum auf Frameworks beruhen, die alle µC Modelle (des jeweiligen Hersteller) unterstützen. Also eine Wollmilchsau mit einer anderen Wollmilchsau im Bauch, die zwei weitere Wollmilchsäue im Bauch hat. Und das lässt man dann in einer IDE laufen, die ebenfalls eine Wollmilchsau sein will. Diesen Stapel bewirbt man dann auch noch als "lightweight". PlattformIO leidet unter maximal vielen Abhängigkeiten, was einen immensen Pflegeaufwand mit sich bringt. Ich sehe darin eher einen Hype als eine langfristig stabile Zukunft. Kann sein, dass ich mich irre. By the way: Was ist eigentlich aus mbed geworden?
Monk schrieb: > PlattformIO leidet unter maximal vielen Abhängigkeiten, was einen > immensen Pflegeaufwand mit sich bringt Das hast du gut zusammengefasst. Ich bin deiner Meinung.
Ob S. schrieb: > In der Historie hat er aber schon eine gewisse Affinität dafür erkennen > lassen. Auch wenn er im aktuellen Thread (ein bisschen) das Gegenteil > behauptet. Nein! Stefanus ist ein typischer Arduino Basher.
Nicola R. schrieb: > Wahrscheinlich wird es ESP32 Für die ESP32 sprechen die schönen, kleinen Boards. Aber es gibt auch viele unterschiedliche Boards. Dazu hast du halt schon deinen drahtlos dabei und musst nicht noch was dran frickeln. Python ist auch gar nicht übel. Ich habe auch gerade einmal mit den Dingern rum gespielt und muss sagen, da hat sich in den Jahren echt viel getan.
Monk schrieb: > PlattformIO leidet unter maximal vielen Abhängigkeiten, was einen > immensen Pflegeaufwand mit sich bringt. > Kann sein, dass ich mich irre. Ja, das tust Du. Denn es gibt in PlatformIO keine Abhängigkeiten um die man sich "von Hand" kümmern muss. Man installiert sich die PlatformIO Extension in VSCode und alles was ein Projekt zum Bauen braucht wird dann runter geladen und installiert. Auch nicht anders als wie in der Arduino IDE oder STM32CubeIDE, aber schon mal einfacher als in der Arduino IDE. PlatformIO hat ganz bestimmt ein paar Macken die ich kritisch sehe, aber gerade der "Pflegeaufwand" gehört eben nicht dazu, im Gegenteil. PlatformIO ist auch kein "Framework" oder "RTOS", eine zusätzliche Schicht Software unter der dann z.B. Arduino liegt. Das "einzige" was PlatformIO wirklich macht ist diverse Platformen zur Verfügung zu stellen unter einem Dach, mit den Toolchains dazu und den Frameworks und diese Pakete aktuell zu halten. Dieter B. schrieb: > Damit habe ich bisher auf SAMD21 und ESP32C3 entwickelt. Und das ist einer der Klemmer den ich mit PlatformIO habe, es gibt zwar eine Platform "Atmel" SAM, die unterstützt in der aktuellen Version allerdings nur noch "Arduino" und "Zephyr". Früher konnte das auch mal "Mbed" und "Simba", das wurde aber entfernt. Und was ich eigentlich nutzen wollen würde wäre "Cmsis", gibt es aber nicht und ein Pull-Request dazu wurde ignoriert und ist jetzt 2 Versionen zurück. PlatformIO "verkommt" immer mehr zum Ersatz für die Arduino IDE und unterstützt immer weniger andere Frameworks. "Atmel AVR" - "Arduino" "Espressif 32" - "Arduino", "Espidf" "Espressif 8266" - "Arduino", "Esp8266-nonos-sdk", "Esp8266-rtos-sdk" "Infineon XMC" - "Arduino" "Nordic nRF52" - "Arduino", "Mbed", "Zephyr" "Raspberry Pi RP2040" - "Arduino" "Renesas RA" - "Arduino", "Cmsis", "Fsp" "ST STM32" - "Arduino", "Cmsis", "Libopencm3", "Mbed", "Spl", "Stm32cube", "Zephyr" "Teensy" - "Arduino", "Zyphyr" "TI TIVA" - "Arduino", "Energia", "Libopencm3" Das ist nur was ich gerade installiert habe, das wird immer mehr zur Mono-Kultur. Und wenn was nicht geht, dann war es das, gerade noch mal ausprobiert, ESP32-C6 kann man zwar mit "Espidf" benutzen, aber "Arduino" geht nicht. STM32C031 und STM32H503 werden auch immer noch nicht unterstützt, für den STM32C031 hatte ich sogar mal ein Board File erstellt das auch lief, mit dem nächsten Update von "ST STM32" habe ich das aber nicht mehr zum Laufen bekommen. Das man den RP2040 nur mit Arduino benutzen kann finde ich schon krass. Also PlatformIO, tolle Sache, man schreibt in die platformio.ini für welche Platform mit welchem Framework und für welches Board man die Software bauen will und die Pakete dafür werden automatisch runter geladen. Solange man sich nur in dem Rahmen bewegt der unterstützt wird läuft das - das ist aber auch eine ganze Menge.
Rudolph R. schrieb: > PlatformIO "verkommt" immer mehr zum Ersatz für die Arduino IDE Wundert mich nicht, denn die extreme Vielfalt ist halt auch extrem aufwändig zu pflegen - nicht für die Benutzer (da hast du mich missverstanden), sondern für die Entwickler von Platformio. Dazu kommt, dass die Pfleger solcher Systeme irgendwann Geld für ihre Arbeit bekommen wollen, spätestens wenn sie es für ihre eigenen Projekte nicht mehr brauchen.
Rainer W. schrieb: > 900ss schrieb: >> Und weshalb jetzt Monk? > > Jetzt - 2022-08-26? Nein, das hast du falsch recherchiert. Das ist nicht das Datum der Nick-Änderung.
Guten Morgen, nach ein paar Tagen Umstiegs-Büffeln wollte ich eine kurze Rückmeldung geben. Für das aktuelle Projekt habe ich mich für den ESP32 entschieden, da er Bluetooth an Bord hat. Dazu die ESP-IDF. Das größte Problem bisher war, dass ich irgendwie keinen Einstieg in das eigentliche Programmieren gefunden habe. Die bisherige Arbeitsweise mit Bits in Registern setzen und so weiter trägt nicht mehr, und die Beispielcodes habe ich auch nur begrenzt verstanden, da sie einfach nicht kompatibel mit der bisherigen loop-Denkweise sind. Dann bin ich auf eine Tutorial-Reihe von DigiKey gestoßen, in der erst einmal erklärt wird, was ein RTOS überhaupt ist: https://youtu.be/F321087yYy4?feature=shared (Introduction to RTOS Part - What is a Real-Time Operating System (RTOS)?) Das hat mir grundlegend weitergeholfen. Im Tutorial gibt es auch Beispiele und kleine Übungen in der Arduino IDE. Diese versuche ich in ESP-IDF nachzubauen, das klappt ganz gut. Zumindest weiß ich jetzt, nach was ich überhaupt in der Doku suchen muss. Vielleicht nützt diese Information noch jemand Anderem. Danke nochmal für alle Beiträge! Nicola
Nicola R. schrieb: > Vielleicht nützt diese Information noch jemand Anderem. Diese jetzt nicht unbedingt, aber ich will auch nach dem laufenden Projekt mit ESP was machen. Währe schön, wenn du deine, wie man heute so schön sagt, "Milestones" und neue Verzweigungen, aber auch Sackgassen hier posten würdest. Zumindest mich interessiert es. Ich habe einen Bekannten, der findet die Dinger schlecht, aber die Erfahrungen liegen auch zurück bei ihm. Meine ersten Erfahrungen hatte ich damals mit dem ESP8266 gemacht. Schon damals fragte ich mich, warum jeder den irgendwo als WiFi dran dengelt, wo der doch selbst ein paar GPIO hat. Was ich wohl zuerst ausprobieren werde, das ist ESP-NOW. Finde ich spannend.
:
Bearbeitet durch User
Nicola R. schrieb: > Die bisherige Arbeitsweise mit > Bits in Registern setzen und so weiter trägt nicht mehr Das hast du richtig erkannt. Prinzipiell kann man schon noch direkt auf Register zugreifen, aber vom Hersteller ist eher vorgesehen, alles über die Funktionen der IDF bzw. des Arduino Frameworks zu machen. Bei ST geht die HAL Bibliothek in die gleiche Richtung. Wobei ich den Eindruck habe, dass die Nutzung der HAL noch als optional betrachtet wird.
Monk schrieb: > Prinzipiell kann man schon noch direkt auf > Register zugreifen, Kann man beim Computer auch. Nur würde sich kaum einer auf einem I5 erstmal ein Betriebssystem basteln, um dann eine Led blinken zu lassen. Einigen "Göttern" hier wird das gewaltig stinken, dass jetzt fast jeder sich irgendwas zusammen dengeln kann, ohne mit jedem Byte auf dem Mikrocontroller ein Bit getrunken zu haben. Ich finde es klasse, dass das immer einfacher wird. Geht es doch letztlich um die laufende Anwendung auf dem Mikrocontroller. Von außen kann man ja leider nicht sehen, ob das ein ASM-Guru oder ein ich-bastel-mir-ein-Arduino-Sketch-Jünger gemacht hat. Den allen, die das so verteufeln, sei gesagt, baut euch doch erstmal einen Motor für eurer Auto oder baut den wenigstens zusammen und ins Fahrzeug ein, bevor ihr euch erdreistet mit der Karre zu fahren. Einfach ist gut und ich stehe auf einfach. Natürlich ist es manchmal blöd, wenn man da noch etwas ändern will, was so nicht funktioniert. Aber die Libraries haben sich auch alle nicht selbst geschrieben. Dann muss man, wie so oft im Leben, an seinen Aufgaben wachsen.
Was spricht denn dagegen beim AVR zu bleiben und das Wlan Modul über AT Kommandos anzusteuern. Ich hatte mich dem Arm Umstieg so meine Probleme und nutze die inzwischen einfach genauso wie AVR, also mit direkten Registerzugriffen. Die ewig langen Parameter, wo man ständig jeden nachschlagen muss, nervte mich, als möglichst viel zu Fuß zu machen
Paule M. schrieb: > Was spricht denn dagegen beim AVR zu bleiben und das Wlan Modul über AT > Kommandos anzusteuern Das ist so wie einen Formel 1-Boliden mit einem Polo zu ziehen.
Paule M. schrieb: > Was spricht denn dagegen beim AVR zu bleiben und das Wlan Modul über AT > Kommandos anzusteuern. Die AT Kommandos sind mindestens unhandlich. Es spricht nichts dagegen einen Avr oder Arduino als halbintelligente Porterweiterung da dran zu hängen. z.B. über I2C
Ich denke es gibt da sicher viele verschiedene gleichberechtigte Lösungen oder Herangehensweisen. AVR kann man sicher auch machen, aber ich finde es auch ganz spannend, noch etwas Neues dazuzulernen. Für mich ist das auch ein bisschen Investition in die Zukunft, wer weiß was noch für Projekte kommen, und umso größer der Werkzeugkasten, umso besser.
Niklas G. schrieb: > Das ist so wie einen Formel 1-Boliden mit einem Polo zu ziehen. Das stelle ich mir sehr unterhaltsam vor.
Hallo Meine übersichtlichen Erfahrungen als Bastler: Mit AVR Studio habe ich aufgehört als ich das erste mal die Arduino IDE nutzen konnte. Die Menge an Libraries und unterstützten CPU's und mittlerweile die Version 2.3 machen das Arbeiten mit uC doch schon sehr einfach. Ich hatte mal PlatformIO verwendet in MS Studio Code, auch sehr schön, aber nach einem Jahr musste ich den PC neu installieren und dann musste ich wieder 1000 Einstellungen machen, konnte mich nicht mehr erinnern, hatte nichts aufgeschrieben... Also Arduino drauf, Libs aus dem Manager ausgewählt, fertig. Ich nutze seit längerem die 8266 oder ESP32 für die Hausauto, oder MySensors wenn es zB mit einem kleinen Arduino + RFM69 gehen soll. Für den RP2040 steht zB der Raspberry Pico. Lässt sich per Arduino sehr leicht programmieren, sogar für beide Kerne, also Double-Tasking (um nicht Multitasking zu sagen). Idiotensicher würde ich fast sagen Setup() und Setup1(), Loop() und Loop1(), fertig. Miniboards mit dem RP2040 hat Ali für ein 3 -4Eur schon im Sortiment Du kannst auf den RP2040 auch Micropython oder Circuitpython drauf tun und in Python programmieren, wenn du das schon für andere Projekte verwendest, z.B. auf dem Raspberry. Dazu nutze ich dann MS Studio Code, weil es angenehmer ist als zB Thonny. Aktuell warte ich auf den MILK-V. DualCore CPU inkl. Funktionen für Machinelearning. Ein Kern nutzt Linux für die komplizierten Dinge, der zweite nutzt Arduino für die schnellen Sachen. Ich werde damit mein Seismometer erweitern. Videoinfo dazu auf UTube hat der "guy with the swiss accent" hervorragend zusammen getragen. Ich bastele nicht den ganzen Tag und habe auch andere Hobbies. Wenn ich das Thema mal aufgreife, möchte ich nicht jedes mal 1 Woche damit verbringen wieder die Environments aufsetzen zu müssen. Daher bin ich im Grunde mit Arduino und Studio Code ganz zufrieden. Ich erhebe aber auch zum Beispiel nicht den Anspruch, das ich alle Register mit Namen kenne und wissen möchte wie man den Timer per Register richtig setzt. Ich nutze die passenden Libraries und gut ist. Der Erbauer der Library hat sich ja schon die Gedanken dazu gemacht, und viele Wege, wenn nicht alle, führen irgendwie nach Rom :-) *Yes, i am lazy* :-) LG Uwe
Nicola R. schrieb: > Meine Frage wäre nun: Was würdet Ihr als nächste Mikrocontrollerfamilie > empfehlen, in der ich mich mit AVR- und Studio 7- Kenntnissen gut > zurechtfinde, und die für solche Vernetzungsgeschichten gut zu > gebrauchen ist? Na ARM, was denn sonst? Erstmal gibt es hier im Forum viele Fragen dazu, dann kann man die auch in 8 Bit programmieren, recht gute DSP Schnittstelle + NotfallDSP-Self-Lösung, und wenn du etwas RISC-Assembler lernen möchtest, kannst du dir auch den Thread vom Niklas ansehen: https://www.mikrocontroller.net/articles/ARM-ASM-Tutorial Naja und C (oder C++) sind ja auch dafür da, Hardware unabhängig zu sein, nicht? ;) (Bietet sich sowieso an, da aufgrund des RISC-Designs nur ein paar Befehle da sind, was erstmal ja gut ist, aber je größer das Programm, desto schwieriger wird die Differenzierung.) Es ist sicher nicht verkehrt, ein paar gute AVR Bibliotheken zu "übersetzen".
Niklas G. schrieb: > Rbx schrieb: >> dann kann man die auch in 8 Bit programmieren > > Wie ist das gemeint?! So wie es da steht (https://developer.arm.com/documentation/ddi0360/f/programmers-model/instruction-length) Wobei, gut das du fragst. Neuere haben ja schon 64 Bit oder können 128 Bit. Weißt du da welche, die gängig sind? Für Embedded gibt es eine ganze Reihe guter Texte zu diesem und jenem, auch für den Umstieg von AVR auf ARM. (Beispielsweise https://www.embedded.com/basics-of-porting-c-code-to-and-between-arm-cpus-from-8-16-bit-mcus-to-cortex-m0/?nab=0 oder https://www.embeddedrelated.com/showthread/comp.arch.embedded/35843-1.php)
Rbx schrieb: > So wie es da steht Da steht nur was von der Breite der Instruktion selbst. Und ARM11 ist ein uralter ARM-Anwendungsprozessor (2002, Prä-Cortex-Zeit), kaum relevant für moderne Mikrocontroller. Ich denke, du meinst die Möglichkeit, 8bit-Werte zu verarbeiten? Das kann jeder Prozessor/Controller, außer ein paar exotischen DSPs. Auf Cortex-M ist das Verarbeiten von 8bit-Werten tatsächlich teilweise langsamer als das Verarbeiten von 32bit-Werten. Aber die Möglichkeit, 8-Bit Werte verarbeiten zu können, ist eigentlich völlig irrelevant für den Umstieg von 8 auf 32bit-Controller. Jemand, der 8bit-Controller gewöhnt ist, wird wohl kaum verstärkt 8bit-Werte auf dem 32bitter einsetzen. Die benutzt man halt wenn man sie braucht. Rbx schrieb: > Neuere haben ja schon 64 Bit oder können 128 > Bit. Weißt du da welche, die gängig sind? Soweit ich weiß gibt es keine 64bit ARM-Mikrocontroller (ARMv8-M ist 32bit). Die Cortex-M3 (und später) können 64bit-Werte einigermaßen effizient verwalten, aber sind dennoch 32-Bitter. Die ARMv8.1-M Vector Extensions können auf 128bit-Vektoren arbeiten, aber die individuellen Werte sind dennoch max. 32bit groß. Es gibt aber anscheinend bisher keine Controller die ARMv8.1-M implementieren. ARM NEON ist ähnlich strukturiert, ist aber nur auf Anwendungsprozessoren verfügbar (Cortex-A). Rbx schrieb: > https://www.embeddedrelated.com/showthread/comp.arch.embedded/35843-1.php Die Jazelle ist für Mikrocontroller völlig irrelevant, wird nicht mehr implementiert (seit ARMv7) und war nie sehr populär. Mit 8bit hat das sowieso gar nichts zu tun, denn die JVM ist 32bittig.
:
Bearbeitet durch User
Niklas G. schrieb: > Ich denke, du meinst die Möglichkeit, 8bit-Werte zu verarbeiten? Das > kann jeder Prozessor/Controller, außer ein paar exotischen DSPs. Nein, das ist leider nicht wirklich so. Naja, kommt halt darauf an, wie man "verarbeiten" und "DSP" genau definiert. Ich denke bei meinem Einwurf konkret an die TMS320xyz. Die sind erstens nicht wirklich exotisch, zweitens nur schwer scharf getrennt entweder als µC oder als DSP einzusortieren, und können drittens nur verdammt umständlich bis garnicht mit Bytes umgehen. Ja, klar, auch meine Meinung ist: ein Produkt, was die Welt nicht wirklich gebraucht hat. Allerdings: Die pure Verbreitung zeigt, dass andere das wohl anders gesehen haben. Und so kam es, dass auch ich mich mit diesen Dingern auseinandersetzen musste...
Rbx schrieb: > Für Embedded gibt es eine ganze Reihe guter Texte zu diesem und jenem, > auch für den Umstieg von AVR auf ARM. Die CPU in einer MCU ist (fast) irrelevant, sofern sie die Leistung erbringen kann (s.a. Taktrate, Wait-States). Interessant bei dem Umstieg ist die interne Peripherie. Und da würde ich darauf achten, dass die MCU eine FPU und eine DSP-Komponente dabei hat. Der Rest, sprich das Handling der internen Peripherie, ist dann das eigentliche Neuland. Der Application-Code ist kein Problem.
Ob S. schrieb: > zweitens nur schwer scharf getrennt entweder > als µC oder als DSP einzusortieren General-Purpose-Mikrocontroller sind das definitiv nicht. Wer als von 8bittern auf leistungsfähigere allgemeine Controller umsteigen möchte, wird kaum bei TMS320 landen, außer er braucht eben ganz spezifisch so einen DSP. Wilhelm M. schrieb: > Die CPU in einer MCU ist (fast) irrelevant Signifikanter Unterschied zwischen 8- und 32bittern ist der Adressraum. Bei 32bittern braucht man solche Konstrukte wie PROGMEM oder Bank-Switching nicht, was das Programmieren schon stark vereinfacht. Das alleine wär schon für mich ein Grund, keine 8-Bitter zu nutzen. Das Interrupt-Handling und Debug-Möglichkeiten sind auch ziemlich wichtig. Wilhelm M. schrieb: > Und da würde ich > darauf achten, dass die MCU eine FPU und eine DSP-Komponente dabei hat. Kommt auch stark auf die Anwendung an.
Niklas G. schrieb: > Signifikanter Unterschied zwischen 8- und 32bittern ist der Adressraum. Sorry, für die schlechte Ausdrucksweise: ich meinte zwischen den verschiedenen "größeren", also ARM, etc. Niklas G. schrieb: > Bei 32bittern braucht man solche Konstrukte wie PROGMEM oder > Bank-Switching nicht, was das Programmieren schon stark vereinfacht. Das > alleine wär schon für mich ein Grund, keine 8-Bitter zu nutzen. Das > Interrupt-Handling und Debug-Möglichkeiten sind auch ziemlich wichtig. Richtig. Und die sehr leistungsfähigen Event-Systeme und auch DMA im Gegensatz zu den 8-Bittern. Niklas G. schrieb: > Wilhelm M. schrieb: >> Und da würde ich >> darauf achten, dass die MCU eine FPU und eine DSP-Komponente dabei hat. > > Kommt auch stark auf die Anwendung an. Klaro, aber es ist bei Bastlern ja so, dass man nie weiß, was noch so kommt. Und wenn das bei einer Familie an Bord ist, ist das ein Vorteil, weil man die Familie nicht wechseln muss. Denn m.E. das Aufwändigste beim Kennenlernen einer Familie ist wie gesagt die interne Peripherie.
Niklas G. schrieb: > Signifikanter Unterschied zwischen 8- und 32bittern ist der Adressraum. > Bei 32bittern braucht man solche Konstrukte wie PROGMEM oder > Bank-Switching nicht, was das Programmieren schon stark vereinfacht. Das ist kompletter Unsinn. Das hat mit 8Bit vs. 32Bit rein garnichts zu tun. Eher mit der Architektur Harvard vs. Von Neumann. Und mit dem Kostendruck, der viele 8 Bitter nur mit einem 16(nicht 8!)Bit-Adressbus ausgestattet hat.
Wilhelm M. schrieb: > Und die sehr leistungsfähigen Event-Systeme und auch DMA im Gegensatz zu > den 8-Bittern. Auch noch Bullshit von der C++-Seite. Es gibt auch 8Bit-µC mit leistungsfähigen Eventsystemen (sogar recht viele) und es gibt sogar 8Bit-µC mit DMA (wenn auch nicht ganz so viele).
Ob S. schrieb: > Eher mit der Architektur Harvard vs. Von Neumann. Die meisten ARMs sind genau wie AVR Harvard-Architekturen - sie haben getrennte Busse für Instruktionen und Daten. Der ARM hat aber einen linearen Adressraum. Ob S. schrieb: > Und mit dem > Kostendruck, der viele 8 Bitter nur mit einem 16(nicht 8!)Bit-Adressbus > ausgestattet hat. Welcher 8bitter hat einen 32bit-Adressbus? AVRs nicht. Und dass 32bitter eben 32bit-Adressbusse haben ist eben der große Vorteil.
:
Bearbeitet durch User
Niklas G. schrieb: > Die meisten ARMs sind genau wie AVR Harvard-Architekturen - sie haben > getrennte Busse für Instruktionen und Daten. Der ARM hat aber einen > linearen Adressraum. Es gibt ja auch reichlich 32Bit-µc, die eben nicht ARM sind. Darüber schonmal nachgedacht und deine Aussage entsprechend kritisch betrachtet? > Welcher 8bitter hat einen 32bit-Adressbus? Meines Wissens nach keiner. Aber z.B. 24Bit gibt es definitiv. Gab es zumindest mal. Also auch hier wieder: du hast unzulässig verallgemeinert. Du kennst scheinbar nur AVR8 und ARM. Und setzt das gleich mit 8Bit vs. 32Bit. Und genau das ist eben hahnebüchener Unsinn, der nur zeigt, wie wenig du "herumgekommen" bist, wie klein dein Horizont eigentlich ist.
Ob S. schrieb: > Es gibt ja auch reichlich 32Bit-µc, die eben nicht ARM sind. Darüber > schonmal nachgedacht und deine Aussage entsprechend kritisch betrachtet? Hast du mal drüber nachgedacht? Ob separate Busse vorliegen oder nicht ist für die Programmierung fast egal. Separate Busse machen es halt nur schneller. Der lineare Adressraum hingegen ist absolut relevant. Ob S. schrieb: > Meines Wissens nach keiner. Aber z.B. 24Bit gibt es definitiv. Gab es > zumindest mal. Auch schon etwas knapp bei der Speichermenge moderner Controller. Da sind die 32bitter immer noch im Vorteil (Linearer Adressraum). Ob S. schrieb: > Du kennst scheinbar nur AVR8 und ARM. Um genau die geht's aber im Thread. Ob S. schrieb: > Und genau das ist eben hahnebüchener Unsinn, der nur zeigt, wie > wenig du "herumgekommen" bist, wie klein dein Horizont eigentlich ist. Was ist denn bei dir los? Anonym rumstänkern aber von geistigem Horizont reden?
Ob S. schrieb: > Auch noch Bullshit von der C++-Seite. Fantasierst Du schon? > Es gibt auch 8Bit-µC mit > leistungsfähigen Eventsystemen (sogar recht viele) sind mir wohl bekannt, wobei der TO die aber wohl nicht meinte. > und es gibt sogar > 8Bit-µC mit DMA (wenn auch nicht ganz so viele). aber auch die sind unter den mainstream AVRs nicht zu finden.
Niklas G. schrieb: > Um genau die geht's aber im Thread. Um AVR8 auf der "8Bit-Seite": ja. Aber das Ziel der Migration war offen, nur "32Bit" war gesetzt (warum auch immer). DARUM ging es in dem Thread. Wenn du nicht mal das verstanden hast, kannst du einem nur leid tun.
Ob S. schrieb: > Um AVR8 auf der "8Bit-Seite": ja. Aber das Ziel der Migration war offen, > nur "32Bit" war gesetzt (warum auch immer). Worauf würdest du also migrieren, was einen linearen Adressraum und eine zeitgemäße Menge an Speicher und Peripherieregistern bietet (>= 32 MiB)? Aber was natürlich kein ARM ist und keinen 32bit Adressraum hat?
:
Bearbeitet durch User
Wilhelm M. schrieb: > Fantasierst Du schon? > >> Es gibt auch 8Bit-µC mit >> leistungsfähigen Eventsystemen (sogar recht viele) > > sind mir wohl bekannt Aha, die sind dir wohlbekannt, aber ich fantasiere, wenn ich sage, dass es sie gibt? >> und es gibt sogar >> 8Bit-µC mit DMA (wenn auch nicht ganz so viele). > > aber auch die sind unter den mainstream AVRs nicht zu finden. Aha, also auch das war dir wohlbekannt, hat die aber nicht davon abgehalten, das Gegenteil zu behaupten. Und ich fantasiere, weil ich darauf hinweise, dass es sie gibt? Wenn irgendwer "fantasiert" (oder sogar wieder zugegebenem eigenen besseren Wissen das Gegenteil behauptet, also sogar bewusst LÜGT), dann bist du das und nicht ich!
Niklas G. schrieb: > Worauf würdest du also migrieren, was einen linearen Adressraum und eine > zeitgemäße Menge an Speicher und Peripherieregistern bietet (>= 16 MiB)? > Aber was natürlich kein ARM und keine 32bit hat? Sind das die Anforderungen des TO, oder entspringen sie deiner Fantasie? Müsst ihr euch .......?
Arduino F. schrieb: > Sind das die Anforderungen des TO, oder entspringen sie deiner Fantasie? Das sind ziemlich relevante Anforderungen für eine moderne leistungsfähige uC-Architektur, wenn man entsprechende Upgrade-Möglichkeiten haben möchte. Die ESP32 und STM32 fallen darunter, aber das ist ja nur ein beschränkter Horizont. Es gibt sicherlich eine tolle 25bit-Architektur die das auch kann. Und wenn man dann noch etwas mehr Speicher braucht upgraded man auf eine 26bit Architektur. So kommt man herum ohne langweilige 32bit-Architekturen!
:
Bearbeitet durch User
Arduino F. schrieb: > Niklas G. schrieb: >> Worauf würdest du also migrieren, was einen linearen Adressraum und eine >> zeitgemäße Menge an Speicher und Peripherieregistern bietet (>= 16 MiB)? >> Aber was natürlich kein ARM und keine 32bit hat? > > Sind das die Anforderungen des TO, oder entspringen sie deiner Fantasie? Sie entspringen deiner Fantasie. Die Anforderungen des TO (der übrigens nicht Niklas G. war, sondern Nicola R.) lauteten ganz anders. Wie genau, können selbst Leute wie du ganz einfach feststellen: einfach mal ganz nach oben scrollen...
Wird das hier wieder so ein Weitpinkel-Wettbewerb bei dem sich die meisten die Füße nass machen?
Norbert schrieb: > Wird das hier wieder so ein Weitpinkel-Wettbewerb bei dem sich die > meisten die Füße nass machen? Der Weise sagt: Wer einen kleinen Horizont hat, kann leicht darüber hinaus pinkeln.
Niklas G. schrieb: > Ob S. schrieb: >> Um AVR8 auf der "8Bit-Seite": ja. Aber das Ziel der Migration war offen, >> nur "32Bit" war gesetzt (warum auch immer). > > Worauf würdest du also migrieren, was einen linearen Adressraum und eine > zeitgemäße Menge an Speicher und Peripherieregistern bietet (>= 32 MiB)? > Aber was natürlich kein ARM ist und keinen 32bit Adressraum hat? Das hatte ich viel, viel weiter oben im Thread schon geschrieben: RP2040, also DualCore ARM M0+. Das ändert aber rein garnichts daran, dass deine Behauptungen schlicht falsch sind. Zumindest in der unzulässigen Verallgemeinerung, die du geäußert hast.
Niklas G. schrieb: > ... Also nicht die Anforderungen des TO. Wenn: Nicola R. schrieb: > aber ich fand es schon umständlich, > zwei Attiny45 über 433MHz miteinander sprechen zu lassen. Das schon umständlich für den TO ist, sind dann die meisten größeren µC noch umständlicher. Viel umfangreicher. Ob dein 26Bitter das besser kann?
:
Bearbeitet durch User
Ob S. schrieb: > Das hatte ich viel, viel weiter oben im Thread schon geschrieben: > RP2040, also DualCore ARM M0+. Deine Lesefähigkeiten scheinen auch etwas eingeschränkt zu sein. Es sollte kein 32bitter und kein ARM sein. Ob S. schrieb: > Das ändert aber rein garnichts daran, dass deine Behauptungen schlicht > falsch sind. Welche genau? Dass sich mit linearem Adressraum einfacher arbeiten lässt? Arduino F. schrieb: > Ob dein 26Bitter das besser kann? Frag unseren weitgereisten "observer", dem 32bitter offenbar zu spießig sind.
Niklas G. schrieb: > Welche genau? Dass sich mit linearem Adressraum einfacher arbeiten > lässt? Deine (falsche) Behauptung war, dass es von der "Bittigkeit" des µC abhängt, welchen linearen Adressraum er bereitstellen kann. Ich habe dir sogar einen Tip gegeben: Viele 8Bitter haben einen 16Bit-Adressraum. Und der Witz ist: sie könnten genausogut (weil nach demselben Prinzip umgesetzt) auch einen 24Bit- oder gar 32Bit-Adressraum haben. Nunja, 32Bit gab es real nie (zumindest meines Wissens nach nicht), 24Bit hingegen aber definitiv schon. Und du weißt ja hoffentlich, wie das mit absoluten Behauptungen so ist: ein einziges Beispiel für das Gegenteil widerlegt sie. Lebe damit.
Ob S. schrieb: > Und du weißt ja hoffentlich, wie das mit absoluten Behauptungen so ist: > ein einziges Beispiel für das Gegenteil widerlegt sie. Dann lass uns doch an deiner Weisheit teilhaben und nenne einen 8bit-Controller mit 24bit Adressraum.
Niklas G. schrieb: > Ob S. schrieb: >> Und du weißt ja hoffentlich, wie das mit absoluten Behauptungen so ist: >> ein einziges Beispiel für das Gegenteil widerlegt sie. > > Dann lass uns doch an deiner Weisheit teilhaben und nenne einen > 8bit-Controller mit 24bit Adressraum. Nö, die Recherche überlasse ich gerne dir. Du könntest dabei tatsächlich noch einiges lernen, also deinen Horizont massiv erweitern (auch in einiger anderer Hinsicht).
Ob S. schrieb: > Nö, die Recherche überlasse ich gerne dir. Du weißt also auch keinen, womit meine Aussage weiter steht. Dein Horizont ist also offenbar mindestens genau so klein, aber dafür mit Hass gefüllt. q.e.d.
:
Bearbeitet durch User
Niklas G. schrieb: > Du weißt also auch keinen Doch, weiß ich. Hab ich sogar selber schon mit gearbeitet. > womit meine Aussage weiter steht. Nö. Aber ich gebe dir mal noch ein, zwei Tage Zeit, um es selbst herauszufinden. Dann löse ich das "Rätsel" auf. Dir ist aber hoffentlich klar, dass du dann endgültig als unwissender Depp dastehst. Ich meine: mangelnde Erfahrung ist niemandes Schuld. Aber mangelnde Kompetenz, auch nur einfachste Sachverhalte zu recherchieren schon. Jedenfalls für alle Großfressen, die ihre aus mangelnder Erfahrung resultierenden Behauptungen als unwiderlegbare Axiome postulieren.
Wilhelm M. schrieb: > Herrlich, dieses Arschlochforum ;-) Zum Glück haben wir ja C++-Arschöcher. Die sind das Sahnehäubchen.
Uwe K. schrieb: > Ich hatte mal PlatformIO verwendet in MS Studio Code, auch sehr schön, > aber nach einem Jahr musste ich den PC neu installieren und dann musste > ich wieder 1000 Einstellungen machen, konnte mich nicht mehr erinnern, > hatte nichts aufgeschrieben... Also Arduino drauf, Libs aus dem Manager > ausgewählt, fertig. Coole Story, nur was für Einstellungen meinst Du bitte? Man installiert Visual Studio Code, installiert da drin dann die PlatformIO IDE Extension und das war es auch schon. Einstellungen sind für ein Projekt in der platformio.ini des Projekts und die gehen ja nicht verloren wenn man PlatformIO neu installiert. Per Rechtsklick einen Ordner in VSCode öffnen, unten in der Leiste auf PlatformIO:Build drücken und es wird alles installiert was man braucht. Inklusive Libraries, denn genau dafür gibt es ja lib_deps. Es kommt mal vor das ein Projekt nach dem Update einer Platform nicht mehr baut, ich hatte zum Beispiel leichte Schwierigkeiten als es ein Update für ESP32 gab mit einem nicht kompatiblen Wechseln von IDF4 auf IDF5. Aber das spezielle Problem hatte sich Espressif ausgedacht. Für sowas kann man dann in der platformio.ini manuell die Version zurück drehen die verwendet wird, etwa so: platform = espressif32@5.3.0
Rudolph R. schrieb: > Coole Story, nur was für Einstellungen meinst Du bitte? > Man installiert Visual Studio Code, installiert da drin dann die > PlatformIO IDE Extension und das war es auch schon. Das sind meine Erfahrungen mit den meisten Plattformen auch. Ob ST, ESP, Atmel...funktioniert eigentlich alles Out of the Box. Klar zieht er beim ersten verwenden die ganzen Abhängigkeiten/Compiler usw. Das aber auch automatisch. Am Anfang war der RP2040 etwas hakelig und man musste manche Dinge anpassen. Keine Ahnung wie das heute ist...
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.