Was genau ist im Datenspeicher eines Mikrocontrollers drinnen?

Andy schrieb:
> Irgendwo hat es da einen Hacken aber wo?

Hat es nicht, es hat höchstens einen Haken.

Andy schrieb:
> dann benutzt man doch hauotsächlich
> die 16 verwendbaren Register zum rechnen oder um Werte einzuspeichern
> und anzuzeigen...

Und wo kommen die Werte her, die in die Register geladen werden? Wo 
werden die Resultate der Berechnungen abgelegt?

Wo liegt der Stack?

Der Haken ist, dass du die typischen Steuerungsaufgaben, für die µCs 
eingesetzt werden, oft schon realisiert bekommst, ohne Variablen im RAM 
zu benötigen. Schlicht deshalb, weil bei geschickter 
Assembler-Programmierung die Register oft ausreichen, um alle während 
des Programmlaufs veränderlichen Daten abzulegen.

Allerdings setzt du mit Sicherheit am Anfang deines Programms den 
Stack-Pointer. Und benutzt Befehle wie "CALL", "PUSH", "POP" und "RET". 
Und schon legst du jede Menge Daten im RAM ab, ohne dir dessen 
vielleicht bewusst zu sein.

Wenn du mal mehr Platz für deine Daten brauchst, benutzt du die Befehle, 
mit denen Daten zwischen den Arbeitsregistern und dem RAM ausgetauscht 
werden können. Die sind dir doch bestimmt bekannt? Von alleine passiert 
da natürlich nichts. Wenn du in Assembler programmierst, musst du dir 
natürlich selbst überlegen, an welche Adresse du welche Daten packen 
willst und wie darauf zugegriffen wird.

...
wobei Datenspeicher und RAM durchaus nicht identisch sein müssen!

Konstanten ( auch Tabellen und Text) sind auch Daten welche aber gern im 
Flash abgelegt werden oder im EEPrOM eben um sie nachträglich ändern zu 
können.

andereseits kan im flash ein interpreterHausen und das eigentliche 
programm im externen eeprom liegen wie auch daten.

so ist die Unterscheidung der Speicherbereiche zwar für die 
Programmestellung wichtig, aber der physische Speicherort wird durch die 
notwendigen Zugriffe bzw Latenzanforderungen bestimmt.

Weil im allgemeinen die variablen Daten weniger Speicherplatz erfordern 
als  Programm und Konstanten (+ modifizirbare Konstanten) findest du in 
µC meist viel mehr Flash und teilweise EEPROM als RAM wobei die erste 
RAMpage oft gleichzeitig die Register und Funktionsregister darstellt.

MfG

wer nicht will muss den RAM ja nicht benutzen...
für eine Operation ist der RAM ja auch total uninteressant.

Aber macht man mehrere Operationen hintereinander, wo man die Ergebnisse 
nicht sofort weiterbenutzt, hat man nicht genug Register um die 
zwischenzuspeichern ... und hier kommt der RAM ins spiel ... da 
Speichern im EEPROM zu langsam wäre und bei begrenzter Anzahl von 
Schreibzyklen auch nicht wünschenswert.

Und für Interrupts braucht man den Stack wo alle Register 
zwischengelagert werden, weil der Interrupt ja keine Ahnung hat in 
welchem Zustand er unterbricht. Und der Stack liegt, wie oben erwähnt, 
im RAM

>Wenn man in Assembler programmiert, dann benutzt man doch hauotsächlich
>die 16 verwendbaren Register zum rechnen oder um Werte einzuspeichern
>und anzuzeigen...

Zum Rechnen benutzt man nur die ALU (Arithmetik Logic Unit), daher
auch der Name. Je nach Chiparchitektur kann es auch mehrere ALUs geben.
Wenn nötig, kann man sich dabei anderer Register bedienen, falls nötig,
aber das geht dann nicht mit allen Registern.

>Die Arbeitsregister befinden sich aber im Prozessor drinnen. In wiefern
>haben diese Arbeitsregister jetzt mit den Datenspeicher zu tun?

Manche Register werden für die Adressierungsarten benötigt und einige
helfen dabei den Datenspeicher zu adressieren und zu verwalten. Andere 
Register haben andere Aufgaben und haben mit dem Datenspeicher wenig
oder nichts zu tun.
Müsste heute passen, wenn ich definieren soll was alles zum Prozessor 
gehört. Gewöhnlich sind beim Controller alle Register auf einem Chip. 
Früher war das ja alles noch aufwendig auf mehrere Chips verteilt
und war somit einfach beschreibbar. Vorbehaltlich würde ich alle 
Komponenten zum Prozessor zählen die keine peripheren Funktionen
haben, z.B. wie die I/O-Register.

>Im Programmspeicher stehen die Befehle drinnen die sich das Steuerwerk
>holt und dann analysiert. Wenn es jetzt eine Rechenoperation gibt dann
>schickt sie die Adressen der 2 Zahlen an die ALU (Rechenwerk) und dann
>wird gerechnet und das Ergebnis kommt dann sowieso wieder in ein
>Register rein und nicht in den Datenspeicher.

Einen Programmspeicher gibts hardwareseitig eigentlich nicht,
Datenspeicher oder Arbeitsspeicher ist die gängige Definition.
Von "analysiern" würde ich jetzt nicht sprechen, eher von "decodieren"
welche im Steuerwerk dann die dazugehörigen Operationen auslöst.
Der Speicher kann ausführbaren Programmcode und/oder Daten enthalten.
Wenn man sich einen Speicherblock mit einem Hexmonitor anschaut wird
man keinen großen Unterschied feststellen. Erst wenn man die Daten
über einen Disassembler anzeigt, ergeben die Bits und Byts einen Sinn,
vorausgesetzt die Startadresse stimmt, sonst wird der disassemblierte
Code nicht viel Freude bereiten(Absturz).
Assembler ist ja nur die (erste?) Generation einer Programmiersprache.
Ganz zu Beginn des Computerzeitalter benutzte man Schalter um
Programmcode oder Daten einzugeben. Später wurde die Programmierung
komfortabler mit Lochstreifenlesern und weiter dann mit Assembler und 
Hochsprachen wie Basic, C usw.
An die ALU werden gewöhnlich nur Daten geschickt, aber es mag 
Adresssierungsarten bei div. Architekturen geben wo das auch anders
geht. Allerdings müsste man für eine verlässlichere Aussage dann
schon den Prozessor kennen.
Die Difinition "Mikrokontroller" besagt ja nur, das außer dem
Prozessor auch Peripherie (Ram, ROM, I/O etc.) mit auf dem Chip ist,
oder ist da jemand anderer Meinung?
Das Ergebnis einer Rechenoperation steht, soviel ich mich noch erinnere
wieder in der ALU und überschreibt die Operanden, aber beschwören
will ich es jetzt nicht. Gewöhnlich muss man die Daten dann per Befehl
in den Arbeitsspeicher schreiben, das müsste richtig sein.

>Und für Interrupts braucht...
Nicht nur dabei, auch bei Unterprogrammaufrufen.

Irrtum vorbehalten.

Andy schrieb:
> Wenn man in Assembler programmiert, dann benutzt man doch hauotsächlich
> die 16 verwendbaren Register zum rechnen ...

16 Register werden also vorausgesetzt, klingt nach RISC. Man kann auch 
mit einem Universalregister (Akkumulator) glücklich werden, btw.

> Die Arbeitsregister befinden sich aber im Prozessor drinnen. In wiefern
> haben diese Arbeitsregister jetzt mit den Datenspeicher zu tun?

Stell Dir vor, Du kannst nur mit Registern als Argumenten rechnen. 
Irgendwoher müssen jedoch diese Argumente auch kommen, dafür bietet sich 
ein Speicher an.

> Im Programmspeicher stehen die Befehle drinnen die sich das Steuerwerk
> holt und dann analysiert.

Die Trennung von Daten- und Programmspeicher (wie bei der 
Harvard-Architektur) ist eigentlich irrelevant. So existiert diese 
Trennung bei der von mir persönlich favorisierten Architektur nach von 
Neumann gar nicht und trotzdem lässt sich mit diesen Dingern gut 
arbeiten.

> Wenn es jetzt eine Rechenoperation gibt dann
> schickt sie die Adressen der 2 Zahlen an die ALU (Rechenwerk) und dann
> wird gerechnet

Ich kenne deine Architektur nicht, aber wenn der entsprechende Befehl 
zwei Adressen kodiert, so werden wohl erst die entsprechenden Werte 
welche hinter diesen Adressen stehen geholt und dann verrechnet.

Beispiel: R=Register, $=Speicheradresse, Syntax: OP dst,src

Ausgangslage: R1=12, R2=4
ADD R1,R2; Addiere Register R2 zum Inhalt von R1
Ergebnis: R1=16
Das geht ziemlich schnell, da die Werte schon im Register sind.

Das dauert wohl etwas länger:
Ausgangslage R1=12, Value($2334)=4
ADD R1,$2334
Ergebnis: R1=16
Wird länger dauern, da erst nachgeschaut werden muß, welcher Wert sich 
hinter Speicherstelle 2334 verbirgt. Im schlechtesten Fall kann die 
Architektur gar keine Addition mit Speicherstellen und der Assembler 
kodiert die Anweisung "ADD R1,$2334" in folgendes:

PUSH R2; R2 koennte wichtige Daten enthalten, daher Sicherung -> Stack
LD   R2,$2334; Unser Argument, die Speicherstelle, ins Register laden
ADD  R1,R2; Jetzt können wir rechnen, R1=R1+R2
POP  R2;, Gesicherten Wert vom Stack nach R2 zurückholen

> und das Ergebnis kommt dann sowieso wieder in ein
> Register rein und nicht in den Datenspeicher.

Dumm nur, wenn man nur 16 Register hat, aber 17 Ergebnisse von 
Berechnungen braucht. Ohne Speicher eine Unmöglichkeite.

> Irgendwo hat es da einen Hacken aber wo?

Und Rechtschreibung ist ecklig, oder? ;-)

> lg Andy

hth, Iwan

PS: Im Architekturführer zu deiner Plattform (oft auch Programming Guide 
oder Instruction Guide genannt) steht das alles ganz genau drin, es 
lohnt sich immer dort hineinzuschnuppern.