Forum: Mikrocontroller und Digitale Elektronik Verständnis Problem bei der AVR- bzw. Harvard- Architektur


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von int 21h (Gast)


Angehängte Dateien:

Lesenswert?

Moin,

ich versuche mir schon seit geraumer Zeit ein Bild von den Internen 
Abläufen eines AVR Mikrocontrollers zu schaffen.
Die Blockdiagramme von der AVR Architektur und die vielen Videos über 
die Harvard Architektur auf YouTube sind ein guter Anfang, aber meiner 
Meinung nach nicht vollständig oder zu ungenau.
Bis her musste ich Stückchenweise Informationen aus diversen Büchern 
rausfiltern oder aus Internet Seiten beschaffen und vor allem eine Menge 
Improvisieren damit es für mich logisch erscheint...

Ich habe jetzt mal aus meinem Wissen heraus ein eigenes Diagramm 
entworfen und möchte die internen Abläufe während eines Zyklus hier 
wiedergeben, in der Hoffnung, dass man mich auf Fehler hinweist und... 
ich denke ihr wisst worauf ich eigentlich hinaus will.
Das Diagramm befindet sich im Anhang.

___________________________________
Vor dem Programmstart:
1. Programmierung des Bootloaders im Flash mittels Serieller 
Schnittstelle
2. Programmierung des Flash-Speichers mittels Bootloader (Wieso man das
   machen muss ist mir unklar)
___________________________________
Programm startet sobald der uC mit Strom versorgt wird:
   Steuerwerk holt die Programmzähler Variable aus dem Register
1. Steuerwerk holt Instruktion und beide Konstanten aus dem Flash
2. Steuerwerk lädt Instruktion in den Instruktions Decoder (wieso auch 
immer)
3. Steuerwerk lädt beide Konstanten in die Register
4. Alu verarbeitet die Daten, konfiguriert/schaltet Datenbus und gibt 
das
   Ergebnis weiter an den Datenbus (und evtl. Flags)
5. PC wird inkrementiert
6. Steuerwerk erhält die Anweisung noch mal von vorne zu beginnen
___________________________________

Wahrscheinlich macht das meiste von mir beschriebene überhaut keinen 
Sinn oder ist unschlüssig, deshalb erwarte ich auch nicht, dass man mir 
den Ablauf von Grund auf erklärt, aber eine sehr gute Quelle wäre 
Hilfreich.

Danke

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

int 21h schrieb:
> 2. Programmierung des Flash-Speichers mittels Bootloader (Wieso man das
> machen muss ist mir unklar)
Weil das auszuführende Programm zwingend im Flash liegen muss. Das ist 
ein "Nachteil" der Harvard Architektur: die Trennung von Daten- und 
Programmspeicher.

int 21h schrieb:
> Programm startet
Die Beschreibung des Programmablaufs könnte von einem beliebigen Rechner 
stammen. Daran ist nicht erkennbar, ob es ein Von-Neumann- oder ein 
Harvard- oder ein sonstiger Rechner ist. Auch ein Von-Neumann-Rechner 
kann/wird einen Flash-Speicher haben, um das Programm und 
Initialisierungswerte zu speichern.

: Bearbeitet durch Moderator
von Karl M. (Gast)


Lesenswert?

Hallo,

und diese Aussage ist falsch:

"Vor dem Programmstart:
1. Programmierung des Bootloaders im Flash mittels Serieller
Schnittstelle
2. Programmierung des Flash-Speichers mittels Bootloader (Wieso man das
   machen muss ist mir unklar)"

von (prx) A. K. (prx)


Lesenswert?

Zum Schema: Wären PC, SP und Flags Teil des Registerfiles, würden die 
Befehle wesentlich länger dauern als real.

von Viktor B. (coldlogic)


Lesenswert?

Der Ablauf vor dem Programmstart ist leider falsch. Vor jeglicher 
Programmierung hat man im Flash lauter Einsen. Deswegen, sollte man den 
MC mit Strom versorgen, wenn der nicht beschrieben ist, macht er nichts 
(alles 1 = NOP, No Operation oder auch invalid OP-Code, weiß nicht, wie 
es beim AVR gelöst ist). Um erstmal etwas ins Flash zu schreiben, 
benutzt man herstellerspezifische Schnittstellen, die betrachten wir 
hier mal nicht. Nehmen wir also an, wir hätten unser Programm schon als 
Abfolge von Bytes im Flash. Beim Anlegen der Spannung, wenn der evt. 
eingebaute Brownout Detection die Reset-Leitung loslässt, macht der MC 
das, was schon beschrieben war mit PC, Steuerwerk etc.
Wichtig: Der Bootloader ist auch nur ein Programm wie jedes andere. Was 
der macht ist - auf einer der seriellen Schnittstellen zuhören und, 
sollte etwas kommen, was nach einem Programm aus einer seriösen Quelle 
aussieht, dieses aus dem Buffer der Schnittstelle ins Flash zu 
schaufeln.
Und zu Punkt 2: versuch mal, das Steuerwerk als eine kombinatorische 
Schaltung zu zeichnen. Du wirst sehen, dass mehr Signale an die ALU 
nötig sind, als die Instruktion freie Bits bereitstellt. Das heißt, man 
braucht etwas, wo der OP-Code reinkommt und die Steuersignale an die ALU 
rauskommen. Genau diese Anhäufung von Logik ist dieses Instruction 
Decoder.

von W.S. (Gast)


Lesenswert?

int 21h schrieb:
> ich versuche mir schon seit geraumer Zeit ein Bild von den Internen
> Abläufen eines AVR Mikrocontrollers zu schaffen.

Dann vergiß dein Diagramm. Es ist schlichtweg falsch - und zwar in allen 
Teilen. Lies dazu lieber die Dokumentation zu den kleineren PIC's. also 
PIC16Fxxx und so. Dort ist das deutlicher dargestellt, um den Leuten zu 
erklären, daß es dort keine Load-Modify-Store Architektur gibt.

Du kennst hoffentlich den grundlegenden Unterschied zwischen Harvard und 
v.Neumann?

Das ist für den Programmierer der eigentliche Knackpunkt:
Bei Harvard ist der Programm-Raum schlichtweg getrennt vom Daten-Raum.

Das hat Konsequenzen:
1. ein Programm kann nicht aus dem Daten-Raum ausgeführt werden
2. für Daten und Konstanten braucht man getrennte Zugriffs-Mechanismen.
3. bei Zeigern muß man strikt untescheiden zwischen Zeigern in den 
Datenraum und Zeigern in den Programm- bzw. Konstantenraum.

Ansonsten weißt du ja, wa eine Turing-Maschine ist, falls dir nochmal in 
den Sinn kommt, ein Diagramm zu erstellen.

W.S.

von Soul E. (Gast)


Lesenswert?

Viktor B. schrieb:

> Wichtig: Der Bootloader ist auch nur ein Programm wie jedes andere.

Dein Bootloader. Also der, welchen der Anwender ins Flash geschrieben 
hat, um damit seine Applikation komfortabel aktualisieren zu können.

Jeder moderne Controller hat auch noch einen primären Bootloader. Der 
ist von Anfang an fest eingebaut und macht die Kommunikation mit dem 
Programmiergerät (über JTAG, SPI, LPD4, ...), initialisiert die Hardware 
(blendet z.B. gesperrte Flash-Pages aus) und übergibt dann beim normalen 
Systemstart die Kontrolle an das Anwenderprogramm bzw den von Anwender 
programmierten Bootloader (welcher auch nur ein Programm wie jedes 
andere ist).

Für die Atmel AVR-Familie sind einige Funktionen des primären 
Bootloaders in der Application Note "AVR910: In-System Programming" 
beschrieben. Mit dem kommuniziert man über SPI während der Reset-Pin auf 
Low liegt.

von c-hater (Gast)


Lesenswert?

Viktor B. schrieb:

> Der Ablauf vor dem Programmstart ist leider falsch. Vor jeglicher
> Programmierung hat man im Flash lauter Einsen.

Kommt drauf an. Es gibt auch Flash, der dann nur Nullen enthält.

> macht er nichts
> (alles 1 = NOP, No Operation oder auch invalid OP-Code, weiß nicht, wie
> es beim AVR gelöst ist)

Da ist der Flash tatsächlich so gestrickt, dass er unprogrammiert nur 
gesetzte Bits enthält. Allerdings wirken die (als Programm ausgeführt) 
nicht wirklich 100%ig wie NOPs, denn das wäre regulär das genaue 
Gegenteil: $00.
Im Wesentlichen tun sie aber effektiv schon das Gleiche wie ein 
regulärer NOP.
Der einzige wesentliche Unterschied ist diese Pseudo-NOPs brauchen zwei 
statt einem Takt pro Instruktion. D.h.: es dauert doppelt so lange, 
einen nicht initialisierten Programmspeicher zu durchlaufen, als wenn 
der nur Nullen enthalten würde.

von Axel S. (a-za-z0-9)


Lesenswert?

int 21h schrieb:

> ich versuche mir schon seit geraumer Zeit ein Bild von den Internen
> Abläufen eines AVR Mikrocontrollers zu schaffen.
> Die Blockdiagramme von der AVR Architektur und die vielen Videos über
> die Harvard Architektur auf YouTube sind ein guter Anfang, aber meiner
> Meinung nach nicht vollständig oder zu ungenau.

Praktisch jedes Datenblatt eines AVR Controllers enthält ein deutlich 
genaueres Blockschaltbild als dein "Werk" oben ...

> Ich habe jetzt mal aus meinem Wissen heraus ein eigenes Diagramm
> entworfen und möchte die internen Abläufe während eines Zyklus hier
> wiedergeben, in der Hoffnung, dass man mich auf Fehler hinweist

Auch das ist relativ ausführlich im Datenblatt beschrieben. Abschnitt 
"AVR CPU Core" und da spezifisch der Unterabschnitt "Instruction 
Execution Timing"

> Vor dem Programmstart:
> 1. Programmierung des Bootloaders im Flash mittels Serieller
> Schnittstelle

Ein AVR enthält nicht zwingend einen Bootloader. Ab Werk ist der Flash 
leer (gelöscht).

> 2. Programmierung des Flash-Speichers mittels Bootloader (Wieso man
> das machen muss ist mir unklar)

Es muß irgendwie ein Programm in den Flash gelangt sein. Das kann 
per Bootloader geschehen, muß aber nicht. Die weitaus meisten AVR 
dürften ihren Flash per ISP-Schnittstelle programmiert bekommen haben.

> Programm startet sobald der uC mit Strom versorgt wird:

Hier fehlt die Initialisierung durch das Hardware-Reset. U.a. werden 
dabei die meisten Register auf definierte Anfangswerte gesetzt.

>    Steuerwerk holt die Programmzähler Variable aus dem Register

Der PC ist keine Variable und auch kein (separates) Register. Der PC ist 
ein Teil des Steuerwerks.

> 1. Steuerwerk holt Instruktion und beide Konstanten aus dem Flash

Aus wievielen Worten ein Maschinensprach-Befehl besteht, ist von Befehl 
zu Befehl verschieden. Deswegen wird immer das erste Wort geholt und 
nach der Decodierung des ersten Worts weiß das Steuerwerk, ob und 
wieviel weitere Worte dazu gehören.

> 2. Steuerwerk lädt Instruktion in den Instruktions Decoder (wieso auch
> immer)

Das ist kein extra Schritt. Das erste Wort jedes Befehls wird direkt in 
den Decoder (respektive dessen Eingangsregister) geladen. Allerdings ist 
schon die Unterscheidung zwischen Steuerwerk und Befehlsdecoder 
merkwürdig. Der Decoder ist der wesentliche Bestandteil des Steuerwerks.

> 3. Steuerwerk lädt beide Konstanten in die Register
> 4. Alu verarbeitet die Daten, konfiguriert/schaltet Datenbus und gibt
> das
>    Ergebnis weiter an den Datenbus (und evtl. Flags)

Die ALU schaltet keine Busse. Das macht das Steuerwerk.

> 5. PC wird inkrementiert

Wenn die Instruktion mehr als ein Wort lang ist, wird er das auch 
zwischendurch schon mal.

> Wahrscheinlich macht das meiste von mir beschriebene überhaut keinen
> Sinn oder ist unschlüssig, deshalb erwarte ich auch nicht, dass man mir
> den Ablauf von Grund auf erklärt, aber eine sehr gute Quelle wäre
> Hilfreich.

Wenn du die internen Vorgänge verstehen willst, dann fang mit einem 
wesentlich einfacheren Prozessor an. Der 6502 wäre z.B. ein solcher. Auf 
http://visual6502.org/ gibt es dafür einen Simulator auf Chip-Ebene. Da 
kannst du den Transistoren beim Schalten zuschauen.

Oder halt eines der Selbstbau-CPU Projekte, die man im Netz findet. 
Irgendwas mit zwei Registern und einer 4-Bit ALU reicht für das 
Verständnis ja vollkommen aus.

Ob Harvard- oder von-Neumann-Architektur ist auf dieser Ebene übrigens 
nur ein relativ unbedeutendes Detail.

von (prx) A. K. (prx)


Lesenswert?


von Axel S. (a-za-z0-9)


Lesenswert?

A. K. schrieb:
> Details zur AVR Mikroarchitektur und dem Befehlsablauf:
> 
http://web.engr.oregonstate.edu/~benl/Courses/ece375.fa18/Lectures/Ch8_AVR_Microarchitecture.pdf

Nett. Aber ich befürchte, daß so viel Detail den TE überfordert.

Beitrag #5645688 wurde von einem Moderator gelöscht.
Beitrag #5646169 wurde von einem Moderator gelöscht.
von int 21h (Gast)


Lesenswert?

Axel S. schrieb:
> Wenn du die internen Vorgänge verstehen willst, dann fang mit einem
> wesentlich einfacheren Prozessor an. Der 6502 wäre z.B. ein solcher. Auf
> http://visual6502.org/ gibt es dafür einen Simulator auf Chip-Ebene. Da
> kannst du den Transistoren beim Schalten zuschauen.

Super, danke vielmals.
Das wird mir sicher sehr nützlich sein.

Aber erstmal 300 Seiten über die 6502 CPU lesen... das wird ein Spaß

von PC intern (Gast)


Lesenswert?

int21h ???

Ist das nicht der DOS interrupt? Wenn du vom PC kommst, musst du 
Umdenken. Die uCs arbeiten ihr Programm so ab, wie der PC das BIOS. Das 
war es dann.

von c-hater (Gast)


Lesenswert?

PC intern schrieb:

> int21h ???
>
> Ist das nicht der DOS interrupt?

Ja.

> Wenn du vom PC kommst, musst du
> Umdenken. Die uCs arbeiten ihr Programm so ab, wie der PC das BIOS. Das
> war es dann.

Nö. Auch unter DOS ist man noch sehr nah an den Grundkonzepten, die für 
heutige kleine µC relevant sind.

Größere µC können allerdings schon sehr stark in Richtung heutiger PC 
gehen, diesen vollständig erreichen oder sogar noch überschreiten. Da 
hast du dann alles, vom Speicherschutz über SIMD-Instructions bis hin zu 
FP-Einheiten und Crypto-Unterstützung und noch einen Haufen Scheiss 
mehr.

Und darüber hinaus u.U. sogar noch weiteres Zeug, was sich in einem PC 
normalerweise eher nicht findet, sondern allenfalls per Steckkarte 
nachgerüstet werden kann, z.B. programmierbare Logik. Wobei zumindest 
ein Teil dieser Sache sich natürlich auch mit den Fähigkeiten moderner 
GPUs abbilden lässt, die ja zum Teil auch schon wieder in die CPUs 
migriert sind.

Irgendwie scheint also alles in Richtung Eierlegende Wollmilchsau zu 
laufen. Unheimlich leistungsfähig, aber genauso unheimlich 
energiefressend...

Beitrag #5649916 wurde von einem Moderator gelöscht.
von Stefan F. (Gast)


Lesenswert?

UART mit einige zig Bytes Hardware-Puffer und Auto-Baudrate fände ich 
auch super.

Ich finde den Parallax Propeller interessant, wegen der Multitasking 
Fähigkeiten. Beim Lesen der Doku bekam mich allerdings so ein Gefühl, 
dass zwischen den Zeilen viele unerwartete Haken darauf warten, entdeckt 
zu werden.

von Mo~by (Gast)


Lesenswert?

c-hater schrieb:
> Irgendwie scheint also alles in Richtung Eierlegende Wollmilchsau zu laufen

Das Problem ist nur dass die "Sau" weitgehend dumm bleibt und alles und 
jedes und überhaupt immer mehr immer mühsamer zu konfigurieren ist. 
Besser wärs die Funktionalität würde nicht auf alles und jedes 
ausgeweitet sondern auf das begrenzt was meistgebraucht wirklich 
vonnöten ist, nur intelligenter! Kleines Beispiel UART: Immer mehr 
Fähigkeiten (die keiner braucht), dafür in der Konfiguration komplex und 
dumm wie ein Brot. Wie wärs man könnte die gewünschte Baudrate samt 
Anschlusspins direkt übergeben? Das Teil konfiguriert sich dafür selbst? 
Man könnte sich als Programmierer viele Vereinfachungen wünschen, der 
Zug fährt aber leider in die umgekehrte Richtung.

von S. R. (svenska)


Lesenswert?

Stefanus F. schrieb:
> UART mit einige zig Bytes Hardware-Puffer und
> Auto-Baudrate fände ich auch super.

Wie soll Auto-Baudrate eigentlich zuverlässig funktionieren? Wenn man zu 
einem bestimmten Zeitpunkt mit einer bekannten Sequenz starten kann 
(z.B. "AT" oder "ENTER"), dann geht das - aber so ganz allgemein?

Und was passiert, wenn die Erkennung mal schiefgeht, ist dann bis zum 
Neustart alles kaputt, oder stellt die UART nach jedem Byte die Baudrate 
neu ein?

von (prx) A. K. (prx)


Lesenswert?

S. R. schrieb:
>> UART mit einige zig Bytes Hardware-Puffer und
>> Auto-Baudrate fände ich auch super.
>
> Wie soll Auto-Baudrate eigentlich zuverlässig funktionieren?

Wenn ein Datenstrom nicht bloss aus sowas wie 0x0F besteht, sondern 
genug verschiedene Zeichen dabei sind, dann entspricht der kürzeste 
Abstand zweier Flanken ungefähr der Bitrate. Das kann man mit weiteren 
Flanken dann noch präziser bekommen.

: Bearbeitet durch User
von Soul E. (Gast)


Lesenswert?

Bei UART-Protokollen mit expliziter Autobaud-Unterstützung (z.B. LIN) 
sendet man ein definiertes Bitmuster (0x55) am Anfang jedes Telegrammes. 
Das erwartet der Empfänger und misst dort die Flanken aus. Dann wird 
entweder der Baudraten-Teiler oder der interne Highspeed-Oszillator 
nachgestimmt.

von c-hater (Gast)


Lesenswert?

Stefanus F. schrieb:

> Ich finde den Parallax Propeller interessant, wegen der Multitasking
> Fähigkeiten. Beim Lesen der Doku bekam mich allerdings so ein Gefühl,
> dass zwischen den Zeilen viele unerwartete Haken darauf warten, entdeckt
> zu werden.

Das einzige, was mich am Propeller fasziniert hat: Wie, zum Teufel, ist 
es eigentlich dazu gekommen, dass der tatsächlich in Stückzahlen 
produziert wurde? Denn eigentlich ist er ja nicht mehr als eine 
Konzeptstudie. Und naja, was aus dem Konzept nach der Evaluierung wurde: 
siehe Schicksal des "Propeller 2"...

War übrigens sicher nicht das erste fehlgeschlagene Multicore-Dingens. 
Ich kann mich da aus Amiga-Zeiten dunkel an etwas erinnern, was 
"Transmeta" hieß. Auch so ein Flop.

Wirklich praktisch umgesetzt wurde das Multicore-Konzept für kleine µC 
eigentlich nie. Es lohnt dafür einfach nicht. Die zusätzlichen Probleme 
können die Vorteile einfach nicht aufwiegen.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Ich kann mich da aus Amiga-Zeiten dunkel an etwas erinnern, was
> "Transmeta" hieß. Auch so ein Flop.

Aber kein Multicore. VLIW mit x86 Emulation, lange nach Amiga.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

A. K. schrieb:

> Aber kein Multicore. VLIW mit x86 Emulation, lange nach Amiga.

Verdammt, wie das Gedächtnis doch nachläßt. Also, nicht "Transmeta", 
sondern "Transputer" meinte ich.

Wobei: auch Transmeta hat mal irgendwie mit dem Amiga gemauschelt und 
ein Flop war's auch. Allerdings ganz ohne Multi-Core und deswegen 
wirklich bezüglich des Kontext wirklich eine völlig unpassende 
Erwähnung.

von Stefan F. (Gast)


Lesenswert?

S. R. schrieb:
> Wie soll Auto-Baudrate eigentlich zuverlässig funktionieren?

Wenn das so einfach wäre, hätten es alle.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Verdammt, wie das Gedächtnis doch nachläßt. Also, nicht "Transmeta",
> sondern "Transputer" meinte ich.

Nur bildeten die Transputer zwar ein Multiprozessor-System, weil dabei 
viele einzelne Cores in separaten Sockeln miteinander arbeiteten, aber 
um Multicore im heute üblichen Sinn von mehreren Cores in einem Sockel 
handelte es sich auch dabei nicht.

Gescheitert sind die Transputer letztlich auch an der Schere von 
Anspruch und Realität in Gestalt einer um Jahre verzögerten 
Weiterentwicklung. Um viel später in einem deutlich besseren Ansatz im 
Controller-Bereich als ZMOS wieder aufzutauchen (dahinter steckt der 
gleiche Kopf). Bei denen wiederum gibt es Multicores.

Beitrag #5650614 wurde von einem Moderator gelöscht.
von Moby (Gast)


Lesenswert?

8Bit und Multicore- technischer Ingenieurs-Blödsinn. Was es die 
Programmierung komplizierter macht steht in keinem Verhältnis zum 
Nutzen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.