Hallo! Ich habe neulich von einem Bekannten sämtliche Bücher geschenkt bekommen, da ich ihm gesagt habe das ich mich für Elektronik & Mikrocontroller interessiere. Unter anderem ist ein Buch namens "AVR Mikrocontroller Programmieren in C" (Erschiene 2010) dabei. An sich sehr interessant, da es kompakt ist und ein paar Projekte enthält. Meine Frage : Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? Oder soll man direkt mit moderneren Chips loslegen? Ich freue mich auf eure Antworten!
:
Robert schrieb: > Meine Frage : Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? Ja, weil eher klein und überschaubar und sehr verbreitet, was Projekte und Lernmaterial angeht. > Oder soll man direkt mit moderneren Chips loslegen? Kann man machen, ist aber nicht zwingend, ggf. eher ungünstig, weil die moderneren 32 Bit Controller auch deutlich komplexer sind. Wer das kleine 1x1 auf dem AVR lernt, kann dann problemlos aufsteigen.
Kurz um die Grundlagen kennenzulernen sicherlich, denn diese sind auch bei anderen Plattformen immernoch grundsätzlich nicht viel anders. Dann aber schnell auf modernere Plattformen wechseln: - STM32 - ATSAM - ESP32 - embedded Linux Und vor allem Frameworks sind heute gefragt, im privaten Bereich jedoch nicht ganz so entscheident.
Blablub schrieb: > Und vor allem Frameworks sind heute gefragt, Das gibt dann LED-Blinker mit gefuehlten 800 kB Flashbedarf.
Für die Grundlagen ist es egal, womit Du anfängst. Das Faktenwissen über konkrete Chips, ihre Register und die Entwicklungsumgebung hat eine geringe Halbwertszeit. Viel wichtiger ist das Methodenwissen, wie Du an eine Aufgabe herangehst, wie Du Datenblätter liest (ja, die sind auf English, und wenn Du Probleme damit haben solltest, dann tust Du gut daran das zu ändern), das Verständnis für interne Abläufe und Strukturen usw usw. Die klassischen AVRs haben aus heutiger Sicht Schwächen. Sie haben relativ wenige und relativ dumme Peripherieeinheiten, sie haben nicht so gute Debugmöglichkeiten, man kann sich durch fehlerhafte Programmierung aussperren, und sie laufen nur bei 5V mit ihrer vollen Taktrate. Es gibt moderne AVRs, die diese Schwächen nicht mehr haben, und es gibt Alternativen: PIC24, dsPIC33 und PIC32 sind recht angenehm und haben deutlich mehr Leistung, und ARM-basierte Controller gibts von dutzenden Herstellern, wenn auch in der Regel nicht in bastelfreundlichen Gehäusen. Aber insgesamt ist es egal, womit Du anfängst. Wichtig ist, dass Du lernst zu lernen, und dass Du Dich nicht auf eine Sache versteifst und dann mit dem Lernen aufhörst. Ich habe vor etwa 40 Jahren mit Z80 angefangen zu programmieren, und nach einem Jahr war ich so weit, dass ich zu den mesiten Opcodes den Hexwert wusste und direkt eintippen konnte. Für die nächste Architektur 6502 habe ich dann nur noch 6 Wochen gebraucht, bis ich genauso weit war. Seitdem sind noch etwa 20 verschiedene Architekturen dazugekommen. fchk
Blablub schrieb: > Dann aber schnell auf modernere Plattformen wechseln: > - STM32 > - ATSAM > - ESP32 > - embedded Linux Kann man machen oder man bleibt beim AVR weil das, was man vor hat, so wenig komplex ist, dass es damit geht. Es kommt also (wie immer) darauf an, was man damit machen will.
Ein arduino uno kostet gerade mal 3 eur. Das arduino IDE ist einfach und schnell zu erlernen. Das ist ein idealer einstieg. Kannst natürlich auch das AVR studio benuzen wenn du maso tendenzen hast.
Falls uns die Asiaten keine Chips mehr liefern sollten - eine Fab für die alten Atmel würden wir hier in Deutschland notfalls auch noch zustande bringen. War in der DDR auch so - da lernten die Studenten auf 8080 Clones. Bei modernen Chips kam es immer wieder zu Versorgungsengpässen.
Ein Ratschlag schrieb: > Bei > modernen Chips (kommt es |kam es } immer wieder zu Versorgungsengpässen. Wo habe ich das schon mal gehört?;-)
Beitrag #6976818 wurde von einem Moderator gelöscht.
Beitrag #6976823 wurde vom Autor gelöscht.
Robert schrieb: > Meine Frage : Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? Ja! Robert schrieb: > Oder soll man direkt mit moderneren Chips loslegen? Ja! Ist das ein Widerspruch? Jain!
Georg M. schrieb: > Atmel hat keine Zukunft. Richtig, Atmel hat nicht einmal eine Gegenwart. Aber darum geht es in dem Thread ja gar nicht, sondern um AVR-Mikrocontroller.
Robert schrieb: > Ich habe neulich von einem Bekannten sämtliche Bücher geschenkt > bekommen,... also alle, die es auf unserem Planeten so gibt? Alle Achtung. Da hast du lang dran zu lesen. Aber ich schätze, daß du eigentlich meinst "ich habe neulich von einem Bekannten sämtliche Bücher geschenkt bekommen, die ich mir mit meinem doch eher endlichen Verstand zum Thema Elektronik so vorstellen kann". Naja, wenn du so fragst, wie man es aus dem Eröffnungspost herauslesen kann, dann befasse dich ruhig mit den AVR und dem zugehörigen Buch. Hoffentlich sind die fertigen Beispiel-Projekte deinem Geschmack entsprechend. W.S.
Robert schrieb: > Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? Pro: - Einfache 8-Bit Plattform mit einfacher integrierter Hardware. - Gute Dokumentation. - Du hast die Bücher. - Auch relativ einfach in ASM programmierbar, trotz RISC-Architektur relativ umfangreicher Befehlssatz. - Mit nur einem Takt Abarbeitungszeit bei den meisten Befehlen recht flink. - In bastelfreundlichen Gehäusen zu bekommen. Und dies wird dank Microchip vermutlich auch noch lange so bleiben. (TI z.B. kündigt DIL derzeit ab) - Braucht im Prinzip nur Spannung. Kontra: - Einen Linux-Kernel (in Emulation) darauf zu booten dauert ein paar Tage. Es gibt eigentlich kein wirkliches Argument dagegen, um mit einem AVR einen Einstieg zu machen. Noch ein paar Dinge: Atmel wurde an Microchip verkauft und die neueren AVR verPICkeln immer mehr. Ich hoffe aber dennoch, dass Dinge wie 5 Bit Stack, 13 Bit Kommandos und 17 Bit Adressbusse beim PIC bleiben. (Als ich einem Bekannten letztens noch 11 7 Bit Register hinzudichtete bekam dieser einen leicht panischen Blick.) Grundsätzlich hast Du bei 8-Bit Controllern den Vorteil, dass Du Dich nicht noch zusätzlich mit Dingen wie unterschiedlichen Clock domains, Port-Matrix, IRQ-Prioritäten oder komplexerer Hardware herumschlagen musst. (Obwohl es das auch da gibt - aber nicht beim einfachen AVR.) Wenn Du noch eine Stufe weiter herauszoomen möchtest, wäre der standard 8051 noch interessant. Da kannst Du dann auch RAM und ROM extern anbinden. Ist aber wieder eine Fehlerquelle. Havard und v. Neumann kann man dort beides realisieren. Aber hast Du ja wahrscheinlich keine Bücher für und ist, was den Aufbau angeht, auch wieder anspruchsvoller. Du kannst DIL-AVRs auf's Steckbrett drücken oder auf Lochraster löten, zwei Kondensatoren dazu - läuft. Du kannst fertige Bastelboards (DAUino oder so ...) benutzen und in der heutigen Zeit auch recht einfach und günstig eigene Platinen designen und fertigen lassen. Viel Spaß! Gruß Jobst
Die Frage ist doch berechtigt. Programmierung auf den 32Bit MCs packt man ganz anders an. Jedes Bit verstehen geht eh nicht mehr. Da sucht man sich RTOS und Libraries, die sich irgendwie um die Details kümmern. Heutzutage hat das mehr Ähnlichkeit mit PC-Programmierung, als mit der Mikrocontroller-Programmierung vor 20 Jahren. Ein Schlosser muss in seine Lehre auch 2 Wochen mit der Feile gearbeitet haben. Gehört zum Allgemeinwissen eines Schlossers. Bin der Meinung, diese Bitfummelei gehört genau so zur Ausbildung eines Entwicklers. Auch wenn man es nie wieder braucht.
Ich denke auch, dass das auf keinen Fall Zeitverschwendung ist. Bis man an die Leistungsgrenze von 8-Bit-Mikrocontrollern kommt, dauert es recht lang. Ich mag dieses Forum hier, habe aber meistens Controller anderer Hersteller in Arbeit. Darum habe ich nicht soo viel Unterstützung. Aber wenn du mit AVR anfängst, passt das optimal. Mehr Hilfe als hier wirst du fast nicht bekommen können. Viel Erfolg!
Ein Kommentar schrieb: > Bin der Meinung, > diese Bitfummelei gehört genau so zur Ausbildung eines Entwicklers. Auch > wenn man es nie wieder braucht. Also einen STM32 programmiere ich abgesehen von der fetten Peripherie wie beispielsweise Ethernet oder USB nach wie vor auf Registerebene. Sämtlicher Hardwarezugriff gekapselt in eine eigene Klasse und in der Regel wenige Zeilen Code. Wofür brauche ich für ADC, DAC, GPIO, RCC, DMA oder Timer eine aufgeblähte HAL?
Jobst M. schrieb: > Es gibt eigentlich kein wirkliches Argument dagegen, um mit einem AVR > einen Einstieg zu machen. Einstieg? Bei Nacht und Nebel - aber in welche Bankfiliale? Ach nein, eigentlich fängt es alles mit der Idee zu und Konstruktion von Geräten an, dazu passend ein Schaltungskonzept (wenn es etwas elektronisches werden soll) und dazu passend einen Mikrocontroller. So herum. Daß man sich ab irgend einer Stelle mit Digitaltechnik und dann mit Programmierung von Mikrocontrollern befassen muß, ist damit verbunden. Es ist kein "Einstieg" in eine separate Welt. Durch eine Luke namens AVR oder i8051 oder sonstwie. Aber es ist ein durchaus interessantes Teil-Thema, vorausgesetzt, man hat bereits fundierte Kenntnisse der übrigen Bereiche. Aber der TO hat sich über seinen eigenen Kenntnis-Stand noch nicht ausreichend geäußert. W.S.
Der müde Joe schrieb: > Bis man > an die Leistungsgrenze von 8-Bit-Mikrocontrollern kommt, dauert es recht > lang. Das würde ich auch so sehen. Der Mega2560 (256 kB Flash, 8 kB RAM) will erst einmal ausgereizt werden... Zudem scheinen mir die AVR sehr robust zu sein, was ein Vorteil für den Anfänger ist. Wenn man den Arduino Uno (oder einen der zahlreichen Clones) mit dem 328 in der DIL-Variante wählt, dann kann man im Falle eines Falles den Chip einfach tauschen (es gibt den nämlich auch schon mit vorinstalliertem Bootloader zu kaufen). Als weiteren Vorteil läuft der auch mit 5V, d.h. der kann mit vielen Bauteilen direkt zusammenarbeiten. Der läßt sich (andere Einstellung in der IDE muß aber vorgenommen werden) aber auch mit 3,3V betreiben, wenn auch mit reduziertem Takt.
Ein Kommentar schrieb: > Ein Schlosser muss in seine Lehre auch 2 Wochen mit der Feile gearbeitet > haben. Gehört zum Allgemeinwissen eines Schlossers. Bin der Meinung, > diese Bitfummelei gehört genau so zur Ausbildung eines Entwicklers. Auch > wenn man es nie wieder braucht. Zu anderen Zeiten war in der Ausbildung ein ganzes Jahr nur Feilen angesagt. Aber davon abgesehen hast du ja recht. Ich denke auch, daß der TS mit einem AVR am Anfang nichts verkehrt macht und, ganz im Gegenteil, dessen Einfachheit zu Beginn eher ein Vorteil ist. Alleine schon das Datenblatt eines AVR z.B. im Vergleich zum Reference Manual eines mittleren STM32 ist eigentlich nur hilfreich. Und AVRs können erstaunlich viel, bis man den ausreizt dauert es schon etwas. Ich habe ebenfalls mit AVRs angefangen - in Assembler - und im Nachhinein hat es sich nur als vorteilhaft herausgestellt.
svensson schrieb: > Wenn man den Arduino Uno ... wobei die IDE und Debugmöglichkeiten bei Arduino sagen wir mal bescheiden sind.
Blablub schrieb: > wobei die IDE ... bei Arduino sagen wir mal bescheiden sind. Nur wenn du damit meinst dass die IDE nicht überfüllt und unübersichtlich sondern einfach und klar ist. Debugged wird mit serial.print. Das zwingt genau zu überlegen und führt zum besseren programmierer. :) Wenn das richtige board und der com-port eingestellt sind läuft das. Das kann vom stm32 oder esp32 nicht gesagt werden, die sind wesentlich komplizierter. Ganz zu schweigen von diversen linux-distros bei denen seit dem "code of conduct" ausser megabloat so ziemlich nichts mehr klappt. Ich bin durchaus fähig baseflight mit eclipse und "arm-non-eabi" zu kompilieren, empfinde das aber als sehr gewöhnungsbedürftiges unübersichtliches und überkompliziertes system.
:
Bearbeitet durch User
Hallo Robert Wie alt bist du? Was sind deine beruflichen Ziele. Willst du hobbymäßig einsteigen oder professionell? Strebst du Software- oder Hardwareentwicklung an. Oder gar beides? In meinen Augen ist es gut, das kleine Einmaleins zu lernen, bevor es in die höhere Mathematik geht. Die "kleinen" Atmels sind für einen Einsteiger schon ziemlich komplex, aber noch gut zu verstehen. Allerdings, willst du "nur" progammieren, dann brauchst du nicht unbedingt elektronische Kenntnisse, willst du selber basteln oder bauen, dann brauchst du neben Kenntnissen in Elektronik auch Kenntnisse in der Programmierung. Die Frage, ob alte oder modernste Controller solltest du ganz hinten anstellen. Sie ist gar nicht für einen Anfänger relevant. Der braucht anfangs viel Hilfe und da sind grad die "alten" Controller sinnvoll, weil man einiges mit umsetzen kann und doch ein noch lesbares Datenblatt hat. Bei allen Überlegungen solltest du nicht aus den Augen verlieren, das sowohl Hardware wie auch Software sehr zeitraubend ist. Nur wenn hohes Interesse vorhanden, wirst du dich erfolgreich weiterbringen. Ansonsten bleibst du auf der Strecke. Also, viel Spaß... Gruß oldmax
Für AVR ASM habe ich "AVR studio 4" sehr geschäzt. Einfach, klar, schnell. Dort hat auch auch der bloat zugeschlagen und neuere versionen sind schrott.
Hallo, ich denke, dass das mit Abstand wichtigste, wenn man mit Controllern anfangen will, hinreichend viele Ressourcen zum Thema "Anfängerfehler" bzw. eine Community ist, die man im Zweifelsfall fragen kann sind. Und da sind m.E. einfach folgende Plattformen am verbreitetsten: -AVR -PIC -Arduino (bitte nicht hauen) Ich würde daher empfehlen erst man mit dem AVR anzufangen. Ein Nachteil ist, wie von Anderen schon angesprochen, natürlich das AVRs in vielen Aspekten nicht mehr so modern sind. Wenn man langfristig dann doch mehr Rechenleistung, Low Power o.Ä. möchte, kann man auf eine andere Plattform wechseln, bei der die Community vllt. kleiner ist, da man sich hinreichend gut selbst helfen kann
Frank K. schrieb: > Ich habe vor etwa 40 Jahren mit Z80 angefangen zu programmieren, und > nach einem Jahr war ich so weit, dass ich zu den mesiten Opcodes den > Hexwert wusste und direkt eintippen konnte. Bei mir hatten sich die Hexwerte so sehr ins Gehirn eingebrannt, dass ich jahrzehntelang jeden Hexdump, den ich erblickte, automatisch disassemblierte. Auch heute schaue immer noch reflexartig, ob sich an markanten Adressen wie z.B. 00x003f oder 0x0066 ein C3, d.h. ein Sprungbefehl befindet. In den letzten 20 Jahren schaue ich aber eher auf ein E im höchsten Nibble jedes Langwortes, aber seit großenteils Thumb genutzt wird, ist das auch eher unwichtig. Ähnlich geht es ja auch vielen Funkamateuren, die jedes Vogelgezwitscher als Morsesignal dekodieren.
Blablub schrieb: > ... wobei die IDE und Debugmöglichkeiten bei Arduino sagen wir mal > bescheiden sind. Und? Mag es an der Oberfläche auch schlicht sein. Andere IDEs sind da eher überladen. Bei dem schlichteren muss man halt mehr schreiben. Mehr lesen. Das übt. Für den Grundlagenerwerb ist das sicherlich besser, als die EierLegendeWollMilchSau. Zudem lässt sich da wohl jeder µC dranstöpseln, für den es einen GCC C++ Compiler gibt. Vom Tiny13 bis zum Multicore mit etlichen 100Mhz C++, C, ASM sind die häufigsten(einzigen?) Sprachen in der Arduino Welt. Somit dürften alle Beispiele aus dem Buch auch mit der Arduino IDE lauffähig sein. Mein Rat, klein anfangen. Die Arduino IDE kostet nix, vielleicht eine Spende. Arduino Boards, z.B. mit einem ATMega328P, sind recht preiswert. Steigerungen und Wechsel der IDE und der Hardware, sind ja jederzeit möglich, wenn man denn irgendwann weiß wohin man will.
AVR wird es noch lange geben, auch in kommerziellen Produkten. Insbesonders, da Microchip ATMEL gekauft hat (Microchip ist für lange Verfügbarkeit bekannt). Es erscheinen sowieso immer noch neue AVR-Derivate. Wenn du in C anfängst, sind die erlernten Dinge sowieso auch auf andere Controller übertragbar. Daher: Immer frisch voraus. Und zum Anfangen sind sie toll, weil weniger kompliziert. Trotzdem lernt man im Gegensatz zum Arduino das Arbeiten mit richtigen µC. Lasst dir aber keinen Assembler aufschwatzen ;-) Ob der AVR auf deine Anforderungen an das Hobby passt, musst du aber selber entscheiden. Ich würds halt mal ausprobieren. Ich persönlich bin eher mit STM32 unterwegs. Ich sehe aber durchaus den Sinn der kleinen 8-Bitter. Ich sehe sie außerdem auch in kommerziellen Produkten (z.B. in meiner Gastherme), von daher ist das kein "Spielkram" und auch nicht "veraltet".
Großenteils: Zustimmung. Name: schrieb: > Trotzdem lernt > man im Gegensatz zum Arduino das Arbeiten mit richtigen µC. Aber da steckt ein logischer Fehler drin.
EAF schrieb: > Aber da steckt ein logischer Fehler drin. Nein. Ein Arduino ist kein µC, sondern so eine Art Programmiersprache. Man merkt das spätestens dann, wenn man etwas spezielleres mit der Peripherie anstellen will. Was nicht falsch ist, aber wenn man Arduino lernt, lernt man nicht "richtig µC programmieren". Ob das eine Rolle spiel, hängt davon ab, was man mit den Kenntnissen anfangen will. Mich persönlich stört, dass man nicht ordentlich debuggen kann. Oder geht das inzwischen?
Name: schrieb: > Ein Arduino ist kein µC, sondern so eine Art Programmiersprache. > Man merkt das spätestens dann, wenn man etwas spezielleres mit der > Peripherie anstellen will. Quatsch. Die register kannst du mit arduino genau so ansprechen wie mit C, denn arduino ist C. Anfänger machen analogWrite(... Profis dann OCR2A = ...
Arduino ist die Kombination aus der IDE, einem Software-Framework und einer mehr oder weniger standardisierten Hardware. Das ganze wirkt ZUSAMMEN. Die Einzelteile sind nicht relevant. Pepe T. schrieb: > Quatsch. Die register kannst du mit arduino genau so ansprechen wie mit > C, denn arduino ist C. > Anfänger machen analogWrite(... > Profis dann OCR2A = ... Jaja immer das gleiche Gelaber. Natürlich gibt es keine spezielle Programmiersprache sondern es wird in C/C++ entwickelt. Aber WENN du das alles mit Registern machen könntest, ohne die ganze Arduino Libs und ohne die IDE, dann bräuchtest du ja kein Arduino. Dann kaufst du einen AVR oder STM32 und entwickelst mit Eclipse und GCC. Also erzähl nichts.
:
Bearbeitet durch User
Name: schrieb: > Mich persönlich stört, dass man nicht ordentlich debuggen kann. Oder > geht das inzwischen? Ist in der Entwicklung und tuts für z.B. für manche ARM schon https://docs.arduino.cc/software/ide-v2 Name: schrieb: > Nein. Ein Arduino ist kein µC, sondern so eine Art Programmiersprache. Falsch! Es ist C++, C und ein wenig ASM Für den Anfänger in der Hauptsache C++. Arduino "besteht" aus 3 Dingen! 1. IDE 2. verschiedenste µC auf Platinchen 3. Ein Framework, mit ein paar Dutzend Funktionen Auf jedes diese 3 kann man verzichten, bzw durch was anderes oder eigenes ersetzen.
Cyblord -. schrieb: > bräuchtest du ja kein Arduino. Dann ... entwickelst mit Eclipse und GCC. Quatsch. Arduino bringt editor, compiler, flashen und serial-console plus plotter in einem sehr einfach zu installierenden paket während eclipse und gcc eher etwas für leute mit masochistischen tendenzen ist.
Cyblord -. schrieb: > Aber WENN du das alles mit Registern machen könntest, ohne die ganze > Arduino Libs und ohne die IDE, dann bräuchtest du ja kein Arduino. Naja.... Ohne Durchgriff auf die Register/Hardware Ebene, könne man wohl keine Hardwarebezogenen Libraries schreiben. Hunderte Libraries beweisen, dass nicht nur geht, sondern sogar manchmal notwendig ist. Also: Es gibt nicht nur schwarz und weiß. Sondern viel Raum dazwischen. Sicherlich bietet Arduino einen kleinen Berg an Komfortfunktionen. Aber keiner zwingt einen dazu sich darauf zu beschränken. Auch du nicht.
EAF schrieb: > Cyblord -. schrieb: >> Aber WENN du das alles mit Registern machen könntest, ohne die ganze >> Arduino Libs und ohne die IDE, dann bräuchtest du ja kein Arduino. > > Naja.... > Ohne Durchgriff auf die Register/Hardware Ebene, könne man wohl keine > Hardwarebezogenen Libraries schreiben. > Hunderte Libraries beweisen, dass nicht nur geht, sondern sogar manchmal > notwendig ist. Niemand bestreitet dass man libs für Arduino schreiben kann. Das SW Framework besteht aus solchen libs. Wie ich oben schon schrieb. > Also: Es gibt nicht nur schwarz und weiß. Es gibt Leute die brauchen Arduino und Leute die brauchen es nicht. Ich will aber von Arduino-Abhängigen nicht hören dass man das alles auch ohne könnte. Technisch kann man. Intellektuell halt nicht. > Sicherlich bietet Arduino einen kleinen Berg an Komfortfunktionen. > Aber keiner zwingt einen dazu sich darauf zu beschränken. Die Grenze ist die Bequemlichkeit und die Hirnkapazität.
EAF schrieb: > Arduino "besteht" aus 3 Dingen! Schrieb ich vor dir bereits. > 1. IDE > 2. verschiedenste µC auf Platinchen > 3. Ein Framework, mit ein paar Dutzend Funktionen > > Auf jedes diese 3 kann man verzichten, bzw durch was anderes oder > eigenes ersetzen. Kann man. Dann ist es halt kein Arduino mehr.
Schade, dass der Thread in Arduino-Bashing abdriftet, obwohl es überhaupt nichts mit der initialen Frage zu tun hat. Man kann sein Brot selbst backen, mit selbst gemahlenem Mehl, aus selbst angebautem Getreide. Wenn man allerdings hungrig ist, geht man zum Bäcker und kauft es, unabhängig von der Hirnleistung. Back to work...
Robert schrieb: > Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? Kommt drauf an, was du damit machen willst. Der Chip alleine macht dich weder reich noch schön. Er fängt auch keine attraktiven Frauen ein. Aber man kann damit nützliche und spannende Dinge bauen. Die AVR Chips sind durchaus noch aktuell - ein Ende nicht in Sicht. > Oder soll man direkt mit moderneren Chips loslegen? Die sehr gut dokumentierten STM32 sind vor allem für Anfänger sehr viel schwieriger zu erlernen, weil sie viel mehr Funktionen haben und man die Wechselwirkungen zwischen den Funktionsgruppen besser kennen muss, um damit zurecht zu kommen. Wenn du sonst noch keine Mikrocontroller programmiert hat, empfehle ich mit AVR anzufangen. Meine Homepage hat für AVR und STM32 eine Menge Lesestoff: http://stefanfrings.de/
Name: schrieb: > Lasst dir aber keinen Assembler aufschwatzen ;-) Lass Dir vor allem aber nicht aufschwatzen, was für Dich am besten wäre! Probiere alles aus und finde Deine Sprache. Je breiter Du aufgestellt bist, desto besser. Und Assembler zu verstehen ist sicherlich kein Nachteil, denn das ist das, was der Controller abarbeitet. Es ist nie verkehrt bei Problemen Detailwissen zu haben. Gruß Jobst
Pepe T. schrieb: > Quatsch. Arduino bringt editor, compiler, flashen und serial-console > plus plotter in einem sehr einfach zu installierenden paket während > eclipse und gcc eher etwas für leute mit masochistischen tendenzen ist. Arduino ist etwas für unbedarfte Anfänger.
Blablub blubberte im Beitrag #6977780:
> Arduino ist etwas für unbedarfte Anfänger.
Also genau das was Robert, der OP sucht?
Siehe auch hier: https://nanoracks.com/wp-content/uploads/NanoRacks-Release-14-Open-Source-Research-Platform-Winner-Announced.pdf https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.1046.3719&rep=rep1&type=pdf https://sallyridescience.ucsd.edu/sally-ride-science-partnership-lets-students-reach-for-the-stars-with-experiments-in-space/ https://atmelcorporation.wordpress.com/tag/international-space-station/ ...
Blablub schrieb: > Arduino ist etwas für unbedarfte Anfänger. Nein, ist es nicht. Ich kenne diverse Prfümittelentwickler und QS-Leute, die ihre Testaufbauten damit steuern. Es ist halt eine komplett andere Stoßrichtung als µC-Programmierung. Die Diskussion stellt sich analog für mich so dar: "Gabeln sind Mist, weil man damit nicht Suppe essen kann". "Ich benutze nur Messer, wie jeder echte Profi". "Nein, beim letzten Mal Reis essen habe ich mir damit die Lippen zerschnitten, jetzt verwende ich nur Löffel, auch für mein Steak". Mache kommen mit Arduino besser zurecht, und für manche Dinge eignet es sich auch besser. Ich persönlich bevorzuge auch eine ordentliche µc-Plattform wie STM32 oder AVRs. Aber das ist eine Geschmacksfrage, und auch davon abhängig was denn damit gemacht werden soll. Sowieso ist die Begrenzung zu 97% nicht die Plattform. Die sitzt vor der Tastatur.
Name: schrieb: > Sowieso ist die Begrenzung zu 97% nicht die Plattform. Die sitzt vor der > Tastatur. AMEN, Bruder, AMEN!
Robert schrieb: > Ist es noch lohnenswert mit AVR Atmel Chips anzufangen? > Oder soll man direkt mit moderneren Chips loslegen? Ja natürlich, warum auch nicht? Zuerst stellt sich die Frage: Was heißt lohnenswert für dich? Ein Hobby ist eigentlich kaum lohnenswert und selbst finanziell bringt dir KnowHow rein gar nichts, solange du kein Geld damit verdienen kannst. Du könntest zB. auch statt AVRs zu programmieren 100 Bücher im Jahr lesen oder jonglieren lernen, wird dir wahrscheinlich alles nichts bringen. Wenn du aber Mikrocontroller programmieren lernen willst -warum auch immer- kannst du das natürlich mit AVRs machen. AVRs sind eine relativ einfache Architektur die zusätzlich sehr gut dokumentiert ist, es ist also sehr leicht Informationen und Hilfe zu finden. Der grundsätzliche Ablauf etwas zu programmieren ändert sich nicht, die C Sprache auch kaum, also ist es für den Anfang tatsächlich recht egal womit man anfängt. Viel wichtiger ist tatsächlich anzufangen. Atmel wurde von Microchip gekauft, derzeit werden noch regelmäßig sowohl neue AVRs als auch PICs auf den Markt geworfen, das ganze ist also noch hochaktuell. Der Niedergang von 8Bit Controllern wurde schon ab den späten 90er prophezeit und ist bis jetzt nie eingetreten. Kurz gesagt, wer heute mit einem halbwegs modernen AVR anfängt zB. eine Atmega 4809 wird den nicht so schnell ausreizen können, damit geht schon einiges. 32 Bit ist natürlich derzeit am angesagtesten und in vielen Branchen zB. Automotive auch seit Jahren ganz klar ganz vorne, allerdings ist der Einstieg wirklich nicht einfach und für einen absoluten Einsteiger schon sehr zäh. https://www.mouser.at/ProductDetail/Microchip-Technology/DM320115?qs=sGAEpiMZZMv0NwlthflBi4UzTHrj%252BUATF6y%2F8caWHDU%3D mfg
> 32 Bit ist natürlich derzeit am angesagtesten
Was aber auch häufig an einem Mißverständnis liegt, denn auch ein Chip
mit einem 8-Bit Rechenwerk kann natürlich auch 16, 32 oder 64 Bit Zahlen
verarbeiten.
Auch beim PC dachten viele, daß ihre Programme mit 64 Bit CPU schneller
laufen als mit 32 Bit CPU.
miros schrieb: > Schade, dass der Thread in Arduino-Bashing abdriftet, obwohl es > überhaupt nichts mit der initialen Frage zu tun hat. Ach, das sind meist die wenigen, welche mit C++ völlig überfordert sind. Die anderen wissen, dass es eine Weile braucht, da sattelfest zu werden.
Beitrag #6978040 wurde von einem Moderator gelöscht.
Es ist lohnenswert jede MCU mal kennengelernt zu haben. Ich habe mit 8051 und Assembler angefangen und musste vor 20 Jahren noch hunderte Seiten Doku durchforsten bevor der Controller irgendwas von sich gab. Daher ist ein Arduino ein nettes Tool für kleine Projekte, die schnell etwas demonstrieren sollen. Geht es aber in die Tiefe und braucht man mehr, dann steht man bei Arduino schnell an. Ich hatte mal ein primitives Problem mit einem 9 Bit seriellen Protokoll. Das können nur wenige MCUs hardwaremässig. Dafür musste ich dann auf STM umsteigen. Frameworks sind natürlich ein Segen bei komplexen MCUs. Besonders die großen Hersteller legen sich hier ins Zeug um mit netten Tools das Programmieren grafisch zu ermöglichen. Bei der STM32IDE und deren TouchGFX Framework kommt man aufgrund der häufigen Updates und Versionsproblemen aber ins Verzweifeln. Bei Mikrocontrollern vermeide ich in der Regel auch C++, die meisten Frameworks sind auch in C geschrieben, da alles sehr hardwarenahe und kompakt sein soll. C++ benötigt zu viel Heap und überlastet den RAM der kleinen schnell mal. Besonders die STM sind mit einer Grafikanwendung, selbst mit externem RAM gleich mal voll. Das ist dann nervig, wenn beim fertigen Programm auf einen anderen Controller gewechselt werden muss, weil der Speicher nicht ausreicht. Besonders blöd, wenn die Platine dann schon fertig ist. Bei den ST Mikrocontrollern sind mir schon merkwürdige Typen untergekommen, die Probleme mit AD und DMA Interrupts hatten. Das kostet dann oft mehrere Tage an Arbeit das Problem überhaupt zu finden. Die Hersteller liefern oft nur mässig Support. Da ist eine große Community sehr hilfreich. Die User finden und lösen Probleme meist schneller als der Lieferant. Beim ESP32 spielt der Speicher wieder keine Rolle, dafür muss man auf Debugging verzichten und weis nicht was in dem Ding wirklich vorgeht. Für kleine Spaßprojekte ist das Teil ok, aber ich würde es nicht in ein Kundenprojekt einbauen. Das meiste was ich in meiner Firma entwickle wird mit AVR, ST oder PIC bestückt. Derzeit können aber alle nicht liefern, also muss man sowieso nehmen was man bekommt.
Arduino für Alle schrieb: > Siehe auch hier: Dann ist mir klar, warum wir seit 52 Jahren niemanden mehr zum Mond geschickt haben. Name: schrieb: > Sowieso ist die Begrenzung zu 97% nicht die Plattform. Die sitzt vor der > Tastatur. Das ist eher eine Pipeline und Arduino setzt davor an.
Hi, mir ist schleierhaft, warum man hier auf anderen Platformen herumhacken muss. Die Frage ist doch ganz einfach, --> genauso wie die Antwort: Lohnt es sich mit AVR anzufangen --> JA, absolut, mach es einfach. Wenn Du das dann probiert hast und Dich damit auskennst, kannst Du immer noch mit größeren Platformen weitermachen (ST32, LPC, ESP32, ...) Gleich mit größeren Platformen zu starten ist möglich, kann für unerfahrene jedoch deutlich schwieriger sein. Viel Spaß !
Pepe T. schrieb: > Debugged wird mit > serial.print. Das zwingt genau zu überlegen und führt zum besseren > programmierer. :) Debuggen mit Serial.print? Das ist wahrlich unprofessionell. Aber bei Arduino und co. gibt es eben keine professionelle Alternative.
Hi Name: schrieb: > Lasst dir aber keinen Assembler aufschwatzen ;-) Du weißt ja sicherlich auch, warum du anonym bleiben willst. Und warum du einen Smiley setzt. Assembler, mag er noch so verpönt sein, ist entgegen vieler Behauptungen gar nicht so schwer und m.E. für Leute, die mit Hard- und Software arbeiten und auch verstehen wollen, wie so ein Ding funktioniert sicherlich sinnvoll. Auch Maschinen werden in AWL, einer Assembler ähnlichen Sprache programmiert. Fast alle meiner Kollegen waren hilflos, wenn sie damit konfrontiert wurden. Bei allen Beiträgen, die hier zu lesen sind, gibt es sehr viele, die in C programmieren, Zeitverzögerungen mit "delay" umsetzen und sich dann wundern, warum manchmal Signale nicht erfaßt werden. Profis wissen das, aber Anfänger fallen immer wieder darauf herein. Also, laßt doch mal die negativ klingende Beurteilung einer Sprache. Jede hat ihre Daseinsberechtigung und ehrlich, bevor wir lesen und den Text verstehen konnten, haben wir das Alphabet gelernt. Nun sind wir auch in der Lage, verschiedene Sprachen zu verstehen. Es ist also nicht falsch, sich auch Mal mit Assembler zu befassen. Gruß oldmax
Martin V. schrieb: > Assembler, mag er noch so verpönt sein, ist entgegen vieler Behauptungen > gar nicht so schwer Nicht um eine LED blinken zu lassen. Auch nicht für einfache Steuerungsaufgaben. Aber mach mal einen TCP/IP Stack damit. Oder implementiere sonst ein komplexeres Protokoll.
Daniel A. schrieb: > Ich hatte mal ein primitives Problem mit einem 9 Bit seriellen > Protokoll. Das können nur wenige MCUs hardwaremässig. Dafür musste ich > dann auf STM umsteigen. Kein Problem für die AVRs. Ein ATtiny2313 hätte völlig gereicht: • Supports Serial Frames with 5, 6, 7, 8, or 9 Data Bits and 1 or 2 Stop Bits • Odd or Even Parity Generation and Parity Check Supported by Hardware
Hi Jobst M. schrieb: > Und Assembler zu verstehen ist sicherlich kein Nachteil, denn das ist > das, was der Controller abarbeitet. > Es ist nie verkehrt bei Problemen Detailwissen zu haben. Das möchte ich etwas ergänzen, alle ! Controller und Prozessoren arbeiten einen Maschinencode ab, der mit Assembler verständlich abgebildet wird und jede Programmiersprache erzeugt letztendlich eine Datei, die der Prozessoroder Controller nacheinander abarbeiten kann. Zugegeben, das auf Windows, Bildverarbeitung, Grafik-,Musik-,etc. Programme zu beziehen, fällt auch mir schwer. Ist aber so. Gruß oldmax
Daniel A. schrieb: > Daher ist ein Arduino ein nettes Tool für kleine Projekte, die schnell > etwas demonstrieren sollen. > Geht es aber in die Tiefe und braucht man mehr, dann steht man bei > Arduino schnell an. Wie oben schon gesagt wurde, das liegt nicht am Arduino oder dessen IDE. Name: schrieb: > Sowieso ist die Begrenzung zu 97% nicht die Plattform. Die sitzt vor der > Tastatur.
Peter D. schrieb: > Daniel A. schrieb: >> Ich hatte mal ein primitives Problem mit einem 9 Bit seriellen >> Protokoll. Das können nur wenige MCUs hardwaremässig. Dafür musste ich >> dann auf STM umsteigen. > > Kein Problem für die AVRs. > Ein ATtiny2313 hätte völlig gereicht: > • Supports Serial Frames with 5, 6, 7, 8, or 9 Data Bits and 1 or 2 Stop > Bits > • Odd or Even Parity Generation and Parity Check Supported by Hardware In der Tat können gerade die STMs kein 9 Bit + Parity. AVRs aber schon. Die Aussage von Daniel ist daher unverständlich. Ich nutze normalerweise nur noch STM, aber für eine spezielle Anwendung wo ich 9 Bit + Parity brauche, nehme ich einen AVR her. Es gibt quasi keinen STM der da kann. Nur entweder 9 Bit ODER Parity.
:
Bearbeitet durch User
Daniel A. schrieb: > Bei der STM32IDE und deren TouchGFX Framework kommt man aufgrund der > häufigen Updates und Versionsproblemen aber ins Verzweifeln. Ja, das ist ein häufiges Problem von Wizzards, die ändern sich schneller, als man gucken kann. Und sind dann oft inkompatibel zu alten Projekten. Oft muß man aber Projekte über viele Jahre pflegen und erweitern.
Frank K. schrieb: > Die klassischen AVRs haben aus heutiger Sicht Schwächen. Sie haben > relativ wenige und relativ dumme Peripherieeinheiten, sie haben nicht so > gute Debugmöglichkeiten, man kann sich durch fehlerhafte Programmierung > aussperren, und sie laufen nur bei 5V mit ihrer vollen Taktrate. Es gibt > moderne AVRs, die diese Schwächen nicht mehr haben, und es gibt Die Aussagen treffen auf alle modernen AVRs nicht zu. Schaue Dir mal die Tiny0,1,2 Reihe an. > Alternativen: PIC24, dsPIC33 und PIC32 sind recht angenehm und haben > deutlich mehr Leistung, und ARM-basierte Controller gibts von dutzenden 32 Bit PIC ist ja wohl eine Sackgasse. > Herstellern, wenn auch in der Regel nicht in bastelfreundlichen > Gehäusen. DIP ist ziemlich tot, egal welcher controller drin steckt.
Blablub schrieb: > warum wir seit 52 Jahren niemanden mehr zum Mond > geschickt haben. Das hat andere gründe. Kubrick ist tot.
Pepe T. schrieb: > Blablub schrieb: >> warum wir seit 52 Jahren niemanden mehr zum Mond >> geschickt haben. > > Das hat andere gründe. Kubrick ist tot. Und wieso können die nicht den Typen anheuern der auch die ganze ISS Videos fälscht?
:
Bearbeitet durch User
Cyblord -. schrieb: > Und wieso können die nicht den Typen anheuern der auch die ganze ISS > Videos fälscht? Glaub nicht dass die ISS videos gefälscht sind. Die ISS ist innerhalb des strahlungsgürtels.
norton schrieb: > DIP ist ziemlich tot, egal welcher controller drin steckt. Es gibt sie noch, sie werden noch produziert, und sie sind zum Experimentieren sehr praktisch.
Stefan ⛄ F. schrieb: > norton schrieb: >> DIP ist ziemlich tot, egal welcher controller drin steckt. > > Es gibt sie noch, sie werden noch produziert, und sie sind zum > Experimentieren sehr praktisch. Warum? Entweder gleich ein PCB designen (Kosten marginal) oder ein Adaptberboard nutzten. Ich vermisse THT nicht.
norton schrieb: > Warum? Entweder gleich ein PCB designen (Kosten marginal) oder ein > Adaptberboard nutzten. Ich vermisse THT nicht. Eben. In Zeiten wo ich in China für quasi umme sogar vierlagige Leiterplatten bekomme plage ich mich nicht mehr mit THT und Basteleien rum. Da wird eine Leiterplatte designt und kurz bestellt. Bis diese da ist, wird aufm Devboard tatsächlich im fliegenden Aufbau das wichtigste geprüft. Setzt natürlich voraus, dass man die Hardware schon fertig machen kann, aber selbst für einen Prototyp mache ich keinen fliegenden Aufbau mehr.
Ihr seid ja auch alle Topexperten und Vollprofis... Aber jemand, der einsteigt, ist doch froh um jedes bißchen Komplexität, die er nicht hat. Dann ist was mit Beinchen zum Anfassen sicher reizvoller.
Cyblord -. schrieb: > Aber mach mal einen TCP/IP Stack damit. Oder implementiere sonst ein > komplexeres Protokoll. [x] TCP/IP-Stack in ASM geschrieben. [x] 64-Bit Orthodrome auf 8051 ASM berechnen lassen. [x] 64k ROM komplett mit ASM gefüllt. Und ich komme gut klar damit. Ich spreche die Sprache, die der Controller spricht und muss nicht mit einer Fremdsprache über einem Dolmetscher mit dem Chip sprechen. Und ich muss meinen fremdsprachigen Text nicht teilweise umformulieren, wenn der Dolmetscher abgelöst wird. (In der Firma bin ich gerade damit beschäftigt Code für C18 auf XC8 (PIC) anzupassen ... danke!) Auf ordentlich abstrahierten Systemen finde ich es richtig eine Hochsprache zu nutzen. Aber eine Ebene über der Hardware, wo ich mit Bits klappere und diese hin und her schiebe oder vielleicht sogar taktgenau reagieren muss ist für mich ASM das Mittel der Wahl. Und bevor das Geschrei gleich wieder los geht: Jeder soll die Sprache benutzen, mit der er glücklich wird! So mache ich das auch. Und ich werde mich hüten, anderen zu sagen, was für sie das Beste ist, nur weil es für mich das Beste ist (oder ich das zumindest glaube). Vor allem weil dies für andere ja auch gar nicht stimmen muss. Ich käme ja auch nicht auf die Idee, jemandem die Farbe meines Auto als die beste Farbe für sein Auto zu empfehlen. Gruß Jobst
Jobst M. schrieb: > [x] TCP/IP-Stack in ASM geschrieben. > [x] 64-Bit Orthodrome auf 8051 ASM berechnen lassen. > [x] 64k ROM komplett mit ASM gefüllt. und, hast du Kollegen die das nachvollziehen, verstehen und warten können? Glückwunsch wenn ja. Ansonsten bist du unbeliebt weil du meinst unersetzlich zu sein. Oder Nerd der das Wissen ohne viel Aufsehen mit ins Grab nimmt.
Beitrag #6979138 wurde von einem Moderator gelöscht.
Beitrag #6979170 wurde von einem Moderator gelöscht.
Ralf schrieb im Beitrag #6979170: > Damit können die sogenannten Vollprofis hier > aber nicht ihr Ego befriedigen. Korrekt. Ich Nachhinein muss ich zugeben, dass meine Ablehnung von Arduino genau darauf beruhte.
Ralf schrieb im Beitrag #6979170: > Damit können die sogenannten Vollprofis hier aber nicht ihr Ego > befriedigen. Stefan ⛄ F. schrieb: > Korrekt. Sehe ich auch so. Sonnst würde nicht immer sofort "scharf geschossen" wenn ich(oder auch andere) als Tipp den relativ einfach handhabenden MSP430 erwähne, der in der Regel fast jeden Job erledigen kann und auch noch ab ca 30 Cent zu haben ist!
:
Bearbeitet durch User
Jobst M. schrieb: > Jeder soll die Sprache > benutzen, mit der er glücklich wird! DAS ist für mich der, ich sag mal, wichtigste Satz in der ganzen Diskussion und dem kann man nur voll und ganz zustimmen.
Johannes S. schrieb: > und, hast du Kollegen die das nachvollziehen, verstehen und warten > können? Wir hatten mal einen Kollegen, der den ganzen Tag lang nur in Erlang programmiert hat. Nach seinem Ausscheiden wurden alles nach /dev/null verschoben. Kein anderer kannte sich damit aus bzw. wollte es lernen.
Hi Johannes S. schrieb: > und, hast du Kollegen die das nachvollziehen, verstehen und warten > können? > Glückwunsch wenn ja. Ansonsten bist du unbeliebt weil du meinst > unersetzlich zu sein. Oder Nerd der das Wissen ohne viel Aufsehen mit > ins Grab nimmt. Nun ja, ein gut dokumentieres Assembler Programm ist genau so gut, wie ein gut dokumentiertes C Programm und wenn jemand kein Assembler versteht, kann er damit auch nicht zurecht kommen, genauso wenig wie einer, der C nicht versteht und diese Programme auch nicht pflegen kann. Also, wem hilft hier die Fachsimpelei um Sprachen? Ein Profi braucht das nicht und ein Anfänger braucht Unterstützung und keine unendlichen Diskussionen, welche Bausteine tot oder welche Sprache sinnvoll ist. Anfangs hatte ich die Frage nach dem Alter und der beruflichen Ausrichtung gestellt. Diese hat der TO noch nicht beantwortet, also ist diese Diskussion schon wieder ein Spielplatz für Pseudoprofis? Gruß oldmax
Beitrag #6979263 wurde von einem Moderator gelöscht.
Beitrag #6979271 wurde von einem Moderator gelöscht.
Mida M. schrieb im Beitrag #6979263: > Wen interessiert von denen schon das > die Arbeit schon ein kleiner AVR mit ein paar Zeilen simplen Assemblers > täte? Wann tut es das denn? Die Anfänger von heute lassen keine LED blinken. Schau doch mal welche "Projekte" da für den Anfang angepeilt werden. Auf ASM zu gehen weil man kleine Blinky Programme damit auch machen kann, macht halt keinen Sinn.
Cyblord -. schrieb: > Auf ASM zu gehen weil man kleine Blinky Programme damit auch machen > kann, macht halt keinen Sinn. Damit geht natürlich weitaus mehr! Und das reicht vielleicht längst aus? Wir sprechen hier von AVRs programmieren, bitte nicht vergessen.
Martin V. schrieb: > Nun ja, ein gut dokumentieres Assembler Programm ist genau so gut, wie > ein gut dokumentiertes C Programm Nö, da ist ein riesen Unterschied. Wenn Du die Familie wechselst, muß Du im C-Programm nur die wenigen Hardwarezugriffe (Pins, ADC, Timer usw.) anpassen. Vorzugsweise hat man die schon in extra Funktionen separiert. Alles andere (Abläufe, Algorithmen usw.) bleibt unverändert und wird nur neu compiliert. Sehr schön kann man das sehen, wenn man z.B. vom Arduino Nano zum Arduino Due wechselt, da sind sogar die Hardwarelibs kompatibel. Man muß eigentlich nichts neu machen. In Assembler kannst Du getrost alles wegschmeißen und nochmal ganz von vorne anfangen. Nur die Programmbeschreibungen und Kommentare kannst Du übernehmen.
Beitrag #6979321 wurde von einem Moderator gelöscht.
Hi Cyblord -. schrieb: > Martin V. schrieb: > >> Assembler, mag er noch so verpönt sein, ist entgegen vieler Behauptungen >> gar nicht so schwer > > Nicht um eine LED blinken zu lassen. > Auch nicht für einfache Steuerungsaufgaben. > Aber mach mal einen TCP/IP Stack damit. Oder implementiere sonst ein > komplexeres Protokoll. Wer sagt denn, daß ein Anfänger gleich mit den komplizierten Aufgaben einsteigt. Ich würde mich auch sehr schwer tun, wenn ich in Assembler mathematische Aufgaben lösen müsste, die über die vier Grundrechenarten hinausgingen. Aber alles ist erlernbar, selbst solche Aufgaben und der Controller oder Prozessor arbeitet eh nur binär. Hochsprachen bieten aber diesbezüglich ausgefeilte Routinen. Also, glaube nicht, daß Profis nicht wissen, was sie einsetzen, um ihre Aufgaben zu lösen. Hier haben wir eine Anfängerfrage und der Fragesteller sollte allerdings schon wissen, wo sein Schwerpunkt liegt. Software allein ist schon so ein weitreichender Gebiet. Da geht es um analytisches Denken, um strukturierte Vorgehensweisen. Viele denken, ach programmieren ist doch gar nicht schwer, es braucht doch nur gesagt werden, was ich vom Controller will und dann tut der das schon. Aber, und das wissen alle, die schon Mal ein Programm geschrieben haben, der Controller oder Prozessor denkt anders. Und dann muss man auch wissen, der Fehler ist immer vor der Tastatur und programmieren ist mit einem langen und zeitraubenden Lernprozess verbunden. Auch Hardware ist nicht mal einfach so zusammen gesteckt. Ein wenig Grundkenntnis ist schon erforderlich. Daher bringt es gar nichts, wenn über Bauteile oder Sprachen diskutiert wird. Der TO hat gezielt nach "alten" AVR gefragt, also macht es keinen Sinn über hochmoderne Pi oder STM zu diskutieren. Klar kann man hinweisen, aber damit ist ja auch schon gut. Gruß oldmax
Kurt F. schrieb im Beitrag #6979321: > Und wenn man den AVR wechseln müsste läufts > auf dasselbe wie bei C hinaus: Nur Hardware-Zugriffe (veränderte > Peripherie) sind anzupassen. Der Arduino Due ist aber kein AVR, sondern ein SAM3X8E ARM Cortex-M3. Die Arduino Entwickler haben da schon gute Arbeit geleistet, die Hardware zu abstrahieren. Hut ab!
:
Wiederhergestellt durch Admin
Hi Cyblord -. schrieb: > Schau doch mal welche "Projekte" da für den Anfang angepeilt werden. Ja, und dann frag doch Mal nach ein oder zwei Jahren, was daraus wurde. Gruß oldmax
Ich weis nicht was ihr euch das Leben schwer macht. Wenn man in Assembler Programmiert kann man ja Libraries und Macros verwenden, die einem die Math. abnehmen? Wenn man in einer Hochsprache programmiert, nimmt diese ja genau genommen auch Makros und Libraries und setzt die dann zusammen. Auch "C" ist keine KI bzw. Echte Intelligenz.
Wer heutzutage noch ganze Libs oder Projekte in Assembler neu anfängt hat es nicht kapiert. Egal, wie sehr man Assembler verteidigt. Es gibt nicht ohne Grund C und Konsorten. Es wurden hier schon genug Beispiele genannt. Und nein, Assembler ist auch bei guter Formatierung einfach unübersichtlich und schlecht wartbar.
Ben S. schrieb: > Egal, wie sehr man Assembler verteidigt. Wie ich immer sage, jede Programmiersprache hat ihre Daseinsberechtigung. Verteidigen muss man da nix, es ist wie es ist.Aber wenn sich jemand für Assembler entscheidet, dann muss er sich ja nicht das Leben unnötig schwer machen, für dass gibt es Makros und Libraris. Genau so wie ich niemals auf die Idee kommen würde für eine Blinkende LED ein "C" Programm zu schreiben, wenn ich das mit 3 Zeilen Assembler schaffe ;-) Genau so Würde ich kein Datenbankprogramm in Assembler schreiben. das wäre in etwa so wie wenn ich mit einer SPS zum Starkstromtechniker gehe um sie zu Programmieren zu lassen, oder zum Programmierer gehe um ein Drehstrommotor Phasenrichtig anhängen zu lassen. Sicher würden es beide wahrscheinlich irgend wie schaffen aber der Overhead ist zu Groß....
Patrick L. schrieb: > Genau so wie ich niemals auf die Idee kommen würde für eine Blinkende > LED ein "C" Programm zu schreiben, wenn ich das mit 3 Zeilen Assembler > schaffe ;-) Die 3 Zeilen zeig mir mal. In C kann man ganze Programme in einer Zeile schreiben, da ein Zeilenumbruch kein Syntaxelement ist. Selbst der abschließende Zeilenumbruch kann entfallen, gibt allerdings ne Compilerwarnung.
Patrick L. schrieb: > Genau so wie ich niemals auf die Idee kommen würde für eine Blinkende > LED ein "C" Programm zu schreiben, wenn ich das mit 3 Zeilen Assembler > schaffe ;-) Natürlich mache ich auch das in C. Und in C könnten das sogar fast drei Zeilen werden. In Assembler mitnichten. Und dann nimmst du morgen einen anderen Controller und dein Led Blinky geht nimmer. Oder in drei Monaten schaut sich ein Kollege deine Blinky an und schreibt es lieber in C neu.
:
Bearbeitet durch User
Ben S. schrieb: > In Assembler mitnichten.
1 | bis.b #0x01,&P1DIR ;P1.0 (LED1) output |
2 | xor.b #0x01,&P1OUT ;P1.0 (LED1) Toggle |
3 | BR $ ; Waitt of Watchdog Reset |
Und das LED Blinkt mit der Devault Watchdog und Lo-Osc. frequenz...
:
Bearbeitet durch User
Patrick L. schrieb: > Und das LED Blinkt mit der Devault Watchdog und Lo-Osc. frequenz... Und jetzt packe da mal eine sinnvolle Zeitkonstante rein. Mit Blinky meinen wir doch sicherlich alle, dass die LED in einer vorgegebenen Zeit blinkt oder?
:
Bearbeitet durch User
Patrick L. schrieb: > Ben S. schrieb: >> In Assembler mitnichten. > >
1 | > bis.b #0x01,&P1DIR ;P1.0 (LED1) output |
2 | > xor.b #0x01,&P1OUT ;P1.0 (LED1) Toggle |
3 | > BR $ ; Waitt of Watchdog Reset |
4 | > |
> > Und das LED Blinkt mit der Devault Watchdog und Lo-Osc. frequenz... Blinken durch Reset. Ist DAS die hohe Qualität welche uns die ASM Jünger versprechen?
Sicher wenn's weiter nix ist? Geht auch mit 3 Zeilen aber ich will zuerst dein "C" Sehen so kannst du ja nur von mir Abkupfern ;-)
Patrick L. schrieb: > Sicher wenn's weiter nix ist? > Geht auch mit 3 Zeilen aber ich will zuerst dein "C" Sehen so kannst du > ja nur von mir Abkupfern ;-) Oh sorry. Der C vs ASM Schwanzvergleich wird mit mir nicht stattfinden. Ich kämpfe auch ungern gegen unbewaffnete. Nur dass DER Code da oben Mumpitz ist, muss nicht weiter diskutiert werden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Blinken durch Reset. Ist DAS die hohe Qualität welche uns die ASM Jünger > versprechen? Keine Ahnung bin kein Jünger ;-) Cyblord -. schrieb: > Oh sorry. Der C vs ASM Schwanzvergleich wird mit mir nicht stattfinden. Sorry du hast ja recht. Lies mich mal wieder Hinreißen, Normalerweise Ignoriere ich solche Sachen. Werde darauf nicht mehr Antworten. Es ging um AVR Wahl und nicht um Code in dem Thread. Alsso JA Mit AVR Anzufangen ist nicht schlecht, obwohl es nicht der µC meiner Wahl wäre, aber einfach weil ich schon auf andere einfachst µC wie, 8048, 8051, 6502, usw. usw. eingefahren bin.
:
Bearbeitet durch User
Patrick L. schrieb: > Sicher wenn's weiter nix ist? > Geht auch mit 3 Zeilen aber ich will zuerst dein "C" Sehen so kannst du > ja nur von mir Abkupfern ;-) Hm, auf dem XMega wäre das mit unbestimmter Frequenz (ich habe nicht geprüft, ob die Register richtig geschrieben sind):
1 | int main(){PORTA->DIR |= 1; while(1) PORTA->DIRTGL |= 1; return 0;} |
Wobei ich natürlich den Vergleich mit Blinky äußerst daneben finde. Denn sobald auch nur etwas Komplexität ins Programm kommt wird Assembler absolut unleserlich und der Umfang explodiert. Ich weiß, stimmt nicht - alles ganz übersichtlioch und wartungsfrei und so. Wir alle wissen, wo man noch Assembler einsetzt (und sonst nirgends): Zur punktuellen Optimierung beispielsweise.
:
Bearbeitet durch User
Patrick L. schrieb: > bis.b #0x01,&P1DIR ;P1.0 (LED1) output > xor.b #0x01,&P1OUT ;P1.0 (LED1) Toggle > BR $ ; Waitt of Watchdog Reset Beim AVR geht das nicht, da setzt das Watchdog-Reset alle Port-Register zurück, da toggled also nichts. Welcher seltsame MC ist das denn, wo der Watchdog kein richtiges Reset ausführt? Man könnte den AVR hinter dem Toggle durch den leeren Flash durchlaufen lassen. Mit dem ATtiny85 sind das etwa 4000 NOPs (0xFFFF), d.h. 2Hz Blinken auf interne 16kHz gefust.
:
Bearbeitet durch User
Johannes S. schrieb: > Jobst M. schrieb: >> [x] TCP/IP-Stack in ASM geschrieben. >> [x] 64-Bit Orthodrome auf 8051 ASM berechnen lassen. >> [x] 64k ROM komplett mit ASM gefüllt. > > und, hast du Kollegen die das nachvollziehen, verstehen und warten > können? > Glückwunsch wenn ja. Ansonsten bist du unbeliebt weil du meinst > unersetzlich zu sein. Oder Nerd der das Wissen ohne viel Aufsehen mit > ins Grab nimmt. Wir kommen gut miteinander klar und haben viel Spaß bei der Arbeit. Mein Code ist IMMER, unabhängig von der Sprache, umfangreich beschrieben. Ich habe ja keine Lust darauf aus dem Urlaub zurückgeholt zu werden. Die drei Beispiele müssen die Kollegen aber nicht nachvollziehen können, da sie aus anderen Projekten sind. Dennoch wird vermutlich jeder damit klar kommen der die Sprache lesen kann. M. K. schrieb: > Jobst M. schrieb: >> Jeder soll die Sprache >> benutzen, mit der er glücklich wird! > > DAS ist für mich der, ich sag mal, wichtigste Satz in der ganzen > Diskussion und dem kann man nur voll und ganz zustimmen. Dennoch geht das Getrommele wieder los: "Meine Sprache ist aber trotzdem besser für Dich! ..." Peter D. schrieb: > Nö, da ist ein riesen Unterschied. > Wenn Du die Familie wechselst, muß Du im C-Programm nur die wenigen > Hardwarezugriffe (Pins, ADC, Timer usw.) anpassen. Man sollte meinen, dass das so ist, ist es aber häufig nicht. Die Praxiserfahrung zeigt mir, dass die Wirklichkeit anders aussieht. > Vorzugsweise hat man die schon in extra Funktionen separiert. Das ist in ASM genau so. > Sehr schön kann man das sehen, wenn man z.B. vom Arduino Nano zum > Arduino Due wechselt, da sind sogar die Hardwarelibs kompatibel. Man muß > eigentlich nichts neu machen. Wie schon gesagt: Jobst M. schrieb: > Auf ordentlich abstrahierten Systemen finde ich es richtig eine > Hochsprache zu nutzen. > In Assembler kannst Du getrost alles wegschmeißen und nochmal ganz von > vorne anfangen. Sehe ich nicht ganz so drastisch. Ich entferne Macros und Funktionen für die alte Plattform und hänge diese für die neue ein. Dann schnappe ich mir den Rest. Befehl für Befehl findet man in den meisten Fällen ein Pendant auf der Zielplattform. Evtl. kann man automatische Ersetzung benutzen. Natürlich ist das etwas Arbeit, aber man muss die Funktionalität nicht neu erfinden. Ben S. schrieb: > Und nein, Assembler ist > auch bei guter Formatierung einfach unübersichtlich und schlecht > wartbar. Kannst Du akzeptieren, dass das nicht für alle Menschen zutrifft? Patrick L. schrieb: > wenn ich das mit 3 Zeilen Assembler schaffe ;-) **Facepalm* Gruß Jobst
>1 | > bis.b #0x01,&P1DIR ;P1.0 (LED1) output |
2 | > xor.b #0x01,&P1OUT ;P1.0 (LED1) Toggle |
3 | > BR $ ; Waitt of Watchdog Reset |
4 | > |
Hier sehen wir den wunderschönen Unterschied zwischen Hochsprache und Assembler. In Hochsprachen hat sich das Konzept des "Clean Code" halbwegs durchgesetzt. Beispiel: Wenn ich eine LED toggeln will, schreibe ich Led.toggle(); Da braucht es keinen Komentar, welcher mir die Welt erlärt. Das "Wie die LED getoggelt wird?" kann ich beruhigt einer tieferen und austauschbaren Schicht überlassen.
Minus M. schrieb: > In Hochsprachen hat sich das Konzept des "Clean Code" halbwegs > durchgesetzt. Richtig. Und ich würde sogar so weit gehen zu behaupten, dass mit ASM das Konzept des "Clean Code" gar nicht durchhaltbar ist. Ich kann mir einfach keinen TCP/IP Stack in ASM vorstellen, der auch nur halbwegs übersichtlich und größtenteils Selbst-Dokumentierend ist oder der irgendwelchen Clean-Code Prinzipien genügen kann.
:
Bearbeitet durch User
Jobst M. schrieb: > Wir kommen gut miteinander klar und haben viel Spaß bei der Arbeit. Na dann war ich wohl zu pessimistisch, passiert schonmal nach ner Flasche Vino :) > Mein Code ist IMMER, unabhängig von der Sprache, umfangreich > beschrieben. Ich habe ja keine Lust darauf aus dem Urlaub zurückgeholt > zu werden. Das ist auch löblich, das kenne ich auch anders, sogar von eigenem Code :)) Bis zu welchem Level geht denn der IP Stack? Spätestens bei HTTP hört der Spaß doch auf, und für das S in IoT wird es richtig unangenehm. In C ist ein IP Stack schon aufwändig genug, den Code von z.B. lwIP guckt sich auch nicht jeder freiwillig an. Schon mit der Optimierung der Einstellungen hat man reichlich zu tun. Und alleine so TCP Anwendungen machen für mich die AVR nicht mehr lohnenswert. Zum Einstieg ok weil weniger komplex, aber alleine das einfachere debuggen der CM war für mich Grund genug das AVR Zeitalter zu beenden.
Minus M. schrieb: >>
1 | >> bis.b #0x01,&P1DIR ;P1.0 (LED1) output |
2 | >> xor.b #0x01,&P1OUT ;P1.0 (LED1) Toggle |
3 | >> BR $ ; Waitt of Watchdog Reset |
4 | >> |
> > > Hier sehen wir den wunderschönen Unterschied zwischen Hochsprache und > Assembler. Nein. Hier sehen wir nur jemanden, der entweder keinen guten Code erzeugen kann, oder die schwachsinnige Herausforderung mit 3 Zeilen Code wörtlich genommen hat. In Assembler geht das so:
1 | 0: |
2 | rcall led_on |
3 | |
4 | ldi r16,50 |
5 | rcall delayms |
6 | |
7 | rcall led_off |
8 | |
9 | ldi r16,50 |
10 | rcall delayms |
11 | |
12 | rjmp 0b |
Alternativ, wenn es weniger Zeilen einnehmen soll:
1 | 0: |
2 | rcall led_on |
3 | ldi r16,50 $ rcall delayms |
4 | rcall led_off |
5 | ldi r16,50 $ rcall delayms |
6 | rjmp 0b |
Ob man die Parameter einer Funktion in die selbe Zeile schreiben will oder nicht, ist Geschmackssache.
:
Bearbeitet durch User
Christian S. schrieb: > In Assembler geht das so: > rcall led_on Es gibt in ASM keinen Mechanismius, welcher den rcall weg optimieren kann. Damit ist der "Speed Vorteil" von ASM verloren und an C/C++ gegangen. Widerspricht so dem Chor der "ASM ist besser" Priester.
Minus M. schrieb: > Christian S. schrieb: >> In Assembler geht das so: >> rcall led_on > > Es gibt in ASM keinen Mechanismius, welcher den rcall weg optimieren > kann. > Damit ist der "Speed Vorteil" von ASM verloren und an C/C++ gegangen. > Widerspricht so dem Chor der "ASM ist besser" Priester. Kurzsichtiger Blödsinn. Warum soll ich da drei Takte sparen, die ich dann im delayms sowieso verbrate? So könnte man sogar in der Funktion noch einen Log-Eintrag generieren, falls die LED z.B. eine Error-LED ist.
Hi Braucht ihr diese unsinnige Selbstdarstellung? Der TO ist ANÄNGER ! Robert schrieb: > Hallo! > Ich habe neulich von einem Bekannten sämtliche Bücher geschenkt > bekommen, da ich ihm gesagt habe das ich mich für Elektronik & > Mikrocontroller interessiere. Er hat bisher weder etwas über sein Alter oder sonstwas über sich ausgesagt. Wenn er ein Troll ist, dann tut ihr genau das, was er will. Ist er das, wofür ich ihn halte, habt ihr ihn ganz wuschig gemacht mit euren Dreizeilencode und TCP Stacks. Mann, ihr müßt es aber wirklich nötig haben. Werdet ihr auf eurem Arbeitsplatz nicht mehr gelobt? Das ist schade, aber so ist der Job, dafür gibt's, auch wenn's frustrierend ist, Kohle. Dem TO kann ich noch ein wenig zur Orientierung mitgeben. Zugegeben, VB und Assembler sind nicht grad erste Wahl, können aber durchaus Interesse wecken, wenn man Schritt für Schritt selbst ein paar erklärte Experimente damit machen kann. Obwohl ich weiß, das der TO schon Lektüre in ausreichender Form vorliegen hat, denke ich ein Blick in den Link kann sich trotzdem lohnen. https://www.makerconnect.de/index.php?threads/ver%C3%B6ffentlichung-pc-und-%C2%B5c-programmieren-in-vb-und-assembler-lehrbuch.4252/ Gruß oldmax
:
Bearbeitet durch User
Hier ist ein Blinky in Micropython
1 | from machine import Pin |
2 | import time |
3 | |
4 | pin = Pin(25, Pin.OUT) |
5 | |
6 | while True: |
7 | pin.toggle() |
8 | time.sleep_ms(150) |
Johannes S. schrieb: > Bis zu welchem Level geht denn der IP Stack? Spätestens bei HTTP hört > der Spaß doch auf, und für das S in IoT wird es richtig unangenehm. > In C ist ein IP Stack schon aufwändig genug, den Code von z.B. lwIP > guckt sich auch nicht jeder freiwillig an. Schon mit der Optimierung der > Einstellungen hat man reichlich zu tun. HTTP (Server oder Client) ist ja schon eine Anwendung selbst und gehört nicht mehr zum Stack. Dieser endet genau an dieser Schnittstelle. Tatsächlich ist Netzwerk auf AVR nicht unbedingt sexy, brauchte ich aber hierfür, also habe ich das mal gemacht (Auch weil ich das einfach mal selbst gemacht haben wollte). Der Stack kann ICMP (nur Ping, also Echo request und Echo reply) und TCP. Die TCP-Daten (für einen bestimmten Port) werden von einem Kommandointerpreter, welcher sonst auch an die UART geknotet werden kann, entgegen genommen und beantwortet. Dem könnte ich jetzt noch ein GET-Kommando beibringen und er würde einen HTML-String zurück liefern können. Brauchte ich aber nicht. "Telnet" reicht. Letztlich hat man einen Speicherbereich, eine Struktur, in die Daten eingetragen werden bzw. beim Empfang ausgelesen werden. Dazu gibt es Zeiger, wo man was findet. Eigentlich ist bis auf die Nutzdatenlänge alles recht statisch. Und gar nicht so komplex, finde ich. Mehrere Verbindungen kann man bei dem Stack allerdings nicht aufbauen. Und ja: Für andere Netzwerkanwendungen nutze ich größere Controller und einen fertigen IP-Stack. Aber ich wollte das einfach mal selbst gemacht haben. Martin V. schrieb: > Werdet ihr auf eurem Arbeitsplatz nicht mehr gelobt? Das > ist schade, aber so ist der Job, dafür gibt's, auch wenn's frustrierend > ist, Kohle. Aufgrund von Corona wird nicht mehr gekuschelt! :-D / :-( Wenn es angebracht ist, gibt es auch Lob. Die meiste Zeit kann ich tun, was ich gerne mache. Und ich finde es nicht frustrierend dafür auch noch Kohle zu bekommen. Ist das bei Dir anders? Dann sprich doch mal mit Deinem Arbeitgeber, dass Dich die Kohle frustriert. Er wird dort sicherlich gerne etwas machen! :-D Gruß Jobst
Hi Sorry, aber ich hab mich schon vor 6Jahren von meinem Arbeitgeber getrennt 😀 Gruß oldmax
Christian S. schrieb: > Warum soll ich da drei Takte sparen, die ich > dann im delayms sowieso verbrate? Guten Tag, Herr Unsinnig und Kurzsichtig. Es ist nett, das sie eingestehen, dass übersichtliche ASM Programme auf Kosten der Geschwindigkeit zu erstellen sind. Merke: Warteschleifen sind als pro Argument, für ASM, kaum tragfähig. Mir scheint, Herr Kurzsichtig, dass sie sich da irgedwie verrannt haben. Auch wenn sie sich das nicht vorstellen können, Herr Unsinnig, ein klein wenig Erfahrung mit Asm ist auch mein eigen. Auch ein paar Kriterien sind mir bewusst: a. Wenn um jeden Taktzyklus gegeizt werden muss. b. Ebenso wenn jedes Programmbyte zuviel zum KO Kriterium wird. c. Man dauerhaft innerhalb einer Prozessorfamilie arbeitet. Schönheit, Wartbarkeit, Portabilität, automatische Optimierung, Definitionen von Datentypen, Abstaktionen und vieles Weitere, gehört einfach nicht in den Kernkompetenzbereich von Assemblern und ihren Anwendern. Bei einem ansonsten kleinen und doofen Blinkprogramm macht es überhaupt keinen Unterschied, ob man es in ASM, C, C++ oder was für einer Sprache abfasst. Einzig in der Lesbarkeit unterscheidet es sich. Hier mal ein Beispiel für einen (schnellen) "Blinker" in C++ für 16MHz ATMega328P
1 | #include <CombiePin.h> |
2 | |
3 | // Arduino UNO Pin 13 == LED_BUILTIN == PB5
|
4 | using BuiltInLed = Combie::Pin::OutputPin<LED_BUILTIN>; |
5 | |
6 | BuiltInLed led; |
7 | |
8 | int main() |
9 | {
|
10 | led.init(); |
11 | for(;;) |
12 | {
|
13 | led.toggle(); |
14 | }
|
15 | }
|
Dazu hier ein Auszug aus dem Kompilat(nur die main).
1 | 00000080 <main>: |
2 | 80: 25 9a sbi 0x04, 5 ; 4 |
3 | 82: 80 e2 ldi r24, 0x20 ; 32 |
4 | 84: 83 b9 out 0x03, r24 ; 3 |
5 | 86: fe cf rjmp .-4 ; 0x84 <main+0x4> |
Jetzt zeigen sie bitte, Herr Assemblerspezi, wie da noch eine Beschleunigung möglich sein soll... Ich sage: Ist es nicht. Damit ist, zumindest an der Stelle, mit ASM kein Blumentopf zu gewinnen. -------- Das Grundthema des Threads ist, "Wie fange ich mit der µC Programmiererei an?" Dazu habe ich eine klare Meinung/Empfehlung! 1. Anfangen mit C++ (wenn es nicht anders geht, auch mit C) 2. Ruhig mit kleinen µC, wie die ATMegas Wobei es keinen Schaden mit sich bringt, auch Asm mal zu üben, und sei es auch nur um festzustellen, dass dieses wenig Freude bereitet. In Sachen µC verstehen, ist das durchaus hilfreich.
:
Bearbeitet durch User
Minus M. schrieb: > Dazu hier ein Auszug aus dem Kompilat(nur die main). >
1 | > 00000080 <main>: |
2 | > 80: 25 9a sbi 0x04, 5 ; 4 |
3 | > 82: 80 e2 ldi r24, 0x20 ; 32 |
4 | > 84: 83 b9 out 0x03, r24 ; 3 |
5 | > 86: fe cf rjmp .-4 ; 0x84 <main+0x4> |
6 | >
|
> > > Jetzt zeigen sie bitte, Herr Assemblerspezi, wie da noch eine > Beschleunigung möglich sein soll... > Ich sage: Ist es nicht. Weil du keine Ahnung hast. Ein typischer C/C++-Only-Krüppel, der das Mantra der Fetischisten glaubt, dass der Compiler schon alles optimal macht. Nein, das tut er nicht. Die Schleife deines "tollen Compilers" umfasst satte 6 Takte. Ein Assemblerprogrammierer kann dieselbe Funktionalität in drei Takten umsetzen. Also 200% Performance im Vergleich zum lausigen Compiler. Jedenfalls auf allen halbwegs "aktuellen" AVR8. sieht dann prinzipiell so aus: ldi Reg,Maske loop: out PINx,Reg rjmp loop Für die ganz alten, die kein Pin-Togglen via PINx unterstützen, wären es vier Takte. Also immerhin auch noch 150% Performance bezüglich des Ergebnisses des lausigen Compilers. sieht dann prinzipiell so aus: ldi Reg1,Maske ldi Reg2,0 loop: out PORTx,Reg1 out PORTx,Reg2 rjmp loop Naja, die Fetischisten argumentieren nun gewöhnlich in höchster Not an dieser Stelle, dass es bei komplexeren Sachen besser würde. Nein, wird es nicht. Höchstens im Vergleich zu einem Asm-Anfänger, nicht aber im Vergleich zu jemandem, der die Maschine wirklich beherrscht, also einem echten erfahrenen Asm-Programmierer. Der kennt auch (mindestens) alle Tricks der Compilerbauer. Er ist aber obendrein natürlich auch schwer im Vorteil, denn er ist nicht gezwungen, seine Optimierungen in hochkomplexe Macros für den allgemeinen Fall in den Kontext einer festgelegten Struktur zu giessen.
Ob S. schrieb: > Die Schleife deines "tollen Compilers" umfasst satte 6 Takte. Ein > Assemblerprogrammierer kann dieselbe Funktionalität in drei Takten > umsetzen. Also 200% Performance im Vergleich zum lausigen Compiler. > Jedenfalls auf allen halbwegs "aktuellen" AVR8. > > sieht dann prinzipiell so aus: > > ldi Reg,Maske > loop: > out PINx,Reg > rjmp loop Mein Sohn! Du behauptest hier, dass mein out mehr Takte in Anspruch nimmt, als dein out. Gleiches gilt für den rjmp. Das kann nicht dein Ernst sein. Sorry, aber so dermaßen blöd kannst du gar nicht sein, wie du dich hier präsentierst. Ich bitte dich: Überprüfe deine Aussagen nochmal. Gehe in dich, und bereue. Danach: Leiste Abbitte!
:
Bearbeitet durch User
Hi Seid ihr jetzt total abgedreht? Soll das etwa dem TO oder sonst wem eine Hilfe sein? Also, wenn das eine Folge von Corona ist, dann werden wir wohl alle früher oder später auch irre. 😱 Gruß oldmax
Martin V. schrieb: > irre Dem Hochsprachen Fan ist vielleicht der ein oder andere Taktzyklus, oder Byte, egal. (wenn ihm es sich leisten kann) Ist das irre? Der ASM Masochist greift zu offensichtlichen Lügen. Ist das irre?
:
Bearbeitet durch User
Ob S. schrieb: > Die Schleife deines "tollen Compilers" umfasst satte 6 Takte. Vielleicht solltest du den Code besser noch einmal lesen.
Ob S. schrieb: > Für die ganz alten, die kein Pin-Togglen via PINx unterstützen, wären es > vier Takte. Also immerhin auch noch 150% Performance bezüglich des > Ergebnisses des lausigen Compilers. > > sieht dann prinzipiell so aus: > > ldi Reg1,Maske > ldi Reg2,0 > loop: > out PORTx,Reg1 > out PORTx,Reg2 > rjmp loop > > Naja, die Fetischisten argumentieren nun gewöhnlich in höchster Not an > dieser Stelle, dass es bei komplexeren Sachen besser würde. Nein, wird > es nicht. Höchstens im Vergleich zu einem Asm-Anfänger, nicht aber im > Vergleich zu jemandem, der die Maschine wirklich beherrscht, also einem > echten erfahrenen Asm-Programmierer. Der kennt auch (mindestens) alle > Tricks der Compilerbauer. Das habe ich mal überprüft:
1 | #include <CombiePin.h> |
2 | |
3 | // Arduino UNO Pin 13 == LED_BUILTIN ist PB5
|
4 | using Led = Combie::Pin::OutputPin<LED_BUILTIN>; |
5 | |
6 | Led led; |
7 | |
8 | int main() |
9 | {
|
10 | led.init(); |
11 | for(;;) |
12 | {
|
13 | led = 1; |
14 | led = 0; |
15 | }
|
16 | }
|
Resultat, wieder nur die main:
1 | 00000080 <main>: |
2 | 80: 25 9a sbi 0x04, 5 ; 4 |
3 | 82: 2d 9a sbi 0x05, 5 ; 5 |
4 | 84: 2d 98 cbi 0x05, 5 ; 5 |
5 | 86: fd cf rjmp .-6 ; 0x82 <main+0x2> |
Auch hier nix von den, angeblich gewonnenen, 50% zu sehen. Im Gegenteil, das ASM Genie hätte hier sogar 2 Register unnötig verplempert.
:
Bearbeitet durch User
Jetzt müsst Ihr nur noch erklären, wozu sich das Programm sinnvoll einsetzen lässt. Außer um sich hier gegenseitig zu beleidigen. Gruß Jobst
Minus M. schrieb: > Resultat, wieder nur die main: > > 00000080 <main>: > 80: 25 9a sbi 0x04, 5 ; 4 > 82: 2d 9a sbi 0x05, 5 ; 5 > 84: 2d 98 cbi 0x05, 5 ; 5 > 86: fd cf rjmp .-6 ; 0x82 <main+0x2> > > Auch hier nix von den, angeblich gewonnenen, 50% zu sehen. > Im Gegenteil, das ASM Genie hätte hier sogar 2 Register unnötig > verplempert. Und das C++-Genie kann nicht bis 6 zählen ;-) Aber bitte nicht immer noch mehr vom Thema abschweifen. Die Frage war nicht, ob Assembler oder C++, sondern ob AVRs lohnenswert sind.
Yalu X. schrieb: > Aber bitte nicht immer noch mehr vom Thema abschweifen. Die Frage war > nicht, ob Assembler oder C++, sondern ob AVRs lohnenswert sind. Un da würde ich ein Klares JA sagen (Habe ich shon gaaanz weit oben geschrieben. Auch wenn ich nicht mit AVR Arbeite, aber das hat andere Gründe siehe Post: Beitrag "Re: AVR Mikrocontroller Lohnenswert?" 73 55
Hi Da das Grundthema bereits vom TO abgehakt scheint und die Diskussion schon lange nicht mehr mit der Frage beschäftigt, habe ich mich entschlossen, doch noch einmal auf ein Post zu antworten Minus M. schrieb: > Martin V. schrieb: > >> irre > > Dem Hochsprachen Fan ist vielleicht der ein oder andere Taktzyklus, oder > Byte, egal. (wenn ihm es sich leisten kann) > Ist das irre? > Der ASM Masochist greift zu offensichtlichen Lügen. > Ist das irre? Gut, des Lesens scheinst du ja mächtig zu sein aber bedauerlicherweise scheint da nichts zu sein, was dich den Inhalt verstehen läßt. Gruß oldmax
Yalu X. schrieb: > Und das C++-Genie kann nicht bis 6 zählen ;-) Es wäre ja auch zu schön, wenn ich ohne jeden Fehler wäre. Vielleicht gar sogar viel zu langweilig.
:
Bearbeitet durch User
Martin V. schrieb: > Hi > > Da das Grundthema bereits vom TO abgehakt scheint und die Diskussion > schon lange nicht mehr mit der Frage beschäftigt Naja nicht ganz, ich lese alles mit und verfolge die Diskussion mit großem Interesse :D Es weicht zwar von meiner ursprünglichen Frage ab, aber lehrreich sind die Beiträge und Meinungen trotzdem. In der zwischenzeit hat sich was die Hardware angeht einiges geändert, was würdet ihr den für eine Hardware empfehlen? Bei den ISP Programmiergeräten gibt es eine große Auswahl und eine großen Preisunerschied von 10€ - über 100€.. Was lohnt sich da?
Hi Nun Robert, anfangs stellte ich eine Frage nach Alter und beruflicher Ausrichtung. Wenn du mit Elektronik vollständig neu anfängst und von Elektrik auch keine Ahnung hast, muß da schon ein wenig ausgeholt werden. Klar reicht vielleicht ein ISP Programmer für ATiny Idee AtMega, aber um irgendwas zu basteln und auszuprobieren kommen da schnell noch Mal 100€ für Bauteile, Meßgeräte und Werkzeug zusammen. Da ist das Taschengeld schnell alle. Aber auch für Berufstätige ist Anfangs die finanzielle Belastung nicht so eingeplant. Aus diesem Grund hab ich mal ein Buch geschrieben, welches im ersten Teil beschreibt, wie ein Programm entwickelt wird. Dafür hab ich VB gewählt, weil es im Netz kostenlos verfügbar ist und sich sehr gut eignet, um erst mal festzustellen, ob programmieren überhaupt "liegt". Der zweite Teil befaßt sich mit, jetzt bitte nicht wieder rumdiskutieren, mit Assembler und Atmega8. Alle Beispiele sind aber auch auf einige andere AtMega anwendbar. Die Lektüre ist kostenlos im Netz verfügbar. Da steht auch etwas von Kosten und auch ein bisschen was zur Elektronik. Falls es dich interessiert https://www.makerconnect.de/index.php?threads/ver%C3%B6ffentlichung-pc-und-%C2%B5c-programmieren-in-vb-und-assembler-lehrbuch.4252/ An den Rest der Gemeinde, nein, ich bekomme dafür kein Geld und ja, es ist nicht ganz fehlerfrei, aber es steht alles wichtige drin, so das man den Fehlern auf die Spur kommen kann. Gruß oldmax
Robert R. schrieb: > was würdet ihr den für eine Hardware empfehlen? Tja darauf antworte ich natürlich mit MSP430 ;-) Gut, Günstig, Große Community, Kostenlose Samples, Leistung stark, Stromsparend, Integrierte Analogtechnik, FRAM, Umfangreiche OnChip Pheripherie, Hohe Verfügbarkeit, Erfahrung damit seit 1992 usw. Und grad zum anfangen, sind die launchpads eine feine Sache ;-)
:
Bearbeitet durch User
Patrick L. schrieb: > Robert R. schrieb: >> was würdet ihr den für eine Hardware empfehlen? > > Tja darauf antworte ich natürlich mit MSP430 ;-) Mindestens einer von uns beiden hat die Frage falsch verstanden.
Robert R. schrieb: > In der zwischenzeit hat sich was die Hardware angeht einiges geändert, > was würdet ihr den für eine Hardware empfehlen? Bei den ISP > Programmiergeräten gibt es eine große Auswahl und eine großen > Preisunerschied von 10€ - über 100€.. Was lohnt sich da? Wenn AVR: ich hatte jahrelang mit einem selbstgebastelten Programmer am Druckerport gearbeitet, hat einwandfrei funktioniert - Kosten praktisch 0. Als dann die Druckerports ausgingen an den aktuellen Rechnern hatte ich mir einen AVRISP mkII gekauft für damals knapp 40€. Mehr habe ich nie vermisst.
Klaus W. schrieb: > Mehr habe ich nie vermisst. Mehr hast du nie kennengelernt. Und meinst jetzt, deinen extrem beschränkten Horizont auch noch an anderen weitergeben zu müssen.
M.A. S. schrieb: > Mindestens einer von uns beiden hat die Frage falsch verstanden. Ja natürlich LOL oder etwas wage formuliert. Nun wen AVR verwende ich den ICE :-) Dies weil das Debuging sauber Funktioniert und eine große Palette von Chips unterstützt wird Inkl ATtiny ;-)
:
Bearbeitet durch User
Patrick L. schrieb: > Tja darauf antworte ich natürlich mit MSP430 ;-) Verbrennt den Ketzer! 😉 Ich finde auf die Frage viele Antworten weil sie ohne einen Sack voller Rahmenbedingungen nicht zu beantworten ist. Es gibt Gründe für PIC10 bis PIC32 + dsPICs, die sich alle recht kräftig unterscheiden. Natürlich die AVRs, die MSP430, STM32 und alle Cortexe ohnehin und ich persöhnlich finde auch den STM8 recht schick. Den RP2040 würde ich aber auch gerne mal ausprobieren. Ich finde die PIOs spannend und es gab situationen da hätte ich sowas sehr gut gebrauchen können, statt mit unflexibler glue logic rumzumachen. Ein wenig wie der Parallax Propeller in modern zu dem ich mich damals nicht durchringen konnte. Wieder andere werden jetzt damit kommen das sie Power brauchen, ihnen Strom und Platz wumpe ist und es die Zukunft sein muss, statt die gut abgehangene Vergangenheit. Also RISC-V, wobei andere meinen MIPS sei unterbewertet. Alles echt müssig. Ich versteh auch den leidenschaftlichen Kampf nicht. Ist für mich alles die gleiche Suppe. Ein gewisser Initialaufwand die Toolchain zum Laufen zu bekommen und der Rest ist Anwendung der LIBs und der Blick ins DB. Je ausgefuchster die CPU wird, umso lästiger wird das bare metall arbeiten damit, also verstehe ich auch die '8bit for ever' Fraktion ganz gut. An fast jeder MCU die ich mal verwendet habe finde ich irgendwas besonders gut, was die anderen nicht haben. Würde ich das nicht kennen, würde ich behaupten sowas braucht kein Mensch. Aber z.B. der ADC im STM8, dem man ein watch window mitgeben kann und der dann auf Automatik oder HW-Timer gesteuert seine Kanäle durchtackert und Alarm gibt wenn Limits gerissen werden, ist extrem schick weil es keine CPU Interaktion braucht. Solche Features, wo man HW kreativ intern verknoten kann, macht es oft möglich das eine schmalbrüstige 8bit MCU den Job spielend erledigt wo man ansonsten eine deutlich schneller MCU benötigt hätte. Deswegen gibt es so viel PIC Derivate, weil die oft extrem angepasste HW haben, die den einen geilen Trick draufhat, der in diesem Projekt die Bude rockt. Ich finde aber keinen Kandidaten den ich generell allen anderen vorziehen würde. Ist immer die Frage was ich brauche und heutzutage ist Verfügbarkeit das Zünglein an der Waage und nicht der mega geile Chip den ich leider erst ende 2023 vielleicht unter Umständen in irgendeiner menge bekomme, wenn bis dahin nicht irgendjemand bereit ist Mondpreise dafür zu bezahlen.
Vielen Dank für eure Antworten! Zu meiner Person, ich bin 17 Jahre und habe Grundkenntnisse im Elektronik Bereich. Ich bastle gerne und schraube das ein oder andere Gerät was bei meinen Eltern kaputt geht ausseinander um zu sehen wie es aufgebaut ist. Ich hab auch ein Multimeter und einen Lötkolben zuhause, ein paar Motoren aus alten Spielzeugen und Led's. Jetzt möchte ich aber gerne tiefer in das Thema Elektronik einsteigen und deswegen schreibe ich hier rein (oft verstehe ich aber nicht alles worüber ihr spricht :D ) Das vorgestellte Buch fine ich ineteressant aber ich dachte eher mit C zu Programmieren, damit habe ich auch schon ein paar Programme geschrieben. Gegenüber Assembler bin ich auch offen, wie ich das verstanden habe ist es sinnvoll zu wissen wie man in Assembler Programmiert weil man dann die Abläufe besser versteht. Schneller geht es aber in C (bitte verzeiht mir wenn ich falsch liege, so habe ich das bisher verstanden)
:
Bearbeitet durch User
Ich habe mir jetzt diese Hardware ausgesucht : https://www.ebay.de/itm/265167340695 https://www.ebay.de/itm/272399547360 Meinungen sind sehr gerne erwünscht
Robert R. schrieb: > Ebay-Artikel Nr. 265167340695 Hast du den dazu passenden µC Board? Das ist nur ein Shield.
Patrick L. schrieb: > Hast du den dazu passenden µC Board? > Das ist nur ein Shield. Nein ich dachte ich kan den µC hier rein stecken und den mit dem ISP Programmieren
Robert R. schrieb: > Nein ich dachte ich kan den µC hier rein stecken und den mit dem ISP > Programmieren Falsch gedacht. Das ist nur eine Aufsteckplatine. Quasi der "Erweiterungskasten Programmiergerät" und du musst jetzt erst mal den "Grundkasten Mikrocontroller" kaufen. Dafür taugt jedes Arduino-Board, das den von dir gewünschten µC drauf hat. Und den µC kannst du dann auch ganz ohne Arduino-Framework verwenden. Du kannst natürlich auch einfach mit dem Arduino anfangen, solltest dir aber immer bewusst sein, dass die Beispiele oft von "ambitionierten Anfängern" publiziert werden und meist nur für sich allein (hinreichend) gut laufen. Wenn du z.B. den Displaytreiber aus dem Beispiel A nimmst und einen PWM-Regler vom Beispiel B hinzufügst, dann kann es sein, dass weder A noch B richtig tun, obwohl sie allein für sich "gut" laufen. Als Tipp: wenn du ein delay() im Code findest, dann hast du oft schon den Programmfehler vor Augen... Besonders die zu solchen von Anfängern veröffentlichten Projekten gehörige Hardware ist dann in vielen Fällen völliger Murks und eben wie der zugehörige Code irgendwie grade so hingefrickelt. Robert R. schrieb: > Gegenüber Assembler bin ich auch offen, wie ich das > verstanden habe ist es sinnvoll zu wissen wie man in Assembler > Programmiert weil man dann die Abläufe besser versteht. Nein, man versteht sie eher noch weniger, weil sie ja kryptisch als Mikroschritte abgearbeitet werden. Aber man sieht, was es wirklich "kostet", eine bestimmte Funktion zu implementieren. Und es wird einem dabei klar, dass auf einem 8-Bit Rechner Operationen mit long oder gar float einfach extrem zeitaufwendig sind.
:
Bearbeitet durch Moderator
Robert R. schrieb: > Nein ich dachte ich kan den µC hier rein stecken und den mit dem ISP > Programmieren Mannomann. ISP bedeutet "In Circuit Programming". Also dass du eben grade NICHT den Controller aus der Schaltung nimmst und irgendwo reinsteckst. Entweder du hast irgendein Board oder du baust das auf dem Steckbrett auf. In beiden Fällen schließt du den ISP direkt dort an und programmierst den Controller in der Schaltung.
Cyblord -. schrieb: > Mannomann. > ISP bedeutet "In Circuit Programming". Es bedeutet eigentlich "In System Programming" ;-) > Also dass du eben grade NICHT den Controller aus der Schaltung nimmst > und irgendwo reinsteckst. Das tut man seit vor der Jahrtausendwende eigentlich nicht mehr... Ich würde hier einfach den Arduino mit dem Mega328 empfehlen. Immer wissend, dass es auch "besser" geht, wenn man den µC mal richtig ausnutzen will und Geschwindigkeit braucht. Und dann braucht es für den Anfang eben nur ein USB-Kabel und den Arduino.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Cyblord -. schrieb: >> Mannomann. >> ISP bedeutet "In Circuit Programming". > Es bedeutet eigentlich "In System Porgramming" ;-) Ja korrekt. Solche Typen triggern mich da komm ich schon mit tippen durcheinander. > >> Also dass du eben grade NICHT den Controller aus der Schaltung nimmst >> und irgendwo reinsteckst. > Das tut man seit vor der Jahrtausendwende eigentlich nicht mehr... Eben. Der TE plant das aber offensichtlich genau so.
Cyblord -. schrieb: > Mannomann. > ISP bedeutet "In Circuit Programming". Du meinst wohl: ISP = In System Programming ICSP = In Circuit Serial Programming Edit: Sorry, hatte die Seite nicht neu geladen und die vorherigen Beiträge nicht gesehen.
:
Bearbeitet durch User
Danke für eure Beiträge, ich habe wieder etwas dazu gelernt. Also neue Wahl getroffen : https://www.reichelt.de/arduino-uno-rev-3-dip-variante-atmega328-usb-arduino-uno-dip-p154902.html?&trstct=vrt_pdn&nbc=1 Kombiniert mit : https://www.ebay.de/itm/272399547360?mkcid=1&mkrid=707-53477-19255-0&siteid=77&campid=5336449576&customid=&toolid=10001&mkevt=1
Robert R. schrieb: > Also neue Wahl getroffen : > https://www.reichelt.de/arduino-uno-rev-3-dip-variante-atmega328-usb-arduino-uno-dip-p154902.html?&trstct=vrt_pdn&nbc=1 Das hätte auch ich Dir empfohlen. Den ISP-Programmer brauchst Du zunächst nicht. Für den Arduino gibt es Programme, die ihm ISP-Programmierung ermöglichen. Zum Arduino: Es ist verlockend, seine Programme als arduinospezifische .INO- Dateien zu schreiben. Das ist sicherlich gut, um schnell etwas anzutesten, was man so im Netz findet. Damit kann man auch gelegentlichen Frust bei eigenen Entwicklungen kompensieren ;-) Aber ich rate Dir, möglichst gleich mit reiner C-Programmierung ohne setup() und loop() anzufangen. Damit hast Du dann uneingeschränkten Zugriff auf die gesamte AVR-Peripherie. Auch wenn die Arduino-IDE nicht so komfortabel zu bedienen ist, ist sie ein einfacher Einstieg mit Bootloader und ser. Monitor für Kontroll-/Debugausgaben und damit gut für erste Erfolgserlebnisse.
:
Bearbeitet durch User
Robert R. schrieb: > Kombiniert mit : > > Ebay-Artikel Nr. 272399547360 Ich überlege grad ob ein JTAG für dich vllt. nicht besser wäre. Natürlich mit einem AVR der JTAG unterstützt. So als Anfänger wäre es doch interessant zu sehen wie der Controller dein Code abarbeitet und wie/wo welche Register gesetzt werden. Grund: Dann kannst du z.B. mit dem AtmelStudio leicht debuggen um zu sehen was im Controller passiert. Das geht mit der Arduino IDE nicht. Ja, per ISP könnte man auch debuggen (debug wire), aber beim 328er ist es mir schon sooo oft passiert, das er die Fuses nicht zurückgesetzt hat und dann wars das mit dem Controller, kommst nicht mehr drauf. Edit: Es wird dir 100% passieren, dass irgendwas nicht so abläuft wie du es dir wünscht und da man in der Arduino IDE den Code nicht "Schritt für Schritt" abarbeiten lassen kann, kann es sehr frustierend werden den Fehler zu finden. Da du ja schon ein Buch hast für C und AVR, fang am besten direkt mit AtmelStudio an. (Meine Meinung - wenn du Arduino möchtest, bitte)
:
Bearbeitet durch User
Am liebsten wäre mir tatsächlich auch kein Arduino. Sondern ein Board mit einem Atmel Chip drauf, ein Programmer dazu und das AVR Studio
Robert R. schrieb: > Am liebsten wäre mir tatsächlich auch kein Arduino. > Sondern ein Board mit einem Atmel Chip drauf, ein Programmer dazu und > das AVR Studio Ich wollte dir grad das "ATMEL Evaluations-Board von Pollin" empfehlen, aber das gibt es nicht mehr und meins brauch ich ab und zu doch mal. Ich schau mal was ich finde, dann liste ich es dir hier mal auf, ok? Du kannst schon ein Arduino Board kaufen und es mit dem AtmelStudio verwenden. Aber ich schau mal was es so schönes gibt.
Adam P. schrieb: > Ich schau mal was ich finde, dann liste ich es dir hier mal auf, ok? Sehr sehr gerne, vielen Dank!
Robert R. schrieb: > Am liebsten wäre mir tatsächlich auch kein Arduino. Du musst mit der Arduino Hardware nicht zwingend "Arduino" machen... > Sondern ein Board mit einem Atmel Chip drauf, ein Programmer dazu und > das AVR Studio Dann kauf den Arduino, deinen seriellen Programmer und tu darauf mit dem Microchip Studio das, was dir gefällt. Der Witz dabei: du kannst dank des Arduino-Systems ganz leicht irgendwelche Aufsteckmodule kaufen, dir den Arduino-Code dazu ansehen und die Dinger dann selber ansteuern.
:
Bearbeitet durch Moderator
Robert R. schrieb: > Zu meiner Person Sympathisch, so habe ich auch angefangen. Mach ne Elektroniker Lehre und geh danach studieren. In der Lehre lernst Du sehr viel das jemand der direkt vom Abi Studieren geht nie lernen wird. Wegen dem Geld geht man eh nicht in die Entwicklung, da macht man lieber BWL oder Scheidungsrecht 😅 Robert R. schrieb: > Am liebsten wäre mir tatsächlich auch kein Arduino. > Sondern ein Board mit einem Atmel Chip drauf, ein Programmer dazu und > das AVR Studio Das ist eigentlich egal. Du must nur mit irgendwas anfangen, mit was ist garnicht so wichtig. Die arduinos sind spuckenbillig und Du bekommst schnelle Ergebnisse. Aber im Endeffekt kannst Du den natürlich auch über AVR Studio + ISP betütern. Später fällt dir der Wechsel leicht. Ist mir ziemlich Wurst ob AVR, PIC, MSP430, STM8. Für alle gibts C-Compiler und Progarmmer / debugger für kleinstes Geld und wie die Peripherie anzusprechen ist, steht im DB. Alles kein Hexenwerk. Der Arduino hat den Vorteil das den fast jeder kennt und am Anfang wirst Du Hilfestellung brauchen. Beim STM8 oder einem der zahlreichen eher exotischen PIC varianten z.B. bist Du da ziemlich auf Dich alleine gestellt. Du wirst wahrscheinlich schnell zu den größeren Dinger kommen. Auch den ESP32 kann man in der Arduino IDE programmieren, die auch nur notdürftig verstecktes C / C++ ist. Also fang einfach mit nem billigen Arduino an und entwickel Dich dann weiter.
Mit einem Arduino Uno hat man ja ein einfaches Atmel Board, mit standarsierten Headern für die Zubehör Shields und dem Bootloader. Einen ISP und Atmel Studio kann man auch verwenden, Das Atmel Studio kann sogar Arduino Projekte einlesen und konvertieren.
Robert R. schrieb: > Zu meiner Person, ich bin 17 Jahre und habe Grundkenntnisse im > Elektronik Bereich. Nur aus purer Neugier: Hast Du vor, beruflich in Richtung Elektronik zu gehen (oder bist gar bereits auf diesem Wege) oder ist es ein Hobby und soll es auch bleiben?
M.A. S. schrieb: > Nur aus purer Neugier Ich habe vor auch beruflich indie Richtung zu gehen, ich habe aber noch keine spezifische Richtung. Anwendungselektroniker fänd ich interessant und danach eventuell ein Studium.
Robert R. schrieb: > M.A. S. schrieb: >> Nur aus purer Neugier > > Ich habe vor auch beruflich indie Richtung zu gehen, ich habe aber noch > keine spezifische Richtung. Anwendungselektroniker fänd ich interessant > und danach eventuell ein Studium. Wenn da noch nix klar ist, dann würde ich mich nicht auf C beschränken. Sondern mit C++ anfangen. Das hat zwei Gründe: A. Wer C++ lernt, bekommt einen stattlichen C Grundstock sofort mit dabei. Umgekehrt ist das nicht so deutlich der Fall. B. Wer einmal richtig C gelernt hat, ist für die OOP verdorben. Sowohl mit Atmel Studio, als auch der Arduino IDE, Eclipse und vielen weiteren, kann man in ASM, C und C++ arbeiten. Betrachtet man das "große Ganze", dann hat ASM seine kleine Nische. C findet sich auf der Grenzschicht zwischen Hardware und Anwendung. z.B. die Windows und Linux Kerne/Treiber sind größtenteils C C++ und die anderen OOP Sprachen haben ihren wichtigsten Platz auf Servern und dem Desktop. Dabei sind sich C und C++ so ähnlich, und so effektiv, dass beide auf µC gut einsetzbar sind. Arduino macht es vor. Am Rande: Die wirklich langsamen Dinger, digitalWrite() und seine Kumpels stecken bei Arduino in *.c Dateien. Mein Rat: Mit C++ beginnen, hauptsächlich, weil das Umlernen von C++ nach C einfacher ist, als von C nach C++. Die prozedurale Denkweise ist schwer wieder aus dem Kopf heraus zu bekommen. Und die OOP Denkweise beinhaltet, zumindest in den Methoden, die prozeduralen Verfahren. Leider ist C++ auch wohl eine der schwierigsten Sprachen. Wenn nicht so gar die schwierigste/komplizierteste überhaupt.
:
Bearbeitet durch User
Minus M. schrieb: > Sondern mit C++ anfangen. > Leider ist C++ auch wohl eine der schwierigsten Sprachen. Irgendwie echt ungünstig. > Am Rande: Die wirklich langsamen Dinger, digitalWrite() und seine > Kumpels stecken bei Arduino in *.c Dateien. Am Rande: es würde auch nichts ändern, wenn die in *.cpp Dateien stecken würden. Der Ansatz eines dynamischen und zur Laufzeit parametrisierbaren Pinzugriffs an sich ist halt elend langsam. Egal, ob C oder C++ oder ASM. > C++ und die anderen OOP Sprachen haben ihren wichtigsten Platz auf > Servern und dem Desktop. Ähem, 64-Bit-Rechner mit 8 Kernen und GHZ-Takt eben... Wer C++ auf dem AVR macht, der muss genau wissen, was so ein C++ Sprachkonstrukt zur Compilezeit bzw. zur Laufzeit macht. Sonst wird es halt einfach ein schlechtes, weil langsames Programm.
Lothar M. schrieb: > ...... Sieht aus, als würdest du nahezu vollständig mit dem übereinstimmen, was ich sagte. Ja, C++ ist schon eine Aufgabe! Lesetipp/Video: "Stop Teaching C" Die menschliche Seite: Wenn ein gestandener C Programmierer "gezwungen" wird Objekt orientiert zu arbeiten, beginnt erstmal das straucheln. Die Denkweise ist schon sehr anders. Umgekehrt ist es eher nur nervig, eine Umgewöhnung.
Minus M. schrieb: > Sieht aus, als würdest du nahezu vollständig mit dem übereinstimmen, was > ich sagte. Nur eben nicht mit der Aussage, dass C++ ideal zum Starten auf einem mickrigen 16MHz-µC ist. Denn so einen Rechner knechtet man mit einer einzigen falschen Codezeile in die Knie. Und weil C++ noch wesentlich abstrakter als C ist, hat man im Handumdrehen eine falsche Codezeile hingeschrieben und macht zigtausendmal pro Sekunde Sachen zur Laufzeit, die besser ein einziges Mal vom Compiler berechnet worden wären. Siehe auch https://www.mikrocontroller.net/articles/C_vs_C++
:
Bearbeitet durch Moderator
Wenn es sich um das "Mist bauen" dreht, dann ist C auch ganz weit vorne. Viele der Fallstricke sind in C++ nicht mehr nötig. Zudem, wie sollte man ein Gefühl dafür entwickeln, was in C++, in welcher Situation geht, wenn man es nicht übt. Ausblenden ist da sicherlich nicht hilfreich. Lothar M. schrieb: > Nur eben nicht mit der Aussage, dass C++ ideal zum Starten auf einem > mickrigen 16MHz-µC ist. Im Moment sieht es so aus, als würden zigtausende von Anfängern genau das gerade tun. Tagtäglich. Die verwenden C++ einfach. Anfangs, sicherlich ohne drüber nach zu denken. Lothar M. schrieb: > C++ Wie ist denn deine Beziehung zu C++?
:
Bearbeitet durch User
AVR Mikrocontroller werden sowohl in Arduino als auch in anderen IDE üblicherweise mit dem avr-gcc Compiler programmiert. Der kann beides, C und C++.
Mi N. schrieb: > Zum Arduino: > Es ist verlockend, seine Programme als arduinospezifische .INO- Dateien > zu schreiben. Das ist sicherlich gut, um schnell etwas anzutesten, was > man so im Netz findet. Damit kann man auch gelegentlichen Frust bei > eigenen Entwicklungen kompensieren ;-) > > Aber ich rate Dir, möglichst gleich mit reiner C-Programmierung ohne > setup() und loop() anzufangen. Damit hast Du dann uneingeschränkten > Zugriff auf die gesamte AVR-Peripherie. > Auch wenn die Arduino-IDE nicht so komfortabel zu bedienen ist, ist sie > ein einfacher Einstieg mit Bootloader und ser. Monitor für > Kontroll-/Debugausgaben und damit gut für erste Erfolgserlebnisse. Hallo Robert, wie man einen Arduino ohne die Arduino-Umgebung nuzen kann, wird in diesem Artikel beschrieben: https://www.mikrocontroller.net/articles/Umstieg_von_Arduino_auf_AVR Für den Start sind auch diese AVR-Artikel auf www.mikrocontroller.net zu empfehlen: https://www.mikrocontroller.net/articles/AVR https://www.mikrocontroller.net/articles/AVR-Tutorial https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
:
Bearbeitet durch User
Alexander S. schrieb: > Hallo Robert, > wie man einen Arduino ohne die Arduino-Umgebung nuzen kann, wird in > diesem Artikel beschrieben: > https://www.mikrocontroller.net/articles/Umstieg_von_Arduino_auf_AVR > Für den Start sind auch diese AVR-Artikel auf www.mikrocontroller.net zu > empfehlen: > https://www.mikrocontroller.net/articles/AVR > https://www.mikrocontroller.net/articles/AVR-Tutorial > https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial Vielen lieben Dank! Ich war gerade dabei mir die neuen Beiträge durchzulesen
Minus M. schrieb: > Wie ist denn deine Beziehung zu C++? Ich kenne es seit der ersten Ausgabe von Bjarne Stroustrups C++ und habe mit dem ersten C++ Compiler "Zortech C++" auf dem 80386 angefangen. Ich verwende auf potenten Prozessoren C++ und auf langsameren uC simples C. Die Grenze liegt gefühlt ca. bei 100MHz.
Robert R. schrieb: > Am liebsten wäre mir tatsächlich auch kein Arduino. > Sondern ein Board mit einem Atmel Chip drauf, ein Programmer dazu und > das AVR Studio Hey, dann mach das doch einfach! :-) Jobst M. schrieb: > Du kannst DIL-AVRs auf's Steckbrett drücken oder auf Lochraster löten, > zwei Kondensatoren dazu - läuft. Du kannst fertige Bastelboards (DAUino > oder so ...) benutzen und in der heutigen Zeit auch recht einfach und > günstig eigene Platinen designen und fertigen lassen. ... und auch dabei bekommst Du hier Hilfe. Was hast Du Dir denn an Funktionalität vorgestellt? Gruß Jobst
Angehängte Dateien:
-
IMG_20220224_072958.jpg
220 KB -
IMG_20220224_073011.jpg
290 KB
Robert R. schrieb: > Adam P. schrieb: >> Ich schau mal was ich finde, dann liste ich es dir hier mal auf, ok? > > Sehr sehr gerne, vielen Dank! Nach längerer Suche musste ich leider feststellen, dass es mittlerweile kaum noch etwas gibt, was einem "Atmel evaluations-board v2.0.1" ähnelt. Bei ebay Kleinanzeigen habe ich ein STK500 gefunden. So wie ich es gesehen habe, hat dieser jedoch kein JTAG Pin-Header, stimmt das? Welche Controller das Board unterstützt, weiß ich leider spontan nicht. Klar könnte man da den JTAG direkt an die Port Pins hängen. Fertige Boards mit fest verbautem Controller finde ich je nach Situation ungünstig. Stell dir vor du hast in paar Monaten eine Idee und willst was programmieren, jedoch hat dein Controller zu wenig RAM. Dann wieder ein neues Board zu kaufen? ...blöd. Aber nun ist es so und 150-200€ für nen Board ausgeben, würde ich jetzt auch nicht. - Entweder du kaufst dir am Anfang das Board, welches du oben erwähnt hast. - Du kaufst dir ein "Mega Pro Mini", der hat einen ATmega2560 drauf https://www.amazon.de/ARCELI-Arduino-Mega-ATmega2560-CH340G-Elektronik/dp/B07MQ1J9MR/ref=asc_df_B07MQ1J9MR/?tag=googshopde-21&linkCode=df0&hvadid=204476351460&hvpos=&hvnetw=g&hvrand=11501061730475294248&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1004061&hvtargid=pla-718074181409&psc=1&th=1&psc=1 - Oder du lötest dir einfach was selber zusammen (siehe Anhang), brauchte ich mal für einen Test (Akkuüberwachung). Verbaut hatte ich einen ATmega1284P, völlig überdimmensioniert aber war vorhanden. Bei JTAG (ISP) Programmierern würde ich mir einen von Atmel kaufen, klar kostet der etwas mehr, aber dann hast du ruhe. Die von Olimex unterstützen wohl nur eine gewisse Anzahl an AVR Controllern. Etwas älter: https://www.ebay-kleinanzeigen.de/s-anzeige/atmos-atmel-avr-jtagice-mkii-debugger-programmer-microcontroller/2006836431-168-8960 https://www.ebay-kleinanzeigen.de/s-anzeige/atmel-jtagice3-debugger-zu-verkaufen-in-duesseltal-/2006259414-226-2098 Neuste Version und kann für die Zukunft auch die SAM Controller (ARM): https://www.ebay-kleinanzeigen.de/s-anzeige/atmel-ice-programmierer-debugger/1973864009-226-8844
:
Bearbeitet durch User
Muß es denn zum Einstieg etwas kompliziertes ein? Ich hatte mit AVR angefangen mit besagtem frei verdrahteten Programmer (heute würde ich dafür einen AVRISP mkII nehmen wahrscheinlich) und Lochrasterplatinen. Da muß man zum ersten Blinken sowenig verdrahten, daß es einfacher ist als etwas vorgekautes zu verstehen. Noch simpler als Lochraster ist ein Steckbrett. Anleitung ist doch hier irgendwo als Artikel? Deshalb meine Empfehlung: irgendein AVR mit Beinchen, AVRISP-Programmierer, Steckbrett, ein paar Widerstände, LED, Drähte, Labornetzteil oder Akku und Spannungsregler und ein paar Stunden Zeit. Dann hat man viel mehr Verständnisgewinn als mit jedem fertigen Board. Wenn einem das zu langweilig wird, hat man eher eine Vorstellung was man danach braucht. Ich hatte wie gesagt so etwa angefangen, und das obwohl ich damals schon ein STK500 daneben liegen hatte, das ich bis heute nicht benutzt habe (sogar mit zusätzlichem STK501, um LQFP64 ohne Löten nehmen zu können), und JTAG-ICE, auch bis heute unbenutzt. Falls jemand löten will: hier liegen auch noch von Pollin 3 Bausätze AVR-Net-IO. Da ist jeweils ein atmega32 drin, das Netzzeug kann man ja am Anfang ignorieren. Muß man aber erst noch zusammenlöten. Wie gesagt: für meinen Geschmack alles viel zu viel für den Anfang. Stumpf ist Trumpf in diesem Fall. Adam P. schrieb: > Ich wollte dir grad das "ATMEL Evaluations-Board von Pollin" empfehlen, > aber das gibt es nicht mehr und meins brauch ich ab und zu doch mal. Habe noch eines hier zum selbst zusammen löten, unbenutzt, noch in Einzelteilen.
:
Bearbeitet durch User
Klaus W. schrieb: > Adam P. schrieb: >> Ich wollte dir grad das "ATMEL Evaluations-Board von Pollin" empfehlen, >> aber das gibt es nicht mehr und meins brauch ich ab und zu doch mal. > > Habe noch eines hier zum selbst zusammen löten, unbenutzt, noch in > Einzelteilen. Ja das wäre doch perfekt. Das Board + ein Atmel-ICE oder mk2 oder JTAGICE3, fertig.
Angehängte Dateien:
-
IMG_20220224_080747.jpg
230 KB
Klaus W. schrieb: > Habe noch eines hier zum selbst zusammen löten, unbenutzt, noch in > Einzelteilen. Wenn er es eh noch zusammenlöten muss, dann könnte er direkt den RS232 Anschluss durch USB ersetzen, dann brauch er keinen externen FTDI Adapter und hat auch direkt die Spannungsversorgung (bis zu einer gewissen Grenze). Nur so als Idee.
Auch wenn ich überhaupt kein Freund der Arduino-IDE bin, finde ich die Arduino-Hardware sehr gut, und das nicht nur für den Einstieg. Wenn ich eine eigene Experimentierplatine mit dem AVR bauen würde, kämen folgende Komponenten darauf: - AVR (irgendein ATmega) - UART-USB-Konverter (um mit dem PC kommunizieren zu können) - Quarz (damit die Baudrate für den UART-USB-Konverter stabil ist) - evtl. noch einen Spannungsregler Genau diese Komponenten hat auch ein Arduino Nano. Warum also selber bauen mit dem Risiko, dass nachher irgendetwas nicht funktioniert und man nicht weiß, ob es an der Hardware, an der Softwareinstallation oder an den (noch) unzureichenden Programmierkünsten liegt? Für erste Tests kann man durchaus auch die Arduino-IDE installieren und hat damit innerhalb von Minuten das erste Blink-Programm am Laufen: - Arduino-Software installieren - Arduino-Board per USB-Kabel mit dem PC verbinden - Aus dem Examples-Menü das Beispiel Blink auswählen - Upload-Button klicken (der Compiler/Linker wird dabei automatisch aufgerufen) - zuschauen, wie die LED blinkt Wenn man später mit anderen AVRs arbeiten will (auf dem Steckbrett oder einer selber gebastelten Platine) kann man das Arduino-Board mit der entsprechenden Software als ISP-Programmer nutzen. Diese Software ist ebenfalls im Examples-Menü der Arduino-IDE enthalten.
Angehängte Dateien:
-
AVR_Analog_Comparator.png
110 KB
Die neueren AVR haben viele verbesserte Funktionen. Sogar der Analogkomparator wurde verbessert.
Adam P. schrieb: > Nach längerer Suche musste ich leider feststellen, dass es mittlerweile > kaum noch etwas gibt, was einem "Atmel evaluations-board v2.0.1" ähnelt. Weil sich das Ganze viel in Richtung der Arduino Boards und Steckbretter verschoben hat. Ich benutze fast nur noch Arduino Module - aber ohne deren IDE und Framework. Robert: Schau mal bei Olimex.
Hallo, Yalu X. schrieb: > Wenn ich eine eigene Experimentierplatine mit dem AVR bauen würde, > kämen folgende Komponenten darauf: > > - AVR (irgendein ATmega) > - UART-USB-Konverter (um mit dem PC kommunizieren zu können) > - Quarz (damit die Baudrate für den UART-USB-Konverter stabil ist) > - evtl. noch einen Spannungsregler > > Genau diese Komponenten hat auch ein Arduino Nano. Man sich aber auch ein Steckbrett einschließlich einem Sortiment Steckbrücken kaufen (braucht man nachher sowieso), einen ATmega<irgendwas>(1) im DIP-Gehäuse, dazu den passenden Baudratenquarz nebst den nötigen Kondensatoren, noch ein paar 100nF-Kondensatoren und 1- und 10KOhm-Widerständen, sowie 3-4 LEDs. Dann fehlt eigentlich nur noch ISP-Programmer. Zur Versorgung dient dann ein sowie so überall herumliegendes USB-Steckernetzteil.(2) Damit kann man sich für ein paar Euro in wenigen Minuten ein voll funktionierendes "Entwicklungssystem" zusammenstecken. Im Gegensatz zum Arduino-Board hat man dann auch mal Kontakt zur Hardware und kann sich damit beschäftigen, als in Internet-Diskussionen langatmige Beiträge zu lesen, warum es unbedingt nötig ist eine der kompliziertesten Programmiersprachen überhaupt direkt am Anfang zu nutzen. Georg M. schrieb: > Die neueren AVR haben viele verbesserte Funktionen. Sogar der > Analogkomparator wurde verbessert. Stimmt, ist aber für den blutigen Anfänger nicht wichtig. rhf (1) Wenn auch völlig veraltet bietet sich hier ein ATmega8 an, da genau der in unzähligen Anleitungen verwendet wird und man damit die angegebenen Quellcode-Beispiele direkt verwenden kann. (2) @Robert: Falls dich das interessieren sollte, kannst du dich gerne an mich wenden.
Hier ist mein Mini-Tutorial für den Einstieg ohne Arduino: http://stefanfrings.de/avr_hello_world/index.html
Hallo, Stefan ⛄ F. schrieb: > Hier ist mein Mini-Tutorial für den Einstieg ohne Arduino: > http://stefanfrings.de/avr_hello_world/index.html Und genau so sollte man auch anfangen. rhf
Stefan ⛄ F. schrieb: > Hier ist mein Mini-Tutorial für den Einstieg ohne Arduino: > http://stefanfrings.de/avr_hello_world/index.html Vielen lieben Dank an alle die sich an diesem sehr lehrreichen Beitrag beteiligt haben! Ich habe vieles neues dazugelernt und durch die verschiedenen Meinungen und Debatten einen Eindruck bekommen wie komplex und gleichzeitig interessant die Mikrocontroller Programmierung sein kann. Ab und an dachte ich mir, muss diese Diskussion jetzt sein aber letztenendes hat mir genau das den Horizont erweitert! @Stefan ⛄ F. , so werde ich auch anfangen "from scratch" . Diese Methode gefällt mir sehr, da ich so nah wie möglich an der Materie sein möchte. Linux bzw Ubuntu nutze ich auch privat, daher finde ich die Konsole nicht befremdlich. Nochmals besten Dank an alle! Wir werden uns hier bestimmt demnächst öfters begegnen wenn ich wieder einen Rat brauche :)
:
Bearbeitet durch User
Robert R. schrieb: > @Stefan ⛄ F. , so werde ich auch anfangen "from scratch" . So kann man es auch machen :) Viel Spaß. Beachte jedoch: Bei diesen Steckbrettern (je nach Qualität) kann es dazu kommen, dass dein Bauteil oder Leitung zwar drin steckt, aber eine schlechte Verbindung vorhanden ist (evtl. Fehlverhalten der Schaltung).
Robert R. schrieb: > so werde ich auch anfangen "from scratch" Nichts gegen zu sagen. Aber wenn Du das erst geschaft hast wirst Du wahrscheinlich die Arduinos zu schätzen lernen wo alles das was Du mühseelig auf Steckbrett machst schon drauf ist. Du hast es Dir dann beweisen das Du es verstanden hast. Ich habe noch mit 8085, Adresslatch, Sram, Eprom und allem anderem angefangen. Auf Lochraster weil Steckbrett extrem fehleranfällg war. Der 8031 war da schon eine echte Verbesserung. Der 8751 schon heutigen flash MCUs ähnlicher. Der AVR war nochmal geiler, dann kamen die (ds)PICs, der STM8, STM32 ... Mach nur nicht den Fehler und beiß Dich dauerhaft an einem Typen fest. Es gibt so viele geile MCUs die alle nicht schwerer zu lernen sind und jeder kann irgendwas besonders gut. Und bare metall ist super um das zu lernen, aber später kannst Du auch ruhig den Kompfort nutzen und Dich mehr auf das zu lösende Problem konzentrieren als nur auf die möglichst pure Art alles selbst zu machen. Verwende nicht nur stumpf irgendwelche Libs. Was die wirklich tun ist oft brutal einfach aber sie tun es auf eine komplizierte Art und unterstützen oft nicht alles was die MCZ HW könnte. Zwei register direkt zu laden ist oft der viel einfachere und schnellere Weg. Aber auch nicht LIBs aus Prinzip ablehnen wenn sie Dein Problem einfach lösen. Locker und flexibel bleiben ;-) Ebenso ASM / C. Gut ASM einwenig zu können, aber auch geren als Inline Code in C, wenn man muss. Und C findet Du auf jeder MCU. Kannst Du eine kannst Du alle, mit ein wenig Einarbeitung und dem DB im Anschlag.
Hallo zusammen, für blutige Anfänger möchte ich noch einen ganz anderen Aspekt anbringen, der m.E. eigentlich nie beachtet wird: die PIN Zahl des verwendeten Objekts der Begierde. In einem Nebenthread kämpft gerade ein Anfänger mit einem 40-Piner. Es muss nicht gerade ein TINY-13 sein sein, aber mit einem TINY-85 und seinen 8K kann man schon eine ganze Menge machen. Dazu vielleicht noch ein I2C-Display. Wenn dann der einfache Timer oder die PIN-Zahl nicht mehr reichen, tut es ein TINY-84 mit 14 Pins vllt. auch, und wenn das dann immer noch nicht reicht, tut es dann ein TINY-861 mit 20 Pins. So etwas auf dem Steckbrett fehlerfrei zusammenzustecken, ist schon ziemlich mühsam, geschweige denn mit 28 oder gar 40 Pins -> Fehlermöglichkeiten ohne Ende. 73 Wilhelm
Ich mag den ATtiny13 auch, aber ich würde nicht zustimmen, dass viele Pins für den Anfang hinderlich seien. Sie müssen nur gut zugänglich sein. Einen 40 Pinner ATmega1284 im DIP Format kriegt man genau so einfach ans Laufen, wie einen 8 Pinner ATtiny13 im DIP Format. Wenn ich sehe, was für Klimmzüge manche Leute machen, um bloß nicht den nächst größeren Chip verwenden zu müssen, kann ich nur den Kopf schütteln. Für mich sind die Arduino Nano Boards eine sehr handliche mittlere Größe. Wenn ich es kleiner brauche, nehme ich ATtiny Chips. Wenn ich mehr Pins brauche, nehme ich ein Crumb644 Modul. Wenn ich mehr Leistung brauche, nehme ich ein STM32 Board in ähnlichem Format. Und wenn ich noch mehr Pins brauche - auch dafür gibt es preisgünstige Module.
Hallo zusammen, hallo Stefan. > Wenn ich sehe, was für Klimmzüge manche Leute machen, um bloß nicht den > nächst größeren Chip verwenden zu müssen, kann ich nur den Kopf > schütteln. Da hast du vollkommen Recht. Das war aber nicht meine Intention. Wenn ich noch keine Ahnung habe, ist doch ein 'Viel-Beiner' wesentlich abschreckender als ein 8-Beiner. Das Lesen des Datenblatts wird ja hier in diesem Forum immer wärmstens (mit erhobenem Zeigefinger!) empfohlen, aber wenn ich (noch) keine Ahnung von Nichts habe, bringt es mich nicht weiter; denn ich verstehe (noch) nicht, was da so alles drin steht. Die vielfältigsten Möglichkeiten des entspr. Chips weiss ich (noch) nicht zu beurteilen. Wenn man vom 8-Beiner VCC, VDD und den Reset-Pin abzieht, bleiben noch 5 Pins übrig. Überschaubar oder..? Und wenn man es geschafft hat, die obligatorische LED zum Blinken zu bringen, lehnt man sich erstmal mit stolzgeschwellter Brust zurück, und denkt wunders, was man vollbracht hat. So haben wir doch alle angefangen, oder..? 73 Wilhelm
Wilhelm S. schrieb: > Wenn ich noch keine Ahnung habe, ist doch ein 'Viel-Beiner' > wesentlich abschreckender als ein 8-Beiner. > So haben wir doch alle angefangen, oder..? Ja. Ich habe mit dem ATtiny13 angefangen, weil er mir (wie du schon sagst) sympathischer war. Aber ich weiß jetzt, dass das Qautsch war. Denn um unbenutzte Pins brauche ich nicht zu sorgen. Vorteilhaft war an dem kleinen Ding nur der geringe Preis, da gab es nicht viel kaputt zu machen. Nur ist der Preisunterschied zum nächst größeren Modell verschwinden gering. Insofern habe ich mir die Entscheidung mehr schön geredet, als ehrlich zu sein.
Hallo Stefan, auch das ist richtig. Aber sind 8 Beine nicht wesentlich übersichtlicher als 28 oder 40? Alles subjektiv. 73 Wilhelm
Wilhelm S. schrieb: > Aber sind 8 Beine nicht wesentlich übersichtlicher als 28 oder 40? Ach, meist sind sie doch sorgfältig in ordentlichen Reihen angeordnet und gut dokumentiert. Ist schon schwer, sich da zu verirren, würde ich mal sagen. Wenn in dem Punkt schon die Überforderung auftritt, oha....
Wilhelm S. schrieb: > Aber sind 8 Beine nicht wesentlich übersichtlicher als 28 oder 40? Wenn ich einige davon schon für den Programmieradapter reserviere, weil ich als Anfänger noch nicht weiß wie man sie doppelt belegt, dann sind die zwei verbleibenden freien I/O Pins eher hinderlich als übersichtlich.
Hi Wilhelm S. schrieb: > Wenn ich noch keine Ahnung habe, ist doch ein 'Viel-Beiner' wesentlich > abschreckender als ein 8-Beiner. Das Lesen des Datenblatts wird ja hier > in diesem Forum immer wärmstens (mit erhobenem Zeigefinger!) empfohlen, > aber wenn ich (noch) keine Ahnung von Nichts habe, bringt es mich nicht > weiter; denn ich verstehe (noch) nicht, was da so alles drin steht. Die > vielfältigsten Möglichkeiten des entspr. Chips weiss ich (noch) nicht zu > beurteilen. > Wenn man vom 8-Beiner VCC, VDD und den Reset-Pin abzieht, bleiben noch 5 > Pins übrig. Überschaubar oder..? Und wenn man es geschafft hat, die > obligatorische LED zum Blinken zu bringen, lehnt man sich erstmal mit > stolzgeschwellter Brust zurück, und denkt wunders, was man vollbracht > hat. > So haben wir doch alle angefangen, oder..? Nun, ein Achtbeiner ist nicht automatisch selbsterklärend, sondern auch hier ist ein Datenblatt das A und O. Ob dann mehr Beinchen am Controller sind, spielt erst mal keine Rolle. Bei den ATinys und AtMegas ist im Datenblatt sehr gut dokumentiert, wie die IO Ebene zu händeln ist. Ich würde einen Mega8 empfehlen, nicht zu groß, aber groß genug, um auch mal Anzeigen mit Multiplex zu realisieren. Auch wenn,s kalter Kaffee ist, eine Uhr ist schon mal ein kleines Projekt, oder eine Ampelanlage für den Modellbau. Später, wenn du deine Erfahrungen gesammelt hast, ist der Einsatz eines Tiny kein Problem. Bedenke, zwei Pins sind schon für die Versorgung erforderlich, da bleibt für Peripherie nicht viel über. In dem von mir gezeigten Buch habe ich versucht, schrittweise mit kleinen Experimenten die Fähigkeiten der Controller zu entdecken. Das mit ASM gearbeitet wurde, sollte kein Hindernis sein, denn die Schritte sind ausführlich erklärt. Mit ein wenig Kopfarbeit also auch auf C umzuschreiben. Falls da Fragen sind, gern auch per PN Gruß oldmax
Hört auf Jungs, es reicht. Alles richtig, aber das ist nicht das, was ich zum Ausdruck bringen wollte. Ihr habt auch alle eure ersten Stunden nach der Fahrprüfung auf einem Ferrari gehabt...? Vom hohen Ross sind Sprüche einfach, da muss man aber erstmal drauf kommen. 73 Wilhelm
Wilhelm S. schrieb: > Ihr habt auch alle eure ersten Stunden nach der Fahrprüfung auf einem > Ferrari gehabt Deine Meinung das es um so einfacher wird je weniger Pins der hat ist eben einfach nicht richtig. Nirgendwo ist das Gewurste größer als wenn man sich den ISP mit dringend benötigten Pins teilen muss, der Speicher zu klein ist, HW nicht verfügbar oder man elendig abwägen muss was man benutzt und was dafür eben unbenutzbar ist oder man bereits bei den ersten Versuchen mit IO Expandern loslegen muss. Oder die Blinky Led bekommt man nocoh hin, aber das naächste Projekt ist das wieder ein anderere, weil der 8beiner einfach zu beschränkend ist. Gleich mit einer ordentlich ausgestatteten MCU beginnen. Dein Ferrari Vergleich ist auch falsch. Der Ferrarie ist die Karre die zu klein ist um da ohne Zerrung reinzukommen und so auf einen Spezialfall ausgelegt, das es für um den Block cruisen oder den Wocheneinkauf zu erledigen einfach nicht langt. Deswegen lernt man in der Golf Klasse und weder auf dem Smart noch auf dem Ferrari. 0815 Teile die jeder kennt, jeder zweite hat und bei denen einem auch viele Helfen können, sind am besten geeignet. Ergo: Arduino
Beitrag #6992311 wurde von einem Moderator gelöscht.
Wilhelm S. schrieb: > Ihr habt auch alle eure ersten Stunden nach der Fahrprüfung auf einem > Ferrari gehabt...? Hier muss ich gestehen, dass mit mein erstes System an/mit ich nach der Ausbildung ersthaft arbeiten musste/durfte eine MV 7800 von DataGeneral war. Zur damaligen Zeit, war das ein ordentlicher Brummer! Für den allerwelts PC-XT Besitzer, war das doch wohl in der "Ferrari Kategorie" und auch wohl nicht viel billiger als ein Ferrari in der Zeit.
[Edit Mod: total passend zum Thema mal wieder Corona ... daher entsprechende Antwortpassagen gelöscht] Wilhelm S. schrieb: > Ihr habt auch alle eure ersten Stunden nach der Fahrprüfung auf einem > Ferrari gehabt...? Ich verstehe zwar Deinen Grundgedanken, muss aber denen recht geben, die schreiben 'mehr Pins heißt nicht automatisch komplizierter'. Wenn man die vielen Pins alle nicht benutzen muss und die nicht benötigten Hardwarekomponenten nicht initialisieren muss, dann entsteht keine größere Komplexität. Mein erstes Mikroprozessorsystem(-chen) war eine Schaltung mit Z80 und Minimalspeicher daran auf einem Steckbrett. Im Vergleich dazu ist ein 40-pinniger AVR völlig harmlos, wenn man z.B. nur eine LED damit blinken lassen will.
:
Bearbeitet durch Moderator
Beitrag #6992382 wurde von einem Moderator gelöscht.
Okay, Corona und Masken haben wir jetzt schon im AVR Thread. Wollen wir noch Ukraine dazunehmen damit hier endlich dichtgemacht wird? ;-) [Edit Mod: nee, wieder aufs Thema konzentrieren oder einfach mal gar nichts schreiben ;-)]
:
Bearbeitet durch Moderator
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.