skriptum „mikrocontroller-systeme“ kapitel 8geju0001/mikrocontroller... · 2009. 10. 7. ·...

Hochschule Karlsruhe Fakultät Elektro- und Informationstechnik Studiengang Energie- und Automatisierungstechnik Dr. J. Hülsemann

Inhalt:

8 Mikrocomputer-Systemarchitekturen..........................................................2

8.1 Adressierung von Systemkomponenten..........................................................2 8.2 Multi-Master-Systeme.....................................................................................4 8.3 Timer / Counter .............................................................................................11 8.4 Schnittstellen und Schnittstellen-Bausteine ..................................................17

9 Optimierungsstrategien .............................................................................27 9.1 CISC- / RISC-Architektur.............................................................................28 9.2 Queue, Cache, Pipelining und Harvard.........................................................29

Skriptum „Mikrocontroller-Systeme“

Kapitel 8:

Mikrocomputer-Systemarchitekturen

Kapitel 9:

Optimierungsstrategien

Mikrocontroller 8.1 Adressierung von Systemkomponenten Seite 2 von 36

HS Karlsruhe, Studiengang Energie- und Automatisierungstechnik Dr. J. Hülsemann

V 1.00

8 Mikrocomputer-Systemarchitekturen • In den folgenden Kapiteln wird die Sichtweise erweitert: nicht mehr der

Mikroprozessor / Mikrocontroller mit seiner Arbeitsweise und Programmierung steht im Vordergrund, sondern das gesamte System Mikrocomputer, bestehend aus einem Prozessor, seinem Daten- und Adressbus sowie den daran angeschlossenen Systemkomponenten.

• Als Systemkomponenten wurden bisher betrachtet: Speicherbausteine (Kapitel 2.4) Ein-/Ausgabebausteine (Kapitel 3.3) Interrupt-Controller (Kapitel 7.4)

• In den folgenden Kapiteln werden als weitere Systemkomponenten vorgestellt: Speicherkarten (Kapitel 8.1) DMA-Controller (Kapitel 8.2) Zähler-/Zeitgeberbausteine (Kapitel 8.3) Schnittstellenbausteine (Kapitel 8.4)

8.1 Adressierung von Systemkomponenten • Bereits bei der Betrachtung der Ein-/Ausgabebausteine wurden die zwei möglichen

Verfahren, die am Systembus angeschlossenen Komponenten zu adressieren, vorgestellt:

Memory Mapped I/O (Speicherbezogene Adressierung der Ein-/Ausgabekomponenten)

I/O Mapped (Isolierte Adressierung der Ein-/Ausgabekomponenten)

• Dabei wurde sichtbar, dass der E/A-Baustein, der ja nur 4 Byte im Adressraum belegt und diese über die Adressbus-Leitungen A0 und A1 ausdekodiert, eine zusätzliche, externe Adressdekodierung benötigt:

Mikro-prozessor

D0 - D7

A0

Ver

glei

cher

(A

dres

s-D

ekoc

oder

)

/CS

A1

A2

Port A

Port B

Port C

Control Word

E/A-Baustein

A15

Abbildung 8-1: E-/A-Baustein mit externer Adressdekodierung

Externe Adress-dekodierung

Mikrocontroller 8.1 Adressierung von Systemkomponenten Seite 3 von 36


V 1.00

• In realen Mikrocomputersystemen ist meist der Adressraum, der durch die Anzahl der Adressbus-Leitungen vorgegeben ist, wesentlich größer, als der an dem Bussystem angeschlossenen Komponenten. Deshalb müssen diese Komponenten mit ihrem kleineren, internen Adressbereich im größeren, äußeren Adressraum durch zusätzliche, externe Adressdekodierer platziert werden.

• Am Beispiel einer Speicherkarte von 8kB Gesamtvolumen, die an einem Systembus mit 16-Bit-Adressbus angeschlossen ist, wird dies in der folgenden Abbildung dargestellt.

Abbildung 8-2: Speicherkarte mit 8kB

Erklärung: Die 8 Speicherbausteine haben jeweils 1 kByte Inhalt, der über ihren den eigenen Adressdekoder verwaltet wird. Entsprechend sind sie nur an den Adressbusleitungen A0 bis A9 des Systembus angeschlossen. Die Dekodierung der Adressbusleitungen A10 bis A12 übernimmt ein externer Dekoder, der für die Speicherbausteine die Chipselect-Leitungen CS0 bis CS 7 aktiviert. Damit sind die Speicherbausteine in einem Bereich von 8k adressierbar. Um jedoch die gesamte Speicherkarte im Adressraum von 64 k (16-Bit-Adressbus) platzieren zu können, wird über drei Schalter, die mit den Adressleitungen A15, A14 und A13 verglichen werden und nur bei Gleichheit den Decoder freigeben, eingestellt, in welchem 8-k-Adressbereich die Karte angesprochen werden kann (mit dem Dekoder können 8 Adressräume ausgewählt werden, jeder von diesen mit 8k Speicher).

Mikrocontroller 8.2 Multi-Master-Systeme Seite 4 von 36


V 1.00

• In Mikrocomputersystemen werden die Systemkomponenten - wie das obige Beispiel zeigt - meist hierarchisch adressiert. Damit kann der vorhandene Adressraum vollständig genutzt werden; es müssen jedoch entsprechende Dekodiereinrichtungen vorhanden sein.

Bit 15

0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

Bit 0

Karten-Adresse

Baustein-Adresse

Speicherzellen-Adresse

Abbildung 8-3: Adresshierarchie einer Speicherkarte

Frage: Die in Abbildung 8-3 dargestellte Adresse liegt in der Karte, die in Abbildung 8-2 dargestellt ist. Unter welcher Adress wird dieselbe Speicherzelle erscheinen, wenn man die Kartenadresse auf "000" stellt?

8.2 Multi-Master-Systeme • Bisher betrachtete Systeme sind sog. "Master-Slave"-System: der Prozessor als

Master liest und schreibt über den ADB / DB; die angeschlossenen Komponenten als Slaves beschränken sich darauf, die Adressen zu dekodieren und die Informationen über den DB in Empfang zu nehmen bzw. Informationen für den Prozessor auf den DB aufzuschalten. Dies kann (siehe Kapitel 2.4) mit synchroner oder asynchror Bus-Steuerung erfolgen.

• Im Folgenden soll dieses System um weitere Master ergänzt werden, wobei davon ausgegangen wird, dass weiterhin nur ein Systembus vorhanden ist. Daraus ergeben sich für ein Multi-Master-System folgende grundsätzliche Aufgaben, die unter dem Begriff "Bus-Arbitration" zusammengefasst werden:

Priorisierung der Bus-Zuteilung Anforderung und Zuteilung des Bus-Zugriffs Sicherung der Datenkonsistenz

• Grundsätzlich vorausgesetzt werden muss, dass die inaktiven Busmaster vom Bus abgekoppelt werden können; dies erfordert Tri-State-Logik der Bustreiber (siehe auch Kapitel 2.4).

• Grundsätzliche Anforderung an jede Art der Busarbitration: ein einzelnerLese- oder Schreibvorgang eines Teilnehmers darf nicht unterbrochen werden!

• Für die Bus-Arbitration können zwei Verfahren verwendet werden:

Lokale Arbitration: die Busmaster regeln den Buszugriff "untereinander"

Globale Arbitration: eine Zusätzliche Harware-Instanz, der

Busarbiter, entscheidet darüber, welcher Busmaster zu welchem Zeitpunkt den Bus zugeteilt bekommt.

Adress-Hierarchie

Master-Slave

Multi-Master Bus-Arbitration Lesen / Schreiben ununter-brechbar Verfahren zur Bus-Arbitration



V 1.00

• Bei der lokalen Busarbitration "besitzt" der Prozessor zunächst den Bus; zusätzliche masterfähige Teilnehmer können den Buszugriff beim Prozessor anfordern: sie sind eingeschränkte Busmaster. Ist der Prozessor bereit, übergibt er den Bus an einen dieser eingeschränkten Busmaster und koppelt sich selbst vom Bus ab. Der eingeschränkte Busmaster kann nun frei über die Buszugriffe verfügen.

• Einfachstes Realisierungsbeispiel für eine lokale Busarbitration ist das "Daisy Chain"-Verfahren ("Gänseblümchenkette"):

Abbildung 8-4: Daisy Chain

Hinweis: die Darstellung ist vereinfacht und reduziert auf die Steuerleitungen für die Priorisierung; Daten- und Adressbus selbst sind nicht dargestellt. Erklärung: Die einzelnen Master melden ihre Bus-Anforderung bei ihrem eigenen Arbiter an (Req) und erhalten dann, wenn der Arbiter den Bus bekommt, das Bestätigungssignal (Ack). Die Arbiter selbst melden die Bus-Anforderung über ein gemeinsames Sammelsignal (Req, alle Einzel-Anforderungen sind ODER-verknüpft) bei dem Mikroprozessor an. Dieser gibt sein Freigabesignal (frei) an den ersten Master bzw. dessen Arbiter in der "Daisy Chain" weiter. Hat dieser gerade keinen Bus-Bedarf, gibt er dieses "frei"-Signal an seinem Ausgang weiter an den nächsten Arbiter in der Kette. Wenn dieser den Bus benötigt, gibt er an seinem Ausgang statts des "frei"-Signals einfach das invertierte "nicht-frei"-Signal weiter. Der nächste Arbiter sieht an seinem Eingang das "nicht-frei"-Signal, kann also den Buszugriff nicht beanspruchen und gibt selbst dieses "nicht-frei"-Signal am Ausgang weiter. Ein Arbiter, der den Bus übernimmt, schließt also alle Arbiter rechts von sich von der Arbitrierung aus: die Prioritätsvergabe der Buszuteilungs ist durch die Anordnung der Teilnehmer in der "Daisy Chain"-Kette festgelegt. Mit der gemeinsamen "BUSY"-Leitung kann während eines Buszugriffs der nächste Arbiter bereits "frei" bekommen und den Buszugriff vorbereiten.

Lokale Bus-Arbitration: Beispiel Daisy Chain Priorität durch Reihenfolge



V 1.00

• Das "Daisy Chain"-Verfahren hat neben dem Vorteil, durch die lokale, dezentrale Arbitrierung wenig Schaltungsaufwand zu benötigen, den Nachteil, dass diese Art der Prioritätsvergabe für Teilnehmer immer "unfairer" wird, je weiter sie in der Kette vom Mikroprozessor entfernt sind.

• Macht man allerdings das Sammel-Anforderungssignal Req der einzelnen Arbiter rücklesbar (in der vorigen Abbildung dadurch kenntlich, dass das Signal mit einem Doppelpfeil zu den Arbitern führt), so kann der einzelne Arbiter bei einer Bus-Anforderung durch seinen Master diese Anforderung solange zurückstellen, wie er auf der gemeinsamen Sammel-Req-Leitung Anforderungen anderer Arbiter feststellt. Damit werden diese zuerst abgearbeitet.

Hinweis: Das "Daisy Chain"-Prinzip wird auch als einfaches Verfahren benutzt, um mehrere Interrupt-Quellen zu priorisieren: dabei wird aus dem "Req"-Sammelsignal in der oberen Abbildung das Sammel-Interrupt-Anforderungssignal an den Mikroprozessor; aus dem "frei"-Signal des Prozessors wird das Interrupt-Acknowledge-Signal.

• Ein weiteres Realisierungsbeispiel für eine lokale Bus-Arbitration stellt das Verfahren "Direct Memory Access (DMA)" dar. Hier soll der Mikroprozessor von der Aufgabe entlastet werden, Daten, die relativ langsam von einem Peripheriegerät geliefert werden (z.B. Floppy-Controller, Serielle Schnittstelle usw.) abzuholen und in den Speicher fortlaufend einzutragen. Diese Aufgabe übernimmt nun ein DMA-Controller, der allerdings dafür den Systembus benötigt (siehe folgende Abbildung). Im einfachsten Fall kann die Bus-Arbitrierung über zwei Signale gelöst werden: der DMA-Controller stellt die Anforderung mit dem HOLD-Signal, der Prozessor schaltet seine Bus-Treiber hochohmig und gibt den Bus an den DMA-Controller durch Aktivierung des HOLD-Acknowledge-Signals ab. Dann ist der Controller Bus-Master.

Abbildung 8-5: Direct Memory Access

Hinweis: Diese Darstellung ist stark vereinfacht!

"faire" Buszuteilung "Daisy Chain" zur Interrupt-Priorisierung

Lokale Bus-arbitration: Beispiel DMA-Controller



V 1.00

Hinweise: Das Peripheriegerät meldet das Vorhandensein von Daten ebenfalls über Handshake-Signale an den DMA-Controller. Der DMA-Controller kann die Daten aus dem Peripheriegerät direkt in den Speicher kopieren oder über einen Zwischenspeicher im Controller. Der DMA-Controller kann den Bus für die Übertragung eines einzelnen Datums belegen; dann "stiehlt" er dem Mikroprozessor einzelne Bus-Zyklen ("cycle steel mode") oder er überträgt ganze Datenblöcke ("burst mode").

• Wenn der Mikroprozessor während der Busbelegungszeit des DMA-Controllers nicht intern weiterarbeiten kann (z.B. bei Befehlen mit vielen Maschinenzyklen, jedoch ohne Zugriffsnotwendigkeit auf weitere Operanden, oder beim Einsatz von Cache-Speichern siehe Kap. 9.2), liegt der Vorteil beim Einsatz eines DMA-Controllers darin, dass für die Busbelegungszeiten der Mikroprozessor keinen Verwaltungsaufwand benötigt - wie das bei einem Interrupt-gesteuerten Abholen der Daten vom Peripheriegerät nötig wäre.

• Bei der globalen Busarbitration wird ein gemeinsamer, globaler Systembus von einem zentralen Busarbiter an mehrere Mikrocomputersysteme verteilt. Diese Mikrocomputersysteme stellen im allgemeinen Fall selbst wieder vollständige Systeme mit jeweils einem lokalen Prozessor dar, der über ein eigenes, lokales Bussystem mit dem lokalen Speicher, E/A-Geräten usw. verbunden ist.

• Die lokalen Mikrocomputersysteme teilen sich den globalen Systembus, um auf von allen gemeinsam genutzte Ressourcen zuzugreifen, wie z.B. globale Speicher zur Datensicherung, E/A-Peripherie oder Kommunikationsgeräte.

Abbildung 8-6: Globaler Arbiter

Zeitvorteil bei DMA

Globale Busarbitration



V 1.00

Erklärung: Jedes Teilsystem fordert mit dem Signale "BREQ" den globalen Buszugriff beim Busarbiter an; dieser verbindet dann - je nach Priorität des Teilsysems - den lokalen Bus mit dem globalen Bus und gibt das "ACK"-Signal zurück.

• Der globale Arbiter kann unterschiedliche Vergabeprinzipien beherrschen; einige sind im Folgenden aufgelistet:

Prioritäts-Steuerung: Jedes Teilsystem besitzt eine feste (oder auch veränderliche) Priorität, nach der die Busvergabe erfolgt.

Zeitscheibenverfahren: Der Bus wird in einem festen Zeitraster (Fenster) von einem Teilsystem zum nächsten weitergeschaltet. Vorteile: einfacher Aufbau des Arbiters, faires, deterministisches Verfahren Variante dazu: Der Bus wird fortlaufend, ohne festem Zeitraster, einem Teilsystem nach dem anderen angeboten; hat ein Teilsystem Bedarf, hält es den Bus mit dem Signal "LOCK" fest. Vorteil: keine ungenutzen Busfenster, trotzdem faires und deterministisches Verfahren (wenn die "LOCK"-Zeit der Teilnehmer fest ist).

Bus-Token-Verfahren: Das Zugriffsrecht auf den Bus wird möglichst fair, aber gesteuert durch die Anforderung der einzelnen Teilsysteme weitergegeben. Vorteil: kein Zeitverlust durch unnötiges Weiterschalten des Bus'.

• Mit dem Signal "LOCK" können zwei verschiedene Aufgaben in Multimastersystemen gelöst werden:

"Festhalten" des gerade zugeteilten Bus, z.B. um das Weiterschalten zwischen zwei Lesevorgängen (oder Schreibvorgängen) zu verhindern und so einen Blocktransfer von Daten zu ermöglichen. Dies verbessert das Verhältnis von Nutzungszeit zu Umschaltzeit und damit den Gesamtdurchsatz. Seine Grenze ist (s.o.) durch die Anforderung der Deterministik und der fairen Vergabe gegeben.

Semaphor-Technik (wird im Folgenden erklärt)

• Die Semaphore-Technik wird in Multimaster-Systemen benötigt, wenn mehrere Prozessoren über einen globalen Bus auf gemeinsame Betriebsmittel, wie z.B. einen bestimmten Speicherbereich im Globalspeicher oder ein globales E/A-Gerät, zugreifen wollen. Das gemeinsam genutzte Betriebsmittel wird dann über eine Semaphore geschützt: dies ist eine zwischen allen Teilnehmern vereinbarte, aber ansonsten beliebige Speicherzelle im Globalspeicher, in der für das zu schützende Betriebsmittel ein "Besetzt"/"Frei"-Zeichen eingetragen werden kann.

• Ein Prozessor, der auf das Betriebsmittel zugreifen will, muss zuvor die Semaphore auslesen: steht dort "frei", darf er selbst "besetzt" eintragen und anschließend beliebig auf das Betriebsmittel zugreifen. Ein anderer Prozessor, der in der Zwischenzeit ebenfalls auf das Betriebsmittel zugreifen will, prüft ebenfalls die Semaphore, liest aber dort bereits "besetzt"; darf also vorläufig nicht zugreifen.Um zu erfahren, wann das Betriebsmittel wieder freigegeben ist, muss der zweite Prozessor jetzt die Semaphore immer wieder auslesen (pollen).

Vergabe-Prinzipien bei der globalen Arbitrierung Bus-LOCK

Semaphore



V 1.00

Beispiel: Der gemeinsam von den Prozessoren A und B genutzte Speicher ist als "Dual ported RAM" ausgebildet: er kann von den beiden Prozessen sozusagen von links und von rechts beansprucht werden. Die Verteilung der Zugriffe über zwei Bus-Systeme mit einem globalen Arbiter (in der folgenden Abbildung nicht dargestellt) sorgt dafür, dass nach jeweils einem kompletten Lesevorgang (Schreibvorgang) des einen Prozessors der andere Prozessor ebenfalls einen Lesevorgang (Schreibvorgang) durchführen kann.

Abbildung 8-7: Dual ported RAM mit Semaphorzelle

Der Algorithmus zur Zugriffsprüfung über die Semaphorzelle, den Prozessor A und Prozessor B beide bearbeiten müssen, bevor sie auf den gemeinsam genutzten Speicher zugreifen dürfen, ist in der folgenden Abbildung dargestellt.

Anwendung einer Semaphor-zelle



V 1.00

Abbildung 8-8: Semaphor-Algorithmen mit Bus-Weitergabe

Erklärung: Der kritische Fall tritt dann auf, wenn die beiden Algorithmen zeitversetzt so bearbeitet werden, dass nach dem Auslesen der Semaphorzelle durch A der Bus durch den Arbiter an Prozessor B weitergegeben wird (Markierung mit dickem Pfeil in der Abbildung)! Beide würden dann zeitversetzt feststellen, dass die Semaphore frei ist, und sie dann beide für "besetzt" erklären. Dieses Problem kann nur gelöst werden durch ein Bus-LOCK-Signal, wie es in der folgenden Abbildung dargestellt ist.

Abbildung 8-9: Sperren des Semaphor-Lesens mit Bus-LOCK

Beispiel: Semaphore und Bus-LOCK-Signal

Mikrocontroller 8.3 Timer / Counter Seite 11 von 36


V 1.00

• Multimastersysteme benötigen für das Semaphor-Verfahren unbedingt einen Bus-Lock-Mechanismus: dieser kann auch durch den Prozessor in Form eines Read-Modify-Write-Befehls realisiert werden. Dabei wird die Semaphore ausgelesen und im selben - nicht unterbrechbaren - Buszyklus das "besetzt"-Zeichen eingetragen.

• Das bisher vorgestellte Semaphor-Prinzip geht von einer binären Semaphore aus: in der Semaphor-Zelle steht lediglich die Information "besetzt/frei". In Multimastersystemen kann dieses Verfahren erweitert werden um "zählende" Semaphoren: es wird dann zusätzlich eingetragen, durch welchen Master das gemeinsame Betriebsmittel belegt ist.

8.3 Timer / Counter • Zur Bildung von Zeiten kann man in Mikrocomputersystemen von der Tatsache

Gebrauch machen, dass der Takt eines solchen Systems meist von einem Quarz-Oszillator stammt und damit sehr genau bekannt ist. Deshalb können Programmlaufzeiten taktgenau berechnet werden und damit zur Zeitbildung verwendet werden. Je nach Länge der benötigten Zeit können diese Zeiten auch durch "Schachtelung" von Programmschleifen erzeugt werden (siehe folgendes Struktogramm).

Abbildung 8-10: Schachtelschleifen zur Zeitbildung

Hinweis: Dieses Verfahren entspricht dem "beschäftigten Warten": der Prozessor verschwendet 100 % seiner Rechenzeit darauf, auf den Ablauf eines Zeitprogramms zu warten.

• Eine Zeitbildung durch eigene Timerbausteine entlastet den Prozessor von diesen Aufgaben. Timerbausteine zählen den Systemtakt; sie müssen vom Prozessor zunächst parametriert und gestartet werden, arbeiten dann aber selbständig. Timerbausteine können auch zum Zählen von extern anschließbaren Signalen verwendet werden. Damit kann mit Timer/Counter-Bausteinen eine Vielzahl von Aufgaben gelöst werden.

Zählen von Impulsen Messen von Zeiten und Frequenzen Erzeugen von Impulsen Erzeugen von Pulsweitenmodulation (PWM)

Semaphore mit Read/Modify/Write Zählende Semaphore

Zeitbildung durch Programmlaufzeit

Zeitbildung durch Timer-Bausteine



V 1.00

• Als Beispiel für einen externen programmierbaren Intervalltimer (PIT) ist in der folgenden Abbildung der Zähler/Zeitgeber 8253 (INTEL) dargestellt:

Abbildung 8-11: Zähler-/Zeitgeberbaustein 8253

Erklärung (Auszug aus dem Manual): Der Baustein wird am Systembus angeschlossen und bietet drei unabhängige 16-Bit-Zähler, die jeweils mit einem eigenen Taktsignal CLK arbeiten. Der GATE-Eingang kann zum externen Triggern des Zählens verwendet werden; der Ausgang OUT zur Ausgabe von Signalen (hier kann z.B. der Interrupteingang des Mikroprozessors angeschlossen werden). Die Zähler sind über den Systembus jederzeit vom Prozessor auslesbar und beschreibbar. Das Steuerwortregister dient zur Parametrierung durch den Prozessor: hier können sechs verschiedene Betriebsarten eingestellt werden. Allen Betriebsarten gemeinsam ist, dass die Zähler von einem Anfangswert (der vom Prozessor vorgegeben wird) herunterzählen.

• Drei Beispiele für die einstellbaren Betriebsarten: Nach dem Einschreiben des Anfangswertes wird dieser über den

CLK-Eingang heruntergezählt; beim Erreichen von "0" wird das OUT-Signal aktiviert und der Zähler bleibt stehen.

Programmierbares Monoflop: eine pos. Flanke am Gate-Eingang startet das Herunterzählen; das OUT-Signal bleibt solange aktiviert, bis "0" erreicht ist.

Periodische Erzeugung von Nadelimpulsen: nach n Takten (n ist der Zähler-Anfangswert) geht das OUT-Signal jeweils für einen Takt auf "0".

Betriebsarten des Timer/ Counter-Bausteins 8253



V 1.00

• Als Beispiel für On-Chip-Timer/Counter eines Mikrocontrollers sind imFolgenden die Bausteine des C517 dargestellt: hier gibt es drei allgemein verwendbare Timer und einen Vergleichszähler (Compare timer, wird hier nicht weiter betrachtet).

• Auch diese Timer können in verschiedenen Funktionsweisen (Modus) benutzt werden, die man über das Timer-Modus-Register TMOD einstellen kann (Auszug):

Modus 0: 8-Bit Timer/Counter mit 1/12 Teiler Modus 1: 16-Bit Timer/Counter Modus 2: 8-Bit Timer/Counter mit automatischem

Nachladen (reload) eines 8-Bit-Wertes

• Die folgenden Abbildungen zeigen als Beispiel den Timer 0 im Modus 1 und Modus 2 in der Blockschaltbild-Darstellung.

Abbildung 8-12: Timer 0 , Modus 1 des C517 / Siemens Manual /

Erklärung: Über das Steuerbit C/T im TMOD-Register wird zwischen dem Zählen von externen Impulsen am Port P3.4 und der Zeitbildung durch Zählen der Oszillator-Frequenz mit 1/12-Vorteiler umgeschaltet. Control ( eigentlich über Gate im TMOD-Register UND TR0 im TCON-Register gesteuert): der Zähler wird entweder nur über den Start/Stop-Schalter TR0 gesteuert, oder über einen zusätzlichen Pegel am Interrupteingang INT0 (Verwendung zur Pulsweiten-Messung) . TL0 und TH0 bilden zusammen das eigentliche Zählerregister mit 16 Bit. Der Zähler zählt grundsätzlich nur aufwärts; beim Durchgang durch "0" wird das TF0-Bit gesetzt und - falls per Software mit TR0 der Zähler nicht angehalten wird - weitergezählt ab "0". Das Überlaufbit TF0 kann mit der passenden Interrupt-Parametrierung zum Auslösen eines Interrupts verwendet werden (siehe dazu das Beispiel auf der nächsten Seite).

Timer/Counter des C517 Modus

Modus 1: 16-Bit Timer



V 1.00

Abbildung 8-13: Timer 0, Modus 2 / Siemens Manual /

Erklärung: Ist der Modus 2 eingestellt, arbeitet der Timer als 8-Bit-Timer/Counter. Ein Überlauf des Zählregisters TL0 setzt dann allerdings nicht nur das Flag TF0, sondern lädt automatisch aus dem Register TH0 den dort eingetragenen Wert wieder in das TL0-Register (reload). Hinweis: Das Register TMOD ist nicht bitadressierbar!

Beispiel: Timer 1 soll bei Aufruf eines Unterprogamms einmalig einen Impuls von 100 Mikrosekunden Länge am Portbit P4.7 ausgeben. Er soll dabei im 16-Bit-Modus arbeiten; Timer 0 darf nicht beeinflusst werden. Die Taktfrequenz beträgt 12 MHz. 12 MHz--> Zähltakt ist dann 1 MHz entsprechend 1 Mikrosekunde. Die Zahl +100d (0064 h) muss wegen des Aufwärtszählens in -100d (FF9C h) umgewandelt werden.

INIT: ANL TMOD, #0Fh ; für Timer1 alle Steuerbits =0 ; d.h. GATE und C/T=0: freilaufender ; Timer am Systemtakt ORL TMOD, #10h ; für Timer 1 Modus 1 einstellen ; (Abb. 8-12 und Abb. 8-14) MOV TH1, #0FFh ; Zählwert vorbesetzen MOV TL1, # 09Ch SETB TR1 ; Start von Timer 1 SETB P4.7 ; Impulsausgabe=1 SETB ET1 ; Interrupt bei Timer 1-Überlauf ; (siehe Abb. 7-14, Register IEN0) SETB EAL ; alle Interrupts freigeben RET (Fortsetzung nächste Seite)

Modus 2: 8-Bit Reload-Timer

Beispiel für Timer 1



V 1.00

Fortsetzung: Interrupt-Serviceroutine bei Timer-1-Überlauf:

ORG 001Bh ; Interrupt-Vektor für Timer 1, ; (siehe Abb. 7-12) CLR P4.7 ; Impulsausgabe auf 0 CLR TR1 ; Timer 1 anhalten RETI Hinweis: In diesem Fall ist ein Aufruf eines eigenen Interrupt-Unterprogramms nicht nötig, da die obigen Befehle direkt in der Vektor-Einsprungtabelle genügend Platz haben.

• Die folgenden Abbildungen zeigen das Timer-Control-Register TCON und das Timer-Modus-Register TMOD. Informationen über weitere Modus befinden sich im Siemens Manual.

Abbildung 8-14: TCON-Register

Register TCON



V 1.00

Abbildung 8-15: TMOD-Register

Register TMOD

Mikrocontroller 8.4 Schnittstellen und Schnittstellen-Bausteine Seite 17 von 36


V 1.00

8.4 Schnittstellen und Schnittstellen-Bausteine • Die Übertragung von digital codierter Information zwischen Teilnehmern ist am

Beispiel eines ganzen Mikrocomputersystems, bestehend aus Prozessor, Speicher, E/A-Bausteine usw. bereits ausführlich betrachtet worden: die Teilnehmer sind hier über Datenbusleitungen miteinander verbunden. Über diese Datenbusleitungen wird die Information parallel übertragen; pro Bit der Information steht zur Übertragung eine eigene Leitung zur Verfügung.

• Sollen mehrere Informationseinheiten übertragen werden, werden diese nacheinander, also seriell über den parallelen Kommunikationsweg übertragen. Dafür ist ein zwischen den Teilnehmern vereinbartes Verfahren (siehe Kapitel 2.4) notwendig: ein Protokoll.

• Werden nicht nur die Systemteilnehmer über den Systembus verbunden, sondern externe Geräte an ein solches System angeschlossen, bezeichnet man diese Verbindung als Schnittstelle (Interface). Wird in einer Zeiteinheit mehr als ein Bit (über mehr als eine Datenleitung) übertragen, handelt es sich also um eine parallele Schnittstelle.

• Vorteil einer Parallel-Schnittstelle: je mehr Leitungen, umso mehr Informationen können zeitgleich übertragen werden.

• Nachteil einer Parallel-Schnittstelle: je mehr Leitungen, umso teurer wird das Kabel.

• Beispiel für eine Parallelschnittstelle: "Centronics-Schnittstelle". Sie ist im PC-Bereich zum Anschluss von Druckern ("LPT") verbreitet und wurde benannt nach einer Herstellerfirma für Drucker. Ursprünglich ein reiner Industriestandard, ist sie in erweiterter Form seit 1994 unter IEEE 1284 normiert.

• Übertragungsraten der Centronics-Schnittstelle sind Geräte-abhängig bis zu einige 1000 Bytes/Sekunde über eine Entfernung von bis zu 5 m.

• Für die Realisierung dieser Schnittstelle wird meist ein Paralle-Portbaustein vom Typ 8255 verwendet (siehe Kapitel 3.3).

• Das Centronic-Kabel besteht aus 36 Adern mit 25-poligem PC-seitigem Stecker (Cannon) und 36-poligem, Drucker-seitigem Stecker (Amphenol).

Abbildung 8-16: Centronics-Stecker (oben: Amphenol, unten: Cannon)

Parallele Übertragung Parallele Schnittstelle Beispiel für parallele Schnittstellen: Centronics-Schnittstelle



V 1.00

• Ein Blick auf die Kontaktbelegung der Centronics-Schnittstelle zeigt, dass von den 36 Leitungen alleine 18 Leitungen als Masseleitungen verwendet werden, während lediglich 8 Leitungen (D0 bis D7) zur parallelen Informationsübertragung (Byte-parallel) dienen.

Abbildung 8-17: Centronics-Steckerbelegung

• Den Ablauf einer Datenübertragung zwischen Rechner und Drucker über ein Hardware-Protokoll ("Handshake") zeigt die folgende Abbildung.

Hinweis: Die folgendeDarstellung zeigt die logische Sicht; dabei gilt wieder: / Signal bedeutet "low-aktives Signal" Um die physikalische Sicht, also die Zustände der Signalleitungen zu erhalten, benötigt man die Zuordnung zwischen logischer Sicht und physikalischer Sicht. Die Centronics-Schnittstelle verwendet hier den sog. "TTL-Pegel" ("transistor-transistor-logic"): Low entspricht 0 - 0,8 V High entspricht 2 - 5 V

Logische und physikalische Darstellung TTL-Pegel



V 1.00

Daten

/ STROBE

BUSY

/ACKN

Abbildung 8-18: Centronics-Handshake beim Drucken

Erklärung: Daten: Der Rechner aktiviert die Datenleitungen D0 bis D7

entsprechend der zu übertragenden Information STROBE: Der Rechner zeigt an, dass die Daten gültig sind BUSY: Der Drucker hat die Daten übernommen, druckt und meldet

während dieser Zeit "beschäftigt" ACKN: Der Drucker meldet "bereit für neues Zeichen"

• Zur Informationsübertragung über längere Strecken ist wegen der Kabelkosten eine bitserielle Übertragung besser geeignet. Die einzelnen Bits der Information werden dabei - im einfachsten Fall über eine Zweidrahtleitung - zeitlich nacheinander als Spannungs- oder Strom-Zustand codiert übertragen.

• Als Betriebsart einer solchen Übertragungsstrecke gibt es drei Möglichkeiten: Simplex Nur eine Richtung der Übertragung (Sender-->Empfänger) Halb-Duplex Datenübertragung in beide Richtungen möglich, jedoch nicht

gleichzeitig. An beiden Seiten der Übertragungsstrecke exisitert jeweils Sender und Empfänger, die sich wahlweise auf die Strecke aufgeschaltet werden können.

Duplex Datenübertragung gleichzeitig in beide Richtungen möglich.

• Die notwendige Synchronisation zwischen Sender und Empfänger wird mit zwei verschiedenen Verfahren erreicht:

Synchrone Datenübertragung Hier wird entweder über ein zusätzliches Taktsignal die Synchronität erzwungen, oder Sender und Empfänger besitzen Taktgeneratoren gleicher Frequenz, müssen aber in regelmäßigen Abständen ihre Takte "nachstellen". Dies erreicht man durch das Übertragen von speziellen Synchronisationszeichen nach jedem Block von Nutzzeichen.

Serielle Übertragung

Simplex Halb-Duplex Duplex

Synchrone Übertragung



V 1.00

Asynchrone Datenübertragung Sender und Empfänger besitzen eigene Taktgeneratoren gleicher Frequenz. Die Synchronisation erfolgt nach jedem einzelnen Zeichen (üblich: 5 bis 8 Bit pro Zeichen) dadurch, dass die Zeichen in einen festen Rahmen, bestehend aus Startbit und Stopbit, verpackt werden.

• Im Folgenden wird die Asynchrone Datenübertragung detailliert beschrieben. • Die Übertragungsgeschwindigkeit bei der seriellen Übertragung wird in "Anzahl

von Bits pro Sekunde" angegeben. Durch mitübertragene Synchronisationszeichen ist die effektive Übertragungsrate, bezogen auf die Nutzzeichen, immer kleiner als die Übertragungsgeschwindigkeit der Schnittstelle. Als "Schrittgeschwindigkeit" wird die Anzahl der Taktschritte pro Sekunde bezeichnet; diese hat die Einheit

1 Baud (Bd) = 1 Taktschritt / Sekunde Bei modernen Übertragungsverfahren wird pro Taktschritt mehr als ein Bit übertragen; hier ist die "Bauderate" nicht gleich der Übertragungsgeschwindigkeit.

• Der Zeichenrahmen (Telegramm-Aufbau) bei der asynchronen Übertragung ist in der folgenden Abbildung dargestellt.

01 0 0 1 1 1 0 0 1 space

mark

Start-bit

Stop-bit

LSB MSB

Paritäts-bit

Abbildung 8-19: Asynchroner Zeichenrahmen

Hinweis: Diese Darstellung zeigt die logische Sicht! Die physikalische Sicht erhält man aus den nachfolgenden Festlegungen.

• Der Ruhezustand der Übertragungsleitung wird "mark", der aktive Zustand der Übertragungsleitung wird "space" genannt.

• Der Sychronisationsrahmen wird gebildet durch Start-/Stopbit; das Startbit hat immer den Zustand "space", das Stopbit immer "mark".

Asynchrone Übertragung

Übertragungs-geschwindig-keit Baud

logische Sicht: mark / space Start-/Stopbit



V 1.00

• Als zusätzliche Datensicherung kann ein Paritätsbit mitübertragen werden. Im dargestellten Beispiel werden die 7 Nutzdatenbits durch das Paritätsbit zur "geraden Parität" ergänzt. Diese Vereinbarung wird vom Empfänger geprüft.

• Die Nutzdaten werden in der zeitlichen Reihenfolge: von LSB zu MSB übertragen.

• Die physikalische Sicht auf die serielle, asynchrone Schnittstelle ist durch verschiedene Standardisierungen festgelegt. Die am weitesten verbreitete ist der Standard RS232C (RS: recommended standard). Hier ein kurzer Blick auf die Entwicklung dieses Standards:

1969 Electronic Industries Association (EIA): Standard für mechanische, elektrische und logische Schnittstelle

1972 Consultative Commitee on International Telegraphy and Telephony (CCITT): Festlegung der Liste der Leitungen in V.24, Festlegung der elektrischen Kennwerte in V.28

RS232C entspricht V.24 +V.28 und DIN 66020; seit 1987: "EIA-232-C"

• Die physikalischen Eigenschaften nach RS232C sind: Spannungsübertragung (Pegel und Zuordnung zur logischen Sicht: siehe

nachfolgende Abbildung) Erd-unsymmetrisch: Potentiale werden gegen Erde gemessen Übertragungsrate 20 kBit/s; heute bis 115 kBit/s Kabellänge max. 15-20 m Stecker-Pinbelegung genormt (siehe weiter unten) Signalquellen müssen kurzschlussfest sein: ohne Beschädigung dürfen

RS232C-kompatible Geräte miteinander verbunden werden; jeder PIN darf also z.B. zum Test mit jedem anderen verbunden werden. Dies ist die wichtigste "RS232C-Kompatibilität"!

Abbildung 8-20: RS232C Spannungspegel

• Die RS232C-Schnittstelle definiert eigentlich die Verbindung zwischen einem Rechner (Data Terminal Equipment DTE) und einer Datenübertragungseinrichtung (Data Communication Equipment DCE). Anstelle von DCE wird auch die Bezeichnung "Modem" (Data Set DS) verwendet. Die dabei festgelegte Stecker-Pinbelegung zeigt die folgende Abbildung.

Paritätsbit

RS 232C-Standard

Physikalische Eigenschaften der RS232C

DTE: Terminal DCE, DS: Modem



V 1.00

Abbildung 8-21: Abbildung 8-22: DTE und DCE nach RS232C verbunden

• Wie bereits die Bezeichnungen der einzelnen Signalleitungen zeigen, wird in der RS232C alles aus der Sicht des Terminals dargestellt ("Transmit", "Receive").

• Die minimal erforderlichen Signalleitungen TxD, RxD (Duplexbetrieb) und Common werden ergänzt um eine Reihe von Handshake-Signalen. Diese sind notwendig, da es sich um zwei verschiedene Geräte handelt, die nicht nur den Datenfluss steuern müssen, sondern auch noch verschiedene Betriebszustände einnehmen können (Rechner ist ein, Modem noch ausgeschaltet usw.). Die folgende Abbildung zeigt den vereinfachten Verlauf eines Sendevorgangs (TD = TxD).

Abbildung 8-23: Handshake zwischen DTE und DCE (vereinfacht)

RS232C: Handshake-Signale



V 1.00

Die genormten Belegung der Steckverbinder zeigt die folgende Abbildung; rechnerseitig ist immer ein Stecker ("male") vorgesehen, modemseitig eine Buches ("female") - allerdings ist heute in der Praxis an beiden Seiten eines Verbindungskabels ein Stecker.

Abbildung 8-24: Steckerbelegung der RS232C (Auszug)

• Häufig wird die RS232C-Schnittstelle nicht für die vorgesehene Kopplung von Rechner und Modem verwendet, sondern aus Kompatibilitätsgründen z.B. für die Kopplung von Rechner und Drucker. Da in diesen Fällen der Koppelpartner selbst sich wie ein DTE verhält - ebenso wie der Rechner - emuliert er das DTE-Verhalten, wie die folgende Abbildung zeigt.

Abbildung 8-25: PC und Drucker nach RS232C verbunden (Beispiel)

Erklärung: Der PC sendet z.B. an den Drucker von PIN 2 aus an PIN 3 (Simplex-Schnittstelle).Die beiden DTE geben sich jeweils selbst die Handshake-Signale nach RS232C-Definition. Oft wird ein ansonsten nicht benutzter PIN 19 als "Puffer-voll"-Signal an den DSR-Eingang des PC geleitet.

PC über RS232C mit Drucker verbinden



V 1.00

• Eine weitere Anwendung der RS232C-Schnittstelle zur Kopplung zweier Rechner zeigt die folgende Abbildung.

Abbildung 8-26: "Nullmodem", Kopplung zweier DTE über RS232C

Erklärung: Beide DTE erzeugen sich normgerecht die Handshake-Signale selbst. Vorteil: die Nullmodem-Verbindung wird von vielen Standard-BIOS-Funktionen unterstützt. ACHTUNG: Oft wird ein spezielles "Nullmodemkabel" mit gekreuzten TxD / RxD-Signalleitungen verwendet. Dieses darf natürlich nicht für den Anschluss eines "echten" Modems an den PC verwendet werden!

• Eine Schnittstellendefinition, die aus der Fernschreibtechnik stammt, ist die "20 mA-Schnittstelle" (DIN 66 258, Teil1), auch "TTY-Schnittstelle" genannt (Teletype). Sie ist besonders störsicher, da hier die Information über eine Stromschleife übertragen wird: logisch "0" entspricht 0 mA, "1" entspricht 20 mA. Die Leerlaufspannung beträgt max. 24 V.

Nullmodem

20mA-TTY-Schnittstelle



V 1.00

• Für die Realisierung einer seriellen Schnittstelle kann prinzipiell ein Portbaustein (siehe Kap. 3.3) verwendet werden, bei dem ein Ausgangs-Portbit über einen entsprechenden Leitungstreiber (Umsetzung von 5 V auf RS232C-Pegel) die Sende- oder Empfangsleitung ansteuert. Allerdings muss dann die Umsetzung eines zu übertragenden Byte in einzelne Bits - entsprechend den Signalzuständen am Portbit - einschließlich des Zeichenrahmens (Startbit, Stopbit, Ermittlung des zusätzlichen Paritätsbits) ausprogrammiert werden. Auch in diesem Fall überlässt man deshalb diese ständig wiederkehrende - und wegen der Flusssteuerung auch mit festen, genau einzuhaltenden Zeitbedingungen verknüpfte - Tätigkeit einem eigenen Controller-Baustein. Dieser übernimmt dann gleich Sende- und Empfangstätigkeit und wird deshalb UART (universal asynchronous receiver transmitter) genannt.

• Die folgende Abbildung zeigt das Blockdiagramm eines einfachen UART-Bausteins (8250; Nachfolgebausteine: 82450, 16450, 16550).

Abbildung 8-27: UART 8250 (Auszug aus dem Blockdiagramm)

Erklärung: Wandlung eines in das Sender-Register parallel

eingeschriebenen Byte in die serielle Übertragung am Ausgang SOUT

Bereitstellen eines von SIN empfangenen Bitmusters im Empfänger-Pufferregister zum parallelen Auslesen

Sender- und Empfängerteil getrennt mit jeweils eigenem, per Software einstellbaren Taktgenerator

Interrupterzeugung möglich bei "Empfangs-/Senderegister leer", "Break-Erkennung", "Übertragungsfehler" usw. (Interrupt-Zusatzinformation im Interrupt-Register)

Vollduplexbetrieb Zeichenaufbau wählbar (5-8 Nutzbits, mit/ohne Parität

gerade/ungerade Integrierte Modem-Steuerlogik für das RS232C-Handshake

UART



V 1.00

Abbildung 8-28: Anschluß-Signale des UART 8250 (Auszug)

Hinweis: Die sog. EIA-Leitungstreiber erzeugen aus der 5-V-Betriebsspannung des PC die Signalpegel +12V bis -12V an der seriellen Schnittstelle (RS232C: +/- 15 V).



V 1.00

9 Optimierungsstrategien Vorbemerkung: Die Entwicklung der Mikrorechner ist geprägt durch eine ständige und rasante Leistungssteigerung. Dies haben die Hersteller einerseits erreicht durch die ständige Weiterentwicklung der Hardware (Verkleinerung der Strukturen, Erhöhung der Taktraten usw.). Andererseits wurde versucht, die Leistungssteigerung durch geschickte Konstruktion der Hardware, also durch Optimierung der Rechner-Architektur, zu erreichten. Einige Optimierungsstrategieen werden im Folgenden vorgestellt; allerdings kann dies nur pauschal geschehen, Details finden sich in /Flik, Liebig/ (siehe Literaturverzeichnis).

• Optimierung soll immer die Leistungsfähigkeit von Prozessoren verbessern. Diese "Leistungsfähigkeit" ist aber eine sehr komplexe Größe: nicht nur die reine Bearbeitungsgeschwindigkeit von Befehlen, sondern auch Taskwechselzeiten, Interrupt-Reaktionszeiten, Zusammenarbeit mit der umgebenden Hardware spielt eine Rolle. Aussagekräftige Maßzahlen zum Vergleich verschiedener Prozessoren lassen sich erst durch eine Probe-Implementierung im echten Umfeld und mit echten Applikationen als Test-Software erhalten.

• Auch wenn man den Blick verengt auf lediglich die Befehlslaufzeiten und damit zur Maßzahl MIPS (million instructions per second) kommt, kann man leicht Äpfel mit Birnen vergleichen:

Beispiel: Die Aufgabe A = B + C wird von einem CISC-Rechner (VAX) in einer Mikrosekunde ausgeführt; dieser hätte also 1 MIPS. Dieselbe Aufgabe von einem RISC-Prozessor ausgeführt, der dafür allerdings 4 Befehle benötigt, die zusammen eine Mikrosekunde benötigen, würde zu 4 MIPS führen.

• Es dürfen also nicht nur die Befehlslaufzeiten gezählt werden, sondern die ausgeführten Funktionen / Zeit. Allerdings stellt man dann fest, dass solche Programm-Laufzeitmessungen wiederum davon abhängen, welche Art von Funktion ausprogrammiert wurde. Kommen z.B. in einem mathematisch-naturwissenschaftlichen Programm viele Gleitpunktrechnungen vor, schneidet natürlich ein Prozessor ohne Gleitpunkt-Coprozessor schlecht ab.

• Es sollten also zur Bildung von Vergleichs-Messzahlen standardisierte Applikationen verwendet werden, sogenannte "Benchmarks". Einige Beispiele:

Whetstone: Befehlsmix ("synthetischer Benchmark") mit Schwerpunkt Numerik / Gleitpunkt (Programmiersprache Algol 60, Fortran)

Dhrystone: 100 Anweisungen aus dem Bereich Betriebssystemprogramme; keine Gleitpunktrechnung (Programmiersprache ADA, C)

Linpack: "echte" Routinen zur Lösung von linearen Gleichungssystemen (Fortran)

Maßzahlen für die Bewertung der Prozessor-leistung MIPS

Benchmark

Mikrocontroller 9.1 CISC- / RISC-Architektur Seite 28 von 36


V 1.00

9.1 CISC- / RISC-Architektur

• Betrachtet man die x86-Familie (Intel), die ja bis zum "Pentium"-Prozessor aufwärtskompatibel entwickelt wurde, fällt die große Anzahl von ca. 500 Befehlen (alle Einzelbefehle gezählt) auf. Die überwiegend historischen Gründe dafür sind:

Zugriffe auf den externen Programmspeicher waren langsamer, als die Prozessor-internen Zugriffe (schneller, statischer RAM-Speicher). Damit war es eine Geschwindigkeitssteigerung, nach einem externen Befehls-Lese-Vorgang möglichst lange Prozessor-intern zu arbeiten. Dies führte dazu, dass neben den einfachen Befehlen weitere, möglichst aufwendige Befehle definiert wurden.

Dem Anwender sollten möglichst umfangreiche Befehlsfunktionen angeboten werden: häufig benutzte Funktionen können damit als ein Befehl aufgerufen werden (Ersatz eines Unterprogramms). Typisches Beispiel hierfür: der Befehl "XLAT" nimmt ein Byte, das ihm im Akku übergeben wird, adressiert über Pointer eine "look-up-table", also eine Tabelle mit Codes, holt aus der Tabelle den zum Byte passenden Code und gibt ihn im Akku zurück ("translate"). Auch Funktionen zur Unterstützung von Betriebssystemtätigkeiten wurden auf Befehlsebene unterstützt.

Auch wenn die Zeit über viele dieser Befehle hinweggegangen ist und z.B. der Einsatz von Hochsprachen diese Befehle überflüssig machte: keinen dieser Befehle konnte man als Prozessorhersteller irgendwann wieder weglassen: dies hätte die Aufwärtskompatibilität zunichte gemacht!

• Die Entwicklung von umfangreichen Befehlssätzen mit komplexen Befehlsfunktionen stellt bereits eine erste Optimierungsstrategie dar.

• Prozessoren mit einem solchen Befehlssatz nennt man "compex instruction set computer" oder kurz CISC-Prozessoren.

Hinweis: Diese komplexen Befehle werden im Prozessor innerhalb der Befehls-Ausführungssteuerung (siehe Kapitel 3.1) nicht "hardwired" also festverdrahtet ausgeführt, sondern sie werden zerlegt in mehrere Schritte. Jedem äußeren Befehl entspricht also eine Sequenz von "Mikroprogramm-Befehlen". CISC-Prozessoren zeichnen sich dadurch aus, dass ein mehr oder weniger großer Teil ihres Befehlssatzes in einem Mikroprogramm realisiert wird. Dieses Mikroprogramm bzw. sein Programmspeicher beansprucht einen erheblichen Teil der Chipfläche und verursacht den entsprechenden Anteil an der gesamten Verlustleistung des Prozessors.

CISC-Prozessoren

Mikro-programm

Mikrocontroller 9.2 Queue, Cache, Pipelining und Harvard Seite 29 von 36


V 1.00

• In den 80er Jahren wurden Assembler-Programme untersucht, die von Hochsprachen-Compilern erzeugt worden waren. Dabei wurde festgestellt, dass 90% des Programmcodes aus Befehlen bestand, die nur 10% des zur Verfügung stehenden Befehlssatzes ausmachten. Grund u.a.: die Compiler-Hersteller versuchen, möglichst nur die Befehle, Register u.s.w. zu benützen, die in allen Prozessorvarianten zur Verfügung stehen.

• Aus diesem Ansatz wurde die RISC-Architektur entwickelt (reduced instruction set computer) mit folgenden Merkmalen:

nur ca. 60 einfache Befehle, die auch von speziellen Compilern genutzt werden

jeder Befehl ist "hard-wired" und wird in einem Takt ausgeführt kein Mikroprogramm minimale Chipfläche und damit minimale Verlustleistung feste Befehlswortbreite (-->leichte Decodierung) Zugriff auf externe Daten nur über zwei Befehle (load-/store); d.h. möglichst

Arbeiten im Prozessor-internen RAM große Anzahl Register keine Kompatibilität zu vorherigen Prozessoren

• Ziel der RISC-Prozessorarchitektur (auch "skalare" Architektur genannt): eine Funktion nicht mit einem Befehl zu bearbeiten,, der viele Takte benötigt, sondern in mehreren Befehlen, die jeweils nur einen Takt benötigen. Dabei sollte dann die gesamte Bearbeitungszeit kürzer sein als bei einem CISC-Prozessor. Der kryptische Befehlssatz, die Notwendigkeit, auch einfache Arithmetikfunktionen in ganze Befehlsketten aufzulösen, führt dazu, dass RISC-Prozessoren nicht mehr in Assembler programmiert werden, sondern in C. Der C-Compiler muss allerdings speziell auf den einzelnen Prozessor zugeschnitten sein, er bestimmt maßgeblich die Leistung des Prozessors.

• RISC-Prozessoren werden mit weiteren Optimierungsmaßnahmen kombiniert (Cache-Speicher, Harvard-Architektur und Pipelining; siehe folgendes Kapitel).

• In den 90er-Jahren wurden RISC-Merkmale auch in die Architekturen der CISC-Prozessoren aufgenommen.

9.2 Queue, Cache, Pipelining und Harvard

• Analysiert man die Gesamtlaufzeit eines Befehls, zeigt sich, dass sich diese aufteilt auf die einzelnen Befehls-Bearbeitungsphasen (siehe Kap. 3.2). Am Beispiel des Befehls:

ADD ANNA , AX ist dies in der folgenden Abbildung dargestellt. Dabei sind die Bearbeitungsphasen auf die Zeiten verteilt, die entweder der BUS benützt wird (Befehlscode lesen, Operand ANNA lesen, Ergebnis-Operand ANNA zurückschreiben) oder die der Prozessor intern arbeitet (Dekodieren des OPCODE, Ausführen der Addition).

RISC-Prozessor

skalare Architektur



V 1.00

Abbildung 9-1: BUS-Belegung und Prozessorbelegung (Beisp.: ADD ANNA,AX)

• Nimmt man an, dass Programme überwiegend linear aufgebaut sind, also auf einen Befehl an der Programmspeicheradresse X der Befehl an der Programmspeicheradresse X+1 folgt, kommt man zu einer der ältesten Optimierungsstrategien, der Queue:

Abbildung 9-2: Befehlswarteschlange (Queue) des 80x86

Erklärung: Die eigentliche Prozessoreinheit EU (Execution Unit, siehe Kap. 3.2) des 80x86 wird ergänzt um eine BIU (Bus Interfache Unit). Diese adressiert den externen Speicher selbständig (genau: führt die Segmentregister) und kann über einen eigenen Program Counter von einer Startadresse an die nächsten sechs Befehlscodes in eine Warteschlange einlesen (auch "Prefetch" genannt). Dann beginnt die eigentliche Befehlsbearbeitung in der EU, die allerdings immer nur den ersten Befehl aus der Warteschlange holt und bearbeitet. Die BIU holt in Zeiten, in denen der BUS von der EU nicht benötigt wird, weitere Befehle, füllt also die Warteschlange nach. Daraus ergibt sich dann ein Zeitverlauf entsprechend folgender Abb.:

Befehls-Warte-schlange "Queue"

Prefetch



V 1.00

Abbildung 9-3: BUS-Belegung und Prozessorbelegung mit Queue

• Die Optimierungsstrategie "Queue" führt also im Idealfall dazu, dass die Fetch-Zeiten parallel zu den internen Bearbeitungszeiten der Befehle liegen, also bei der Messung der Befehlslaufzeit nicht mitgezählt werden (z..B. von Write Op-1 bis Write Op-2, also der Laufzeit des Befehls 2, misst man lediglich einen Execute und einen Decode-Zyklus)

• Wenn der lineare Ablauf des Programms allerdings unterbrochen wird durch einen Sprung oder einen Unterprogramm-Aufruf, sind alle Befehle, die bereits in der Queue nach diesem Befehl auf ihre Bearbeitung warten, überflüssig. In diesem Fall erhält die BIU die Sprungziel-Adresse und füllt von hier aus zunächst die Queue mit sechs Befehlen auf. Während dieser Zeit steht die EU.

• Diese Optimierungsstrategie geht also - wie die nachfolgenden auch - von bestimmten Annahmen über den Programm-Aufbau aus.

• Eine weitere Möglichkeit, Programmlaufzeiten zu optimieren, liegt in der Ausnutzung der Speicher-Hierarchie: große RAM-Speicher werden aus Kosten- und Platzgründen als externe DRAM realisiert, kleine RAM Speicher können als SRAM auf dem Prozessorchip integriert werden (siehe Kapitel 2.4). Entsprechend ergibt sich eine hierarchische Staffelung der Zugriffszeit: externe DRAMs sind langsamer anzusprechen als interne SRAM. Zwischen beiden liegen Laufzeit- und Größenmäßig die extern aufgebauten SRAMs.

• Kopiert man einen Ausschnitt aus dem Programmspeicher in einen solchen, schnellen SRAM-Zwischenspeicher, so nennt man diesen Cache. Der Prozessor adressiert und holt die Befehle dann grundsätzlich nur im Cache. Dadurch werden wiederholt ausgeführte Befehle entsprechend schneller bearbeitet.

• Droht der der Prozessor bei der Programmbearbeitung den im Cache befindlichen Programmausschnitt zu verlassen, muss rechtzeitig ein neuer Teil aus dem externen Programmspeicher in den Cache kopiert werden. Für diese Tätigkeit ist also eigene Intelligenz in Form eines Cache-Controllers nötig. Die folgende Abbildung zeigt die Anordnung eines einfach vorhandenen Cache als Pufferspeicher zwischen Prozessor und externem Hauptspeicher.

Optimierung ist abhängig von Programm-Struktur

Speicher-Hierarchie Cache Cache-Controller



V 1.00

Abbildung 9-4: Cache

• In modernen PC-Architekturen wird zusätzlich zu einem Cache für den Programmspeicher auch ein Cache für Daten verwendet. Damit wird natürlich die Aufgabe für den Controller schwieriger: er muss nicht nur das Laden und Adressieren erledigen, sondern auch noch für die Datenkonsistenz zwischen Daten im Cache und den Kopien im Hauptspeicher sorgen.

• Realisiert man - wie oben beschrieben - eine dreistufige Speicherhierarchie, so nennt man den Cache, der im Prozessor realisiert ist "Level-1-Cache", den extern realisierten Cache "Level-2-Cache".

Hinweis: Der grundsätzliche Unterschied zwischen einer Queue und einem Code-Cache zeigt sich dann, wenn im Programm ein Sprungbefehl auftritt:

Ist das Sprungziel innerhalb des Programmausschnittes, der sich gerade im Cache-Speicher befindet (sog. "hit"), wird der Sprungbefehl und alle nachfolgenden Befehle weiterhin mit der vollen Zugriffsgeschwindigkeit ausgeführt.

Bei der Queue muss auf jeden Fall der Warteschlangen-Inhalt komplett verworfen werden und die neuen Befehle nachgeladen werden!

Ein Sprungbefehl wird bei der Cache-Lösung nur dann die Laufzeit verlängern, wenn er aus dem Programmausschnitt, der sich gerade im Cache befindet, herausführt. Dann gilt auch hier: der Cache muss zunächst neu geladen werden.

Daten-Cache L-1-Cache, L-2-Cache



V 1.00

• Zerlegt man die Ausführung eines Befehls wieder in seine Bearbeitungsphasen und lässt jetzt jede Bearbeitungsphase in einer eigenen Hardware-Instanz durchführen, so wird ein Befehl praktisch wie auf einem Fließband von einer Instanz zur nächsten weitergereicht. Diese Optimierungsstrategie nennt sich Pipelining.

• Dadurch kann z.B. die erste Instanz, die für den Befehlsfetch zuständig ist, gleich nach dem Holen des ersten Befehls mit dem Holen des nachfolgenden, zweiten Befehls weitermachen usw. Sie übergibt einfach den geholten Befehlscode an die nächste Instanz, die die Decodierung durchführt (siehe nächste Abbildung); diese übergibt nach der Decodierung den Befehl an die Ausführungseinheit. Dort wird die eigentliche Befehlsfunktion bearbeitet und anschließend - in diesem Beispiel - ein Operand in den Speicher zurückgeschrieben.

Abbildung 9-5: Pipelining

• Bei einem vierstufigen Pipelining sind also gleichzeitig 4 Befehle in Bearbeitung. Betrachtet man die Zeitpunkte, an denen ein Befehl fertig wird, also der Ergebnisoperand in den Speicher zurückgeschrieben ist, so sieht man, dass im Idealfall pro Takt des Prozessors ein Befehl fertiggestellt ist.

• Damit ist es möglich, auch lange Befehle, die eigentlich - wie oben dargestellt - vier Takte benötigen, scheinbar in einem Takt bearbeitet werden. Dieses Verfahren lässt sich beliebig erweitern - solange man Befehlsbearbeitungsphasen findet, die in eigenen Hardware-Instanzen realisiert werden können. Damit steigen dann natürlich auch die Kosten eines solchen Systems.

• Ähnlich wie die Queue hat auch das Pipelining das Problem, dass bestimmte Annahmen über den Verlauf des Programms zutreffen müssen, ansonsten kommt das "Fließband" ins Stocken. Dies kann z.B. ein Sprungbefehl sein: wie bei der Queue holt die Fetch-Instanz immer nur den nächsten, im Programmspeicher stehenden Befehl (siehe nächste Abbildung).

Pipelining

Pipelining mit Sprungbefehl



V 1.00

Abbildung 9-6: Pipelining mit Sprungbefehl und Leerzyklus

Erklärung: Die Decodier-Instanz erkennt den Sprungbefehl und fügt für die nachfolgende Instanz einen Leerzyklus ein. Dieser wandert durch die Instanzen hindurch, während die Fetch-Instanz den Befehl-X von der Sprungzieladresse holt.

• Eine weitere Annahme über den Ablauf des Programms, die in der Abbildung 9-2 vorausgesetzt wird, wird schnell sichtbar, wenn man sich die Frage stellt, wie eigentlich eine Instanz das Operations-Ergebnis in den Speicher zurückschreiben kann, während gleichzeitig eine andere Instanz einen Befehlsfetch, also ein Lesen des nächsten Befehlscodes aus dem Speicher durchführen soll. Die bisher betrachteten Systemarchitekturen, bei denen der Prozessor mit einem Adreß- und Datenbus am Speicher für Code und Daten angeschlossen ist (von Neumann-Architektur) würden diesen BUS-Konflikt auflösen durch Einfügen von Leerzyklen. Dies könnte etwa wie folgt aussehen:

Abbildung 9-7: Pipelining bei von Neumann-Architektur

Erklärung: Das Zurückschreiben des Operanden für Befehl-n hat Vorrang vor dem Fetch des Befehls-n+3. Damit häufen sich die Leerzyklen im Pipelining.

Pipelining ohne Sprung-Befehl (oben) und mit Sprungbefehl (unten)

von Neumann-Architektur



V 1.00

• Pipelining wird nur dann effektiv, wenn man gleichzeitig auf Befehle und Daten zugreifen kann: wenn also zwei getrennte BUS-Systeme vorhanden sind. Diese Form der Rechnerarchitektur nennt man "Harvard-Architektur". Nur damit ist ein konstanter Strom von Befehlen und Daten in den Prozessor erreichbar. Dies ist natürlich auch die teuerste Form der Optimierung.

Abbildung 9-8: Rechner-Architekturen

• Abschließend soll die Blockstruktur des Pentium-Prozessors zeigen, dass viele der hier dargestellten Optimierungsstrategien sich dort wiederfinden.

Harvard-Architekture



V 1.00

Abbildung 9-9: Pentium-Blockstruktur (aus: H.P. Messmer, „PC-Hardware“,

Addison-Wesley)

8 Mikrocomputer-Systemarchitekturen8.1 Adressierung von Systemkomponenten8.2 Multi-Master-Systeme8.3 Timer / Counter8.4 Schnittstellen und Schnittstellen-Bausteine

9 Optimierungsstrategien9.1 CISC- / RISC-Architektur9.2 Queue, Cache, Pipelining und Harvard

skriptum „mikrocontroller-systeme“ kapitel 8geju0001/mikrocontroller... · 2009. 10. 7. ·...

Documents