Nur auf Docsity: Lade Skript Embedded System und mehr Skripte als PDF für Informationstechnik herunter!
Embedded Systems 1
Prof. Dr.‐Ing. Lukusa Didier Kabulepa
(Version: März 2011)
Eingangs‐ einheiten
Ausgangs‐ einheiten
Verarbeitungs‐ einheit Embedded (Algorithmen, Software Strategien,Vorgaben)
Benutzereingaben z.B. Tasten
Ausgaben für den Benutzer z.B. Anzeige
Sensoren Aktuatoren Prozeß Information Energie Material
Embedded Microcontroller
Andere eingebettete Systeme
Andere eingebettete Systeme
(Druck,^ Prozessgrößen Temperaturen, Licht, magnetischesFeld, …)
Stellgrößen
ControlDebug^ ProcessorCore ProgramMemory RAM
PeripheralModule #
Bus Matrix
PeripheralModule #
Peripheral Access Control PeripheralModule #n
OscillatorPLL^ Mikro‐
Controller
Organisatorisches
Vorlesungszeiten und Orte
‐ Mittwoch 8.00 H ‐ 9.30 H Raum L
‐ Mittwochh 9.45 H ‐ 11.15 H Raum L114 ( l(Alternierend d mit ÜbÜb ung))
Erste Übung am 30.03.
‐ DonnerstagDonnerstag 9 45 H 9 .45 H ‐ 11 15 H 11 .15 H Raum H0807Raum H
Zusätzliche Laborzeiten
‐ Mittwoch 13.40 H – 15.10 H Raum S
EMB Institutswebseite
http://www.emb.hsp // ‐mannheim.de//
Prinzipieller Aufbau eines eingebetteten Systems
Benutzereingaben z B Tasten
Ausgaben für den Benutzer
E b dd d Mi t ll
Eingangs‐ einheiten
Ausgangs‐ einheiten
Verarbeitungs‐ einheit
z.B. Tasten Embedded Microcontroller z.B. Anzeige
einheiten einheit einheiten Embedded eingebetteteAndere Software^ eingebetteteAndere (Algorithmen, Strategien, Vorgaben)
eingebettete Systeme
eingebettete Systeme
Sensoren Aktuatoren
Prozeß
Information Energie Material
Prozessgrößen (Druck, Temperaturen, Licht, magnetisches F ld )
Stellgrößen
HS Mannheim EMB1:März 2011 LDK
Feld, …)
Kap. 1 ‐ 3
Anwendungsbereiche von eingebetteten Systemen
Zahlreiche Einsatzgebiete im industriellen Umfeld
Medizintechnik Automatisierungs‐ h k Automotive (^) Luft‐ und Raumfahrt‐ technik
technik Unterhaltungs‐ technik elektronikelektronik
Embedded System Beispiel 1: Antiblockiersystem (ABS) in einem KraftfahrzeugAntiblockiersystem (ABS) in einem Kraftfahrzeug Ein Antiblockiersystem (ABS) in einem Kraftfahrzeug soll ein mögliches Blockieren der Räder bei starkem Bremsen verhindern. Es sorgt also für eine bessere Lenkbarkeit beim Bremsen.
Die Signaleg der Raddrehsensoren werden im ABS Steuergerätg zur Berechnungg der Radgeschwindigkeit herangezogen. Aus den Radgeschwindigkeiten einzelner Räder wird eine Referenzgeschwindigkeit des KFZ gebildet. Mittels der Überwachung der Veränderungen der gemessenen Radumfangsverzögerungen erkennt das ABSVeränderungen der gemessenen Radumfangsverzögerungen erkennt das ABS Steuergerät jeden Bremsschupf an einem Rad und startet dementsprechend eine ABS Regelegung.
Während einer ABS Regelung (als Zusammenspiel der Hardware und Software in einem eingebetteten System) wird ein Regelzyklus (Aufbau / Halten / Abbau des Bremsdrucks) ca. 4 bis 15 mal pro Sekunde durchlaufen. Druckaufbau Einlassventil geöffnet die Hydraulikpumpe^ /^ Auslassventil Bremsflüssigkeit^ geschlossen und fördert^ /^ Aus sie^ dem in^ Druckspeicherden Bremskreis.^ saugt
Druck halten Einlassventil geschlossen zwischen^ / demAuslassventil Einlass‐ undgeschlossen dem Auslassventil.^ /^ Der^ Druck^ bleibt^ konstant
Ei l il hl / A l il öff / Di H d lik fö d
HS Mannheim EMB1:März 2011 LDK
Druckabbau Einlassventil die frei werdendegeschlossen Bremsflüssigkeit^ /^ Auslassventil zurückgeöffnet in den/^ Die Hauptbremszylinder.^ Hydraulikpumpe^ fördert
Kap. 1 ‐ 5
Embedded System Beispiel 1: Antiblockiersystem (ABS) in einem Kraftfahrzeug Ausgaben Embedded Microcontroller
Antiblockiersystem (ABS) in einem Kraftfahrzeug
Eingangs‐ einheiten
Ausgangs‐ einheiten
Verarbeitungs‐ einheit ABS
Berechnete Radgeschwindigkeit an andere Steuergeräte
Daten von anderen Steuergeräten (z.B. ACC Bremsaufforderung der d h l ) ABS Regel‐ algorithmen
an andere Steuergeräte (z.B. Motorsteuerung, …) übertragen
der automatischen Distanzregelung ) ACC: Adaptive Cruise Control
Sensoren: Raddrehsensoren, (^) MagnetventileAktuatoren: Drucksensoren g
Druckleitungen (^) Elektronischer ReglerRegler HydraulikblockHydraulikblock
Bereich: Automotive
Embedded System Beispiel 2: Infusionspumpe
Die Infusionspumpe sollDie Infusionspumpe soll eine hohe Genauigkeit der Dosierung bei gleichmäßiger undeine hohe Genauigkeit der Dosierung bei gleichmäßiger und pulsationsfreier Förderung und damit die Wirksamkeit und Sicherheit der Infusions‐ therapie mit hochwirksamen Medikamenten ermöglichen.
Kleine Volumina (in der Regel nicht größer als 50 ml) müssen unmittelbar nach dem Einschalten des Geräts (also ohne Anlaufverluste) gefördert werden können.
Infusionspumpen besitzen zur Förderung der zu applizierenden Flüssigkeiten einen von von einem eingebetteteng Mikrocontroller angetriebeneng Pumpenmechanismusp ((z.B. Kolbenpumpe, Rollen‐Peristaltikpumpe, Schieber‐Peristaltikpumpe, …)
Zahlreiche nationale und internationale Regelwerke und Normen umfassen strengeZahlreiche nationale und internationale Regelwerke und Normen umfassen strenge Anforderungen für die Infusionspumpe. Beispielsweise soll der Infusionsstrom unter‐ brochen werden, sobald ein als Gefährdung für den Patienten eingestufter Fehler (z.B. HöhHöherer DD ruck,k niedrigeri d i DD ruck,k L ftblLuftblasen ii m ÜbÜb erleitungssystem,l it t …)) erkanntk t wird.i d
HS Mannheim EMB1:März 2011 LDK (^) Kap. 1 ‐ 9
Embedded System Beispiel 2: Infusionspumpe (Fortsetzung)
Infusionsbeutel Luftblasendetektor (Air‐in‐line sensor) Verstärker (^) TastaturKleine Drucksensor
(Air‐in‐line sensor) Alarm EXTERNE SPEICHER
Nockenwellen
ADC MUX Processor DebugControl Core ProgramMemory RAM
P i h l
Bus Matrix
P i h l
Peripheral Access Control P i h l
OscillatorPLL^ Mikro‐ Controller Treiber DAC
Temperatur‐ sensor
DAC PeripheralModule#1 PeripheralModule#2 PeripheralModule#n
X
Treiber
MUX
ADC
Schlauch
Verschlusssensor
Zahn‐ räder
Kommunikations‐ schnittstellen
Motor
Schlauch Anzeigen
Typischer Ablauf der Entwicklung eingebetteter Systeme
Kundenauftrag
Kaufmännische und
Kundenauftrag Lastenheft
technische Entscheidungen
Pflichtenheft Systemanforderungen Systemauslegung
Pflichtenheft
Systemauslegung Auswahl der Hardwareplattform Festlegung des Softwarekonzeptes
Hardwareentwicklung Mikrocontroller und umgebende Beschaltung auf einer elektronischen
Softwareentwicklung Platine
Integration & Verifikation
HS Mannheim EMB1:März 2011 LDK
Endprodukt in Form eines eingebetteten Systems Kap. 1 ‐ 11
Entwicklungsablauf in Form eines V‐Modells
Kundenziele
Systemanforderungen Validierung^ &^ Rückverfolgbarkeit^ (Traceability) Akzeptanztest /Akzeptanztest^ / Abnahmetest
g g ( y)
Systemspezifikation
System Integration & Test
Verifikation
HW‐Spezifikation SW‐Spezifikation (^) HW Integrationstest SW Integrationstest Verifikation
Verifikation
Spezifikationen von HW‐Komponenten
Spezifikationen von SW‐Komponenten
Test/Überprüfung von HW‐Komponenten
Test/Überprüfung von SW‐Komponenten
Implementierung von HW‐Komponenten
Implementierung von SW‐Komponenten HW: Hardware SW: Software
Aufbau der Vorlesung
KKapitel it l 2 P 2 : P rozessorkernk Architektur, Prozessorregister und Befehlssatz (Bsp: ARM), Interrupts
Kapitel 4: Debug Modul
DebugModul ProzessorKern Programm speicher‐ speicherDaten‐
Kapitel 3: Speicher Cache, flüchtige Speicher (RAM), nicht‐flüchtige Speicher (ROM, Flash) Busmatrix Peripheriebrücke
Kapitel 5: Peripherie‐Module Timer, PWM, AD‐Wandler, GPIO,
g p ( , )
PeripherieModul #1 PeripherieModul #i PeripherieModul #j PeripherieModul #q
Kommunikationskontroller
Kapitel 6: Sensoren G d i i i B i i l
Signal‐ Signal‐
Grundprinzipien, Beispiele
Kapitel 7: Aktuatoren AufbereitungSignal Aufbereitung^ Signal^ Grundprinzipien Beispiele
Aktuatoren Sensoren
Grundprinzipien, Beispiele
Kapitel 8: Hardware‐nahe ProgrammierungProgrammierung
Kapitel 9: Echtzeitbetriebssysteme (RTOS) Ei h ft B i i l
HS Mannheim EMB1:März 2011 LDK
(RTOS) Eigenschaften, Beispiele
Kap. 1 ‐ 15
Zusammenspiel zwischen Software und Hardware
C Code
EMB Themenbereiche
Compiler
Assembler Betriebssystem
Anwendungssoftware SOFTWARE
Prozessor Speicher Peripherie‐Module Eingänge Ausgänge‐
Assembler Betriebssystem
HARDWARE
SOFTWARE Befehlssatzarchitektur (ISA: Instruction Set Architecture)
Mik l kt i h S h lt
Logische Gatter / Digitale Blöcke
Datenpfade / Kontrollflüsse (Steuerwerk)
Sensoren Transistoren
Mikroelektronische Schaltungen Aktuatoren
Sensoren
KapitelKapitel 22
Prozessorkern:
A fbAufbau undd F F unktionsweisekti i
ThemenThemen
Teil 1: Grundlageng
Aufbau und Funktionsweise eines Prozessors ‐ Phasen der Befehlsausführung ‐ Prozessorarchitektur PipelineProzessorarchitektur, Pipeline ‐ Unterbrechungsbehandlung
T il 2 ARM7Teil 2 : ARM7 alsl B iBeispielprozessor i l
‐Befehlssatz, Registersatz ‐ ARM Unterbrechungsarten
Teil 3: ARM7 Assembler Programmierung
Teil 4: ARM7 C Programmierung
Prinzipieller Aufbau eines Prozessorkerns (2)
IR: Instruction Register / Befehlsregister
/
Steuersignale
Statussignale (Rückmeldungen)
PC: Program Counter / Befehlszähler
ALU A i h i L i
Steuereinheit (Control unit) Datenpfad (Data path)
ALU: Arithmetic Logic Unit / Rechenwerk
GPR G l P
Befehlsdecoder
Steuerwerk Registerbank (GPRs)
GPRs: General Purpose Registers / Frei verwenbare Register
IR PC ALU
Lesebus für Befehle (Anweisungen) (^) Adressbus für Daten D t h ibb
Daten‐ Lesebus Adressbus für Befehle (Anweisungen)
Lesebus Datenschreibbus
Programmspeicherg p Datenspeicherp
HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 5
Von‐Neumann vs. Harvard Prozessorarchitektur
Von‐Neumann Architektur Harvard Architektur Steuereinheit (Control unit) Datenpfad (Data path)
Steuerwerk Registerbank (GPRs)
Steuereinheit (Control unit) Datenpfad (Data path)
Steuerwerk Registerbank (GPRs) Befehlsdecoder Befehlsdecoder
IR PC ALU IR PC ALU
Bus Schnittstelle
P d
Bus Schnittstelle
Programmspeicher Datenspeicher
Programm‐ und Datenspeicher
In einer VonIn einer Von‐ Neumann Architektur liestNeumann Architektur liest Eine Architektur weist verschiedene Busse der Prozessorkern Befehle und Daten über den gleichen Bus. Somit stehen Befehle und Daten typischerweise im
Eine Architektur weist verschiedene Busse für Befehle und Daten auf. In dieser Architektur stehen Daten und Befehle typischerweise in unterschiedlichen Befehle und Daten typischerweise im gleichen Speicher.
Befehle typischerweise in unterschiedlichen Speichern.
Funktionsweise eines Prozessorkerns Die gemeinsame Arbeitsweise des Datenpfades mit der Steuereinheiten eines ProzessorsDie gemeinsame Arbeitsweise des Datenpfades mit der Steuereinheiten eines Prozessors umfasst folgende Phasen (als Zustände eines endlichen Automaten zur Abarbeitung von Maschinenbefehlen):
1 Befehlsholphase^ /^ Instruction Fetch ( IF )
Anhand der im Befehlszähler angegebenen Adresse wird der nächste zu bearbeitende Befehl aus dem
Steuereinheit (Control unit) Datenpfad (Data path)
Steuerwerk Registerbank Programmspeicher in das Befehlsregister (IR) geladen.
2 Decodierungsphase^ /
Instruction Decode ( ID )
Befehlsdecoder
Steuerwerk Registerbank (GPRs)
Instruction Decode ( ID ) Befehle werden in Steuersignale für den Datenpfad umgesetzt.
3 Operandenholphase^ /^ Operand^ Fetch^ ( OF )
IR PC ALU
3 Operandenholphase^ /^ Operand^ Fetch^ ( OF )^5
Mittels der im Befehle codierten Adressteile von Ope‐ randen werden die benötigten Adressen berechnet.
Anschließend werden Operanden geholt.^1
Anschließend werden Operanden geholt.
4 Ausführungsphase^ /^ Execution ( EX )
Bearbeitung der zuvor geholten Operanden Programmspeicher Datenspeicher
5 Rückschreibphase^ /^ Write^ Back^ ( WB )^ and/or^ MEM
Ergebnisse der Ausführung werden in die vorgesehenen Speicherstellen (Datenspeicher oder Register) ZurückgeschriebenZurückgeschrieben. (WB(WB Schreibe in ein ProzessorregisterSchreibe in ein Prozessorregister MEMMEM Schreibe in eine Speicherzelle)Schreibe in eine Speicherzelle)
HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 7
Funktionsweise eines Prozessorkerns in Form eines endlichen Automatenendlichen Automaten
IF B f hl h l
ID
Befehl
OF
Operanden
EX WB
Befehl holen Befehl Befehl^ Ergebnis decodieren
Operanden holen
Ergebnis ausführenBefehl speichern
PC
OF
Operanden‐ Adressen berechnen
WB
Adresse fürs Ergebnis berechnen
PC Berechnung
berechnen berechnen
Für jeden Befehl wird der Prozessor diesen Zyklus durchlaufen. Befehle eines Programms werden nacheinander jeweils in diesem endlichen Automaten (also in diesem Befehlszyklus) vom Prozessor abgearbeitet Je nach BefehlsartAutomaten (also in diesem Befehlszyklus) vom Prozessor abgearbeitet. Je nach Befehlsart werden manche Phasen (Zustände) des endlichen Automaten nicht verwendet. Je nach Prozessortyp und verwendetem Maschinenbefehlssatz findet man unterschiedliche AA usprägungenä dd es vorgestelltent llt B f hlBefehlszyklus. kl
Befehlsholphase (1)
S h ittSchritte dd er B f hl h l hBefehlsholphase: ‐ Der Befehlszähler PC (Programm Counter) liefert die Adresse des zu holenden Befehls ‐ Ein Zugriff auf den Programmspeicher erfolgt. ‐ Der gelesene Befehl wird ins Befehlsregister IR (Instruction Register) geladeng
IR = MEMORY [PC]
‐ Der Befehlszähler wird um die Breite (in Bytes) eines Befehls inkrementiert, um die Adresse des nächsten Befehls bereitzustellen.
PC = PC + 1 Prozessor mit 8 ‐Bit Befehlen PC = PC + 2 Prozessor mit 16 ‐Bit Befehlen PC = PC + 4 Prozessor mit 32 ‐Bit Befehlen PC = PC + 8 Prozessor mit 64 ‐Bit Befehlen
‐ Viele Prozessoren verwenden die gleiche (konstante) Länge für alle Befehle. Für manche Prozessoren ist die Befehlslänge (je nach Befehlsart) variabel gehalten um eine Reduzierung der gesamte Codegröße eines Programmsgehalten, um eine Reduzierung der gesamte Codegröße eines Programms erzielen zu können. HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 11
Befehlsholphase (2) Die Adresse des nächsten BefehlsDie Adresse des nächsten Befehls Der nächste auszuführende Befehl wird steht im Befehlszähler PC.
Der nächste auszuführende Befehl wird ins Befehlsregister IR geladen.
MUX +4 (oder +2 oder +1) 2: CPU‐abhängig Steuer‐ werk Registerbank (GPRs)
Shift Left IR Register ) ( Befehls ‐ OpCode (^) Registerbank (GPRs) Lese Register ‐ 1 Lese Register‐ 2
Register )
PC
rS rS DatenLese 1 ‐ ALU
Rechen‐ Werk
OpCode RegA
MUX 2:1 (^) MUX 3:
Schreib Register‐
Befehlszähler
PC (^) rD
Schreib Daten ‐
Daten^ Lese 2 ‐ ALU RegB
Programm‐ Daten i h‐
Vorzeichen Erweiterung ‐
Programm speicher speicher
Steuersignale
MUX 3: Statussignale
Decodierungsphase (1)
II n didi eser PhPh ase wirdi d d d er ii m B f hlBefehlsregister i t IRIR vorhandeneh d MM aschinenbefehlhi b f hl entschlüsseltt hlü lt und in Steuersignale für den Datenpfad umgesetzt.
Jeder Maschinenbefehl besteht typischerweise aus einem OpCode und Operanden oder Ortsangaben der Operanden. OpCode Beispiel eines 16 ‐Bit Befehls: (^1110 1001 0011 )
ADD R9 R3 R PP assended StSteuersignale: i l ‐ L dLade I h ltInhalt vom RRegister i t R2 iR2 i n dd en ALU EiALU Ei ngang AA ‐ Lade Inhalt vom Register R3 in den ALU Eingang B ‐ Führe eine Addition in der ALU aus S i h di S i d R i t R
Nach Entschlüsselung vom OpCode (also nach Ermittlung der Befehlsart) bestimmt
‐ Speichere die Summe in das Register R
g p ( g ) die Steuereinheit: ‐ Was der Datenpfad des Prozessors tun soll. Z BZ.B. Addieren Multiplizieren Sprunganweisung (Branch) LadenAddieren, Multiplizieren, Sprunganweisung (Branch), Laden, Speichern, logische Operation, … ‐ Wo sich die Operanden befinden (falls benötigt) ‐ AA n welcherl h St llStelle dd as ZZ wischenergebnisi h b i gespeicherti h t wird.i d
HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 13
Decodierungsphase (2)
MM ancheh MM aschinenbefehlehi b f hl werdend bb ereitsit ii n dd er DD ecodierungsphasedi h aufgelöst.f lö t S S omitit werden die nachfolgenden Phasen nicht ausgeführt.
Beispiel: Unbedingte Sprünge mit Offset (bezüglich des Befehlszählers) Die in der Befehlsholphase durchgeführte Anpassung des Befehlszählers wird in der Dekodierungsphaseg p korrigiert.g ‐ Sprung (Branch) mit dem Adressabstand Offset PC = PC + Offset ‐ Typischer Fall: Rücksprungadresse nach Beendigung einer Funktion.
In der Implementierung der Dekodierungsphase unterscheiden sich RISC (Reduced Instruction Set Computer) Architekturen wesentlich von den CISC (Complex IInstruction Set t ti S t C C omputer)t ) A A rchitekturen.hit kt
In RISC Architekturen werden Maschinenbefehle schnell durch eine relativ einfache Hardwareeinheit entschlüsselt. Für die relativ kleine Anzahl von RISC Maschinenbefehlen (Größenordnung: 100) weisen die OpCodes die gleiche Länge auf. In CISC Architekturen zerlegtg zuerst ein ((mikroprogrammierter) p g ) Hardwareintepreterp komplexe Maschinenbefehle in einfache Befehle (auch Microcode genannt). Der Prozessorkern wird dann die Microcodes ausführen. Die CISC Maschinenbefehle weisen verschiedene Längen auf Dementsprechend ist die Dekodierung aufwändiger als in RISCverschiedene Längen auf. Dementsprechend ist die Dekodierung aufwändiger als in RISC Architekturen.
Operandenholphase
RegistersatzRegistersatz
R R R
Vor der Ausführung zahlreicher Befehle müssen die Eingangsregister RegA und R B d ALU it d O d R R R R
RegB der ALU mit passenden Operanden gefüllt werden.
R R R
In diesem Bild spielt das ALU Eingangs‐ Register RegA die Rolle eines Akkumulators.
Mux Steuersignale
Wie werden nun die benötigten Operanden aus dem Speicher geholt?
ALU RegA ALU RegB
Mux Steuersignale Im OpCode eines Maschinenbefehls wird auch die passende Adressierungsart itt lt
ALU Steuer‐
Einheit
ermittelt. Typischerweise unterstützt jeder Prozessorkern verschiedene Adressierungs‐ (^) Einheit
Statussignale
Arten: immediate / direkt / indirekt / indiziert / autoinkrement / …
HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 17
Operandenholphase : Adressierungsarten (1)
- Unmittelbare Adressierung (Immediate addressing mode) Der Operand ist selbst im Befehl codiert. OpCode Imm. Operand Beispiel: LOAD R14,# Der Wert 2 wird in R14 als Operand geladen.
OpCode Imm. Operand
Der Wert 2 wird in R14 als Operand geladen.
- Absolute / Direkte Adressierung (Absolute / Direct addressing mode) Der Befehl enthält eine Speicheradresse an der der Operand stehtDer Befehl enthält eine Speicheradresse, an der der Operand steht.
Beispiel: LOAD R14 007E
OpCode (^) Address LOAD R14, 007E Der auf der Adresse 007E gespeicherte Wert wird in R14 geladen.
Speicher
R14 Operand Adresse 007E 16 = (^00000000011111102)
Operandenholphase : Adressierungsarten (2)
- Registerg Adressierungg ( (Register g addressing mode)g ) Der Operand befindet sich in einem Register. Die Registernummer ist im Befehl codiert. OpCode Reg‐Nr. (^) R
Register Op. Beispiel: LOAD R7, R Lade den Inhalt vom Register R
0010 0111 0100 0000 R1R
R Lade den Inhalt vom Register R4 O d 0642 R (also den Operanden) ins Register R7. 0642
R R R R
Operand 0642
- Register indirekte Adressierung (Register indirect addressing mode) Das Register enthält die Adresse einer Speicherzelle, in der sich der Operand befindet.
Beispiel: (^0100 0111 0010 )
OpCode (^) R R R
Register Op. Reg‐Nr. p LOAD R2, (R7) Speichere 055516 an der im Register R7 vorhandenen Adresse
R R R AdresseO d vom t ht R
0555
Address F120AB
R R R
Operanden steht Speicher Im^ Register^ R Operand:p 0555 Address F120AB^16
HS Mannheim EMB1:März 2011 LDK Kap 2. ‐ 19
Operandenholphase : Adressierungsarten (3)
- • Register relative Adressierung (Register relative addressing mode):Register‐relative Adressierung (Register relative addressing mode): Das Register enthält die Basisadresse, worauf der im Befehl angegebene Offset addiert wird. Die Summe bildet dann die Adresse, an der der Operand im SS peicheri h steht.h
Beispiel: (^0101 0000 0101 )
OpCode (^) Address12 (^) R R R
Register
LOAD R0, (5)R Lade den Inhalt von der berechneten Adresse
R R R R ins Register R Address F120AB
R R Address+ Address F120AB 16
Speicher (^) Operand (^) + Address F120B0 16
Address 5
- PC‐relative Adressierung (PC‐relative addressing mode) Der Befehlszähler (PC) stellt die Basisadresse dar, worauf der im Befehl angegebene b addiertddi t wird.i d
Beispiel: LOAD R0,(10)PC Der in R0 zu ladende Operand befindet sich an der Adresse PC + 10
