Atmel AVR: Architektur und interner Adress-/Datenbus sind mir unklar!

Tino M. schrieb:

> Bei einem Atmega8 ist der Adressbus vom FLASH 16bit breit, Register,
> I/O, SRAM und EEPROM jedoch 8bit breit. Warum ist der Adressbus vom
> FLASH 16bit breit? Es handelt sich doch um einen 8-Biter!

Frag dich mal, was für Inhalte der Adressbus transportiert und wieviele 
Bits man dafür benötigt. Tip: Beim Mega8 sind es mehr als 8 und weniger 
als 16.

> Instruction Register und Instruction Decoder in 16bit ausgeführt ist,
> obwohl das General Purpose Register doch nur 8bit breit ist.

Und schau man in die Befehlssatzbeschreibung, wieviele Bits eines oder 
mehrerer Register bei indirekter Adressierung über Register verwendet 
werden (also Adressierung über die X/Y/Z-Register).

> Ist das soweit richtig?

Vom Verständnis her kein bischen. Du scheinst noch keinerlei Vorstellung 
davon zu haben, was Adressen und was Daten sind.

> In diesem Zuge frage ich mich auch, wie groß das größte externe EEPROM
> bei einem ATmega8 sein kann.

Unbegrenzt, wenn man es seriell anschliesst ;-).

Aufgrund der Harvard-Architektur muss man erst mal zwischen 
Programmspeicher (Flash) und Datenspeicher (SRAM) unterscheiden.

Das Flash hat eine Datenbusbreite von 16bit, da die Befehle 16bit breit 
sind (in 8bit würde man nicht genügend unterbringen können, da auch 
teilweise die Operanden mitcodiert werden).
Die Adressbusbreite richtet sich nach der Speichergröße.

Das SRAM hat 8bit Datenbusbreite (und hierüber erfolgt die Einstufung 
als 8bit-System!), die Adressbusbreite richtet sich auch hier nach der 
Speichergröße.

Tino M. schrieb:

> Sicherlich ist bekannt, was Adressen und Daten sind.
> Eine Adresse gibt an, wo die Daten liegen.

Und, was hat das jetzt damit zu tun, dass der AVR ein 8-Bit Prozessor 
ist?

In ein Einfamilienhaus passen maximal 4 Leute.

Aber in einer Strasse können Millionen von Einfamilienhäuser stehen. 
Jedes mit seiner eigenen Adresse, die natürlich größer als 4 sein kann.

> Die Daten findet man an der Adress-Stelle.
> Jede Adresse kann doch beim ATmega8 Bit aufnehmen?!

Nö

Der AVR kann 8-Bit an Daten in einem Rutsch verarbeiten, wobei es ein 
paar Ausnahmen gibt, aber im wesentlichen sind die Daten auf jeweils 8 
Bit limitiert.
Aber das heißt ja nicht, dass er sich diese 8_bit nicht auch aus einem 
Terrabyte großen Speicher holen kann, wenn die Adressregister nur groß 
genug sind.

Tino M. schrieb:
> Wenn ich bereits die Antwort auf meine Fragen wüsste, würde ich wohl
> kaum hier im Forum fragen, oder?

Man könnte ja auch Google benutzen ...

> Und diese Klugscheißerantworten à la "Unbegrenzt, wenn man es seriell
> anschliesst ;-)" gehen mir und anderen Anfängern tierisch auf den Sack!
> :(

Ja du ganz ehrlich - so ist es aber. Man kann alles anschließen soweit 
eine Schnittstelle vorhanden ist.

Ich würde hier nicht anfangen den großen Macker zu markieren. Da bist du 
nämlich hier definitiv falsch. Und schon garnicht wenn ich keine Ahnung 
habe (wie jeder Anfänger). Ich warne dich nur - du wirst hier gnadenlos 
zerlegt ... Hier im Forum ist dein 'Status' wichtig. Glaube mir als 
Anfänger hat man hier einen ziemlich schlechten. Lass dich nicht ärgern 
aber mach bloss keinen auf dicke Hose. Das könnnen wir hier nämlich 
garnicht haben. Und bitte unterlasse wüste Beschimpfungen (vielleicht 
mir) und anderen gegenüber. Gleiches gilt für süffisante Kommentare 
(z.B. 'Klugscheißer' und sowas).

Hi,

> Warum ist der Adressbus vom
> FLASH 16bit breit? Es handelt sich doch um einen 8-Biter!

Also ...

Die Breite des Adressbus gibt an, auf wie viele Adressen die CPU 
zugreifen kann.
Die Breite des Datenbus gibt an, auf wie breit die Daten sein können, 
mit der die CPU arbeiten kann.

Vorab:
2^8  = 256
2^16 = 65535

Beim AVR sind die Daten, die in der CPU verarbeitet werden können, 8 Bit 
breit (Wie das für Adresspointer aussieht, weiss ich gerad nicht, glaub 
der berechnet L, H getrennt). D.h., es wird mit 8Bit breiten Daten 
gerechnet.

Der Adressbus beim selbigen ist etwas grösser, nämlich 16Bit. D.h., der 
AVR ist in der Lage, 64k Adressen zu bearbeiten. Soll heissen, der AVR 
kann von 64k möglichen Adressen jeweils 8Bit Daten holen oder 
wegschreiben.


---
Das Dingen ist Havard Architektur. Das wiederum bedeutet, dass die CPU 
zwei Interfaces hat, jeweils aus Daten- und Adressbus bestehend:
- Programmspeicher (Flash)
- Datenspeicher & Peripherals

Er kann diese "gleichzeitig" bearbeiten, es treten keine 'Stalls' auf, 
wenn z.B. Mem geschrieben (Write Back) und der nä. Befehl (Instruction 
Fetch) geholt werden soll.
Das ist aber auch der Grund, warum Daten, die im Flash abgelegt wurden, 
mit PROGMEM gelesen werden müssen.


So, nun hab ich mich auf die Schnelle hoffentlich nirgends vertan :-)


VG,
/th.

Tino M. schrieb:

> Und diese Klugscheißerantworten à la "Unbegrenzt, wenn man es seriell
> anschliesst ;-)" gehen mir und anderen Anfängern tierisch auf den Sack!

Die weitaus meisten an Mikrocontroller extern angeschlossenen EEPROMs 
sind tatsächlich serielle Typen. Parallelen EEPROMs begegnet man fast 
nur noch in Altlasten und in der Lehre.

Wenn dir mein Stil, Leuten bei solchen Fragen eher beim Selberdenken zu 
helfen, indem die Richtung aber nicht das fertige Ergebnis geliefert 
wird, dann ignoriere es eben. Gleich rumzukotzen, wenn man auf die Frage 
keinen direkt fürs Referat verwendbaren Text geliefert bekommt, geht 
nämlich wiederum mir auf den Sack.

Tino M. schrieb:
> @Uwe...
> Danke für die Erklärung, die ist schlüssig.
> Neu ist für mich, dass die Einstufung der Systeme vom SRAM abhängig ist.


Du legst hier etwas zuviel Gewicht darauf.

Für die Einstufung ist in erster Linie entscheidend, mit welcher 
Datenbreite in der CPU gerechnet werden kann, wie breit die Register in 
der CPU sind. Dort entscheidet sich die Einstufung.

Der Transfer zum Speicher, ob der jetzt auf einem 8-Bit oder einem 
16-Bit Datenbus passiert, ist normalerweise nicht das entscheidende 
Kriterium.

Also: Kann die CPU 2 Zahlenwerte addieren, und zwar in einem Rutsch 
addieren, wenn beide Werte 16 Bit breit sind, oder muss sie das auf 2 
mal machen, weil es nur 8 Bit breite Register bzw. Additionsbefehle die 
nur 8 Bit bearbeiten gibt.

> @Karl heinz Buchegger
> Wenn der AVR auf eine Adresse zugreifen kann, kann dieser die 8 Bit in
> einem Rutsch dort rausholen, soweit richtig?

Ja.
Aber wie gesagt: Das ist meistens nicht das entscheidende Kriterium für 
die Einstufung einer CPU. Speicher-Bottlenecks kann man mit Caches 
entschärfen. Berechnungen auf mehrmals, wegen nicht ausreichender 
Reigsterbreite aber nicht.

Wobei es nicht gilt, wenn die CPU ein paar Spezialbefehle hat, die mit 
höheren Bitzahlen umgehen können. Entscheidend ist, wenn man sich den 
Befehlssatz ansieht, wie es mit der Mehrzahl der Befehle aussieht.

Und bei einem AVR kann die Mehrzahl der Befehle eben nur 8 Bit Einheiten 
in einem Rutsch bearbeiten. Für mehr Bits sind mehrere Befehle nötig.

Tino M. schrieb:

> @Random...
> Das klingt interessant, was du beschreibst!
> Durch die Havard-Architektur ist es also möglich gleichzeitig zu lesen
> und zu schreiben?!

Nicht in den gleichen Speicher, das sollte klar sein.
Aber Flash und SRAM parallel würde gehen. Ob man das auch macht ist eine 
andere Geschichte.

Denn deswegen macht man keine Harvard Architektur.
Man macht sie um eine saubere Trennung zwischen Daten und Programm zu 
haben. Damit ein Programm sich nicht so ohne weiteres selbst im 
Programmspeicher rumpfuschen kann.

> In diesem Zuge frage ich mich auch, wie groß das größte externe
> EEPROM bei einem ATmega8 sein kann. Eigentlich kommt es doch nur
> drauf an, wieviele Pins man für den Daten- und Adressbus zur
> Verfügung hat, oder?
> Nehmen wir mal an, ich habe 20 Pins frei (Steuerleitungen
> vernachlässigt).
> Der Datenbus ist 8bit breit, somit habe ich nur noch 12 Pins
> für den Adressbus zur Verfügung. Demnach kann ich ein
> EEPROM mit maximal (2^12)x8, also 4k x 8bit anschließen,
> richtig?

Nein falsch.
Du kannst ja zb auch einen Pin spendieren, um der externen Hardware 
anzuzeigen: jetzt liegt der High-Anteil von der Adresse auf den 11 
Adressleitungen, bzw. jetzt der Low-Anteil.
Du machst also ein Multiplexing auf dem Adressbus.
Dadurch hast du 22 Adressleitungen bekommen und kannst etwas über 4MByte 
adressieren.

Und ja. Sowas hat man schon gemacht.
Es gibt auch noch andere Mischformen: Wo sich Adress und Datenbus die 
gleichen Leitungen teilen.

Erlaubt ist, was gefällt und was umsetzbar ist. Alles nur eine Frage der 
Organisation.

Tino M. schrieb:

> man was fragt, sollte man es so formulieren: "Hey Leute, ich bin
> Profi-Programmierer, bin seit 34 Stunden auf den Beinen, halte mich mit
> 5 Liter Kaffee wach und irgendwie habe ich nun ein Brett vorm Kopf. Ich
> kann mich an die ADC-Routinen nicht mehr erinnern, kann mir einer ein
> Programm in C schreiben?! Danke!". *lach*

Der würde aber hier was zu hören bekommen.
Ebenfalls lach

Tino M. schrieb:

> Noch mal eine Frage zur Harvard-Archtitektur und internen
> Adressleitungen im AVR:
> Die Adressleitungen zum Programm-Code (Flash-Speicher) sind der Anzahl
> 16.

Da dieser AVR das Flash eingebaut hat, kann das so sein, muss aber 
nicht, wenn es nicht notendig ist, weil gar nicht soviel Speicher 
eingebaut ist. Wie genau Atmel das macht, da musst du Atmel fragen.

> Wenn ich jetzt 32 Register an die CPU hänge, wieviele Adressleitungen
> sind dort vorhanden?

Die Register SIND in der CPU. Die werden nicht drangehängt

> Soweit, wie ich das verstanden habe, werden intern 16 Adressleitungen
> verwendet, weil sich Anweisungen meist nicht mit 8 Bit zufrieden geben.
> Ein Register ist ein Byte groß, das ist bekannt. Aber es gibt auch
> Spezial-Register, z.B. der Program Counter, der ist nach meinen
> Erkenntnissen nämlich 16bit breit, nur wie werden diese adressiert? 8
> oder 16bit?

gar nicht. Die werden nicht adressiert. Zumindest nicht so, wie anderer 
Speicher adressiert wird. Die sind einfach da. Wenn ein Befehl eines 
dieser Register braucht, dann schaltet ein Transistor eines dieser 
Register auf den internen Datenbus. That's it. Mehr ist dazu nicht zu 
sagen. Jeder Befehl löst intern einfach nur Schaltvorgänge aus ohne das 
da irgendwelche Registeradressen im Spiel sind.

Alle diese Register zusammengenommen + eine Arithmetikeinheit SIND die 
CPU

Karl heinz Buchegger schrieb:

> gar nicht. Die werden nicht adressiert. Zumindest nicht so, wie anderer
> Speicher adressiert wird. Die sind einfach da.

Also Kuriosum sei am Rande mit dem CDP1802 von RCA ein früher 
Mikroprozessor genannt, dessen Program Counter ausnahmsweise kein 
derart implizit zugeordnetes Spezialregister war, sondern der 16 16bit 
Register hatte, von denen jedes als Program Counter verwendbar war. Es 
gab ein spezielles 4bit Register, das eines dieser 16 Register als 
aktuellen Program Counter definierte.