Microcontroller-Programmierung AVR oder Arduino?

[klecksii]

Guten Tag,
mich reizt es schon länger, in die Microcontroller-Programmierung einzusteigen. Nun ist die Frage, Arduino oder AVR? Oder doch was anderes? Was gibt es da an Auswahl?

Da ich noch keine Erfahrung in dem Bereich habe, würde ich mich sehr freuen, wenn mir jemand sagen kann, was die Vorteile/Nachteile sind, und was man mir empfehlen würde. Ich möchte das schon einigermaßen professionell aufziehen, also kein 0-8-15, sondern etwas worauf man in Zukunft auch aufbauen kann. Programmiererfahrung (Grundlagen) sind schon vorhanden, aber µCs habe ich noch nie programmiert!

Ich freue mich schon auf Eure Erfahrungswerte und Tipps. Vielen Dank!

 

[blöderidiot]

Was möchtest Du denn mit dem Mikrocontroller machen? Was willst Du dranhängen? Welches Problem willst Du lösen?

Mit einem Mikrokontroller alleine kannst Du nicht viel anfangen

P.S.: https://www.computerbase.de/forum/forums/einplatinencomputer-raspberry-pi-arduino.205/

 

[kartoffelpü]

Nutzen die meisten Arduinos nicht ebenfalls AVRs?

Vielleicht hilft dir das weiter: https://avrgeeks.com/avr-vs-arduino/

 

[Piktogramm]

Arduino zum anfänglichem Herumspielen und die Grundlagen zu verstehen finde ich i.o.

Von AVR würde ich Abstand nehmen, die 32bit AVRs sind praktisch abgekündigt und die 8bitigen µC haben auch nur noch eine Perspektive, wo man um jeden Bruchteil eines Cents kämpfen muss (also auch bei der Bezahlung der Entwickler).

Imho sinnvoller wäre im zweiten Schritt sich anzusehen, was mit STM Nucleo Boards möglich ist oder mit anderen ARM32 etablierter Anbieter.

 

[HITCHER_I]

Raspberry Pico kann man komfortabel in Python programmieren.
Schau dir mal das Video an:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[blöderidiot]

ESP-32 kann man sowohl mit der Arduino-Umgebung (C/C++) als auch mit Python steuern:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[schrotti12]

Ich hab mit ESP32 angefangen, da dieses System FreeRTOS unterstützt und gleichzeitig auch mit Arduino umgehen kann. Gute Compiler-Suite, Entwicklung mit VS Code, Flashen direkt über USB-Kabel, etc. Zusätzlich bietet ESP32 auch Zwei-Kern-Systeme, sodass OTA Updates implementiert werden können. Technisch finde ich das eine echt tolle Platform, da WiFi und Bluetooth direkt integriert sind.

 

[juwa]

Auf dem Arduino läuft ein ATmega Prozessor von AVR. Der Arduino ist praktisch also ein AVR Prozessor montiert auf einer Platine inklusive fertiger Beschaltung und Flasher.

Die CPU läuft mit 16 Mhz und der verfügbare Speicher für Programme ist 30 KB. Da der Code aber sehr hardwarenah ist, hat man kaum Latenzen. Den Arduino nimmt man für einfache aber hardwarenahen Sachen, wo es auf Timings ankommt, wie z.B. der Ansteuerung von LEDs, Servos und Motoren. Einen AVR-MC nimmt man, wenn man den auf einer selbst entworfenen Platine montieren will.

Der Raspberry PI Pico macht das gleiche wie der Arduino. Nicht zu verwechseln mit dem ohne Pico, der was ganz anderes ist und ein Betriebssystem braucht.

 

[HITCHER_I]

Wobei man den PICO auch in C in der Arduino IDE programmieren kann, und der kostet nur 5€ bei Reichelt.de zB.. Das Zubehör ist viel teurer, wie zB. so ein "Starter-Set" https://www.amazon.de/Freenove-Raspberry-Contained-Compatible-Tutorials/dp/B09H2SV5XB/
Der PICO kann sogar Stereo-Audio MP3 abspielen über die Circuit-Python mp3 Bibliothek und VGA-Ausgabe selbst generieren, sodass jemand schon einen C64- und SNES Emulator damit erstellt hat,
außerdem kann man den von 125 auf 250 MHz übertakten.

 

[forstman94]

Wie viele schon gesagt haben, sind Arduinos AVRs.

Arduino zum anfänglichem Herumspielen und die Grundlagen zu verstehen finde ich i.o.

Von AVR würde ich Abstand nehmen, die 32bit AVRs sind praktisch abgekündigt und die 8bitigen µC haben auch nur noch eine Perspektive, wo man um jeden Bruchteil eines Cents kämpfen muss (also auch bei der Bezahlung der Entwickler).

Imho sinnvoller wäre im zweiten Schritt sich anzusehen, was mit STM Nucleo Boards möglich ist oder mit anderen ARM32 etablierter Anbieter.

Die Aussage ist leider etwas Murks. Schau mal, es gibt Geräte, die batteriebetrieben laufen. Das ist bspw. mein Hobbysteckenpferd. Und diesbezüglich fährt man mit AVRs sehr gut.
Ich habe für mich noch keinen Grund gesehen, wieso ich tatsächlich einen ARM, oder überhaupt etwas mehr als einen ATMega etc. brauchen würde. Selbst viele 3D-Drucker benutzen (noch) 8-Bit AVRs.

Ich würde als Einstieg von Arduinos absehen. Sie können recht wenig, kosten aber dafür recht viel (z.B. hoher Stromverbrauch, langsamer und schlechter ADC, wenig Interrupt-Pins). Den Einstieg allgemein empfinde ich, anders als viele denke ich, schwierig. Im "Makerspace" wird in den Tutorials viel Mist geschrieben, der auch im Nachhinein bei einem hängen bleibt und zu Problemen führt.
Es ist darüber hinaus auch üblich, dich als Nutzer dann an veraltete Bauteile heranzuführen, die extrem überteuert verkauft werden. Als Beispiel für die Mitleser mit Vorkenntnis werden zur Motoransteuerung L298N-Treiber empfohlen, die absolute Grütze sind.

Es ist sehr sinnvoll, sich zu fragen, was man überhaupt erreichen will. AI-Kram ist mit AVRs nicht möglich, ebenso wenig "anspruchsvollere" Sachen. Gleichzeitig reichen AVRs für fast alles aus, wie gesagt, ich selber habe noch keine 32Bit MCU benötigt.

Als Einstieg in AVRs würde ich einen ATTiny der 2-Series empfehlen. Zum Beispiel den ATTiny1627 oder den ATTiny3227. Programmierung geht auch über PlatformIO oder ArduinoIDE und wird hier mit dieser Lib beschrieben:
https://github.com/SpenceKonde/megaTinyCore

Es ist damit auch möglich fast komplett ohne irgendwelche Anpassungen Programme für Arduinos darauf laufen zu lassen.

Ich würde da nach Breadboards dafür Ausschau halten. Die Dinger gibt es auch schon bestückt wie bei Arduinos. So mache ich das in der Designphase und habe mir dafür selber eine entsprechende Platine anfertigen lassen. Bei Bedarf kann ich die auch zum Selbstkostenpreis veräußern.

Als Forum kann ich dir Mikrocontroller.net empfehlen, auch wenn die Umgangsformen da manchmal sehr schlecht sind. Das hat sich zum Glück gebessert mit der Umstellung auf Zwangsregistrierung der Poster. Das Forum ermöglicht dir dann auch später bei Sammelbestellungen bei z.B. Mouser oder Digikey teilzunehmen.

 

[Piktogramm]

Die Aussage ist leider etwas Murks. Schau mal, es gibt Geräte, die batteriebetrieben laufen. Das ist bspw. mein Hobbysteckenpferd. Und diesbezüglich fährt man mit AVRs sehr gut.

Das ist ja der Witz, geht es um Batteriebetrieb sind ARM32 µC von STM im Deepsleep bei >10nA, mit aktiver RTC bei ~200nA und ein Atmega 328p bei 750nA mit RTC und 100nA im Tiefschlaf. Die maximale Leistungsaufnahme liegt bei den 32bit ARM µCs meist höher, aber man kann die Dinger auch auf 20MHz laufen lassen und dann sind sie für die meisten Operationen immer noch um Größenordnungen schneller als 8bit µC. Ganz davon abgesehen, dass es bessere, mehr Schnittstellen für I/O gibt.

Und was man auch nicht vernachlässigen sollte. Die µCs sind so oder so sparsam. Die meisten Designs verpulvern die elektrische Energie wo ganz anders. Eine dauerhaft leuchtende LED, Spannungswandler mit (im Vergleich) hoher Verlustleistung, ...

Ich habe für mich noch keinen Grund gesehen, wieso ich tatsächlich einen ARM, oder überhaupt etwas mehr als einen ATMega etc. brauchen würde. Selbst viele 3D-Drucker benutzen (noch) 8-Bit AVRs.

Kommt drauf an, was der µC alles machen muss. Per Spi von einer SD-Karte Koordinaten auslesen und Schrittmotoren ansteuern geht noch recht gut.
Netzwerkkommunikation, Berechnung von Offsets/Verzerrung, Berechnung von Zwischenschritten bzw. etwas feinfühliger Ansteuerung von Motoren sowie grafische Displays über einen einzelnen 8bit µC kann man aber vergessen.
Wobei es zugegebenermaßen auch Platinchen gibt, wo ein Atmega als zentraler µC herhalten muss, das Netzwerk über einen viel leistungsfähigeren ESPxxx abgehandelt wird und das Display auch nochmal einen eigenen µC hat..

 

[forstman94]

Mmmh, das sind so Pauschalisierungen... Das ist jetzt doof zum Zerpflücken.

Das ist ja der Witz, geht es um Batteriebetrieb sind ARM32 µC von STM im Deepsleep bei >10nA, mit aktiver RTC bei ~200nA und ein Atmega 328p bei 750nA mit RTC und 100nA im Tiefschlaf. Die maximale Leistungsaufnahme liegt bei den 32bit ARM µCs meist höher, aber man kann die Dinger auch auf 20MHz laufen lassen und dann sind sie für die meisten Operationen immer noch um Größenordnungen schneller als 8bit µC.

RTCs benutzt man bei MCUs nicht zur tatsächlichen Zeiterfassung, sondern um einfache Intervalle im Ablauf zu benutzen. Da ist die MCU einfach im Tiefschlaf und wird vom RTC geweckt. Die Verbrauchsnummer finde ich da ausgedacht. Wenn ich einen ATMega328 oder einen ATTiny-2-Series in den Tiefschlaf lege und vom RTC wecken lasse ist dessen Verbrauch bei <=0.1µA entsprechend dem Datenblatt. Betrieb mit dem RTC als Taktgeber ist unsinnig, weil I/Os nicht funktionieren werden, und weil es einfach extremst langsam ist da auch nur kleinste(!) Berechnungen durchzuführen (KHz vs. MHz).
Dann lässt du außer Acht, dass Wachphasen eben fast gar nicht damit ausgefüllt werden, dass Berechnungen ausgeführt werden, sondern, dass ein ADC irgendwelche Messungen vornimmt, oder das über eine Schnittstelle Daten übertragen werden. Da nützt mir der angebliche Geschwindigkeitsvorteil eines ARM nichts.

Ganz davon abgesehen, dass es bessere, mehr Schnittstellen für I/O gibt.

Öh, das ist auch wieder so pauschal. Ich habe den Eindruck, du hast da den ATMega328 vor dir, wenn du einen Vergleichs-AVR hinzuziehst.

Und was man auch nicht vernachlässigen sollte. Die µCs sind so oder so sparsam.

Das stimmt wie gesagt nicht. Ich erstelle hauptsächlich Geräte, die über Batterien laufen (2xAAA oder eine Knopfzelle). Der Unterschied war hier mindestens bei Faktor 3, weshalb ich auf AVRs gegangen bin. Ob ich bei meinem Gerät einmal im Jahr oder einmal in 3 Jahren (auch gerne ein kleineres oder größeres Beispielinterval) die Batterien wechseln muss, ist nicht egal.

Die meisten Designs verpulvern die elektrische Energie wo ganz anders. Eine dauerhaft leuchtende LED, Spannungswandler mit (im Vergleich) hoher Verlustleistung, ...

Nochmals, hier geht es um batteriebetriebene Geräte. Da gibt es keinen Spannungswandler, die Geräte laufen einfach mit der Batteriespannung. LEDs leuchten auch nicht dauerhaft. Entweder es gibt sie nicht, oder sie werden ganz ganz kurz aufgeblinkt.

Netzwerkkommunikation

Dafür nimmt man keinen AVR. Und meistens auch keinen ARM. Das regelt ein externer Chip. Bei batteriebetriebenen Geräten wird das eh über Funk gemacht. Da ist es sinnvoller eine entsprechende Platine mit Antenne gleich so zu bestellen und darauf zu montieren.

Berechnung von Zwischenschritten bzw. etwas feinfühliger Ansteuerung von Motoren

Dafür nimmt man Motortreiber.

grafische Displays über einen einzelnen 8bit µC kann man aber vergessen

Natürlich geht das? FullHD H264 Videos mit 24 Vollbildern pro Sekunde geht aber nicht.
Wie gesagt, viel Pauschalisierung, viel falsches Design, weil du annimmst, mit der MCU alles machen zu müssen, obwohl es besser und günstiger ist externe ICs dafür zu nehmen, dann mehrmals vom Batteriebetrieb abgesehen, anstatt beim Thema zu bleiben.

Ganz marktwirtschaftlich gesagt als anderer, kürzerer Ansatz, damit auch Nichtfachkundige das nachvollziehen können. Wenn deine Behauptungen korrekt wären, dann würde in jedem Gerät ein ARM stecken. Außensensoren, kleine Spielzeuge, Beleuchtungen, Gadgets, Flaschenöffner, die bei Benutzung die Musik meines Vereines spielen. Microchip würde keine neuen AVRs mehr entwickeln, sondern den Produktionszweig komplett stilllegen. Oft genug finden sich in Fernbedienungen auch noch einfache Schieberegister. Die müssten ja auch schon seit Jahrzehnten ausnahmslos durch AVRs ersetzt worden sein.

Wobei es zugegebenermaßen auch Platinchen gibt, wo ein Atmega als zentraler µC herhalten muss, das Netzwerk über einen viel leistungsfähigeren ESPxxx abgehandelt wird und das Display auch nochmal einen eigenen µC hat..

Das kannst du dir mit Kapselung bei OOP vergleichen. Ich muss mich nicht mit SDKs und Eigenheiten und Interna diverser Komponenten und Protokolle beschäftigen, sondern ich habe ein externes Modul, was die ganze Arbeit für mich übernimmt, und was ich ansprechen kann.
Ich kann natürlich einen AVR ohne LCD-Treiber nehmen und damit trotzdem einen LCD direkt ansprechen. Oder ich nehme einen AVR mit LCD-Treiber, oder einen externen von bspw. NXP und freue mich an der Kostenersparnis, Entwicklungsersparnis dem geringeren Stromverbrauch, und massig Zusatzfunktionen, die ich bekomme, und ohne Aufwand in mein Produkt integrieren kann.

 

[HITCHER_I]

Netzwerkkommunikation könnte man auch über eine serielle Schnittstelle realisieren, über kurze Distanz.
Der Rasperry Pico hat 2 Spannungswandler, die CPU-Kerne laufen nur mit 1.1 V.
Das ist aber alles nebensächlich, wichtig ist ein günstiger Preis, und gute Dokumentation und große Verbreitung, und somit beste Unterstützung.

 

[LochinSocke]

Speicher für Programme ist 30 KB.

Der originale Uno (R3) nutzt Optiboot und hat 31,5kb frei.

 

[Piktogramm]

@forstman94
Natürlich ist es Pauschalisierung. Ohne konkrete Rahmenbedingungen kann es keine konkreten Aussagen geben. Da der TE recht pauschal gefragt hat, bleibe ich bei pauschalen Aussagen.

Auch dein Rumgereite vonwegen, dass es um batteriebetriebene Anwendungen ginge. Das ist wirklich nur dein Punkt, der TE fragt dazu nichts konkretes von der Anwendung die du damit irgendwann mal realisiert hast. Und wenn du die Werte zum Stromverbrauch anzweifelst, die sind aus dem Datenblatt vom 328p und STMs STM32L412xx Familie (ok die Werte vorher waren von einem kleinem ARM M0 µC und nicht vom M4 "Dickschiff", das zieht etwas mehr, aber immer noch deutlich weniger als die meisten AVR µCs).
Und die Atmega µC werden auch nur bedingt weiterentwickelt. Die ISA ist statisch, die AVR 16bit und 32bit sind beerdigt und die 8bit-Linie wurde konsolidiert.

Ganz marktwirtschaftlich gesagt als anderer, kürzerer Ansatz, damit auch Nichtfachkundige das nachvollziehen können. Wenn deine Behauptungen korrekt wären, dann würde in jedem Gerät ein ARM stecken. Außensensoren, kleine Spielzeuge, Beleuchtungen, Gadgets, Flaschenöffner, die bei Benutzung die Musik meines Vereines spielen. Microchip würde keine neuen AVRs mehr entwickeln, sondern den Produktionszweig komplett stilllegen. Oft genug finden sich in Fernbedienungen auch noch einfache Schieberegister. Die müssten ja auch schon seit Jahrzehnten ausnahmslos durch AVRs ersetzt worden sein.

Als europäischer Entwickler ist es nicht sinnvoll Aufwand in eigene Fortbildung zu investieren für Produktkatogorien, wo um jeden Brauchteil eines Cents gekämpft wird. Zudem gerade in dem Segment Atmega bzw. die Firma Microchip mit ihren Mondpreisen für Uralttechnik veschwinden wird. Im asiatischem Raum gibt es mittlerweile 0,10€ RISC-V µCs..

Das kannst du dir mit Kapselung bei OOP vergleichen. Ich muss mich nicht mit SDKs und Eigenheiten und Interna diverser Komponenten und Protokolle beschäftigen, sondern ich habe ein externes Modul, was die ganze Arbeit für mich übernimmt, und was ich ansprechen kann.

Kommt sehr auf den Fall an. Man kann zB für Lora fertige Module nehmen, die aus Modem für PHY und einem STM32 µC für alle höheren Protokollschichten inkl. Crypto dient um dann via SPI oder I²C mit diesem Modul zu sprechen. Oder man kauft einfach direkt einen STM32, nutzt die Softwarebibliotheken von STM für das Lora Protokoll und kapselt gemäß dem Gedanken hinter OOP auf Softwareebene. Der Unterschied ist der Energiebedarf des zusätzlichen µC und der BOM für eben jenen gesparten µC samt Peripherie. Analog gilt das ganze für Zigbee (da wirft man dann eher Geld in Richtung Microchip statt STM).
Und es ist fast überall so, an den Stellen wo ein Atmega zu klein/schwach ist um eine Aufgabe zu erfüllen, ist es wirklich nur selten sinnvoll beim Atmega zu bleiben anstatt das eigene Design zu konsolidieren und einen moderneren µC zu nutzen.

Und sind wir realistisch muss sich Niemand um den Energiebedarf von µCs oder BOM Gedanken machen als Anfänger. Es geht erstmal um Grundlagen, da kann man Arduino Uno R3 nutzen (oder die billigen Nachbauten) und erstmal Grundlagen lernen und danach weitersehen.

 

[forstman94]

Auch dein Rumgereite vonwegen, dass es um batteriebetriebene Anwendungen ginge. Das ist wirklich nur dein Punkt

Worauf du in den folgenden von mir zitierten Aussagen eingehst. Du fängst doch auch an mit...

Das ist ja der Witz, geht es um Batteriebetrieb

Und wenn du die Werte zum Stromverbrauch anzweifelst

Ich zweifel die nicht an. Ich erkläre dir, wieso du das Datenblatt falsch gelesen hast.

Und die Atmega µC werden auch nur bedingt weiterentwickelt. Die ISA ist statisch, die AVR 16bit und 32bit sind beerdigt und die 8bit-Linie wurde konsolidiert.

Wen interessiert das? Kann ich mir die neuen Instruktionen dann auf dem ARM runterladen? Was bringt das dem TE? Was bringt das bei meinem Anwendungsfall?

Als europäischer Entwickler ist es nicht sinnvoll Aufwand in eigene Fortbildung zu investieren für Produktkatogorien, wo um jeden Brauchteil eines Cents gekämpft wird.

Stimmt, deswegen werden auch nirgendwo Abstriche im Cent-Bereich gemacht. Nie...
Aber auch wieder völlig abseits von meiner Aussage, was du da schreibst. Die Idee ist ja man bleibt bei Komponenten, die man kennt, und bedienen kann. Das konkrete Beispiel war jetzt, nutze ich einen Motortreiber, oder steuere ich den Motor mit Mosfets selber an. Beispiel zwei war, nutze ich den integrierten LCD-Treiber der MCU oder mache einen eigenen, oder nutze ich einen vorhandenen externen IC dafür.
Dazu schreibe ich nämlich:

Ich kann natürlich einen AVR ohne LCD-Treiber nehmen und damit trotzdem einen LCD direkt ansprechen. Oder ich nehme einen AVR mit LCD-Treiber, oder einen externen von bspw. NXP und freue mich an der Kostenersparnis, Entwicklungsersparnis dem geringeren Stromverbrauch, und massig Zusatzfunktionen, die ich bekomme, und ohne Aufwand in mein Produkt integrieren kann.

Und du liest da nur "Kostenersparnis" und haust fleißig in die Tasten. Das ist doch unfair(?)

Kommt sehr auf den Fall an. Man kann zB für Lora fertige Module nehmen, die aus Modem für PHY und einem STM32 µC für alle höheren Protokollschichten inkl. Crypto dient um dann via SPI oder I²C mit diesem Modul zu sprechen. Oder man kauft einfach direkt einen STM32, nutzt die Softwarebibliotheken von STM für das Lora Protokoll und kapselt gemäß dem Gedanken hinter OOP auf Softwareebene. Der Unterschied ist der Energiebedarf des zusätzlichen µC und der BOM für eben jenen gesparten µC samt Peripherie. Analog gilt das ganze für Zigbee (da wirft man dann eher Geld in Richtung Microchip statt STM).

Jo. Im ersten Falle, wie gesagt, eine externe Lösung, wie ich sie vorschlug. Im zweiten Falle brauchst du aber auch zusätzliche Komponenten...
In deinem Beispiel, es lohnt sich grundsätzlich nicht RF-Baugruppen selber zu erstellen. Da kann man viel falsch machen. Nicht umsonst ist auf Produkten die ganze Baugruppe als Platine aufgelötet, entweder mit im PCB integrierter Antenne, oder mit Anschluss. Das sagte ich aber auch bereits:

Da ist es sinnvoller eine entsprechende Platine mit Antenne gleich so zu bestellen und darauf zu montieren.

Und sind wir realistisch muss sich Niemand um den Energiebedarf von µCs oder BOM Gedanken machen als Anfänger. Es geht erstmal um Grundlagen, da kann man Arduino Uno R3 nutzen (oder die billigen Nachbauten) und erstmal Grundlagen lernen und danach weitersehen.

Es muss sich auch (im Sinne von tatsächlich) niemand Gedanken um die "Weiterentwicklung" von AVRs machen...
Die Idee war, dass die Arduinos aus mehreren Gründen unterlegene MCUs verwenden, einer davon war der Stromverbrauch. Ich zitiere mich nochmals selbst:

(z.B. hoher Stromverbrauch, langsamer und schlechter ADC, wenig Interrupt-Pins)

Auch hier pickst du dir den Stromverbrauch raus, und liest dann nicht mehr weiter. Was soll das? Im Prinzip reißt du meine Aussagen aus dem Kontext in einem Maße, dass du mir Wörter in den Mund legst.

Und ganz realistisch betrachtet: Ich war Anfänger, und musste mir sofort Gedanken um den Energiebedarf meines Projektes machen. Und beim nächsten auch. Und beim nächsten. Nur mal so nebenbei. Ich habe mein erstes Projekt angefangen mit einem Nano und einer 9V Blockbatterie. Das Gerät konnte nur 2 Wochen laufen. Das fertige Projekt läuft mit einer 2032 ein Jahr lang.

So, um es nochmal zusammenzufassen, in der wahrscheinlich vergeblichen Hoffnung, dass meine Aussagen nicht aus dem Kontext gerissen, neu interpretiert, und mit falsch angewandtem oder mangelndem Wissen kommentiert werden:

Ich empfehle dem TE immernoch einfach AVRs zu verwenden. Ich empfehle aber, aus mehreren, verschiedenen Gründen, nicht Arduinos zu verwenden, sondern andere bereits bestückte Boards mit anderen MCUs, beispielsweise der ATTiny-2-Series. Hier nochmal die Lib mit vielen Zusatzinfos: https://github.com/SpenceKonde/megaTinyCore
Dazu noch einige Dinge, die es zu beachten gibt:

Den Einstieg allgemein empfinde ich, anders als viele denke ich, schwierig. Im "Makerspace" wird in den Tutorials viel Mist geschrieben, der auch im Nachhinein bei einem hängen bleibt und zu Problemen führt.
Es ist darüber hinaus auch üblich, dich als Nutzer dann an veraltete Bauteile heranzuführen, die extrem überteuert verkauft werden. Als Beispiel für die Mitleser mit Vorkenntnis werden zur Motoransteuerung L298N-Treiber empfohlen, die absolute Grütze sind.

Falls das in dem Geblubber auch noch untergegangen sein sollte, wiederhole ich nochmal mein Angebot die Breadboard-Platinen mit ATTiny3227 und 1627s, die ich für mich erstellt, geordert, und bestückt habe, zum Selbstkostenpreis an den TE abzugeben.

Vielen Dank und einen schönen Abend.

 

[TomH22]

Als Forum kann ich dir Mikrocontroller.net empfehlen, auch wenn die Umgangsformen da manchmal sehr schlecht sind. Das hat sich zum Glück gebessert mit der Umstellung auf Zwangsregistrierung der Poster.

Wenn ich mir die Diskussion hier zwischen Dir und @Piktogramm ansehe, dann weiß ich warum Du Dich bei Mikrocontroller.net wohlfühlst

 

[juwa]

Es geht erstmal um Grundlagen, da kann man Arduino Uno R3 nutzen (oder die billigen Nachbauten) und erstmal Grundlagen lernen und danach weitersehen.

Genau, der Arduino wurde ja schon vor sehr langer Zeit hier in Italien als Lern-Projekt für Schüler und Studenten entwickelt. Als Einstieg und zum Lernen der Grundlagen auch heute noch keine schlechte Wahl, da es zudem sehr viel Dokumentationen und Literatur dazu gibt.

Natürlich gibt es jetzt ~20 Jahre später bessere und schnellere Teile als den ATMega328, aber um Stückpreise und kommerzielle Projekte ging es hier ja ursprünglich nicht.

 

[forstman94]

Wenn ich mir die Diskussion hier zwischen Dir und @Piktogramm ansehe, dann weiß ich warum Du Dich bei Mikrocontroller.net wohlfühlst

Ja, ich bin da abgehärtet. Früher hätte ich sowas ignoriert. Man lernte (mittlerweile ist das da deutlich besser) da aber schnell mit etwas schwierigen Diskussionspartnern klarzukommen.

 

[TomH22]

mich reizt es schon länger, in die Microcontroller-Programmierung einzusteigen. Nun ist die Frage, Arduino oder AVR? Oder doch was anderes? Was gibt es da an Auswahl?

Wenn man wirklich noch völlig unbedarft/unerfahren in diesem Bereich ist, und auch vielleicht noch garnicht so genau weiß, was man damit machen will, ist der „Ur-Arduino“ auf AVR Basis mit der Orginal Arduino IDE nach wie vor kein schlechter Einstieg.

Es funktioniert einfach „Out-of-the-Box“ ohne Probleme, für die ersten Schritte reicht auch der Abstraktions-Layer der Arduino Library. Wenn man etwas tiefer einsteigen und z.B. direkt auf I/O Register Ebene programmieren möchte, sind die AVRs auch noch relativ einfach zu verstehen.

Ja klar, die AVR basierten Arduino Boards haben nicht das beste Preis/Leistungsverhältnis, aber da wir da über eine Investition von 20 EUR reden, ist das erst mal egal.

Natürlich kann man auch andere Plattformen, wie STM32 oder ESP32 mit der Arduino IDE und -Library ansprechen, hier hakt es aber schnell mal im Detail. Wenn man Erfahrung hat, meist kein Ding, aber für die ersten Schritte kann es hinderlich sein.

Wenn man mehr Komfort beim Entwickeln möchte, bietet sich tatsächlich VSCode mit Platform.io an. Damit kann man, auf geeigneten Plattformen, wie STM32 auch debuggen, außerdem hat man eine wesentliche höhere Performance beim Compilieren. Das ist bei den AVRs egal, aber z.B. bei STM32 macht es einen großen Unterschied.

Imho sinnvoller wäre im zweiten Schritt sich anzusehen, was mit STM Nucleo Boards möglich ist oder mit anderen ARM32 etablierter Anbieter.

Auch wenn ich persönlich ein großer Fan von STM32 bin, würde ich schon sagen, das sie nicht so super Einsteiger freundlich sind. Wenn man STM32 richtig ausnutzen will, sollte man aber den STM32Cube Libraries benutzen, das erfordert aber schon etwas mehr Übung. Ich nutze für die Entwicklung die Nucleo Boards von STM auch sehr gerne, für das fertige Projekt kann man dann auf „China-Ware“ umsteigen. Nucleo Boards bekommt bei u.a. bei Conrad oder Reichelt, leider in sehr reduzierter Auswahl.
China STM32 Boards, wie die ganzen „Bluepill“ Nachbauten haben so ihre Tücken. Wenn man STM32 nutzt, sollte man in jedem Fall die paar Euro in einen STLink Nachbau von Amazon oder Ali investieren.

Klingt jetzt schon verwirrend und kompliziert -> dann zurück zu Punkt 1 - > Orginal Arduino

Der Raspberry PI Pico macht das gleiche wie der Arduino.

Raspberry PI hat, genau wie die Original Arduinos, den Vorteil, das es „offizielle“ Boards der Raspberry Foundation gibt. Und die sind noch nicht mal teuer, Auch die Dokumentation auf der Raspberry Website ist sehr gut. Wenn man WLAN möchte, ist der Pico W für mich der ESP32 Killer.

Das Original C SDK für den Pico ist anspruchsvoller als Arduino und läuft auch nur unter Linux (was dank WSL auch für Windows Nutzer heute kein wirkliches Problem mehr ist).

Aber mittlerweile kann man den Pico ja auch mit der Arduino IDE programmieren - habe ich aber noch nicht ausprobiert.

Die große Stärke des Pico ist die gute MicroPython Implementierung, sie unterstütz auch den Pico W.

MicroPython ist zwar nicht mehr “traditionelle“ Microcontroller Entwicklung, aber für viele Dinge ausreichend schnell auf dem Pico und man ist sehr produktiv.

Insofern wäre der Pico (W) mit Micropython für mich der zweite „blutige Anfänger“ Tipp.

Ich möchte das schon einigermaßen professionell aufziehen, also kein 0-8-15, sondern etwas worauf man in Zukunft auch aufbauen kann

Was meinst Du mit „professionell“. Planst Du in diesem Bereich Geld zu verdienen, oder meinst Du nur das Du einen „professionellen“ Qualitätsanspruch hast?