Tag zusammen! Ich versuche mir nach und nach beizubringen, wie man AVR Mikrocontroller in C mit Microchip Studio programmiert. Dafür habe ich mir das passende Buch von Heimo Gaicher gekauft und bis jetzt ungefähr die Hälfte durchgelesen. Bis jetzt kann ich mit den "basics", die im Buch erklärt werden (Bitmanipulation, Datentypen, Register usw) mehr oder weniger gut umgehen. Bevor ich jedoch weiterlese und die etwas "härteren" Sachen, wie Timer, Interrupts usw. angreife, würde ich gerne noch ein par kleine Sachen bzw. Schaltungen aufbauen, um das ganze programmieren zu trainieren. Dabei denke ich an wirklich einfache Sachen, z.B. ein par Schalter oder Sensoren (keine Analogen) als Eingang, ein par LEDs oder Relais als Ausgang schalten usw.. Etwas, was schnell auf dem Breadboard aufbaubar ist, oder vielleicht irgendwas, wofür die Platine schnell zusammengeklebt ist. Nun meine Frage: Welche einfachen Projekte könnt Ihr empfehlen, um das reine programmieren auf einem einfachen Level zu üben? Was hat Ihr gebaut, als Ihr gelernt habt zu programmieren? Über ein par Tipps oder Empfehlungen würde ich mich freuen. Ich benutze übrigens einen Arduino nano, den ich mit eine AVR ISP MKII über den ICSP- Pins programmiere.
:
Bearbeitet durch Moderator
Bau eine Uhr, evtl. mit DCF77 oder irgendwelche LED-Spielereien mit sinnvollem Code, beispielsweise ein Lauflicht, welches die Sequenz in einer Schleife "berechnet" und nicht nur aus einer Tabelle liest oder was auch immer. Ansonsten sind diese Controller so vielseitig, Du musst selbst wissen, was Dich interessiert. Es gibt nicht viele einfache Dinge, wofür sich die Dinger nicht einsetzen lassen würden.
Ein ws2812 LED streifen? Vielseitig, nett, geil. Wie laila. Warum das "Microchip Studio" und nicht arduino wie das alle anderen machen?
Mach erster noch mindestens Timer. Jede Applikation hat mindestens einen Timern im Einsatz. Lauflicht --> Timer Eingänge (entprellt) --> Timer Patterngenerator --> Timer Zähler auf LED ausgeben --> Timer LCD --> Timer Statemachine oder ähnliche abstrakte Dinge die nicht auf Hardware basieren kannst du auch an einem PC trainieren. Da hast du einen Debugger und kannst Schritt für Schritt durchsteppen.
Grob gesagt, weil ich die Dinger "richtig" programmieren will. Arduino feiern viele, ist ja auch okay aber ich finde das ist ein Kinderspielzeug. Platinen mit µCern, die gezielt für ihre Aufgaben gebaut wurden, finde ich viel hochwertiger, professioneller und vor allem schöner als irgendein Stack aus nem Arduino und irgendwelchen shields und Leitungen zwischen einzelnen Modulen... Und mit Anbetracht dessen, dass ich evtl. nach der Ausbildung noch studieren will, ist es bestimmt nicht schlecht schon mal Vorkenntnisse mitzubringen.
The D. schrieb: > einfachen Projekte könnt Ihr empfehlen, um das reine programmieren auf > einem einfachen Level zu üben? Es hängt von der Hardware ab. Eine LED blinken lassen, einen Zaster die LED toggeln lassen, eine 7-Segment Anzeige 4-stellig multiplexen, dabei auf Tastermatrix reagieren und Analogeingang per Poti eine Spannung vorgeben und anzeigen, per PWM die LED entsprechend dimmen, dasselbe mit nacktem 3 1/2 stelligen LCD Glas und alphanumerischem LCD. Solche Hardware war z.B. das Pollin AVR Eval Board mit drangestrickter Anzeige. Dann sollte man Kommunikation üben: RS232, RS485, USB, sprechen mit Infrarotfernbedienungen und Funkthermometern, einlesen von DCF77 oder digitalen Temperatursensoren. Mit dem Grundstock kann man eine Menge machen: uC als Tastenaggregat, uC als Uhr mit Wecker hier wollte jemand 8-kanalige 12V Zeitschaltuhr, als (Rampen)Temperaturregler, RGB Dimmer, messen von pH Wert oder Luftfeuchte und Steuerung von Belüftung, uC als Modelleisenbahnfahrtregler oder als Anzeige elektronischer Messschieber.
The D. schrieb: > ich finde das ist ein > Kinderspielzeug. Du verkehrst mit ahnungslosen die dir unsinn einreden. > Platinen mit µCern, die gezielt für ihre Aufgaben > gebaut wurden, finde ich viel hochwertiger, professioneller und vor > allem schöner Das ist nichssagende warme luft. Politikerambitionen? In der praxis kann arduino ide von 328p über stm32 bes esp32 alles. Dafür musst DU 3 neue IDE lernen die du dann später eh nie mehr brauchst. Das beste was du tun kannst ist die arduino IDE zu installieren um damit deinen 328p zu programmieren, zb eine 256-farben 100 LED lichterkette. Oder einen multicopter. Die waren früher alle auf arduino basis.
:
Bearbeitet durch User
Alt G. schrieb: > Das beste was du tun kannst ist die arduino IDE zu installieren um damit > deinen 328p zu programmieren, Habe ich da irgendetwas verpasst? Gibt es in der Arduino IDE inzwischen einen vernünftigen Debugger?
The D. schrieb: > Arduino feiern viele, ist ja auch okay aber ich finde das ist ein > Kinderspielzeug. Nein, Kinderspielzeug ist das nicht, es ist eine schnelle Prototypenplattform. Nicht nur für die Hardware, auch für die Software. Es gibt beispielsweise einen kompletten SDR-Transceiver für Kurzwelle, der als Arduino-Projekt besteht, mit um die 6000 Zeilen Code. Aber man muss die Arduino-IDE nun auch nicht unbedingt mögen, und es spricht nichts dagegen, Arduino-Hardware auch auf andere Weise zu programmieren. (Wobei mir persönlich dieses Visual-Studio-Zeugs auch nicht so gefällt, aber das ist wie immer bei IDEs sehr stark Geschmackssache.) Wenn du aber ernsthafter einsteigen willst, lohnt es sich, irgendwas als Plattform zu nutzen, was du in-circuit debuggen kannst. Prinzipiell geht das auch bei einem ATmega328 mit debugWIRE, aber dann brauchst du externe Debuggerhardware (JTAGICEmkII, Atmel-ICE, irgendwelche neuren Microchip-Teile müssten auch gehen). Da stellt sich natürlich die Frage, ob du lieber nicht stattdessen dann einen neueren AVR (oder auch gleich einen ARM) und so ein Curiosity Nano Board nehmen willst. Je nach Controller hast du dann mehr Platz und den Debugger gleich mit dabei.
Wolfgang schrieb: > Gibt es in der Arduino IDE inzwischen einen vernünftigen Debugger? Debugger sind etwas für phantasielose leute. Wir arduinistas schärfen unseren "sixt sense" für softwareprobleme indem wir alle debugger ausser Serial.println verschmähen.
:
Bearbeitet durch User
> Grob gesagt, weil ich die Dinger "richtig" programmieren will. +1 dafür. Ich programmiere die Dinger in Assembler. Vielleicht nicht das schnellste in der Programmierung, vielleicht schlechter auf andere Prozessoren zu portieren, aber bei einfachen Sachen nicht langsamer als C und in der Ausführung auf dem Prozessor definitiv schneller. Beim PIC kann ich Assembler nicht empfehlen, aber der AVR hat einen guten Befehls- und Registersatz dafür.
Angehängte Dateien:
-
ATmega328P_fuses.png
34 KB
Alt G. schrieb: > Warum das "Microchip Studio" und nicht arduino wie das alle anderen > machen? Microchip Studio, nix Arduino IDE.
Georg M. schrieb: > Microchip Studio Das hiess früher "Atmel studio" und war bis zur version 4 auch brauchbar. Nach version 4 wurde das bulkig, kompliziert und langsam und dann hat Arduino ide das plattgebügelt.
:
Bearbeitet durch User
Ich habe damals zwar mit PIC in Assembler angefangen aber für die Projekte ist es egal. Hier ein paar Dinge die ich so gemacht habe: * Taster einlesen > LED schalten * Lauflicht (Pause nicht mit Timer sondern NOPs/Loops) * Zähler auf einer 7-Segment-Anzeige * Zähler auf 4 gemultiplexten 7-Segment-Anzeigen * Ampel-Schaltung (Ablaufen lassen der Ampelphasen) * Digital-Uhr (HW-Timer, Interrupts) * DCF77-Funkuhr und serielle Ansteuerung der Anzeigen über Schieberegister
Ich habe auch mit Assembler auf dem PIC angefangen, waren einfach die ersten Mikrocontroller, zu denen ich Kontakt hatte. Ich habe so ein Ding irgendwann in der Steuerung eines Notlichts gefunden und dann so ooooch will ich auch. Allerdings hatte sich das für die PICs mit Kenntnis über die Existenz von AVRs ganz schnell erledigt, die PIC in Assembler zu programmieren ist ein Krampf weil sie keinen nennenswerten Registersatz haben und der Befehlssatz ist genau so mies. Hier liegen immer noch welche aus meiner Anfangszeit (PIC16F877), mit denen ich hoch hinaus wollte, die aber noch niemals Strom gesehen haben. Vielleicht noch ein paar Tips für den Anfang. Ruhig mit sehr simplen Sachen anfangen. LED blinken lassen, dabei die CPU ruhig mit vollen 20Mhz laufen lassen und die Zeit mit NOP-Schleifen warten. Da bekommt man ein gutes Gefühl dafür, wie verdammt schnell der kleine Käfer mit seinen so wenig klingenden 20Mhz eigentlich ist und wieviel Rechenzeit man vernichten muss, damit so eine LED sichtbar blinkt. Steuerbarkeit durch Tasten "nachrüsten" wie LED Dauerlicht oder Geschwindigkeit/Tastverhältnis variieren. Dann LED blinken lassen mit den Timer/Counter-Modulen, Interrupts. Davor vielleicht noch Allgemeines zur Programmierung wie was sind Interrupts, was sind Funktionen, was ist ein Stack, wobei ich nicht weiß, ob man sich in C um sowas kümmern muss oder ob C das alleine macht. Wenn möglich immer gleich die Hardware nutzen wenn es um Timer/Counter (auch PWM) und Schnittstellen wie RS232 oder I2C, SPI geht. Nur im Ausnahmefall in Software, aber das bleibt im Vergleich zur Hardware immer 'ne bloatige Krücke. Dabei nicht so Fehler machen, wie bei schneller RS232 auf den internen RC-Oszillator vertrauen. Habe ich probiert, Ergebnis was wie erwartet, es funktioniert nicht. ADC ist auch ein tolles Spielzeug. Bau einen programmierbaren Dämmerungsschalter oder ähnliches damit. Damit ist man eigentlich schon ziemlich weit, der Rest sind dann so Kommunikations-Dinge wie LCD-Display oder das schon angesprochene 7Segment-Multiplexing. Was man aber an anderen Dingen an die Schnittstellen hängt... kann ja alles sein. Da muss man echt wissen, in welche Richtung der TE will.
Angehängte Dateien:
-
Read_EEPROM.png
47 KB
Alt G. schrieb: > Nach version 4 wurde das bulkig, kompliziert und langsam und dann hat > Arduino ide das plattgebügelt. Vielleicht sehe ich schlecht und muss zum Augenarzt, aber bei der Arduino IDE kann ich viele Funktionen einfach nicht finden.
Angehängte Dateien:
In dem Beispiel: 01b9(hex) = 441(dec)
Mir ist auch soo langweilig... Würde so gerne was basteln, hab aber nicht den blassesten Schimmer was. Vielleicht ein Futterhäuschen für unsere fetten Amseln - aber welche IDE (oder Idee) nehme ich da?
Georg M. schrieb: > aber bei der > Arduino IDE kann ich viele Funktionen einfach nicht finden. Das ist ein feature. Unnötiges weglassen. Sachen die man nie braucht weglassen. Anfängertauglich. Warum meinst du hat der ESP8266 / ESP32 den bastelmarkt so schnell erobert? -> Arduino IDE. Warum meinst ist der STM32 weniger beliebt obwohl preis/leistung besser sind als 328p? -> arduino ide. Einem anfänger ein proprietäres kompliziertes IDE aufzuschwatzen weil "hochwertiger, professioneller, schöner" ist verarsche, ist bösartig. Damit machst du die lernkurve für den anfänger zu steil und viele schmeissen deswegen hin. Pfui wer auch immer solche tips gibt!
Du suchst was zum Anfang, eine einfache Hardware und die passende Software dazu. Natürlich mit der passenden Erklärung und genaue Angabe des Ablauf. Leider helfen dir die Handbücherdabei nur bedingt. Habe es selber anhand von kleinen Projekten gelernt und nach und nach immer grösser geworden. Kann die das empfehlen: https://www.makerconnect.de/index.php?resources/ Da findest zu fast jeden Thema was passendes. Wenn es nicht klappt oder du noch mehr Software kannst du gern schreiben. achim
The D. schrieb: > Etwas, was schnell auf dem Breadboard aufbaubar ist Wie wäre es mit einer Lichtschranke? Die könnte man stufenweise ausbauen: 1) Unterbrechung des Lichtstrahls erkennen 2) Fremdlicht messen und heraus rechnen 3) Eine Beleuchtung 1min einschalten, wenn jemand den Flur betritt 4) Die Zeit einstellbar machen 5) Die Anzahl der Personen zählen und seriell ausgeben 6) Die Anzahl auf einer 7-Segment Anzeige ausgeben 7) Die Anzahl auf einem OLED ausgeben 8) Die Zeit über Internet (Web browser) einstellbar machen und dort auch die Anzahl ausgeben
Alt G. schrieb: > Einem anfänger ein proprietäres kompliziertes IDE aufzuschwatzen weil > "hochwertiger, professioneller, schöner" ist verarsche, ist bösartig. > Damit machst du die lernkurve für den anfänger zu steil und viele > schmeissen deswegen hin. Vielleicht wäre es ja auch besser wenn diejenigen, die beim kleinsten Problem oder bei der kleinsten Hürde gleich hinschmeissen, hinschmeissen. Ich jedenfalls kann mich noch an Zeiten erinnern wo es nicht für jeden kleinen trivialen Mist einen Gehgips für Hirnreduzierte gab. Wenn man etwas wollte, dann hat man es gelernt. Was zu der Zeit übrigens vorzüglich ohne Juuuutjube: »Schmink-Tipps und Programmierung von Dummies für Dummies« funktionierte.
Alt G. schrieb: > Sachen die man nie braucht weglassen Nur, dass die Arduino-Schöpfer dir halt diktieren, was "man nie braucht". Klar, wenn man mit einem Bootloader arbeitet, kann man keine Fuses ändern, aber das heißt nicht, dass andere sowas nicht doch mal brauchen können. Arduino ist sicher kein schlechtes System, aber es als das Alleinseligmachende anzupreisen, geht auch komplett an der Realität vorbei.
wenn man etwas komplexere Übungs-Projekte sucht: Es bietet sich an, bestimmte Dinge "revers zu engineeren". Ich denke da an: Fahrrad-Tacho Rollanden-Schaltuhr Da kann man schon mal bei der "Bedienelemente-Nutzung" oder Kalorien-Berechnung (Fahrrad-Tacho), oder bei der automatischen Sonnenaufgangs/Untergangsberechnung (Rolladen-Schaltuhr) etwas ins Grübeln kommen. Im besten Falle "funktioniert" das nachprogrammierte besser als das Original, auch wenns nur simuliert ist auf dem Steckbrett. Wer mag, kann ja dann das Steckbrett auch noch eliminieren, und die notwendige Hardware auch noch aufbauen/nachbauen.
Wolfgang schrieb: > Gibt es in der Arduino IDE inzwischen einen vernünftigen Debugger? Gibt es bei Lego eine FEM Statikberechnung ?
Norbert schrieb: > Vielleicht wäre es ja auch besser wenn diejenigen, die beim kleinsten > Problem oder bei der kleinsten Hürde gleich hinschmeissen, > hinschmeissen. Villeicht sollte ein anfänger der sein blink programm versucht nicht mit fuses konfrontiert werden? Die beschäftigung mit den IDE eigenheiten eines kompliziert-systems lohnt sich für anfänger nicht. Da braucht er 5 min für das blink programm und 2 wochen bis das in der proprietären "supi pro ide" kompilierbar ist und nochmals 2 tage bis er es geflasht hat. Mit arduino läuft das blink in spätestens einer stunde. Warum, trotz vorhanden sein einer kompletten espressif IDE, verwenden 80% der hobbyuser arduino für esp32? Warum, trotz vorhandensein der ganzen eclipse oder visualschrott toolchain, braucht fast niemand bluepills? Das "ich kann es und deshalb muttu es auch lernen" macht keinen sinn. Das ist etwa gleich blöde wie deutsche rechtschreibregeln. Wenn ein anfänger schreibt "viel hochwertiger, professioneller und vor allem schöner als irgendein Stack aus nem Arduino" dann ist der 100% auf dem falschen dampfer.
:
Bearbeitet durch User
Alt G. schrieb: > Warum meinst ist der STM32 weniger beliebt obwohl preis/leistung besser > sind als 328p? -> arduino ide. Ich dachte: Alt G. schrieb: > In der praxis kann arduino ide von 328p über stm32 bis esp32 alles. Du widersprichst dir also im selben thread. Es gab früher übrigens IDE die nicht überladen aber funktional trotzdem besser waren als Arduino, die konnten wenigstens undo, einrücken, suchen&ersetzen. Aber seit dem man nichts mehr selbst entwickelt "zu teuer" sondern Eclipse oder VisualStudio als Grundlage verwendet, sind 'die grossen' IDE unzumutbar, da stimme ich dir zu. AtmelStudio ist dermassen grottenlahm, Renesas Workplace auch, die setzen auf VisualStudio auf und sind trotzdem höchstens 1/4 so performant, warum auch immer, drüberprogrammiert statt entwickelt. Und von dem ganzen Eclipse-Scheiss "die beste Erfindung seit dem Rad" ist planlosigkeit eh der Standard. Von einer vernünftigen Hilfe im System ganz zu schweigen.
Alt G. schrieb: > Warum, trotz vorhandensein der ganzen eclipse oder visualschrott > toolchain, braucht fast niemand bluepills? Schließt du da von dir auf andere? Eclipse, Visual Studio und viele andere IDEs sind sehr beliebt in Kombination mit dem Arduino Framework. Manche benutzen sie nur als besseren Editor, manche benutzen sie mit Arduino Plugins anstelle der Arduino IDE. Die Blue-Pill Boards waren sehr beliebt, solange sie funktionierten. Seit etwa Januar 2020 werden nur noch (schlechte) Fälschungen angeboten, denn die originalen µC sind nicht mehr verfügbar. Ich bin sicher, dass die Boards wieder beliebt werden, wenn man sie wieder mit originalem STM32 kaufen kann.
Jörg W. schrieb: > Wenn du aber ernsthafter einsteigen willst,... Mir klingt das immer nach einem Dieb, der zur Nacht in ein Haus einsteigen und klauen will. Aber der TO fängt wie gar viele an der falschen Stelle an, wenn es etwas ernsthaftes werden soll. Nicht zuerst irgendwelche Teile kaufen und irgendwelche Programme sich installieren und dann fragen, wie man damit zu Potte kommen kann, sondern zu allererst sich in die Dinge einarbeiten, die man zu benutzen gedenkt. Betrifft sowohl die beabsichtigten Teile als auch die in Frage kommenden Programme. Tja, und noch davor ist der Gedanke an irgend ein Projekt, also was man entwerfen und dann bauen will. Bloß sich darin üben, wie man eine LED ein- und ausschaltet oder etwas ähnliches, das ist ein bissel zu wenig. Sowas habe ich jahrelang auf der 'embedded' gesehen: Stände mit Leiterplättchen, immer nach dem Motto "habe Controller, suche Anwendung". Also, soll es wirklich etwas Ernsthaftes werden oder Spielerei bleiben? W.S.
NIMH Ladegerät? Da kann man sich mit einfachen Spannungsabschaltungen bis zu komplexen Ladealgorythmen vorarbeiten und es immer weiter verbessern. Temepraturfühler, Messgenauigkeit, Delta T oder U Abschaltung etc pp Ein Radiowecker..ganz einfach. Dann mit FM Modul, Mit Übertragung der TExtinformationen, mit MP3 Player , DCF77 etc pp. Alles lässt sich immer weiter auf die Spitze treiben und daher tolle Fortschritte machen
ODer meine akteulle Inspiration Beitrag "Spielekonsolen mit AVR" Einen Gameboy etc auf AVR Basic Angefangen, von Snake, zu sokoban etc pp
Alt G. schrieb: > Mit arduino läuft das blink in spätestens einer stunde. Bei einem Mikrocontroller sind seine Peripheriekomponenten das wichtigste. Das ist der Unterschied zwischen einem Mikrocontroller und einem Mikroprozessor. Deswegen gib es so viele unterschiedliche Mikrocontroller. Und wenn man C/C++ sehr gut kennt, heißt das noch lange nicht, dass man einen Mikrocontroller programmieren kann. Und der Sinn von Arduino war, von der Hardware zu befreien: man programmiert nicht den Mikrocontroller, man programmiert Arduino, man liest das Datenblatt in vielen Fällen überhaupt nicht.
Dr. Sommer schrieb: > Was willst du mit dem Steinzteit AVR. Genau das Richtige weil so einfach wie möglich und doch langt es den meisten Hobbyisten für alles und immer. Lass Dich von "Steinzeit" Abqualifizierungen nicht abhalten. Das spricht nämlich tatsächlich für Ausgereiftheit, große Code- InternetHilfe- und Literaturbasis. Ben B. schrieb: > Ich programmiere die Dinger in Assembler. +1 Bevor man mit Hochsprache irgendwo in der Mitte einsteigt wär der Einstieg bei den Basics auch für später hilfreich.
Georg M. schrieb: > Und der Sinn von Arduino war, von der Hardware zu befreien: man > programmiert nicht den Mikrocontroller, man programmiert Arduino, man > liest das Datenblatt in vielen Fällen überhaupt nicht. Der begabte arduino anfänger lernt dann sehr schnell die hardware direkt anzusteuern. Und zwar aus seiner bekannten funktionierenden umgebung heraus. Er ist nicht gezwungen gleich 2 oder 3 komplexe sachen gleichzeitig zu lernen.
Alt G. schrieb: > Das beste was du tun kannst ist die arduino IDE zu installieren um damit > deinen 328p zu programmieren, zb eine 256-farben 100 LED lichterkette. > Oder einen multicopter. Die waren früher alle auf arduino basis. Nein die Arduino-IDE ist gut wenn man mal was schnell zusammenklöppeln will und nicht wirklich in das Thema µC einsteigen will. Das merkt man sehr schnell wenn man mal vom Standard abweicht und Dinge umsetzen will die von der Arduino-Community so nicht vorgesehen sind. Wenn man es richtig lernen will geht man möglichst schnell eigene Wege. Ob das dann eine IDE wie Mikrochip Studio, Eclipse oder was anderes oder ob man es mit einem simplen Editor und einem selbständigen Aufruf von Compiler, Linker etc., also quasi zu Fuß auf der Kommandozeile, macht ist dabei weniger wichtig. Bei letzterem ist die Lernkurve wohl steiler und der Weg steiniger, aber man wird wohl deutlich mehr lernen, weil man sich zum einen mit der Hardware und den Programmierwerkzeugen intensiver auseinandersetzen muß. Eine IDE nimmt einen da vieles ab, ist aber am Ende auch ein bischen wie eine Blackbox. Wenn der TO das ganze beruflich nutzen will, dann wäre es vielleicht sinnvoll herauszufinden mit welchen Werkzeugen vorangig in der Industrie gearbeitet wird.
Zeno schrieb: > Das merkt man > sehr schnell wenn man mal vom Standard abweicht und Dinge umsetzen will > die von der Arduino-Community so nicht vorgesehen sind. Det ist quatsch. Sag mir mal was mit arduino nicht machbar ist ...
Beitrag #7193681 wurde von einem Moderator gelöscht.
Beitrag #7193683 wurde von einem Moderator gelöscht.
Alt G. schrieb: > Det ist quatsch. > Sag mir mal was mit arduino nicht machbar ist ... Wo habe ich geshrieben das es nicht machbar ist?
Alt G. schrieb: > Sag mir mal was mit arduino nicht machbar ist ... Wurde doch schon geschrieben: Fuses ändern. Das ist beim AVR durchaus elementar, sowas zu können. Auch einige ARMs haben sowas, aber beim AVR wurde sehr viel über Fuses gesteuert. Aus IC-Design-Sicht hat eine Fuse den Vorteil, dass sie nur einmal beim Reset eingelesen wird und daher über die gesamte Laufzeit des Logik-Komplexes keine weiteren Änderungen berücksichtigt werden müssen.
Leute: wenn es nur noch um Attribute von Personen geht, ist es höchste Zeit, sich zurückzulehnen und was anderes zu machen.
Georg M. schrieb: > Vielleicht sehe ich schlecht und muss zum Augenarzt, aber bei der > Arduino IDE kann ich viele Funktionen einfach nicht finden. Genauso ist es. Die Arduino-IDE ist für die breite Masse gemacht und daher soll es möglichst einfach und übersichtlich sein. Und da tut sie auch und ja man kann natürlich alles umsetzen wenn man will, aber komfortabel ist halt anders - das merkt man ganz schnell wenn die Projekte größer werden oder man Bibliotheken einsetzen möchte die nicht für Arduino vorgesehen sind.
Jörg W. schrieb: > Leute: wenn es nur noch um Attribute von Personen geht, ist es höchste > Zeit, sich zurückzulehnen und was anderes zu machen. +1
@TO Wie wäre es mit einer eigenen Wetterstation? Für alles was mit Wetter zusammenhängt gibt es alle möglichen Daten zu erfassen. Die dazu erforderlichen Sensoren liefern da von digitalen Daten (einfache "ja/nein-Aussagen", Impulsfolgen (z.B. Windmesser)) bis zu diversen analogen Daten. Die verwendbaren (käuflichen) Sensoren verwenden neben einfachen digatalen/analogen Schnittstellen auch Standadardsysteme wie SPI, I2C, 1-Wire oder auch RS485. Die Daten muß man ja auch irgendwie ausgeben, also braucht es ein Anzeigesystem. Die Daten wird man in aller Regel weiterleiten z.B ein PC-System/RasPI, beispielsweise via RS232 oder Funk, welches die Daten weiter aufbereitet und in eine DB schreibt und/oder auf einer Webseite darstellt. Man kan also mit so einem Projekt sehr viele Baustellen bedienen und üben. Man muß ja auch nicht alles auf einmal machen, man kann da ja auch Schritt für Schritt vorgehen und das das System immer wieder erweitern. Der Phantasie sind dabei keine Grenzen gesetzt. Betrachte es halt als Vorschlag. Ich habe so etwas gemacht. Einen Teil der Sensoren habe ich selbst gefertigt. So etwas macht Spaß, man lernt was und ganz nutzlos ist es auch nicht.
Alt G. schrieb: > Der begabte arduino anfänger lernt dann sehr schnell die hardware direkt > anzusteuern. Und zwar aus seiner bekannten funktionierenden umgebung > heraus. > Er ist nicht gezwungen gleich 2 oder 3 komplexe sachen gleichzeitig zu > lernen. Im Übrigen ist das Microchip Studio für einfachste Einsteiger-Übungen überhaupt nicht komplizierter als Arduino IDE.
Georg M. schrieb: > Im Übrigen ist das Microchip Studio für einfachste Einsteiger-Übungen > überhaupt nicht komplizierter als Arduino IDE. Naja, der Vorteil der Arduino-Welt ist nicht so sehr die IDE selbst, sondern das Framework, mit dem man viele Dinge bereits abstrahiert bekommt. Das ist wie mit der Hardware selbst, man hat schon viel vorbereitet bekommen und kann "gleich loslegen". Für einen schnellen Erfolg und einen Einstieg ist das sicher nicht unsinnig, und man kann, wenn man eh schon ein passendes Board hat, natürlich von da aufbauend dann tiefer in die Materie einsteigen. Vorteilhaft ist ja, dass Arduino einem keine Steine in den Weg legt, direkt auf die MCU-Ressourcen zuzugreifen, so wie man es ohne die Arduino-Umgebung ohnehin machen müsste. Über IDEs und deren Für und Wider kann man sich eh vortrefflich streiten, das führt zu nichts. Schließlich gibt es keine bessere IDE als Emacs, oder war das Vim? Habe ich jetzt vergessen. :-))
Ich habe mir relativ früh einen NiboBee Roboter als Bausatz gekauft. Dessen Sein AVR war bereits mit einem lauffähigen Testprogramm ausgestattet. Ein (zu avrdude kompatibler) ISP Programmieradapter ist auch schon auf dem Board. Die Platine hat viele freie Pins für Erweiterungen. Ich hatte zunächst etwas Bastelspaß und konnte mir danach erstmal die Hardware im Detail anschauen. Danach habe ich mich an die Programmierung gemacht. Mein erster spannender Knackpunkt war, dass das Ding "von alleine" nicht richtig geradeaus fahren konnte. Ich musste einen Regel-Algorithmus implementieren. Jedenfalls fand ich es schon sehr hilfreich, mit der bereits erprobten Hardware zu beginnen, die gut dokumentiert und durchschaubar ist. Den Bausatz kann ich nur empfehlen.
Wenns partout kein Arduino sein soll, kann man sich auch so einen USB-TTL Wandler oder BT-Modul an die UART hängen und sich mit dem PC verbinden. Entweder tuts dann ein Terminalprogramm oder eine eigene GUI macht auch nen schlanken Fuß. Ob man sich dann sein Multimeter, Ozilloskop, Komponententester Frequenzgenerator oder sonstwas lehrbuchartiges zusammensteckt, macht dann eigentlich keinen großen Unterschied mehr.
Danke bis jetzt an alle Antworten. Aber Leute Leute... Ich wollte jetzt keine Debatte machen ob die Arduino IDE oder zB das Michrochip Studio besser ist! Ich wollte einfach nur nach ein par einfachen Ideen, was man damit so machen könnte, fragen... Was ich im ersten Post über den Arduino geschrieben habe, war nur *meine persönliche Meinung*. Ich finde den Arduino einfach nur unattraktiv. Ist so und akzeptiert das bitte. Die Arduino IDE ist ja gezielt so weit vereinfacht, dass jeder durchschnittliche Mensch damit lernt, "auf die schnelle" einen Mikrocontroller zu programmieren. Genau das hab ich nicht vor! Wie bereits geschrieben, ich will die ganze Mikrocontroller- Programmiergeschichte von oben bis unten kennenleren. Klar, alles kann man nie wissen, aber Ihr wisst, worauf ich hinaus will. Außerdem bietet dass "direkte programmieren" bestimmt mehr Vorteile, als die Arduino IDE, wie manche schon gesagt haben, zB die Fuse- Einstellungen. Man lernt die Mikrocontroller einfach genauer kennen und weiß, wie was funktioniert. Und ich möchte es am besten auch so wie damals lernen, das heißt aus Textbooks und nicht alles aus dem Internet "Nachmachen". Aber ganz ehrlich, ich finde soo viele guten Step- By- Step- Tutorials über Mikrocontroller programmieren gibt es bei Youtube auch nicht. Da gibt es zwar ein par gute Playlists, aber als Anfänger finde ich, dass da viel übersprungen wird und alles durcheinander geigt wird. Da ist das Buch von Heimo Gaicher eigentlich gar nicht so schlecht dabei, obwohl ich es in einem anderen Thread von mir als nicht so toll empfunden habe- bis ich einiges verstanden habe. Und nochmal: In Zukunft werde ich vielleicht Mikrocontroller auch mal beruflich programmieren. Wenn ich da mit Arduino ankomme, lachen mich die meisten Ingenieure aus. Zu den Projektideen: Freut mich, da war vieles dabei von Taster abfragen und LED einschalten bis Wetterstation. Aber vieles davon würde ich nicht wirklich als Anfängerprojekt bezeichnen, eine 7- Segmentanzeige zu multiplexen finde ich (zumindest zu diesem Zeitpunkt) noch etwas kompliziert. Ich meinte da viel mehr etwas, um sich einfach die ganzen bitschiebereien, Datentypen, Schleifen usw. an der Tastatur und im Kopf "zu gewöhnen". Aber die harten Projekte, wie ganze Spiele an LCDs will ich erstmal lassen. Geschweige den von dem einen ARM Cortex- Sarkasten... Warum ich übrigens auf die Idee kam, programmieren zu lernen: Ich würde mir gerne eine kleine Lötstation für JBC- Lötspitzen bauen, sprich einfaches DC Netzteil, eine 7Segmentanzeige für die Temperatur, ein Encoder (Für den Anfang tuts ein Poti bestimmt auch) und diese einzustellen, und dann als Interface des ganzen ein Mikrocontroller, der mit einem Mosfet die Heizung schaltet. Ich denke das ist zwar aufwendig, aber für einen Anfänger bestimmt gut machbar. Viel mehr ziele ich jedoch an ein kleines Ausbildungs- Abschlussprojekt, ich würde mir nämlich ein elektropneumatisches Dosiergerät für Flüssigkeiten, alias ei dne meisten "pneumatic solder paste dispencer", den es im Internet für 50€ gibt bauen. Im Prinzip auch ganz einfach, ein µC steuert ein Magnetventil an, auch hier kann über einen encoder die "Anzeit" des Ventils eingestellt werden und mit einer 7seg angezeigt werden. Ganz simpel. Das soll aber ein mehr mechatronisches Projekt werden, da kommt ja auch noch Pneumatik dazu und da ich in einem Betrieb arbeite, der Edelstahl bearbeitet, darf ich mir bestimmt ein sehr schönes Gehäuse dafür bauen. Außerdem kann man mit solchen µControllern alles mögliche machen! Da kann man auch einiges an Bauteilen sparen, wen man es mit Software, anstatt mit fünf 4000er TTLs und etlichen passiven Bauteilen macht. Und bei uns auf der Arbeit liegen jede Woche unter anderem mindestens 10 defekte Thermostate für Heizungen (Meistens immer nur ein Relais defekt) im Container, die ich mitnehmen darf. Da hat man schnell zig mini 12V- Schaltnetzteile, eine ganze Raaco Schublade voll mit ATMega64ern und weiteres, was so auf den Platinen drauf ist...
The D. schrieb: > Und nochmal: In Zukunft werde ich vielleicht Mikrocontroller auch mal > beruflich programmieren. Wenn ich da mit Arduino ankomme, lachen mich > die meisten Ingenieure aus. Nur die, die nicht verstanden haben, dass man damit eine einfach erhältliche Plattform in den Fingern hält. Aber richtig ist: man sollte dafür natürlich mehr können, als nur im Arduino-Framework was zusammen zu tippen. > Freut mich, da war vieles dabei von Taster abfragen und LED einschalten > bis Wetterstation. Aber vieles davon würde ich nicht wirklich als > Anfängerprojekt bezeichnen, eine 7- Segmentanzeige zu multiplexen finde > ich (zumindest zu diesem Zeitpunkt) noch etwas kompliziert. Das ist aber genau die "Bitschieberei", die du dir ja im nächsten Satz wünschst. Außerdem lernt man gleich, einen Timer zu benutzen, das ist wirklich essenziell für MCUs. Du solltest natürlich die Hardware dafür so bauen, dass die 7-Segment-Anzeige nicht durchbrennt, wenn ein Segment dauerhaft an ist. > Aber die harten Projekte, wie ganze Spiele an LCDs will ich erstmal > lassen. Geschweige den von dem einen ARM Cortex- Sarkasten... Cortex-M ist nicht grundlegend schwieriger als AVR. Auch das ist erstmal eine MCU. Allerdings: wenn man mit den Dingern mehr machen will als mit einem AVR, wird man sich zu allererst mit deren Taktsystem auseinander setzen müssen, das wiederum von Hersteller zu Hersteller und von Baureihe zu Baureihe unterschiedlich ist. Auch diese MCUs haben natürlich einen Standard-Takt, mit dem sie starten, aber der ist mehr oder weniger wirklich nur dafür da, dass man überhaupt erstmal ein Programm abarbeiten kann. Das ist aus meiner Sicht der wesentliche Unterschied zum AVR, bei dem du deinen Takt über Fuses und externe Beschaltung vorgibst. > Ich würde mir gerne eine kleine Lötstation für JBC- Lötspitzen bauen, > sprich einfaches DC Netzteil, eine 7Segmentanzeige für die Temperatur, > ein Encoder (Für den Anfang tuts ein Poti bestimmt auch) und diese > einzustellen, und dann als Interface des ganzen ein Mikrocontroller, der > mit einem Mosfet die Heizung schaltet. Ich denke das ist zwar aufwendig, > aber für einen Anfänger bestimmt gut machbar. Das ist aber deutlich mehr als die Wetterstation. ;-) Insbesondere erlauben die JBC-Patronen ja eine relativ hohe kurzzeitige Heizleistung, also musst du auf jeden Fall ein Konzept im Griff haben, das (bspw. via Watchdog) ggf. die Heizung schnell abschaltet, falls sie länger als eine bestimmte Zeit an ist, damit die Patrone nicht zu glühen anfängt … außerdem musst du den ganzen Spaß mit Analogmimik und Messen sehr kleiner Spannungen (vom Thermoelement) beherrschen, inklusive der Methoden, diese Messung so zwischen die Heizperioden zu schachteln, dass sie störungsfrei arbeitet. Aber das nur am Rande. > Außerdem kann man mit solchen µControllern alles mögliche machen! Da > kann man auch einiges an Bauteilen sparen, wen man es mit Software, > anstatt mit fünf 4000er TTLs und etlichen passiven Bauteilen macht. Gar keine Frage. Wir haben hier Nachtlicht und LED-Thermometer als öffentlichkeitstaugliche Bausätze, das LED-Thermometer hat außer den LEDs nur noch einen Controller und den obligatorischen 100-nF-Kondensator, das Nachtlicht hat noch einen LED-Vorwiderstand und einen Kondensator an der Fotodiode. Der Rest ist alles Software. (Btw.: 4000 ist CMOS, nicht TTL. ;-)
:
Bearbeitet durch Moderator
The D. schrieb: > Freut mich, da war vieles dabei von Taster abfragen und LED einschalten > bis Wetterstation. Aber vieles davon würde ich nicht wirklich als > Anfängerprojekt bezeichnen, eine 7- Segmentanzeige zu multiplexen finde > ich (zumindest zu diesem Zeitpunkt) noch etwas kompliziert. Geanau deshalb hatte ich ja die Wetterstation ins Spiel gebracht. Es ist gerade am Anfang wichtig das man ein Erfolgserlebnis hat und auch noch einen kleinen praktischen Nutzen, außer dem Programmieren erlernen, ziehen kann. Man kann ja ganz klein anfangen und das Projekt über die Zeit immer weiter erweitern. Du wirst sehen man findet immer wieder neue Ideen. Ich habe viel mit MSP430 Prozessoren von TI gemacht. Die finde ich persönlich ganz nett. Da gibt es eigentlich für jeden Geschmack etwas. Das ist aber ein Thema wo die Ansichten definitiv auseinander gehen.
Sowas vereinfache ich mir heute auch mit den kleinen Controllern. Doppel-Blinkgeber mit NE555? Blödsinn, ein ATTiny kann das besser und mit weniger Bauteilen (erst recht wenn die 3,3..5V schon da sind), auch wenn sich die CPU hinterher langweilt.
The D. schrieb: > Wenn ich da mit Arduino ankomme, lachen mich die meisten Ingenieure aus. Ehrlicherweise lacht ein gestandener Arduino- Entwickler momentan über Dich!
Jörg W. schrieb: > Das ist aber deutlich mehr als die Wetterstation. ;-) Lach, das hängt natürlich davon was man in eine Eigenbauwetterstationen an Sensorik alles einfließen läßt. Es gibt deutlich mehr Daten als eine Vantage Pro liefert. Siche sind da auch Daten dabei die für das aktuelle Wetter nicht relevant sind, aber die Erfassung und Auswertung ist interessant - zumindest wenn man sich dafür interessiert. Hätte ihm auch einen Hybridzusatz für Analogrechner (quasi ne digitale Schnittstelle zum Analogrechner) vorschlagen können. Die dürfte allerdings für die Mehrheit hier eher uninteressant sein - man bräuchte dazu auch erst mal einen Analogrechner und das ist ja auch schon wiederein eigenes Projekt.
Da sind auch ein paar Anregungen drin, vor allem im Band 3: http://stefanfrings.de/mikrocontroller_buch/index.html Und wenn dir die AVR mal zu klein oder zu langweilig werden, geht es dort mit STM32 weiter: http://stefanfrings.de/mikrocontroller_buch2/index.html Oder du fängst gleich mit STM32 an - wie du willst. AVR sind einfacher. Wo weniger drin ist, kann man weniger falsch machen.
Jörg W. schrieb: > Cortex-M ist nicht grundlegend schwieriger als AVR. ...nur die Kotz-Peripherie, von jedem Hersteller anders asynchron irgendwas wofur es billig IP gab drangestrickt und weitgehend undokumentiert.
Alt G. schrieb: > Der begabte arduino anfänger lernt dann sehr schnell die hardware direkt > anzusteuern. Der ist mir noch nicht begegnet, sondern eher die Leute, die mir sagen "ich programmiere NICHT auf Registerebene". W.S.
Jörg W. schrieb: > Cortex-M ist nicht grundlegend schwieriger als AVR Völlig indiskutabel zum Einstieg. Die beste Garantie daß die Motivation schnellstens flöten geht. ARM kocht zwar auch nur mit Wasser. Allerdings gibts hier erheblich mehr zu konfigurieren, viele Dinge sind für einfache Anwendungen viel zu kompliziert konstruiert. Man braucht nur mal die zugehörigen Handbücher vergleichen.
Jörg W. schrieb: > Das ist aber deutlich mehr als die Wetterstation. Naja, wie man's nimmt. So eine Wetterstation kann materialmäßig wesentlich umfänglicher sein als die Lötstation, aber bei der letzteren muß man zuvor mehr nachdenken, damit einem das Ding nicht durch einen Zufall ausglüht. Das ist bei der Wetterstation anders: wenn die durch besagten Zufall außer Tritt kommt und nur noch Hausnummern anstelle Wetterdaten liefert, dann landen eben unsinnige Werte in der Datei. Weiter nix. W.S.
> Ehrlicherweise lacht ein gestandener Arduino- > Entwickler momentan über Dich! Nicht wirklich. Ich lache selbst als reiner Hobby-AVR-Freak über die ganzen "Entwickler", die ohne Ardummino und irgendwelche Klickibunti-IDEs nicht mal einen einfachen Blinker zustande bekommen würden. Oder irgendwelche Ardummino-Boards (bzw. gilt für alle Eval-Boards) im Manhatten-Style auf kommerziellen Platinen. Sowas zeigt sehr deutlich, daß diese "Entwickler" nicht mal die Grundlagen verstanden haben. Okay, vielleicht muß man das beim Ardummino auch nicht, das wäre ein Argument... aber ob man sich dann Entwickler nennen sollte? Und für den Einstieg ist der AVR wirklich ein sehr gut geeigneter Controller. Eigene Erfahrung. Hier mal zwei Videos, die so die "Grenzen" dieser Controller erreichen. https://www.youtube.com/watch?v=ZpPd0pdQ3dE https://www.youtube.com/watch?v=vPZ5ByIxiFM Und keine Sorge, so gut, daß ich sowas mal schnell nachbauen könnte, bin ich selbst nicht mit den Dingern.
Lust L. schrieb: > Jörg W. schrieb: >> Cortex-M ist nicht grundlegend schwieriger als AVR > > Völlig indiskutabel zum Einstieg. Hau mal nicht so auf den Putz. Immerhin soll in diesem Thread ja mit dem Programmieren in C begonnen werden und nicht in Assembler. Da stimmt das durchaus, was Jörg geschrieben hat. Der wesentliche Unterschied zwischen Cortex-M und AVR besteht darin, daß es beim Cortex zumeist viel mehr an Peripherie gibt als bei AVR. Deshalb ist das Manual dicker. Aber man muß ja nicht alle Peripherie benutzen, die so ein Cortex-M drin hat. Das geht auch rein physisch nicht, weil die meisten Portpins mehrfach belegt sind und man sich eben nur eine Funktion von mehreren aussuchen muß. Eben die, die man für's Projekt braucht. W.S.
Ben B. schrieb: > Hier mal zwei Videos, die so die "Grenzen" dieser Controller erreichen. Ja ganz nett aber die zeigen eben auch was man dann besser mit einem leistungsstärkeren Controller in Angriff nimmt. W.S. schrieb: > Aber man muß ja nicht alle Peripherie benutzen, die so ein Cortex-M drin > hat Schon klar. Man muß nur die richtige finden, auf die richtigen Pins schalten und noch die richtige der gefühlt tausend, je nach Hersteller unterschiedlichen Konfigurationsmodi einstellen... Solche Ratschläge können nur von erfahrenen Entwicklern kommen die von der Situation des Einsteigers Null Ahnung haben.
:
Bearbeitet durch User
Lust L. schrieb: > Man muß nur die richtige finden, auf die richtigen Pins schalten und > noch die richtige der gefühlt tausend, je nach Hersteller > unterschiedlichen Konfigurationsmodi einstellen Muss man beim AVR auch.
Ben B. schrieb: > Ich lache selbst als reiner Hobby-AVR-Freak... ...ich nicht mehr. Meine Vorlage für den VL53L1X-TOF am Tiny1614 waren zwei Arduino-Projekte.
Jörg W. schrieb: > Lust L. schrieb: > >> Man muß nur die richtige finden, auf die richtigen Pins schalten und >> noch die richtige der gefühlt tausend, je nach Hersteller >> unterschiedlichen Konfigurationsmodi einstellen > > Muss man beim AVR auch. Lothar M. schrieb: > Kurz und knackig: wenn du vorher noch nichts mit solchen Dingern gemacht > hast, dann ist ein 8-Bit Controller mit 3 Timern und serieller Schnitte > eben viel, viel einfacher zu begreifen als einer mit 19 Timern mit je 13 > Modi und Ethernet-Schnitte. Um mal mit Mod-Mund zu antworten, vielleicht ist das überzeugender ;-)
Nur weil "ARM" dran steht, heißt das nicht, dass deshalb jeder ARM so überladen wäre. Vergleiche mal beispielsweise die Peripherie eines ATSAMD11 mit einem AVR128DB48.
Jörg W. schrieb: > dass deshalb jeder ARM so überladen wäre Also ich bleib dabei und Du solltest es auch tun. 8Bit bleibt durchgehend einfacher programmierbar als jeder ARM. Noch ne mod-originale Kostprobe?: Lothar M. schrieb: > Nein, man muss eben z.B. um bei modernen 32-Bittern einen Portpin für > die blinkende LED ansteuern zu können ggf. erst mal schauen, dass die > entsprechende Spannung für den Port eingeschaltet ist, dann dass ggfs. > der Takt für den Port eingeschaltet ist, dann ggfs. noch eine > alternative Funktion von dem Pin weggebogen werden muss, und dann kann > das Ganze schon mal länger dauern, als nur 8-Bit-mäßig "2 > Registerzugriffe und die LED blinkt!"
Lust L. schrieb: > 8Bit bleibt durchgehend einfacher programmierbar als jeder ARM. Du solltest mit solchen Attributen wie "durchgehend" und "jeder" vorsichtiger sein. Auch Lothar schreibt da was von "ggf.". AVRs sind eben mittlerweile nicht mehr nur AT90S1200-mäßig simple Teile, sondern auch da gibt es ziemlich komplexen Kram, der der Komplexität einfacher ARMs keineswegs mehr nachsteht. Daher sind die Pauschalisierungen schlicht Unsinn, und eine "Verteufelung", dass man mit ARMs gar nicht einsteigen könne, völlig unangebracht. Wenn du natürlich einen ATmega328 gegen einen aufgeblähten SAME70 oder STM32F7xx (so du ihn überhaupt kaufen kannst :) vergleichst, dann stimmt das, aber dann vergleichst du Äpfel mit Ananas, nichtmal mehr mit Birnen.
Jörg W. schrieb: > AVRs sind eben mittlerweile nicht mehr nur AT90S1200-mäßig simple Teile, > sondern auch da gibt es ziemlich komplexen Kram, der der Komplexität > einfacher ARMs keineswegs mehr nachsteht. So ist es. Aber zwei Vorteile haben die neuen AVR8, selbst mit der mittlerweile teilweise recht komplexen und umfangreichen Peripherie immer noch: Das einfachere (weil fast vollautomatische) Taktsystem und das deutlich einfacher gestrickte Interruptsystem. Eher als Nachteil würde ich allerdings die Einfachheit des DMA-Systems einschätzen, denn das ist nur deshalb so überaus einfach, weil es schlicht nicht vorhanden ist...
Nun ich hätte aus diesem Forum noch viel mehr Zitate ARM vs. AVR zu bieten und mit jedem einzelnen schwindet der Eindruck Jörg W. schrieb: > da gibt es ziemlich komplexen Kram, der der Komplexität einfacher ARMs > keineswegs mehr nachsteht. Verteufelung liegt mir allerdings fern- so einen 32Bitter zu beherrschen und auf Leistung satt zurückgreifen zu können ist sicher ein erhebendes Gefühl. Das teilen wir ;-) c-hater schrieb: > Eher als Nachteil würde ich allerdings die Einfachheit des DMA-Systems > einschätzen, denn das ist nur deshalb so überaus einfach, weil es > schlicht nicht vorhanden ist... Meine Einschätzung dazu wäre: Wo es auf einem 8Bitter DMA bräuchte nimmt man besser gleich was höherbittiges. > AVR8 ... mit der mittlerweile teilweise recht komplexen ... Peripherie Zum Beispiel?
:
Bearbeitet durch User
Lust L. schrieb: > Meine Einschätzung dazu wäre: Wo es auf einem 8Bitter DMA bräuchte nimmt > man besser gleich was höherbittiges. Wenn 8Bit-Daten zu bewegen sind (und auch die 32-Bitter bewegen z.B. mit ihren UART- I2C- usw. Einheiten nur 8Bit-Daten), dann wäre der Vorteil eines DMA-Systems exakt gleich. Er würde die MCU von diesem Kram entlasten. Egal, ob die nun 8bittig oder 32bittig ist. Capisce?
Lust L. schrieb: > Zum Beispiel? Beispiele habe ich genannt. Du musst sie dir nur ansehen. Die Peripherie manches Cortex-M0 ist weniger komplex als der aktuellen "Highend"-AVRs. Ich finde die Peripherie der AVRs (auch der modernen) trotzdem gut, aber sie ist eben nicht mehr so simpel wie die der ersten AVRs. Anders gesagt: nicht mehr so primitiv.
c-hater schrieb: > Er würde die MCU von diesem Kram entlasten. Das war doch gar nicht die Frage. Wo es auf dermaßen Speed bzw. große Datenmengen ankommt nimmt man besser gleich mehr als 8Bit- was meint leistungsfähigere 32Bit MCUs. Bei AVRs und für deren typische weniger datenintensiven Aufgaben ist DMA doch so ziemlich überflüssig und allenfalls ein Instrument, um die vergleichsweise beschränkte AVR Leistung doch noch ein wenig zu erweitern oder ein paar mehr Optionen zur Programmgestaltung zu bekommen. Jörg W. schrieb: > Die Peripherie manches Cortex-M0 ist weniger komplex als der aktuellen > "Highend"-AVRs. Also das Beispiel mit dem ATSAMD11 überzeugt mich nicht. Ja es stimmt, manchen Timer und erst recht das Event-System oder die CCL-LUT eines AVR-Dx gilt es wirklich zu durchschauen, doch das muß man ja nicht nutzen und kann die MCU trotzdem simpel mit allen ihren Grundfunktionen in Betrieb nehmen. Ein Cortex-M0 kocht da zwar auch nur mit Wasser aber eben mit etwas mehr (u.a. Datenblattseiten). Und nein- ich behaupte keinesfalls das wäre nicht beherrschbar und unüberwindlich...
Lust L. schrieb: > doch das muß man ja nicht nutzen Das Argument trifft aber auf so ziemlich jede MCU zu. ;-)
Nein, es ist ein Unterschied ob ich beim AVR alles nutze ocer nicht oder bei einemArm erst zig Sachen konfigurieren muss um das wnige überhaupt nutzen zu können. Bei mehrfach belegten Pins z.B, Das alles ist bei ARM komplexer. Und wenn er verallgemeinet ARM vs. AVR geht man vom gängigen aus Atmega32, 664 etc pp und Bluebill etc. Es gibt immer von allen auch komplexe Beispiele, auf so einer Basis lässt sichs aber kaum sachlich diskutieren "> doch das muß man ja nicht nutzen Das Argument trifft aber auf so ziemlich jede MCU zu. ;-)"
Peter K. schrieb: > oder bei einemArm erst zig Sachen konfigurieren muss um das wnige > überhaupt nutzen zu können Bei manchen Leuten frage ich mich, ob sie jemals einen einfachen ARM programmiert haben. Hier ein Minimalbeispiel, was ich mal für einen SAMD20 geschrieben habe:
1 | #include "sam.h" |
2 | void _exit(int i) {for(;;){}} |
3 | |
4 | int
|
5 | main(void) |
6 | {
|
7 | // unusable, since PORT is a macro
|
8 | // PM->APBBMASK.bit.PORT = 1;
|
9 | PM->APBBMASK.reg = 8; |
10 | |
11 | /* PA19: input with pulldown */
|
12 | PORT->Group[0].PINCFG[19].bit.INEN = 1; |
13 | PORT->Group[0].PINCFG[19].bit.PULLEN = 1; |
14 | PORT->Group[0].OUTCLR.bit.OUTCLR = (1 << 19); |
15 | |
16 | /* PA16: input with pullup */
|
17 | PORT->Group[0].PINCFG[16].bit.INEN = 1; |
18 | PORT->Group[0].PINCFG[16].bit.PULLEN = 1; |
19 | PORT->Group[0].OUTSET.bit.OUTSET = (1 << 16); |
20 | |
21 | /* LED0 on XPlainedPro: PB30, active low */
|
22 | PORT->Group[1].DIRSET.bit.DIRSET = (1 << 30); |
23 | PORT->Group[1].OUTSET.bit.OUTSET = (1 << 30); |
24 | |
25 | for (;;) |
26 | {
|
27 | if ((PORT->Group[0].IN.bit.IN & (1 << 19)) != 0) |
28 | {
|
29 | /* PA19 pulled high */
|
30 | /* turn on LED */
|
31 | PORT->Group[1].OUTCLR.bit.OUTCLR = (1 << 30); |
32 | /* wait for button release */
|
33 | while ((PORT->Group[0].IN.bit.IN & (1 << 19)) != 0) |
34 | {
|
35 | }
|
36 | }
|
37 | |
38 | if ((PORT->Group[0].IN.bit.IN & (1 << 16)) == 0) |
39 | {
|
40 | /* PA16 pulled low */
|
41 | /* turn off LED */
|
42 | PORT->Group[1].OUTSET.bit.OUTSET = (1 << 30); |
43 | /* wait for button release */
|
44 | while ((PORT->Group[0].IN.bit.IN & (1 << 16)) == 0) |
45 | {
|
46 | }
|
47 | }
|
48 | }
|
49 | |
50 | return 0; |
51 | }
|
Wo sind hier "zig Sachen"? Das wirklich einzige, was sich nennenswert vom AVR unterscheidet ist, dass man den PORT-Block im Powermanager in Betrieb nehmen muss – beim AVR sind standardmäßig alle Blöcke eingeschaltet, und man muss einzeln ausschalten, was man nicht braucht, um Energie zu sparen.
:
Bearbeitet durch Moderator
Was allgemeine Beispiele sind, da tust Du dich etwas schwer mit, oder? Es gibt wohl gerade beim Arm sehr viele <besonderheiten bereits bei einfachen togglen Beispielen. Wenn Du natürlich einen nicht doppelt belegten <pin oder einen bei dem diese <Funktion gerade frei ist, verwendest gibt es das Problem naturgemäß nicht. Aber als Anfänger erwischt man nicht selten eben genau diese Pins und sucht sich einen Wolf
c-hater schrieb: > Das einfachere (weil fast vollautomatische) Taktsystem und > das deutlich einfacher gestrickte Interruptsystem. Nun ja, so etwas hat ernste physikalische Gründe. Schwingquarze lassen sich verhältnismäßig einfach bis zu Frequenzen von so etwa 30 MHz herstellen. Damit ist auch die in einem simpleren Taktsystem mögliche Taktfrequenz auf diesen Bereich beschränkt. Nun könnte man auf die Idee kommen, so einen Quarz auf der 3. oder 5. Oberwelle zu erregen, um damit höhere Taktfrequenzen hinzukriegen, aber das würde bedingen, daß man ein ein zweites auf diese Obewellen abgestimmtes Resonanzgebilde in Oszillator hat. Sowas wird zu kompliziert für den praktischen Einsatz. Die Leute wollen 2 Pins haben wo der Quarz dran kommt und allenfalls noch 2 Kondensatoren und einen Widerstand dort noch dranklöppeln. Mehr nicht. Man sieht es hier ja allenthalben, daß gerade die Programierer mit allem Analogen und HF-technischen auf Kriegsfuß stehen. Die Folge ist, daß man für höhere Taktfrequenzen einen chipinternen abstimmbaren Oszillator nimmt, der dann per PLL stabilisiert wird. Und die Folge davon ist eben, daß es mehr einzustellen und in Gang zu setzen gibt als bei einem simpleren Taktsystem. Naja, und wer das Interruptsystem gerade bei den heutigen Cortexen-M für kompliziert hält, hat offenbar vergessen, wie das etwas früher bei den ARM7..9 aussah. Oder er ist so jung, daß sowas vor seiner Zeit lag. Noch ein Wort zu den auch hier immer wieder aufflammenden Vergleichen im Stile von "meiner ist größer als deiner...": Dem Professionellen sind derartige Gedanken herzlich fremd. Da zählen ganz andere Dinge wie Übersetzungswerkzeuge, Verfügbarkeit, Zuverlässigkeit, Qualität der Dokumentationen, Eckdaten und Eignung für ein Projekt überhaupt, inclusive Aufwand für Anpassung an das Projekt. Was da für den Bastler bleibt, ist nur noch eine individuelle Präferenz, also ob einem der eine Chip besser gefällt als der andere. Aber das ist wie mit den Frauen: der eine mag lieber blonde, der andere brünette. W.S.
Peter K. schrieb: > Aber als Anfänger erwischt man nicht selten eben genau diese Pins und > sucht sich einen Wolf Eben deshalb predige ich immer wieder, daß man wissen sollte, was man tut, bevor man es tut. Also die Nase ins Manual stecken und es verstehen, bevor man mit allem Anderen überhaupt anfängt. Und dann systematisch vorgehen. Nicht einfach drauflos schreiben. Aber genau DAS tun vermutlich viele Bastler eben nicht, sondern sie schreiben erstmal munter drauflos und benutzen dann den Debugger, um ihr Zeug nachträglich zum Funktionieren bringen zu wollen. OK, es gibt gute Manuals, die man leicht versteht und es gibt schlechte Manuals, die einem das Verstehen schwer machen. Gute Manuals zu schreiben, ist eben auch eine Kunst, die nicht jeder Hersteller beherrscht. W.S.
Peter K. schrieb: > Was allgemeine Beispiele sind, da tust Du dich etwas schwer mit, oder? Irgendwie bist du ziemlich (un)lustig. Ich poste ein Beispiel, welches ziemlich klar demonstriert, dass die Behauptung "ARM ist (generell) unzumutbar für dein Einstieg" doch recht deutlich widerlegt. Von dir kommt daraufhin Prosa und ich würde kein "allgemeines Beispiel" bringen? Die Definition von IO-Pins für Sonderfunktionen sind auf jeder MCU halt etwas, wofür man das Manual durchlesen muss. Ob du nun für die Ausgabe einer PWM sowas brauchst wie:
1 | /*
|
2 | * PB16: PWM output to generate V[LCD]
|
3 | * PB16 = TC6/WO[0], function E
|
4 | */
|
5 | PORTB.PMUX[16 / 2].bit.PMUXE = PORT_PMUX_PMUXE_E_Val; |
6 | PORTB.PINCFG[16].bit.PMUXEN = 1; |
oder
1 | TCCR1A=_BV(COM1A1)|_BV(COM1A0); |
2 | TCCR1B=_BV(WGM12); /* Timer Stopped */ |
Keins von beiden ist irgendwie "komplexer" als das andere, aber beide erschließen sich ohne Durchlesen der Doku absolut nicht.
Ben B. schrieb: > Im Vergleich zu was? Zu den diskutierten 32Bit ARM vielleicht? Peter K. schrieb: > Nein, es ist ein Unterschied ob ich beim AVR alles nutze ocer nicht oder > bei einemArm erst zig Sachen konfigurieren muss um das wnige überhaupt > nutzen zu können Das versuch ich ja auch verzweifelt deutlich zu machen ;-) Jörg W. schrieb: > Das wirklich einzige, was sich nennenswert vom AVR unterscheidet ist, > dass man den PORT-Block im Powermanager in Betrieb nehmen muss – beim > AVR sind standardmäßig alle Blöcke eingeschaltet Der Teufel liegt eben in den zahlreichen Details. Die Taktkonfiguration hast Du gepflegt unter den Tisch fallen lassen. Du kannst nun freilich weitere in Deinen Augen Simpel-Beispiele aufführen. Was nichts an der Tatsache ändert daß ARM insgesamt komplexer (zu konfigurieren) ist. 'Einfach' ist übrigens nicht wenn man weiß wie was geht. Sondern wenn man tatsächlich 'einfach' zu jener Erkenntnis kommt. Da sind die Wege beim AVR eben schneller.
W.S. schrieb: > Die Leute wollen 2 Pins haben wo der Quarz dran kommt und allenfalls > noch 2 Kondensatoren und einen Widerstand dort noch dranklöppeln. Mehr > nicht. Was hälst Du von 'gar kein Quarz' weil der interne Takt für die meisten Zwecke hinreichend genau ist? Beim modernen AVR trifft das zu. > Aber das ist wie mit den Frauen: der eine mag lieber blonde, der andere > brünette. Äpfel mit Birnen? > Also die Nase ins Manual stecken und es verstehen, bevor man mit allem > Anderen überhaupt anfängt Auch das eine Bemerkung im Stile "Komplexitätsunterschiede unerheblich, alles eine Geschmacksfrage". Schön, kannst Du als all-mcu-gestählter Profi so sehen. Nicht so der Einsteiger. Jörg W. schrieb: > dass die Behauptung "ARM ist (generell) unzumutbar für dein Einstieg" > doch recht deutlich widerlegt Das wiederum hat hier niemand behauptet.
Lust L. schrieb: > Die Taktkonfiguration hast Du gepflegt unter den Tisch fallen lassen. Weil das Beispiel schlicht ohne eine solche auskommt. Das ist an der Stelle durchaus vergleichbar mit dem AVR, wenn ich mich recht erinnere läuft der SAMD21 dann mit 2 MHz. Aber er läuft. (Der AVR ist mit 1 MHz Standardtakt auch kein Rennauto.) Das da oben ist ein komplett lauffähiges Beispiel. Es war meine Inbetriebnahmefirmware für ein SAMD21 Xplained Pro um zu sehen, ob sowohl Hardware als auch Toolchain das tun, was sie sollen. > Was nichts an der Tatsache ändert daß ARM insgesamt komplexer > (zu konfigurieren) ist. Dass vieles bei den ARMs komplexer werden kann, ist unstrittig. Dass der Teufel im Detail liegt, auch nicht – aber das ist bei AVRs nicht anders. Zumindest nicht, wenn man den vorgefertigten Arduino-Trampelpfad verlassen möchte (und das war die Absicht des TEs). Strittig ist in meinen Augen lediglich die Behauptung, dass man das einem Einsteiger gar nicht zumuten könnte. Das wollte ich widerlegen und zeigen, dass auch dort der Einstieg "ganz unten" recht problemlos möglich ist. Was ich bei AVR wirklich besser finde ist die komplett integrierte Toolchain. Du kannst also ein Programm mit
1 | avr-gcc -mmcu=atmega328 -O -o foo.elf foo.c |
komplett "aus der Dose raus" compilieren und das Resultat flashen. Startup-Code, Standardbibliothek und Linkerscripte werden bei einer sauberen Installation passend gefunden und sind generisch genug, um wohl mehr als 99 % der Anwendungsfälle abzudecken. Bei ARM wurschtelt jeder seins, du musst dich um Startup-Code mit passendem Linkerscript selbst kümmern. Jeder Hersteller kümmert sich nur um seine eigenen IDEs und bastelt das dann darin zurecht.
Lust L. schrieb: > Jörg W. schrieb: >> dass die Behauptung "ARM ist (generell) unzumutbar für dein Einstieg" >> doch recht deutlich widerlegt > > Das wiederum hat hier niemand behauptet. Dann erinnere ich dich hiermit an diese deine Aussage: Beitrag "Re: AVR- C: Welche einfachen Projekte für den "Einstieg"?" "Völlig indiskutabel zum Einstieg."
:
Bearbeitet durch Moderator
Jörg W. schrieb: > "Völlig indiskutabel zum Einstieg." Na gut. Erwischt👍 Für die meisten Einsteiger dürfte es dennoch zutreffen. Der Aha-Effekt stellt sich bei einem simplen sbi DDR-Bitx + sbi OUT-Bitx definitiv schneller ein 😉
Lust L. schrieb: > Der Aha-Effekt stellt sich bei einem simplen sbi DDR-Bitx + sbi OUT-Bitx > definitiv schneller ein Genau das war aber mein Minimalbeispiel da oben. Es trackt den Button auf dem Xplained Pro und gibt ihn auf der LED wieder aus. An der Stelle sind die Peripherals der Atmel (nunmehr Microchip) Cortex-M0+ sehr ähnlich zu denen der XMega. Vorteilhaft ist, dass es separate Register zum Setzen und Löschen eines Bits gibt, sodass man kein read-modify-write braucht (SBI und CBI sind read-modify-write). Aber das hatte Atmel auch schon bei den Xmegas an Bord. (Warum das vorteilhaft ist merkt man spätestens dann, wenn ein Register auch mal ein Interrupt-Flag beinhaltet, dessen unbeabsichtigtes Löschen Schaden verursachen kann.) Klar, die Zeiten, da das komplette Manual eines AT90S2343 (mehr oder minder ein Vorläufer des ATtiny15, der wiederum Vorläufer des ATtiny25/45/85 ist) auf nur 59 Seiten passte, sind vorbei. Heutige Controller fangen irgendwo bei 500 Seiten an, und selbst bei einem moderaten SAMD51 bist du schon bei fast 2000 Seiten. Allerdings muss man nicht jede Seite daraus kapiert haben, um den Kram zu benutzen. Man kann sich stückweise rantasten, und ja, sehr wahrscheinlich wird man bei einem ARM als erstes mal das Clocksystem in Betrieb nehmen, um den Controller mit ein paar Megahertz mehr laufen zu lassen. Aber das sind jetzt auch nicht 200 Zeilen Quellcode, das man dafür braucht, eher 20 oder 30. ps: Ich bin durchaus nach wie vor AVR-Fan. Ich finde sie für viele Aufgaben geeignet. Aber jemandem, der aktuell einsteigt, sollte man die kleinen Cortexe nicht madig machen. Die sind allesamt sehr attraktiv.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Aber jemandem, der aktuell einsteigt, sollte man die kleinen Cortexe > nicht madig machen. Die sind allesamt sehr attraktiv. Der AVR Einstieg schließt doch die spätere ARM Nutzung nicht aus. Ersterer gestaltet sich aber viel einfacher- und darum genau geht es für den Einsteiger und seinem Erlernen grundlegender Konzepte, samt schneller Erfolgserlebnisse. Vielleicht stellt sich für den Bastler (wie bei mir) sogar heraus daß es noch mehr ARM Power auch zukünftig nicht bedarf. Attraktiv (in Deinem Sinne) hin oder her. Attraktiv für mich sind neben dem simplen Aufbau beispielsweise bastlertaugliche Gehäuse und 5V Fähigkeit. Das gibts zwar mehr oder eher weniger bei ARM auch aber selten alles zusammen.
:
Bearbeitet durch User
Lust L. schrieb: > Attraktiv für mich sind neben dem simplen Aufbau beispielsweise > bastlertaugliche Gehäuse und 5V Fähigkeit. Naja, wer im Jahr 2022 noch nicht wenigstens ein TQFP als Bastler löten kann, braucht eigentlich auch nicht mehr einsteigen. ;-) Für mich sind die durchaus "bastlertauglich" (es muss ja nicht gleich ein QFN sein). Auch viele neuere AVRs sind nicht mehr im ollen riesigen DIL zu haben. Das "bastlerfreundlich" heißt dabei auch, dass es mir viel mehr Spaß macht, mit SMD-Bauteilen zu basteln als der olle riesige Kram "aus Opas Zeiten". 5-V-fähig sind auch viele ARMs inzwischen, um bei den Atmels zu bleiben, da sind es die SAMCxx. (Aktuell kaufen kann man natürlich gerade alles mögliche nicht, aber das ist ein anderes Thema und betrifft alle möglichen ICs.)
SMD Bauteile passen aber weder ins Steckbrett, noch auf Lochraster Platinen. Dazu braucht man dann wieder Adapter die extra kosten.
Stefan ⛄ F. schrieb: > SMD Bauteile passen aber weder ins Steckbrett, noch auf Lochraster > Platinen. Dazu braucht man dann wieder Adapter die extra kosten. So ist es. Früher(tm) konnte es sogar gut und gerne passieren, dass der beschissene Adapter teuerer war als die MCU, die man adaptieren wollte. Nunja, zumindest dieses Problem ist durch die extremen Preiserhöhungen bei vielen MCUs inzwischen weitgehend "gelöst"...
Stefan ⛄ F. schrieb: > SMD Bauteile passen aber weder ins Steckbrett, noch auf Lochraster > Platinen. Beides habe ich nie gemocht. Aber heutzutage bekommt man Platinen billig, das reißt das locker wieder raus.
Jörg W. schrieb: > Aber heutzutage bekommt man Platinen billig, das reißt das locker wieder > raus. Eine simple, minimal=IC große DIL Fassung (wie beim modernen AVRxDx möglich) ist und bleibt trotzdem die glasklar bessere, billigere, kleinere, praktischere, zeitsparendste Lösung. Wohlgemerkt in schmaler Version und wenn es sich mit der Pin-Quantität ausgeht. > 5-V-fähig sind auch viele ARMs inzwischen Nach meinem Eindruck weiter die Ausnahme. Und angeblich tendiert ja alles mit Macht zu kleineren Versorgungsspannungen ...
:
Bearbeitet durch User
Jörg W. schrieb: > Aber heutzutage bekommt man Platinen billig Aber ich will nicht für jedes Experiment eine Platine bezahlen müssen und darauf warten. Dazu muss man erstmal mit den CAD Programmen umgehen lernen. Das hatte ich mal zu DOS Zeiten gemacht. Nochmal tue ich mir das nicht mehr an. Ich baue praktisch nichts mehrmals, da scheue ich den Aufwand. Wer Elektronik Entwicklung zum Beruf hat muss sicher viel weniger experimentieren. Der plant eine Platine und die funktioniert dann auch auf Anhieb. Ich bräuchte bestimmt 5 Anläufe. Für mich sind Boards im Format des Arduino Nano hilfreich, gibt's ja auch mit ARM Controllern. Also selbst man mit SMD nicht klar kommt, ist man (noch) nicht ganz aufgeschmissen.
Also ich hab damals mit dem Atmega32 angefangen und bin später auf den STM32F103 umgestiegen. Beides hier im Forum verbreitete und empfohlene Microcontroller. Alleine der Einsatz der Standard Peripheral Library war schon eine Hürde, auch weil das Datenblatt von Registern/Registerwerten spricht, die ja in der SPL versteckt sind. Dazu die verstreute Dokumentation in Datenblatt und Reference Manual. Noch später habe ich mich dann mit Infineon XMCs beschäftigt, wo dann für die Peripherieansteuerung noch ein Codegenertor zum Tragen kommt und entsprechend eine weitere Abstraktionsschicht auf die Low-Level-Peripherieansteuerung setzt. Da hat mir der AVR-Zwischenschritt einiges erleichtert. Kann ja sein, dass es noch deutlich einfachere ARMe gibt. Jörg W. schrieb: > Aber heutzutage bekommt man Platinen billig, das reißt das locker wieder > raus. Sehe ich auch so. Für Steckbrettaufbauten nimmt man Minimalboards wie Nucleo, Bluepill etc. und für die fertige Anwendung lässt man dann einfach eine Platine fertigen. @TE: Ich würde gleich mit dem richtigen Projekt bzw. Teilbereichen daraus anfangen. Es geht mit einer blinkenden LED los (zeigt dir auch in Zukunft, dass das Programm läuft), dann kommt die serielle Schnittstelle (erst nur Senden, dann auch Empfangen), dann ein Temperatursensor (Werte per Serieller), Taster/Encoder/Poti (Anzeige per Serieller), und dann die Siebensegmentanzeige. Danach vielleicht ein Zeilen- oder Graphikdisplay. Das sind doch alles überschaubare Teilaufgaben.
Stefan ⛄ F. schrieb: > Aber ich will nicht für jedes Experiment eine Platine bezahlen müssen > und darauf warten. Für die Experimente gibt's doch genügend Experimentierboards. Gerade die kleinen Curiosity Nano sind nicht schlecht, auch die Xplained Mini von Atmel waren praktisch. Das ist besser als "nur 'ne DIL-Fassung", weil man gleich noch Programmer, die unentbehrlichen Abblock-Cs etc. mit drauf hat. Wer will, kann diese Boards ja dann immer noch mit den mitgelieferten Stiftleisten auf Lochraster oder Steckbrett nageln.
Jörg W. schrieb: > Für die Experimente gibt's doch genügend Experimentierboards. Ja, die nutze ich auch gerne.
Jörg W. schrieb: > Gerade die kleinen Curiosity Nano sind nicht schlecht Dem kann ich nur zustimmen- ein kompletteres modernes, bequemes und dabei günstigeres AVR Entwicklungssystem gibts nicht. Natürlich hat die Platine auch gewisse Ausmaße. Dann stellt sich allerdings die Frage ob man statt dessen nicht lieber einen etwa gleichgroßen Raspi-Pico -ganz anders in MicroPython- programmiert oder ein ähnliches System. So ein kleiner DIP-AVR/PIC behält hingegen stets seine Berechtigung, auch wenn der Programmer extern nötig ist. Abblock-C('s) sind hingegen problemlos in einer DIL Fassung unterzubringen, für externe Beschaltung brauchts bei AVR meist nicht mehr. Das mag bei ARM schon anders ausschauen!
Lust L. schrieb: > Dann stellt sich allerdings die Frage ob man statt dessen nicht lieber > einen etwa gleichgroßen Raspi-Pico -ganz anders in MicroPython- > programmiert oder ein ähnliches System. Für den TE nicht, denn er wollte ja (sinnbildlich gesehen) eher in die Tiefe gehen. > Das mag bei ARM schon anders ausschauen! Warum sollte es? Wie du an obigem Beispiel siehst, startet auch der mit einem internen RC-Oszillator, und mehr als die Abblock-Cs muss der erstmal nicht zwingend haben. Trotzdem würde ich mir keinen ARM im DIL kaufen, selbst wenn es sie vereinzelt gibt. ;-)
:
Bearbeitet durch Moderator
The D. schrieb: > Aber vieles davon würde ich nicht wirklich als > Anfängerprojekt bezeichnen, eine 7- Segmentanzeige zu multiplexen finde > ich (zumindest zu diesem Zeitpunkt) noch etwas kompliziert. Ich meinte > da viel mehr etwas, um sich einfach die ganzen bitschiebereien, > Datentypen, Schleifen usw. an der Tastatur und im Kopf "zu gewöhnen". 7S-Mux ist doch ideal geeignet zum Lernen der Bitmanipulationen. Es hält auch ein paar Fallgruben bereit, wenn man es nicht richtig verstanden hat. Z.B. Flackern, wenn man keinen Timerinterrupt benutzt oder Ghosting bei falscher Reihenfolge der Befehle.
Jörg W. schrieb: > Für die Experimente gibt's doch genügend Experimentierboards. Stimmt. Preislich ist so ein Board jedoch schon eine ganz andere Liga, als ein nackter ATmega328P-PU. Einmal kurz abgerutscht, schon sind 16..30 Euro im Müll. Beim Atmega sind es nur 2 Euro.
Steve schrieb: > Einmal kurz abgerutscht, schon sind 16..30 Euro im Müll. Ehrlich: ich habe schon manches elektronische Bauteil in die Schrottkiste befördert. So ein Experimentierboard gehört bislang nicht zu den Opfern. Wenn du nicht gerade mit Spannungen von 12 V oder mehr daran herum fummelst, ein simpler Kurzschluss eines IO-Pins für kurze Zeit killt keinen Controller so schnell.
Jörg W. schrieb: > ein simpler Kurzschluss eines IO-Pins für kurze Zeit killt keinen > Controller so schnell. .. hat aber trotzdem Beschädigungen zur Folge die man womöglich & üblerweise nicht gleich bemerkt? Wie schauts mit Verpolung aus? Oder irgend eine elektrostatische Sache? Grundsätzlich sind die vielen Maker Breakout Boards aber schon eine tolle Erfindung.
Lust L. schrieb: > Jörg W. schrieb: > >> ein simpler Kurzschluss eines IO-Pins für kurze Zeit killt keinen >> Controller so schnell. > > .. hat aber trotzdem Beschädigungen zur Folge die man womöglich & > üblerweise nicht gleich bemerkt? Ist dir das ernsthaft schon mal passiert? Mir nicht. Auch wenn es ganz theoretisch natürlich passieren kann. Der Vorteil der Demoboards: deren MCUs benutzt du am Ende sowieso nicht für ein fertiges Projekt, denn ein solches bekommt eine eigenständige Platine. Bei einem steckgewackelsockelten DIP dagegen wird keiner einen history track führen um bei der späteren realen Verwendung zu sehen, ob der nicht vielleicht schonmal derartige Misshandlungen überlebt hat. > Wie schauts mit Verpolung aus? Ein ordentliches Board hat eine Verpolsicherung, oft eine TVS-Diode. Wenn du die Dinger, wie heute oft üblich, via USB speist, dann hat sich das sowieso mit Verpolung. > Oder > irgend eine elektrostatische Sache? Genauso: theoretisch kann man da immer dem IC Schaden zufügen. Daher wird in den entsprechenden Messlabors der Hersteller auch fein säuberlich auf ESD-Schutz geachtet. Rein praktisch ist das letzte Bauelement, was ich mir wohl mit ESD geschossen habe, vor vielen Jahren eine Tunneldiode gewesen (leider, hätte ich gern noch für Experimente zur Verfügung gehabt). Klar, mit 12 V auf einem Board abrutschen ist schnell tödlich, da habe ich mir auch schon einen Controller gekillt. Aber sowas benutzt man eher in realen Projekten und nicht auf Demoboards.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ist dir das ernsthaft schon mal passiert? Durchaus. Und bei manchem I/O Pin war ich mir nicht sicher ob eine Programm-Fehlfunktion nicht doch mit einem Hardware-Schaden zusammenhängt. Trotzdem trotzten die meisten AVRs bislang meiner Schludrigkeit. Jörg W. schrieb: > Der Vorteil der Demoboards: deren MCUs benutzt du am Ende sowieso nicht > für ein fertiges Projekt, denn ein solches bekommt eine eigenständige > Platine > eher in realen Projekten und nicht auf Demoboards Die Grenzen verschwimmen. Wie etwa bei den Pi- und Curiosity Boards. Ist doch schön wenn die Programming/Debugging Funktion fürs Projekt gleich frei Haus mit dabei ist. Steve schrieb: > Preislich ist so ein Board jedoch schon eine ganz andere Liga, als ein > nackter ATmega328P-PU. Der Pi-Pico ist preislich schon sehr verlockend, zumal jetzt mit Drahtlos-Funktionalität.
Lust L. schrieb: >> Ist dir das ernsthaft schon mal passiert? > > Durchaus. OK, dann unterscheiden sich unsere Erfahrungen. Der einzige "Nichttotalausfallfehler", den ich bislang hatte (und für den ich auch keine Ursache erahnen kann) war ein ATmega324, der viel zu viel Strom im Standby aufgenommen hat und daher für die (batteriebetriebene) Anwendung nicht mehr brauchbar war. Da habe ich mich im Nachhinein geärgert, so ein blödes DIL-40 benutzt zu haben statt eines TQFP. Letzteres hätte ich mit der Heißluftpistole viel einfacher wechseln können als den ollen DIL. Den hatte ich nur genutzt, weil aufgrund der Größe des Gehäuses eigentlich Platz ohne Ende im Gerät war. Bis auf die erhöhte Stromaufnahme funktioniert das Teil allerdings nach wie vor (benutze ich gelegentlich für AVRDUDE-Tests auf einem STK500 mal).
Jörg W. schrieb: > Letzteres hätte ich mit der Heißluftpistole viel einfacher wechseln > können als den ollen DIL Entschuldigung, sowas kann ich nicht nachvollziehen. Den "ollen" DIL wechselt man notfalls mit dem Fingernagel und braucht den neuen IC auch nicht einlöten. Mir fällt auf daß Du hier öfter offensichtlich komplizierteres als einfach oder gar einfacher verkaufen möchtest 😉
Lust L. schrieb: > Entschuldigung, sowas kann ich nicht nachvollziehen. Den "ollen" DIL > wechselt man notfalls mit dem Fingernagel und braucht den neuen IC auch > nicht einlöten. In dem Falle nicht. Fassungen benutze ich nicht. Kontaktstellen sind schließlich die ausfallhäufigsten Elektronikbauteile überhaupt. 40 Pins auf 5 cm Länge auslöten macht halt keinen Spaß und ist Stress für die Platine. Aber keine Sorge, das war meine letzte DIL-MCU, die ich verbaut habe, und das ist auch jetzt schon einige Jahre her. ;-) Nochmal muss ich mir den Stress nicht geben.
Jörg W. schrieb: > Fassungen benutze ich nicht. Kontaktstellen sind schließlich die > ausfallhäufigsten Elektronikbauteile überhaupt. Natürlich nimmt man da ordentliche, vergoldete Präzisionsfassungen. Hatte noch nie ein Problem damit und würde mich schon SEHR wundern wenn hier jemand solcherlei berichten würde. > 40 Pins auf 5 cm Länge auslöten macht halt keinen Spaß und ist Stress > für die Platine. Eben. Deshalb mit Fassung. Die großen DIP 40Pinner (es gibt die aktuellen 4809er damit) sind wegen ihrer blanken Größe für Projekte ohnehin aus der Zeit gefallen- aber zum grobmotorischen Basteln noch ganz gut geeignet. Deshalb schrieb ich weiter oben was von schmalem DIP Gehäuse zur Verwendung in Projekten.
Jörg W. schrieb: > Da habe ich > mich im Nachhinein geärgert, so ein blödes DIL-40 benutzt zu haben statt > eines TQFP. Letzteres hätte ich mit der Heißluftpistole viel einfacher > wechseln können als den ollen DIL. Also jeder vernünftige Mensch, der DIL benutzt (und damit die DIL-Nachteile in Kauf nimmt), nimmt dann natürlich wenigstens auch die DIL-Vorteile mit: d.h.: das Teil bekommt natürlich einen Sockel. Und wenn man das getan hat, dann möchte ich sehen, wer von uns schneller einen Mega1284P wechselt, wenn deiner als TQFP/QFN/MLF auf dem Board klebt und meiner elegant in seinem DIL-Sockel steckt. Vor allem dann, wenn deiner auch noch schön viel Decoupling-Hühnerfutter in unmittelbarer Nähe hat...
Jörg W. schrieb: > In dem Falle nicht. "der Fall" um den es mir hier geht sind Steckbretter und Lochraster Platinen. Du bist ganz woanders, bei fertigen Platinen, für die braucht niemand mehr das DIL Format. c-hater schrieb: > das Teil bekommt natürlich einen Sockel. Ja
Lust L. schrieb: > Die großen DIP 40Pinner (es gibt die aktuellen 4809er damit) sind wegen > ihrer blanken Größe für Projekte ohnehin aus der Zeit gefallen- aber zum > grobmotorischen Basteln noch ganz gut geeignet. Ja, war eigentlich damals schon aus der Zeit gefallen, nur dass der Platz eben da war und ich es deshalb benutzt habe. Meine Konsequenz daraus habe ich geschrieben: kein DIP mehr in fertigen Projekten. Habe ich seitdem durchgehalten. :) TQFPs sind ja nun wirklich nicht schwierig zu löten, kleiner gehe ich auch nur, wenn es irgendwas nur in QFN oder so überhaupt gibt.
Stefan ⛄ F. schrieb: > "der Fall" um den es mir hier geht sind Steckbretter und Lochraster > Platinen. Ich würde mir trotzdem keinen ATmega4809 in DIP mehr dafür hinlegen, sondern nehme dann lieber ein Devboard. Für die alten, die noch in einen STK500 passen, ist das OK, das benutze ich vor allem für AVRDUDE immer mal wieder.
Ich schätze mal, dass sie in 10 Jahren ganz weg sind.
Lust L. schrieb: > Natürlich nimmt man da ordentliche, vergoldete Präzisionsfassungen. > Hatte noch nie ein Problem damit und würde mich schon SEHR wundern wenn > hier jemand solcherlei berichten würde. Mich auch. Schließlich war das jahrzehntelang DIE bewährte Standard-Technologie (und nichtmal unbedingt mit superteuren Sockeln, auch nicht im Industriebereich). Klar, es gibt hin und wieder Kontaktprobleme. Da hat un's Jörg schon Recht, Kontakte sind immer ein Problem. Aber: typisch erst nach Jahren im Betrieb. Und die Abhilfe ist extrem einfach: einmal rausziehen, einmal reinstecken und der Drops ist gelutscht für die nächsten zehn Jahre... In aggressiver Atmosphäre gelten aber natürlich andere Regeln.
Stefan ⛄ F. schrieb: > Ich schätze mal, dass sie in 10 Jahren ganz weg sind. Abwarten. Menschliche Hände werden nicht filigraner😃 Aber es ist natürlich schon so daß die Hardware immer kleiner wird. Für meinen Geschmack wird man sich da aber wesentlich mehr Programmierkomfort einfallen lassen müssen um AVR & Pic, Asm & C wirklich unattraktiv werden zu lassen. c-hater schrieb: > Klar, es gibt hin und wieder Kontaktprobleme. Ohne Steckverbindungen kommt E-Technik nun mal nicht aus. Ob mit oder ohne IC-Fassungen.
Lust L. schrieb: > Stefan ⛄ F. schrieb: >> Ich schätze mal, dass sie in 10 Jahren ganz weg sind. Für einen Zeitraum würde ich mich da auch nicht festlegen wollen. ;-) > Abwarten. Menschliche Hände werden nicht filigraner😃 Menschliche Hände waren in der Lage, Magnetkernspeicher zu fädeln. Dagegen ist das Löten eines TQFP mit 0,8 mm Pinraster Pipifax. > Für meinen > Geschmack wird man sich da aber wesentlich mehr Programmierkomfort > einfallen lassen müssen um AVR & Pic, Asm & C wirklich unattraktiv > werden zu lassen. Man sieht ja an den neuen (nun schon aus dem Hause Microchip kommenden) AVRs, dass da durchaus ein Marktsegment noch existiert. Lediglich über 4-Bit-MCUs spricht wohl wirklich keiner mehr.
Ich würde ganz anders anfangen. Such dir ein reales Projekt, dass du für dich selbst brauchst und wachse daran. Immer wenn etwas neues hinzu kommt (z.B. Timer), übe es außerhalb seines Projektes und wenn du meinst, dass du soweit bist, implementiere es in dein Projekt. Läuft es da nicht, übe weiter, finde die Fehler und bringe es zum laufen. Läuft dein Projekt, versuche den Code zu verbessern. Du wirst viel mehr Spaß haben, wenn du etwas baust, das genau das macht, was es für dich tun soll. Und je mehr du machst, dein erstes Projekt wird hier und da noch weitere Funktionen bekommen oder ausgefeilter in der Funktion sein. Das behält man auch viel besser im Kopf, wie ich finde.
Jörg W. schrieb: > Dagegen ist das Löten eines TQFP mit 0,8 mm Pinraster Pipifax. Die meisten aktuellen Mikrocontroller haben inzwischen 0,5mm Pinraster.
Jörg W. schrieb: > Menschliche Hände waren in der Lage, Magnetkernspeicher zu fädeln. > Dagegen ist das Löten eines TQFP mit 0,8 mm Pinraster Pipifax. Und doch gibt es solche und solche Hände. TQFP löten gelingt manuell natürlich mit etwas üben, Geschick und manchem Trick und mancher Technik. Aber es ist und bleibt schwieriger als eine DIL Fassung löten. Ich selber setze Fassungen und Draht-Bauelemente ein wo immer möglich. Man muß sich das Leben nicht unnötig kompliziert machen- insbesondere als freiwilliger, spaßorientierter Bastler. Stefan ⛄ F. schrieb: > Die meisten aktuellen Mikrocontroller haben inzwischen 0,5mm Pinraster. Da hört bei mir der Löt-Spaß auf. Sehr schön lötbar und trotzdem sehr klein sind dagegen aktuelle Tinys der Sorte 1614.
Lust L. schrieb: >> Die meisten aktuellen Mikrocontroller haben inzwischen 0,5mm Pinraster. > Da hört bei mir der Löt-Spaß auf. Bei mir auch. Es ist mir nach einigen Fehlversuchen gelungen, aber das war so mühsam, darauf habe ich keine Lust. Man muss sich im Hobby nicht selbst quälen.
Stefan ⛄ F. schrieb: > Jörg W. schrieb: >> Dagegen ist das Löten eines TQFP mit 0,8 mm Pinraster Pipifax. > > Die meisten aktuellen Mikrocontroller haben inzwischen 0,5mm Pinraster. Ist 'ne Frage der Pinanzahl. Einen SAMD21 oder AVR128Dx im 32-Pin-TQFP bekommst du immer noch mit 0,8, aber auch 0,5er lassen sich mit der Hand löten. Manch einer schwört auf Hohlkehle, aber auch Lötpaste geht, sowohl mit Kolben als auch Heißluft. Aber es ist natürlich richtig, die Welt wird kleiner. :-) Nicht alle finden das schlecht: Platinenpreise richten sich immer noch nach der benutzten Fläche.
Jörg W. schrieb: > Platinenpreise richten sich immer noch nach der benutzten Fläche. Deshalb ja DIL Fassung auf Universal-Platine plus Draht-Bauelemente 😃
Was ich aber inzwischen total gerne mit SMD auf Lochraster mache: Abblock-Kondensatoren zwischen zwei Pins löten. Demnächst kommen vielleicht noch Widerstände dazu, mal sehen.
Lust L. schrieb: > Jörg W. schrieb: >> Platinenpreise richten sich immer noch nach der benutzten Fläche. > > Deshalb ja DIL Fassung auf Universal-Platine plus Draht-Bauelemente 😃 Du kennst doch den Spruch, wer nicht mit der Zeit geht, geht mit der Zeit … Wenn nun jemand heutzutage da einsteigen möchte (damit fing der Thread ja an), würde ich ihm die Technik des letzten Jahrtausends nicht mehr nahelegen wollen. Ob die DILs nun in 10 Jahren aussterben werden oder in 20, es gibt eh schon mehr und mehr immer relevantere Teile nicht mehr in dieser Bauform. Nun kann man über die bösen Hersteller schimpfen – oder mit der Zeit gehen. Mir macht jedenfalls das Basteln mit SMD-Bauteilen genauso Spaß, wie vor 40 Jahren mit den damaligen Bauteilen. Dass es mittlerweile industriell gefertigte Platinen zu völlig bastlertauglichen Preisen gibt ist ein Pluspunkt, danach hätten wir uns vor 40 Jahren die Hände gerieben.
Jörg W. schrieb: > Wenn nun jemand heutzutage da einsteigen möchte (damit fing der Thread > ja an), würde ich ihm die Technik des letzten Jahrtausends nicht mehr > nahelegen wollen Du unterschätzt eines gewaltig: DIL-Fassung, Universalplatine, bedrahtetes Bauelement bringen vom Basteln bis hin zu einem fertigen Projekt eine Flexibilität mit sich die ihresgleichen sucht, so schnell nicht veralten wird. Diesbezüglich wird die anzufertigende SMD Platine immer hintenan stehen, ganz egal wie schön sie als kompakte Lösung auch sein mag. Und wiegesagt, menschliche Hände werden nicht kleiner und dessen Träger wird die gerade einfachere, schnellere, günstigere, manchmal auch nur "begreifbarere" Lösung immer vorziehen. > es gibt eh schon mehr und mehr immer relevantere Teile nicht mehr in > dieser Bauform Es sollte Dir eigentlich zu denken geben daß Microchip einen neuen AVR (4809) sogar im "ollen" 40Pin DIP Breit-Format rausbringt ;-) Käufliche Breakout-Platinen sehe ich als wunderbare Ergänzung eines immer breiteren Angebots. Doch werden sie DIL-Fassung, Universalplatine, bedrahtetes Bauelement ebensowenig vollständig ersetzen wie die hochmoderngelobten 32Bitter ihrer kleineren ollen "steinalten" Brüder. Alles hat eben seine Vorzüge wie Nachteile- und es ist doch super wenn man damit immer passender und zielgenauer konstruieren kann!
:
Bearbeitet durch User
Jörg W. schrieb: > Ist 'ne Frage der Pinanzahl. Einen SAMD21 oder AVR128Dx im 32-Pin-TQFP > bekommst du immer noch mit 0,8, aber auch 0,5er lassen sich mit der Hand > löten. Meine Technik ist, ich flute eine Pinreihe mit bleihaltigem Lot, daß es richtig schön glänzt und fließt. Dann halte ich die Reihe senkrecht und ziehe das Lot mit dem Kolben zu einer Seite hin ab. Bei Bedarf mache ich wieder frisches Lot auf die restlichen Pins. Die Pins einzeln zu löten, schaffen meine Hände nicht mehr. 0,5mm Pitch geht nochmal deutlich schwerer als 0,65mm.
:
Bearbeitet durch User
Lust L. schrieb: > Du unterschätzt eines gewaltig: DIL-Fassung, Universalplatine, > bedrahtetes Bauelement bringen vom Basteln bis hin zu einem fertigen > Projekt eine Flexibilität mit sich die ihresgleichen sucht, so schnell > nicht veralten wird. Da bin ich halt anderer Meinung (und habe andere Erfahrungen). Die Zeit wird's zeigen.
Peter D. schrieb: > Meine Technik ist, ich flute eine Pinreihe mit bleihaltigem Lot, daß es > richtig schön glänzt und fließt. Dann halte ich die Reihe senkrecht und > ziehe das Lot mit dem Kolben zu einer Seite hin ab. Meine Technik ist, die IC-Pins (als erstem Bauteil auf der Platine) ohne Rücksicht auf Verluste großzügig zu löten und die entstandenen Pin-Pin Verbindungen wieder heißgemacht mit der Platine senkrecht nach unten auf eine harte Unterlage wegzuschlagen. Das geht natürlich nur bis zu einer bestimmten Platinengröße und wenn eventuelle Zinnspritzer keiner anderen Struktur schaden können bzw. leicht wegzumachen sind. Das ergibt fast garantiert professionellste Lötstellen die von maschineller Lötung nicht mehr zu unterscheiden sind.
:
Bearbeitet durch User
Peter D. schrieb: > Meine Technik ist, ich flute eine Pinreihe mit bleihaltigem Lot, daß es > richtig schön glänzt und fließt. Dann halte ich die Reihe senkrecht und > ziehe das Lot mit dem Kolben zu einer Seite hin ab. Bei Bedarf mache ich > wieder frisches Lot auf die restlichen Pins. Die Pins einzeln zu löten, > schaffen meine Hände nicht mehr. Ich mache es ähnlich, allerdings nehme ich zum Entfernen von überschüssigem Lot feindrähtige Litze, die ich als Entlötlitze missbrauche. Das geht super. Es bleibt so immer genug Lot an der Lötstelle übrig, um eine sichere Kontaktierung zu gewährleisten.
Lust L. schrieb: > ... die entstandenen Pin-Pin > Verbindungen wieder heißgemacht mit der Platine senkrecht nach unten auf > eine harte Unterlage wegzuschlagen. Du misshandelst offensichtlich gern Deine Platinen. So hat eben jeder seine Vorlieben. Lust L. schrieb: > Ich selber setze Fassungen und Draht-Bauelemente ein wo immer möglich. > Man muß sich das Leben nicht unnötig kompliziert machen- insbesondere > als freiwilliger, spaßorientierter Bastler. Das lese ich so, das Du eigentlich immer die THT Technologie einsetzt und da frage ich mich schon wie man da beim Löten massenhaft die Pins verbindet, so daß man da so rappiade Methoden anwenden muß. Bei THT passiert es mir äußerst selten, daß ich da mal 2 Pins miteinander verbinde, aber mit etwas Flußmittel ist der Fehler schnell beseitigt.
Zeno schrieb: > Du misshandelst offensichtlich gern Deine Platinen Das klappt besser als es sich anhört. Zumal das Ergebnis so klasse ist. Unangenehmer wirds allerdings wenn Mikrospritzer noch offene kleine Pads bedrahteter Bauelemente treffen. > Bei THT passiert es mir äußerst selten, daß ich da mal 2 Pins > miteinander verbinde Das betrifft natürlich ausschließlich SMD Bauteile wenn es denn nicht anders geht. Und ganz generell: Es ist noch kein Meister vom Himmel gefallen. Vermutlich gehe ich selber SMD dafür auch zu oft aus dem Weg 😉
Zeno schrieb: > Es bleibt so immer genug Lot an der Lötstelle übrig, um eine sichere > Kontaktierung zu gewährleisten. It depends. Ich habe schon oft genug zu viel wieder "rausgesaugt" aus irgendwelchen Lötstellen. ;-) Für "richtige" Projekte gebe ich inzwischen auch mal Geld für Pastenschablonen aus.
Ein Sauger für heißes Zinn wäre toll, im Prinzip wie der Speichel-Sauger vom Zahnarzt. Gits ja auch, nur leider teuer.
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.