8015 Microkontroller-Familie

Such mal unter 8051, nicht 8015.

Basti schrieb:
> Ich empfehle den 0815.

Jou, sind dieselben Ziffern und auch dieselbe Quersumme. Kann also nicht 
falsch sein... ;-)

...

Du hast Arduino Erfahrungen. Also solltest du mit den AVR Typen 
weitermachen, denn du kannst die vorhandenen Werkzeuge nutzen.

Auch, wenn hier ab und an Glaubenskriege geführt werden, der CPU Typ ist 
relativ unwichtig für die meisten Projekte.

Wenn man in Assembler reinschnuppern will, dann ist der 8051 die erste 
Wahl. Gegen so einen durchdachten, kompakten und einfachen Befehlssatz 
kommen PIC und AVR lange nicht an.
Mächtige Befehle für Bitmanipulationen, schön kompakte Befehle für 
Schleifen, Verzweigungen und Tabellenzugriffe, sogar Mul und DIV gibt es 
und die meisten Befehle gehen direkt im RAM bzw. auf IO-Register.

Auch die 4 Interruptprioritäten sind sehr nützlich. Z.B. kann man das 
zeitkritische 1-Wire in SW implementieren, ohne das andere Interrupts 
das Timing stören.
Von den Compilern gibt es Demoversionen mit Codelimit.
Für die Silabs 8051 kann man sogar den Keil als Vollversion bekommen, 
wenn man sich registriert.

Da die 8051 sich nur im Includefile unterscheiden, kann man mit jedem 
C51-Compiler auch jeden anderen 8051 programmieren bzw. simulieren. Nur 
das Debuggen bzw. Codebanking (>64kB) ist für die Derivatfamilien 
speziell.

Peter D. schrieb:
> Wenn man in Assembler reinschnuppern will, dann ist der 8051 die erste
> Wahl. Gegen so einen durchdachten, kompakten und einfachen Befehlssatz
> kommen PIC und AVR lange nicht an.
Mir gefällt der Akku nicht. Da war der AVR mit seinem 32er-Registersatz 
eine helle Erleuchtung...

> Mächtige Befehle für Bitmanipulationen, schön kompakte Befehle für
> Schleifen, Verzweigungen und Tabellenzugriffe, sogar Mul und DIV gibt es
> und die meisten Befehle gehen direkt im RAM bzw. auf IO-Register.
Allerdings fällt man dann auf die Nase, wenn man diesen Befehlssatz 
auf eine andere, moderne Architektur ummünzen muß.

Lothar M. schrieb:
> Mir gefällt der Akku nicht.

Der Akku wird ja fast nur für die Grundrechenarten (+-*/) gebraucht und 
das ist in Steuerungen selten die Hauptsache. Daher habe ich das nicht 
als Flaschenhals bemerkt, sondern viele Variablenoperationen direkt in 
Registern bzw. SRAM durchgeführt.

Lothar M. schrieb:
> Allerdings fällt man dann auf die Nase, wenn man diesen Befehlssatz
> auf eine andere, moderne Architektur ummünzen muß.

Wer vorhat, mehrere Architekturen zu benutzen, der sollte C nehmen.
Ich meinte mit "reinschnuppern" auch eher, um mal zu verstehen, wie so 
ein MC tickt.
Ich rate heutzutage keinem mehr, größere Projekte in Assembler zu 
schreiben, das ist vergeudete Zeit.

Verwundert schrieb:
> Ein Admin eröffnet den GK?
Admin != Moderator
Und nur wer unbedingt gegen irgendwas oder für irgendwen kämpfen will, 
eröffnet einen Krieg.
Mir ist es nicht wert, um eine uC Architektur zu kämpfen. Dazu habe ich 
schon zu viele verschiedene verwendet und bin mit jeweils jedem uC zum 
jeweiligen Ziel gekommen...

> Na denn, AVR und 8051 sind alte Kamelen
Aber genau nach diesen beiden uC hat der TO gefragt.

Nina schrieb:
> Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz
> gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in
> die Microkontroller Programmierung einarbeiten.
Man kann sogar damit und mit einem vernünftigen Programmierstil etwas 
sinnvolles machen. Allerdings sind gefühlte 95% der im Netz 
herumfliegenden "Arduino-Programme" die Bits nicht wert, die sie im 
Speicher belegen. Ich sage z.B. meinen daraufhin sichtlich schockierten 
Praktikanten: ein "delay()" ist ein Programmfehler!

Peter D. schrieb:
> Ich meinte mit "reinschnuppern" auch eher, um mal zu verstehen, wie so
> ein MC tickt.
Da stimmt es allerdings, wenn es ums Verstehen geht: der 51er mit seiner 
überschaubaren Peripherie ist leichter zu kapieren.
Wenn es aber um den Nutzen geht: alle modernen Architekturen sind wie 
der AVR registerorientiert.

Verwundert schrieb:
>>> Na denn, AVR und 8051 sind alte Kamelen
>> Aber genau nach diesen beiden uC hat der TO gefragt.

Dann schmeiße ich mal diesen hier in die Runde: STM32F030

Ein kleiner Cortex-M0. Günstig, schnell, kostenlose IDE in Massen (ja, 
auch Keil MDK-ARM gehört dazu), zahlreiche Debugger (der ST-Link ist für 
den Anfang sicherlich nicht schlecht), moderne Architektur, etc.

Nina schrieb:
> Oder spielt es keine Rolle?

Jepp. Wenn man gewillt ist was zu lernen, so ist die Architektur relativ 
egal. Kennt man einen sehr gut, so fällt der Umstieg auf andere ziemlich 
leicht.

Nina schrieb:
> Ich habe bisher nur ein paar kleine Projekte mit einem Arduino Bausatz
> gemacht um mich an das Gebiet ranzutasten und würde mich gerne weiter in
> die Microkontroller Programmierung einarbeiten.

Schon mal ein guter Anfang. Pass nur auf, dass der Arduino nicht deinen 
(noch nicht wirklich entwickelten) Programmierstil für immer versaut. 
Wärst nicht der Erste, dem das passiert.

Hallo,

Verwundert schrieb:
> W.S. schrieb:
>> Bei beiden Architekturen kann man sehr gut die Grundlagen und Assembler
>> lernen. Das ist wichtig.
>
> Watt ein Blödsinn, watt ein Gefasel der ewig gestrigen. Die Erde dreht
> sich weiter und heute programmiert man in Hochsprache.

eigetnlich warte ich auf den Tag, wo es keine neuen Prozessoren und 
Compiler mehr gibt, weil kein Programmierer den Kram, der da erzeugt 
wird, mehr lesen kann.

Vermutlich gibt es dann aber Transistoren, die nicht nur 0 und 1 als 
Zustand können sondern auch geschweifte Klammern.

Gruß aus Berlin
Michael

Michael U. schrieb:
> Vermutlich gibt es dann aber Transistoren, die nicht nur 0 und 1 als
> Zustand können sondern auch geschweifte Klammern.

Hochsprachenelemente in Silizium zu giessen wurde schon gelegentlich 
versucht, war aber letztlich nie auf Dauer erfolgreich. Es erwies sich 
als sinnvollere Arbeitsteilung, den Prozessoren die Grundoperationen der 
eingesetzten Technik beizubringen, und den Compilern die Hochsprachen zu 
überlassen.

Verwundert schrieb:
> kann ja den Befehlssatz
> auswendig lernen.

Schwachsinn, man muss ihn verstehen und auch anwenden können.

...

Verwundert schrieb:
> Für die jenigen, für die der uC nur Mittel zum Zweck
> ist, die interessante Projekte umsetzen, ist am überflüssig.

Grundkenntnisse in Assembler sind beim Debugging durchaus hilfreich. Man 
muss dafür nicht in Assembler programmieren können, sollte aber in der 
Lage sein, vom Compiler erzeugten Code leidlich lesen zu können.

Verwundert schrieb:
> Was gibt es beim add oder sub zu verstehen? Musst du ein +
> oder- auch verstehen?

Das kann aber einfacher oder komplizierter sein. AVR ist dahingehend 
(meist) ziemlich einfach lesbar, Cortex M0 ebenso. Wer die kennt, der 
kann zur Not auch MIPS Code einigermassen lesen, ohne sich allzu lange 
damit befassen zu müssen

8-Bit PICs hingegen verwenden eine Mnemotechnik und Zusammenhänge, sich 
nur Eingeweihten erschliessen. Die liegen damit ziemlich quer zum Rest 
der Welt und die Kenntnis anderer Akkumulator-Architekturen wie 8051 
hilft auch nur begrenzt weiter.

Verwundert schrieb:
> Und deshalb schreibt man einfach + in Hochsprache.
Und ohne Nachzudenken vor und hinter diesem "einfachen" + ein float oder 
noch besser (weil genauer) ein double.
Und dann wundert man sich, warum der uC so langsam ist. Ich hätte schon 
solche Bacheleranden und Masteranden. Und erst nachdem Ich die 
struktuellen Fehler mal aufgezeigt hatte und die behoben waren, war 
auf einmal sogar noch Rechenzeit für Anderes...

> Die Masse hier dürfte einen Akkuschrauber nutzen. Aber ein paar
> Prediger raten ab und schwören auf den mehrfach angeschliffenen
> Schraubendreher mit Holzgriff.

Nein, Lothar meint nur, daß es gut wäre die Bits (beim Akkuschrauber) 
unterscheiden zu können.

Meine Frau benutzt auch einen Akkuschrauber, wird aber nie den 
Unterschied zwischen Phillips und Pozi verstehen, da sie Schrauben nicht 
interessieren. Und jemand anderer die vermurksten Dinger ausbohren darf.

MaWin schrieb:
> Und ARM Cortex STM sind zwar leistungsfähiger, aber wenn es nur um
> Leistungsfähigkeit geht tut es auch dein PC.

Äpfel, Birnen.... Hmmmm. Aber egal, jeder hat so seine Meinung.

Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen, wo es 
doch Computer und Smartphones gibt?

Verrwundert schrieb:
> Falk B. schrieb:
>> Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen,
>> wo es doch Computer und Smartphones gibt?
>
> Macht man ja auch nicht mehr. Die Kids fangen früher mit den
> Taschenrechnern an und die Dinger können viel mehr als früher.

Nur die Kinder nicht ... :-^

Hallo,

Verrwundert schrieb:
> Ach ja, rechnest du noch alles mit Logarithmustabelle und
> Messschieber?
> Weil dem PC und Smartphone misstraust? Die App werden nicht in ASM
> geschrieben. ;-)

Man muß dem PC und dem Smartphone genauso mißtrauen können wie 
Logarithmustabelle und Rechenschieber.

Man muß sich daran erinnern können, weshalb es sinnvoll ist einen 
Überschlag zu machen, die Fehlergrenzen einschätzen zu können usw.

Genauso wie man auf einen kleinen AVR wie auf einen PC losgehen und dann 
weder Geschwindigkeit noch Speicherplatz reichen, genauso kann man eine 
tolle Formel in den Taschrechner tippen und dem Ergebnis blind 
vertrauen.

Auf einem AVR ein wenig Assembler zu prgrammieren zeigt schnell, daß man 
eben auf diese Grenzen achten muß. Dann denkt man auch auf einem 
größeren und in C über Registergrößen und Speicherplatz und 
Geschwindigkeit nach.

Ein 64 Bit Shift auf einem AVR in ASM ist keine Problem, in C mit dem 
GCC funktioniert es nur noch irgendwie.
Ist für einen 8-Bitter auch eher eine Zumutung wie auch ein paar andere 
Sachen. Genau das trifft aber auf alle µC oder SoC zu. Man kann einen 
anderen nehmen, aber nicht wie beim PC einen schnelleren Prozessor und 
ein paar GB Ram mehr und dann das Programm einfach darauf laufen lassen.

Wird heute aber gern gemacht. Dann gibt es TVs mit Reaktionszeiten im 
"Ewigkeitsbereich" oder Smartphones, die nach einem Update praktisch 
unbenutzbar werden, weil kritiklos jeder Unfug unbedingt noch ins System 
mußte.

Gruß aus Berlin
Michael

Nina schrieb:
> Oder spielt es keine Rolle?

Managment summary:
  Spielt keine Rolle.

Detailed explanation:

Da Du anscheinend gerade anfängst ist jeder uC erst mal brauchbar.

Sollte es irgendwann nicht mehr reichen, dann hast du aber mehr 
Erfahrung um Dir einen Anderen zu suchen.
Erfahrungsgemäss reichen aber die "ollen Kamellen" ziemlich lange, wenn 
man (mit zunehmendem Wissen) die implementierten Lösungen optimiert.

ASM oder nicht? Meiner Meinung nach sind Kenntnisse in Assembler für 
seriöse SW Entwicklung, zumindest im Embedded Bereich, unverzichtbar. 
Und auch ziemlich spannend.
Am Ende des Tages sollte es Dir (als Hobby-Programmierer) aber est mal 
Spass machen.
Und "falsch" geht da eigentlich fast garnicht.

Grüße
Andreas

Verrwundert schrieb:
> Andreas H. schrieb:
>> Erfahrungsgemäss reichen aber
>> die "ollen Kamellen" ziemlich lange,
> Sind aber schwerer handzuhaben als modernere! (Darauf bezieht sich der
> Ausdruck)

Für Dich ist ja auch ein "+" einfach nur ein "+".
Solange man die uC nur soweit einsetzt bis sie das erste Mal "warm" 
werden, ist man mit modernen uC natürlich länger auf der sicheren Seite.
Aber wo bleibt da denn der Spass?

Anyway. Der TO fängt gerade an. Da ist das was er schon hat genau das 
Richtige. Alles andere wäre mMn. Overkill.

Grüße
Andreas

MaWin schrieb:
> Uli, der Wilde schrieb:
>> Die 8051 Architektur ist veraltet, die von AVR oder PIC doch schon ein
>> Stueck neuer.
>
> Immer wieder derselbe Käse der hier behauptet wird.
>
> Der PIC ist älter als der 8051.

8051 geb. 1980
PIC  geb. 1976

@ Verrwundert (Gast)

>> Warum soll man heute noch des kleine 1x1 und Kopfrechnen lernen,
>> wo es doch Computer und Smartphones gibt?

>Macht man ja auch nicht mehr. Die Kids fangen früher mit den
>Taschenrechnern an und die Dinger können viel mehr als früher. Eine ganz
>normale Entwicklung, wie bei den uC auch.

Eine ganz normale Fehlentwicklung, in der Tat. Tasten drücken und blind 
dem Taschenrechner vertrauen, ohne zu wissen das da im Prinzip im 
mHintergrund abgeht. Das war zu meiner Zeit schon ein Problem, heute ist 
es das noch viel mehr.
Nein, ich propagiere keinen Rechenschieber und auch kein ASM. Aber 
Grundlagenwissen!!!

Jeder Compiler erzeugt als Zwischenschritt Assembler. Und bisher 
brauchte ich diese Stufe bei jeder Architektur, weil bisher noch kein 
Compiler fehlerfrei war.

Man kann Assembler ignorieren so wie man eine Dichtung im Wasserhahn 
auch ignorieren kann. Aber trotzdem ist er ganz alltäglich. Und wenns 
drauf ankommt ist es gut, zu wissen, wie man die Dichtung ersetzt...

Verwundert schrieb:
> Die Masse hier dürfte einen Akkuschrauber nutzen. Aber ein paar Prediger
> raten ab und schwören auf den mehrfach angeschliffenen Schraubendreher
> mit Holzgriff.
Ich rate dazu, zu erkennen, für welche Aufgabe welche Schraube die 
richtige ist. Die stolzen Akkuschrauberbesitzer schrauben dann mangels 
weitergehenden Interesse alles mit ihren Spax zusammen, nur wiel sie 
nicht wissen, wofür die M10 Maschinenschrauben sind...

Oder andersrum: wer nur einen Hammer kennt, für den sieht die ganze Welt 
wie ein Nagel aus.

Verwundert schrieb:
> Hier im Forum kannst du gut erkennen wohin das führt. Die Jungs kennen
> nur avr und verteidigen die Dinger gegen alles und jeden.

Ich glaube da unterschätzt Du das Forum.

Viele dürften das Problem haben, einige Sachen hier einfach nicht 
ausdiskutieren zu können, weil da irgendwann auch 
Firmeninteressen/Know-How ins Spiel komt.

Darum halten sich die Leute da zurück und begrenzen sich nur auf das, 
was sie auch im Hobbybereich benutzen.

Grüße
Andreas

Verwundert schrieb:
> Die Jungs kennen nur avr und verteidigen die Dinger gegen alles und
> jeden.
Es bringt dann aber auch nichts, die ARM Cortex uC als alleiniges 
Allheilmittel anzupreisen. Oder gar für den Anfänger. Die kapieren ja 
schon den NVIC nicht...

> Die Jungs kennen nur avr und verteidigen die Dinger gegen alles und
> jeden.
Ich brauchte letzthin einen uC, den man parasitär über einen 10k Pullup 
eines Eingangssignals versorgen konnte: ATtiny9

Und ich brauchte einen, der einfach ein Display ansteuern kann: STM32F4

Fazit: man nimmt den uC, der die Aufgabe am besten packt.

@  Timer0 (Gast)


>Lothar M. schrieb:
>> Ich sage z.B. meinen daraufhin sichtlich schockierten
>> Praktikanten: ein "delay()" ist ein Programmfehler!

Jaja, die liebe Schwarz-Weiß Malerei . . .

>Sicher setzen die meisten "Arduino-Coder" die Funktion an den falschen
>Stellen zu falschen Zwecken ein, aber von pauschalisierenden
>Rundumschlägen würde ich trotzdem lieber Abstand nehmen.

Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen, 
allerdings dort, wo es sinnvoll und unkritisch ist. Einfaches Beispiel. 
Wenn ein Startbildschirm für ein paar Sekunden angezeigt werden soll, 
macht man das sicher NICHT mit einem Timer, denn die CPU hat in dem 
Moment so oder so nichts zu tun. Anderes Beispiel. Wenn man einen 
DMX-Datenstrom sendet, muss man immer wieder ein BREAK erzeugen. Das 
kann man mit einem Timer oder dem UART selber machen, muss man aber 
nicht. Ich habe dafür mehrfach ein _delay_us(100) genutzt, und das sogar 
in einem Timer-Interrupt!!! Jehova, Jehova!

> Ich habe dafür mehrfach ein _delay_us(100) genutzt, und das sogar
> in einem Timer-Interrupt!!! Jehova, Jehova!

_delay_us aus der AVRlibc läuft auch nur im Kreis, wärend die 
Arduino-Variant wohl per TimerInterrupt eine Variable hoch(runter) 
zâhlt. Das ist zwar etwas genauer, da keine ISR die Wartezeit 
verlängert, geht aber bei gesperrten INT's z.B. innerhalb einer ISR 
nicht.

Falk B. schrieb:
> Jaja, die liebe Schwarz-Weiß Malerei . . .
Wenn schon jedes Wort auf die Goldwaage gelegt werden muss, hier eine 
leicht überarbeitete Variante:

1

Ein _delay_ms() im Programmablauf ist fast immer ein Programmierfehler.

Oder andersrum:

1

Neun von zehn _delay_ms() sind unnötig.

Das waren dann auch genau die delay(), die ich den Praktikanten 
angekreidet und wegoptimiert habe. Es ist ja nicht "schlimm", wenn in 
der Initialisierung mal 50ms gewartet wird. Aber wenn sowas in jedem 
Durchlauf der Hauptschleife passiert, dann ist das nur kostspielige 
Rechezeitvernichtung.
Wie? Das Programm hat gar keine Hauptschleife? Das ist in 99% der Fälle 
auch ein Programmfehler. Oder eher ein Konzeptfehler...

> Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen,
> allerdings dort, wo es sinnvoll und unkritisch ist.
Mir scheint, dir ist die Problematik eines delay() bekannt.
Einigen anderen aber offenbar nicht, denn sonst käme nicht wöchentlich 2 
mal die Frage nach dem "abbrechbaren delay()".

@ Lothar Miller (lkmiller) (Moderator) Benutzerseite


>> Jaja, die liebe Schwarz-Weiß Malerei . . .
>Wenn schon jedes Wort auf die Goldwaage gelegt werden muss, hier eine
>leicht überarbeitete Variante:

Nun ja, du bist ja auch bei anderen Dingen für ABsolutismen bekannt, ich 
sag nur Entkoppelkondensator . . . 8-0

>Ein _delay_ms() im Programmablauf ist fast immer ein Programmierfehler.

>Neun von zehn _delay_ms() sind unnötig.

Damit kann man sich schon eher anfreunden. ;-)

>> Me too! Auch ich nutze regelmäßig die "bösen" delay-Funktionen,
>> allerdings dort, wo es sinnvoll und unkritisch ist.
>Mir scheint, dir ist die Problematik eines delay() bekannt.

Gerade so.

>Einigen anderen aber offenbar nicht, denn sonst käme nicht wöchentlich 2
>mal die Frage nach dem "abbrechbaren delay()".

Was zumindest ICH mit dem immer gleichen, weil immer gültigen Hinweis 
auf den schönen Artikel Multitasking beantworte.

Lothar M. schrieb:
> Wie? Das Programm hat gar keine Hauptschleife? Das ist in 99% der Fälle
> auch ein Programmfehler. Oder eher ein Konzeptfehler...

Nö. Bei Systemen mit (RT)OS gibt es entweder nur eine irgendwo im 
Scheduler o.ä. versteckte oder sogar gar keine echte Hauptschleife. Bei 
vielen Anwendungen mit kooperativem Multitasking sollte man es auch 
tunlichst unterlassen, auf Anwendungsebene Hauptschleifen zu 
implementieren, z.B. in SPS-Programmen.

Andreas S. schrieb:
> z.B. in SPS-Programmen.
Und gerade ein SPS Programm ist das Beispiel für eine Hauptschleife 
schlechthin. Dort wird nämlich das Programm an sich als Teil so einer 
Schleife ausgeführt. Und zwar möglichst schnell, ohne auf irgendwas zu 
warten (das nennt sich dann Zykluszeit). Natürlich darf man da nicht 
zusätzlich eine "eigene" Hauptschleife einführen, weil man dann ja das 
implizite Prozessabbild (Lesen und Schreiben der EA) komplett umgeht.

Am besten gefällt mir hier, dass SPS Programmierer (oft ohne es zu 
wissen) mit Zustandsautomaten arbeiten (die heißen dann Merkerketten).

Falk B. schrieb:
> Nun ja, du bist ja auch bei anderen Dingen für ABsolutismen bekannt, ich
> sag nur Entkoppelkondensator . . . 8-0
Es gibt für auch für Absolutismen eine Ausnahme. Allerdings muss man die 
dann auch jeweils gut begründen können. Und das kann man erst dann, wenn 
man den zugrunde liegenden Mechanismus verstanden hat.
Man könnte z.B. Fahranfängern sagen: fahre nur auf geteerten Wegen! Wenn 
dann die letzten 100m unbefestigt sind, dann darf er die mit gutem Grund 
mal "ausnahmsweise" fahren um sein Ziel zu erreichen. Aber wenn er 
sofort nach dem Losfahren über den nächten Feldweg in einen Wald fährt, 
dann darf er sich nicht wundern, wenn es recht schnell holprig wird... 
;-)

Und mit dem Verstehen sind wir wieder beim 8051 und dem AVR: diese wenig 
komplexen Controller kann man noch relativ leicht überblicken und 
begreifen. Und wenn man die dann kapiert hat, dann kann man sich nach 
Großem recken und sich mal den Registersatz eines I.MX6 oder auch nur 
die DMA oder den NVIC eines ARM zu Gemüte führen.

Lothar M. schrieb:
> Andreas S. schrieb:
>> z.B. in SPS-Programmen.
> Und gerade ein SPS Programm ist das Beispiel für eine Hauptschleife
> schlechthin.

Dann solltest Du mich nicht sinnentstellend zitieren!

> Natürlich darf man da nicht
> zusätzlich eine "eigene" Hauptschleife einführen, weil man dann ja das
> implizite Prozessabbild (Lesen und Schreiben der EA) komplett umgeht.

Genau. Bei einer S7 muss auch der OB1 einfach durchlaufen.

> Am besten gefällt mir hier, dass SPS Programmierer (oft ohne es zu
> wissen) mit Zustandsautomaten arbeiten (die heißen dann Merkerketten).

Für SPS-Programme in SCL/ST haben wir uns ein paar Vorlagen für 
Zustandsautomaten gebaut, die dann in den meisten FB verwendet (und dann 
durch OB aufgerufen) werden.

> Und mit dem Verstehen sind wir wieder beim 8051 und dem AVR: diese wenig
> komplexen Controller kann man noch relativ leicht überblicken und
> begreifen. Und wenn man die dann kapiert hat, dann kann man sich nach
> Großem recken und sich mal den Registersatz eines I.MX6 oder auch nur
> die DMA oder den NVIC eines ARM zu Gemüte führen.

Einer meiner Favoriten für das Erlernen akkumulatorbasierter 
Architekturen/Befehlssätze wäre der Z80. Anschließend vergleicht man 
solch einen Ansatz mit registerbasierten Prozessoren. Ebenfalls sehr 
hilfreich ist zu späteren Zeitpunkten die Beschäftigung mit Prozessoren, 
die eine sehr strenge Trennung der Adressräume für Daten und Programme 
haben, d.h. Harvard-Archikturen. Die krasseste Ausprägung dieser 
Trennung hatte ich bei einem Philips PCB5011 erlebt, der vier separate 
Adressräume mit völlig voneinander getrennten externen Bussen hatte: 
Programm, X-Daten, Y-Daten, ROM-Koeffizienten. Für Programm und 
ROM-Koeefizienten gab es nicht einmal Schreibbefehle. Die 
Daten-Datenbusbreite betrug 16 Bit, die Programm-Datenbusbreite 40 Bit. 
Mit solch einem Prozessor konnte man nicht wirklich gut arbeiten, 
weswegen er wohl auch keine nennenswerte Verbreitung erzielt hat. Das 
grundlegende Konzept findet man aber wiederum in VLIW-Architekturen 
wieder, d.h. in einem Programmwort befanden sich sechs  Befehle, die 
blockierungsfrei gleichzeitig ausgeführt wurden.

NEIN, ich empfehle NICHT den Aufbau und die Programmierung eines 
PCB5011-basierten Rechners für jedermann!