AVR Mikrocontroller Lohnenswert?

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.

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.

Ein Ratschlag schrieb:
> Bei
> modernen Chips (kommt es |kam es } immer wieder zu Versorgungsengpässen.

Wo habe ich das schon mal gehört?;-)

Robert schrieb:
> Ist es noch lohnenswert mit AVR Atmel Chips anzufangen?

Atmel hat keine Zukunft.

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.

Dislikes für eine wahre Aussage? Mann Mann Mann...

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

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.

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.

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.

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.

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.

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.

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

Blablub blubberte im Beitrag #6977780:
> Arduino ist etwas für unbedarfte Anfänger.

Also genau das was Robert, der OP sucht?

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

https://www.microchip.com/en-us/development-tool/EV35L43A

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.

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.

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.

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?

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.

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

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!

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

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.

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!

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.

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...

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?

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.

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.

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.

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.

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.

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.

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

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.

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!

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?

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.

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.

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 ;-)

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 ;-)

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)

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.

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.

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.

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.

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)

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

AVR® DB Microcontroller Family
https://www.youtube.com/watch?v=EH1FozhBKHc

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.

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.

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++

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++?

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

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

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

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.

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.

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.

Die neueren AVR haben viele verbesserte Funktionen. Sogar der 
Analogkomparator wurde verbessert.

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.

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 :)