Pfad: Home => AVR-Überblick => Programmiertechniken => Assembler-Lernhindernisse

Ein spassiges Experiment

Wer sich ein paar Tage lang köstlich amüsieren möchte, starte in einem Programmierforum den Thread "Hallo. Ich bin 15 und möchte gerne Mikroprozessoren programmieren. Mit was fange ich an? Wie lege ich los?" Schneller als man lesen kann, füllt sich der Thread mit Beiträgen. Schon früh wird der Thread zum Toprenner im Forum. Du brauchst auch nicht weiter auf eingehende Ratschläge zu antworten, das Ganze läuft jetzt nach Regeln ab, auf die Du sowieso keinen Einfluss mehr hast und nehmen kannst.

Nach dem dritten Beitrag kann man aufhören mitzulesen, weil sich der Thread ab jetzt nicht mehr mit der eigentlichen Frage befasst, sondern in die Tiefen der Frage "Welche Programmiersprache ist die Beste, die Schönste, die Schlaueste, die Sicherste, die Eleganteste, die Optimalste der Welt?" abgetaucht ist. Was sich da jetzt abspielt, ist ein Wettstreit von Philosophien, Glauben, Geschmackssache oder es spult sich einfach nur die jeweilige eigene IT-Sozialisation ab (mit was habe ich angefangen, was hat mir persönlich bei was geholfen oder mit was wurde ich am Anfang eher unglücklich). Das schreibt der durchschnittliche Schreiber aber so nicht, sondern formuliert es als Ratschlag, es ihm doch bitte schön gleich zu tun.

Im Folgenden sind daher ein paar typische Reaktionen und Argumente dargestellt, woher sie kommen und was sie noch mit der eigentlichen Frage zu tun haben.

"Nimm Dir ein gutes Buch und lerne C"

Genau: fange mit etwas an, was mit AVR-Prozessoren möglichst gar nichts zu tun hat. Für das Du auch gar keinen Prozessor brauchst und alles auf dem PC erledigen kannst. Am Ende hast Du drei Monate lang Sprachkonstrukte erlernt, die Dich so tief in diese Sprache haben eintauchen lassen, dass Du Dein ursprüngliches Ziel, den Herrn Mikroprofessor in den Griff zu kriegen, längst vergessen hast.

Stattdessen hast Du gelernt, dass man beim Schreiben immer schön einrücken muss, damit am Ende die Klammer-Auf-Zeichen genau so oft vorkommen wie die Klammer-Zu-Zeichen. Die Sprache hat Dich zum (Klammer-)Affen gemacht, dessen intellektuelles Niveau mit dem Zählen von Klammerebenen erschöpft zu sein scheint.

Mit dem ursprünglichen Lernziel "Ich will, dass der Prozessor das tut, was ich will" hat das alles nix zum Tun. Das kommt jetzt erst, wenn Du Dich mit dem Timer im AVR befasst und schaust, wozu Du den einsetzen kannst. Jetzt kommt die Stunde der Wahrheit, wenn Du Dich endlich damit befasst, welche Kontrollbits in welchem Timerkontrollregister jetzt für das Zälen wie gesetzt werden müssen. Wenn Du beides, Assembler und C, von der Sprache her beherrscht, wirst Du merken, dass es völlig egal ist, in welchem Sprachkonstrukt Du das nun machst. Es ist dasselbe, nur mit anderen Worten, ungefähr so unterschiedlich wie englisch und französisch. Als Beleg dafür ein Beispiel aus dem ATMEL-Datenbuch zum Initialisieren des 16-Bit-Timers:

asm und C Beispiel Aus Sicht des Anfängers ungefähr gleich kryptisch, weil er erst mal wissen und verstehen muss was eigentlich TCNT1 ist. Und dazu ist die mühsame Tour durch das Device Databook unumgänglich. Oder eine etwas einfachere Darstellung des Timers und seiner Modi.

Und bei C halt mit Klammernzählen und Parameterübergabe und anderem völlig nutzlosem Quatsch, der Dir beim Verständnis des Timers Null weiterhilft und alles nur unnötig umständlich macht. Um das Verstehen, wie der Timer jetzt genau funktioniert und welche von den 38 verschiedenen Betriebsarten jetzt genau die Richtige ist, die bei Deinem Hardware-Problem weiterhilft, kommst Du halt doch nicht herum.

Halt, doch, Du kannst in einer der vielen Bibliotheken suchen, ob jemand schon mal das gleiche Problem gelöst hat wie Du. Die famose Funktion rufst Du mit den richtigen Parametern auf (was kommt jetzt zuerst, was kommt als Zweites, welcher Variablenttyp ist jetzt der Richtige, etc.) und schon macht der Timer genau das, was Du willst (oder auch was Anderes). Das bringt Dich zwar um die Niederungen des Verständnisses dafür herum, wie der Timer genau funktioniert. Dafür bist Du ab jetzt überwiegend damit befasst, was sich der Bibliothekprogrammierer dabei gedacht hat, als er dies oder jenes so gelöst hat, dass es genau für Dein Problem nicht passt. Ab jetzt bist Du damit beschäftigt, an der Bibliothek herumzubasteln, kommst aber trotzdem nicht darum herum zu erlernen, wie der Timer in seinem Innern funktioniert. Nur jetzt halt auf dem Umweg, dass Du es beim Umbau der Bibliothek zwingend brauchst. Am Ende wird die Frage, ob die Bibliothek jetzt irgend etwas geholfen und vereinfacht hat oder ob Du mit dem Selberausdenken schneller gewesen wärst, mal so oder mal so ausfallen. Soweit der arg hilfreiche Rat im Forum "Nimm hohes C, dann brauchst Du das nicht alles selber lösen": im Ernstfall hilft Dir das gar nix und hält Dich nur davon ab zu verstehen, wie der verdammte Timer jetzt wirklich tickt. Prädikat: machmal hilfreich, manchmal steht die Bibliothek nur der genialen eigenen optimal an deinen Bedarf angepassten Lösung im Weg herum.

Aber das schönste Argument für C kommt erst beim zehnten Thread-Beitrag. Du kannst, wenn Du kannst, Dir den vom C-Compiler erzeugten Assembler-Code anschauen und gucken, wie der Compiler das gelöst hat. Das ist jetzt das Huhn-Ei-Henne-Problem völlig auf den Kopf gestellt: also erst C lernen, dann Assembler. Oder umgekehrt? Also irgendwie beides gleich versiert, aber nur, um dem C-Compiler auf die schlimmen Finger gucken zu können oder seine verunglückten Übersetzungsversuche zur Not manuell korrigieren zu können. Muss ich jetzt genau verstehen, wie der Compiler seine Arbeit verrichtet? Hat er dann überhaupt als geeignetes Werkzeug seine Daseinberechtigung? Das ist jetzt für den 15-jährigen Fragesteller überaus hilfreich: wie jetzt, muss ich erst in der Lage sein, beides so gut zu können, dass ich mich nicht auf den Compiler verlassen muss? Der ist jetzt hellauf begeistert und hochmotiviert, jetzt genau was zuerst zu lernen? Und vor allem es wie zu lernen? Sehr hilfreicher Forumsbeitrag, das hilft schon mal weiter, die Probleme enger einzukreisen. Und dem Fragesteller zu signalisieren: mach was Du willst, Du wirst schon in genügend Probleme mit dem C-Compiler reinrennen, dass Du Dir noch wünschen wirst, zuerst Assembler gelernt zu haben.

Noch so ein hilfreiches Argument: es gibt mehr C-Programmierer als Assembler-Programmierer. Mit dem Argument sollte man ihm zu Flash, Java, HTML oder Office/VBA raten. Das hilft ihm dann immens weiter, mit den AVR irgendwas anzufangen. Genausogut könnte man raten, doch lieber Portugiesisch zu lernen. Dann könnte man sich zwar mal mit einem Brasilianer unterhalten, aber halt nicht mit einem AVR spielen.

Ach ja, bei Thread-Eintrag Nummer 16 kommt noch das Argument, man könne bei C ja auch Assembler-Inline machen. Das ist ein noch dämlicheres Argument, weil ab jetzt die gesamten Innereien des C-Compilers bekannt sein müssen, damit man mit dem Inlinen nix Wichtiges kaputt macht. So schlägt man sich bei C mit den selbst geschaffenen Problemen herum und merkt irgendwann nicht, dass die ganze angebliche Vereinfachung alles nur noch komplizierter macht. Von dem Huhn-Ei-Henne-Problem mal abgesehen.

Ab jetzt ist der Thread in Selbstvergessenheit abgetaucht und zu rein gar nix mehr nutze.

"Lern Basic, das ist am Einfachsten"

Vorsicht: Hier schreibt einer, dessen Haupttätigkeit darin besteht, sich mit der eigenwilligen Syntax des Basicdialekts mittels Nachschlagen im Handbuch schlau zu machen, der genau das, was er sucht, darin aber nicht findet und sich infolgedessen mit von-hinten-durch-die-Brust-ins-Auge-Lösungen herumschlägt. Als Beispiel hier mal das Timer-Init von oben.


$regfile = "m8def.dat"                    'für Mega8 
$crystal = 8000000                        'für 8MHz Quarz

Config Portd = Output                     'definiert Portd als Output

Config Timer1 = Timer , Prescale = 256    'Konfiguriere Timer1
Enable Timer1                             'schalte den Timer1 ein
On Timer1 Isr_von_timer1                  'verzweige bei Timer1 Überlauf zu   Isr_von_Timer1
Enable Interrupts
Timer1 = 34285                            'Timer1 soll schon von 34285 wegzählen

Do
 '....Hauptprogramm
Loop
End

Isr_von_timer1:                            'ISR von Timer1
Timer1 = 34285                             'Timer1 soll wieder von 34285 wegzählen
Toggle Portd.0                             'schaltet Portd.0 im Sekundentakt
                                           'EIN und AUS
'....oder z.B. incr Variable   

Return

Der geniale Basic-Programmierer hat mit diesen Zeilen mal eben den ganzen Port D zum Ausgang gemacht, setzt immerzu den Timer auf 34285, wenn er überläuft, und lässt das Portbit PD0 bei jedem Interrupt vom Timer torkeln. Dass jeder Timer das Torkeln eines Portbits schon von sich aus kann, ohne dass man es ihm per Serviceroutine erst beibringen müsste, merkt der Basic-Programmierer erst gar nicht, weil er sich mit den 28 Seiten über den Timer im ATMEL-Handbuch auch gar nicht herumschlagen muss. Dass das jeweilige Rücksetzen des Zählers mit dem CTC-Modus ganz automatisch vor sich geht, wenn man die famosen Comparer im Zähler einsetzt, merkt er auch nicht. Und dieses Herumschlagen mit dem Handbuch auch gar keinen Sinn macht, weil er diese Spezialitäten gar nicht von seinem Compiler angeboten kriegt und auch nicht umgesetzt kriegen würde. Also gibt es dies für den Basic-Programmierer einfach nicht. So was nennt man "kastrierte Wahrnehmung".

Was daran irgendwie einfacher sein soll als Assembler zu lernen, lässt den Verdacht aufkommen, dass wenn man nur ein Zehntel der Hardware eines AVR zur Verfügung hat, es schon irgendwie einfacher sein muss, weil man mit den 90% gar nicht erst behelligt wird und es sich in der so eingeschränkten Welt gut und bequem leben lässt. Wenn es außer Timer(Off) und Timer(On) gar nix zu programmieren gibt, ist mit dem Lernen schnell fertig und kann so viel frühzeitiger als der mühsame Assembler-Lerner mit den wild blinkenden Lämpchen glänzen. Schon bei der nächsthöheren Aufgabenstellung, die Helligkeit der LED mit einem Potentiometer zu regeln, lässt den Basicprogrammierer in sein Handbuch abtauchen, wie jetzt der Timer dazu gebracht werden kann, sein Ausgangssignal auf genau den Portanschluss zu bringen, an dem er die LED gerade angeschlossen hatte. Spätestens jetzt wissen wir, warum Basic einfacher ist: was nicht geht, geht halt irgendwie nicht. Und: wenn er ein echtes Problem lösen muss oder will, muss er halt doch noch was Anderes dazulernen. Und: schnelle Lernerfolge sind langfristig manchmal mit einem mühsamerem Umstieg verbunden. Die Mauern, die der Basic-Compiler um den Programmierer herum errichtet hat, werden von diesem gar nicht als solche wahrgenommen, weil er die eingeschränkte Welt als Prozessoreigenschaft wahrnimmt. Und beim Umstieg wird der so Umerzogene immense Probleme kriegen, weil er sich die Welt immer so schön einfach vorgestellt hatte.

Das macht Assembler so viel komplizierter als Basic: es bietet einfach viel mehr Möglichkeiten an. Aber wer halt keinen Navi im Auto hat, braucht sich damit auch nicht herumschlagen.

"Bei komplexen Projekten sind Hochsprachen einfach besser!"

Dieser Beitrag kommt garantiert, wenn man im Forum zwölf Zeilen Assembler-Quellcode postet und die Mitleser bittet, beim Finden des Fehlers behilflich zu sein. Der Schreiber empfindet deshalb schon zwölf Zeilen als so komplex, weil er bei einer einzigen Zeile schon nur noch Bahnhof versteht und daher zwölf davon als superkomplexen Bahnhof einstuft. Der will einfach nicht schreiben, dass er von Etwas gar nix versteht und rät daher, lieber ein Problem zu beschreiben, vom dem auch er etwas versteht. Es ist halt psychisch leichter verkraftbar, eigenes Nichtwissen und -können dadurch in seiner selbstbewusstseinszerstörenden Wirkung abzumildern, indem man dieses Fehlen als Vorteil verkauft und dem Fehlergeplagten eine andere Sprache empfiehlt. Den Gefallen kann man ihm leider nicht tun.

Was ist nun ein wirklich komplexes Projekt, bei denen Hochsprachen ein Segen wären? Sind es einfach komplizierte Abläufe im Programm, also viele Entscheidungen und Ablaufvarianten? Diese Sorte komplexer Aufgabenstellungen kann man in welcher Sprache auch immer programmieren, sie neigen in jedem Fall zu Undurchsichtigkeit, die man nur mit Flussdiagrammen und ähnlichen Methoden in den Griff kriegt.

Oder sind es etwa komplexe Datenstrukturen, bei denen die Hochsprache irgendwas hilft und einfacher macht? Irgendwelche dynamischen Puffer oder Records mit vier verschiedenen Datentypen im Gemisch? Hat es alles nicht oder ist in Assembler genauso schwierig zu programmieren wie in irgendeiner Hochsprache.

Pufferüberläufe oder Bereichsüberschreitungen? Die zaubert auch keine Hochsprache weg, wenn man sie nicht sorgfältig schon in der Planung behandelt und abfängt. Ob man das mit dem Abfragen des Carry- oder Zero-Flags vom Prozessor erledigt oder als "Exception" behandelt, ist dabei ziemlich egal. Leider ist eine Hochsprachen-Exception in der Bremssoftware einer Straßenbahn genauso fatal in seiner Wirkung wie ein unbehandelter Überlauf.

Der Gipfel an Verwirrung ist der Hinweis, dass ohne die segensreiche Hilfe von Hochsprachenbibliotheken der Prozessor doof sei und nicht mal zwei und zwei zusammenzählen könne. Der Schreiber hat Null Ahnung von ADD, SUB, INC, ADIW und MUL, weil er in C einfach nur +, -, ++, +2 und * schreibt und dem Compiler den Rest überlässt. Mit den 15 Zeilen Assembler zur Hardware-Multiplikation zweier 16-Bit-Ganzzahlen ist er schon geistig überbelastet und bleibt schon aus reiner Denkfaulheit bei seinen C-Leisten. Komplexität in diesem Sinne ist "um die Multiplikation habe ich mich noch nie gekümmert, die ist mir auch zu kompliziert".

Also was ist mit Komlexität genau gemeint? Wahrscheinlich gar nichts, nur einfach ein bedeutungsloses Wort, das sich nach mehr Bedeutung anhört. Siehe oben.

"Assembler lernt man am Besten am PC!"

Genau, das erspart Dir die Enttäuschung, die eintritt wenn Dein Prozessor partout nicht das tut, was Du willst. Willst Du von Frankfurt nach Köln, fährst Du viel schöner erst mal nach Dresden und dann erst nach Köln. Damit bist Du erst mal maximal weit weg von Deinem Ziel und Du lernst stattdessen, wie man Betriebssystemrotinen im Windoof oder Linux aufruft, um irgendwas auf den Bildschirm zu zaubern. Das hilft Dir zwar nix, weil Dein Prozessor gar keinen Bildschirm hat, aber es ist eine Zeitlang auch ganz intellektuell unterhaltsam. Da Du irgendwann halt doch den erworbenen AVR-Chip mit Deinen Ideen füttern willst, in dem nackigen Dings aber gar kein Betriebssystem werkelt und irgendwelche vordefinierten Dinge macht, fängst Du grad von vorne wieder an und merkst, dass Dir die ganze PC-Assembler-Quälerei dabei rein gar nix nutzt. Ätsch, jetzt weißt Du, wozu Assembler genau nicht gut ist.

"Kauf Dir einen Arduino und werde glücklich damit"

Dieser Threadbeitrag hat wegen des niedrigen Preises und der weiten Verbreitung eine zunehmend hohe Priorität (Platz drei bis fünf, würde ich ungefähr schätzen).

Mit dem Ratschlag lernt der Anfänger über den AVR garantiert rein gar nichts, weil ihm gegenüber die Hardware sorgfältig und vollständig abgeschirmt wird. Allenfalls über Software-Schnittstellen darf er darauf zugreifen, und wenn er mutig ist, ein paar Portpins schalten oder ADC-Werte einlesen. Schon die Programmierung einer Weckuhr als Geburtstagsgeschenk ist eine Weltaufgabe, weil der Programmierer dazu seinen an die diversen Portanschlüssen angebauten Drahtverhau am Rande des schönen Boards an jemand Anderen verschenken müsste. Das ist zwar preislich nicht das Problem, aber so richtig attraktiv, dass man es auf den Nachttisch stellen wollte, ist der Verhau angebauter Elektronik halt eben auch nicht.

Aber der Arduino ist halt auch gar nicht dafür gedacht. Er wird gerne von Informatikern gekauft, die von Elektronik Null Ahnung haben, gar nicht löten können oder wollen und damit gerne Informatik-Selbstzweck-Beschäftigung betreiben wollen. Damit sind wir beim 96-poligen ATXmega-Ungeheuer mit extra viel RAM weil schon die C-Fließkommabiblithek davon ein Viertel des Flash einnimmt. Die zwar kein intelligenter Mensch braucht, die aber halt mal dazugeladen wird, wenn der Programmierer nicht aufpasst.

Nur die gemächlichen 20 MHz Takt sind beim Berechnen von Mandelbrot-Mengen etwas hinderlich, so dass vielleicht 256-Stück-Farmen von Arduinos ein Lösungsansatz wären, um an die Rechengeschwindigkeit von heutigen PCs heranzukommen. Wie geschrieben: überwiegend Selbstbeschäftigung mit selbst definierten Softwareproblemen. Nix, was sich irgendwie in der realen Welt gebrauchen ließe oder zur Lösung realer Probleme beitrüge.

Jedenfalls lassen sich die meisten Arduino-Probleme lösen, ohne auch nur einen Funken Ahnung von der Hardware zu haben. Wenn der Anfänger also hiermit anfangen soll, lernt er nicht so arg viel über die AVR-Hardware. Wegen der vielen "Das darfst Du nicht!" und "Das geht nicht!" ist Arduino zum Lernen noch weniger geeignet als Basic. Es ist halt Alles-in-Allem nur ein Spielzeug für Hyper-Intellelle mit C-Spleen.

"Pascal und ADA sind aber noch viel schöner!"

Mit den Thread-Argumenten 18 und 22 sind wir vollends in den Niederungen nutzloser Ratschläge angekommen. Die Ratschläger befassen sich seit Jahren mit der überflüssigen Idee, dafür Compiler zu entwickeln, scheitern aber an dem zu geringen Speicherraum dieser Prozessoren von nur 32 kB und der Tatsache, dass ein ATtiny noch viel weniger davon hat. Aber ihr Beitrag durfte in dem Forum nicht fehlen, damit die Welt aufmerkt, dass es auch noch denkbare, wenn auch nicht ganz realisierbare Alternativen zu dem ganzen Standardzeugs gibt. Es lebe die IT-Vielfalt und die reine, häre und unverfälschte Idee!

Banale Nutzenüberlegungen sind da nur reine Spaßbremsen.

"Wir sind dabei, den ultimativen (Basic, C, ...) Interpreter zu entwickeln, mach mit!"

Vorsicht vor denen! Die haben ein selbst geschaffenes Problem, das zu lösen zu rein gar nix nutze ist. Die sind schon froh, wenn sie mit einem Query über die serielle Schnittstelle den aktuellen Inhalt eines Registers in ASCII-Zeichen auslesen können. Wenn man zurückfragt, zu was das gut sein soll, gibt es wortreiches Geklingel, das allesamt nach akademisch klingt. Die Befassung eines Mikroprofessors mit der Frage, ob der Anwender gerade die Worte "Read" oder "Write" an ihn abgesetzt hat, kann schon mal vorkommen, ist aber sonst zu nix Sinnvollem gebrauchbar.

"Assembler oder C ist aber nicht portierbar!"

Der Schreiber muss heute für Autohersteller A und morgen für Autohersteller B irgendwelche Software für die Überwachung und Steuerung der Bremsen entwickeln und sorgt sich darum, dass seine intellektuellen Leistungen vielleicht nicht ausreichend gewürdigt werden, wenn Hersteller B jetzt das Gleiche will wie A, dessen Einkaufsabteilung aber nur einen Knebelvertrag mit Prozessorhersteller C hat und daher Prozessoren von Hersteller D gar nicht verwendet. Statt jetzt die gesamte Entwicklung für die Autofirma B neu anzuwerfen, möchte er möglichst viel von seinem mühsam erstellten und getesteten Code wiederverwerten und sucht daher nach dem Eierlegenden-Wollmilchsau-Compiler, der sowohl die Prozessoren von C als auch D kann, per Compilerschalter heute dies und morgen das produziert und übermorgen was ganz Anderes auswirft und ihm so die Arbeit bis auf Null erleichtert.

Der Eierlegende-Wollmilchsau-Compiler ist notwenigerweise so unübersichtlich und so voller Fallen, dass zur Einarbeitung dreimonatige Schulungen nötig sind. Genau das Richtige für den 15-jährigen Fragesteller, wie gemacht für den. Darauf hat er gewartet und kann endlich mit der Planung der nächsten fünf Lebensjahre anfangen.

Am Ende muss der Programmierer von Autozulieferungsfirmen das Ganze auch noch qualitätsgesichert dokumentieren, damit er beim Bremsversagen fein raus ist und beweisen kann, dass es jedenfalls nicht an seiner Software lag, warum 224.000 Neuwagen in die Werkstatt zurückgerufen werden mussten, nachdem schon 34 Nobelautos aus undurchsichtigen Gründen krachend auf vor ihnen fahrende Fahrzeuge aufgefahren waren. Vielleich kann der Abnehmer und Qualitätssicherer in Autofirma A gar kein Assembler, nur C oder nur MCS4711 oder was auch immer. Jedenfalls hat der Schreiber ein Problem, das der anfragende Anfänger im Forum gar nicht kennt, weil der grad noch gar keine einzige Sprache und Prozessorfamilie kann. Merkt der Forumbeiträger aber gar nicht, weil er so mit sich selbst beschäftigt ist (oder auch nur das hirnlos nachplappert, was irgendein anderer Software-Profi-Fuzzi mal als wohlfeiles Argument gegen Assembler in die Welt gesetzt hat).

Beiträge dieser Art können getrost ignoriert werden.

"Die 8-Bit-Prozessoren sind total out, heute ist 32 Bit Standard!"

Der hat schon 8 Bit nicht kapiert und müht sich trotzdem ab, das jeweils Neueste auf dem Markt zu kapieren. Dieses Nebengleis in der Diskussion regt alle die an, die als Entzwickler immer ganz vorne dran sind. Es entspinnt sich eine Diskussion über die Vor- und Nachteile von ganzen Familien. Den Teilthread kann man getrost zuklappen, weil den Beiträgen allesamt gemeinsam ist, dass die Familien weder bei Reichelt noch bei Conrad im Programm sind, für die es Testplatinen zum Preis eines koreanischen Kleinwagens oder auch gar nicht erst zu kaufen gibt und jedenfalls für den spärlich mit Taschengeld ausgestatteten 15-jährigen Fragesteller so geeignet sind, dass er allenfalls als 30-jähriger mit festem Monatseinkommen anfangen kann es jetzt endlich zu erlernen. Bis dahin ist dann allerdings schon 256 Bit Standard und es wird wieder nix mit Anfangen.

Langfristig denken und lieber gar nix lernen als was schnell Veraltendes. Die Technik der Herausschiebens, diesmal nicht mit ROL und ROR realisiert.

Fazit

Jeder der Ratschläge hat was, aber halt grad gar nix für den blutigen Anfänger. Merke:



©2013 by info@avr-asm-tutorial.net