Embedded Systemarchitekturen und …€¦ · · 2014-04-14Embedded Systemarchitekturen und Echtzeitbetriebssysteme 2 4.2. IAR Debug- und Testverfahren im Überblick..... 76 4.2.1

Embedded Systemarchitekturen und Echtzeitbetriebssysteme

Inhaltsverzeichnis

1. ANWENDUNGSFELDER VON EMBEDDED SYSTEMEN ........................ 5

2. BEGRIFFSDEFINITIONEN UND ANFORDERUNGEN ............................ 16

2.1. Ein einführendes Beispiel ................................................................ 16

2.2. Anforderungen an ein Echtzeit-Betriebssystem ............................... 18

2.2.1. Rechtzeitigkeit ..................................................................... 18

2.2.2. Gleichzeitigkeit .................................................................... 20

2.2.3. Vorhersehbarkeit (Determinismus) ...................................... 21

3. AUFBAUSTRUKUR VON EMBEDDED SYSTEMEN ............................... 22

3.1. Embedded Systemarchitekturen ...................................................... 22

3.2. Vergleich Mikrocontroller versus Mikroprozessor ............................ 22

3.3. Hauptfunktionskomponenten eines Embedded Systems ................. 24

3.3.1. Mikrocontrollerfamilien (Auswahl)........................................ 29

3.4. Beurteilungskriterien für die Auswahl eines Mikrocomputersystems 36

3.4.1. Auswahl geeigneter Mikrocontroller - Bsp. TI MSP430 ....... 37

3.5. Der Adressraum der MSP430-Mikrocontrollerfamilie ....................... 42

3.5.1. MSP430 Memory Map im Detail .......................................... 44

3.5.2. Das Device Description File msp430F449.ddf .................... 46

3.5.3. Das Special Function Register File msp430F449.sfr.......... 47

3.6. Mikrocontrollerspeicher .................................................................... 62

3.7. Die CPU ........................................................................................... 63

3.7.1. Addressing Modes............................................................... 65

3.7.2. The Instruction Set .............................................................. 66

3.8. Kontrollfragen ................................................................................... 71

4. DER SOFTWARE BUILD PROZESS BEI EMBEDDED SYSTEMEN ...... 72

4.1. Entwicklungsschritte für ein Mikrocomputersystem .......................... 76

Embedded Systemarchitekturen und Echtzeitbetriebssysteme 2

4.2. IAR Debug- und Testverfahren im Überblick.................................... 76

4.2.1. IAR C-SPY Debugger Sysytems ......................................... 77

4.2.2. Test im EPROM .................................................................. 79

4.2.3. Test im Monitor ................................................................... 80

4.2.4. Test im Simulator ................................................................ 81

4.2.5. Debugging mit dem JTAG Interface .................................... 82

4.3. Building Salco RTOS Applications ................................................... 85

5. LOW POWER OPERATING MODES ....................................................... 88

6. INTERRUPTS UND INTERRUPT SERVICE ROUTINEN (ISR) ............... 90

6.1. Begriffsdefinitionen, unterschiedliche Arten von Interrupts .............. 91

6.1.1. Hardware-Interrupts (“Interrupt Request”-Leitungen) .......... 91

6.2. Übertragung des Interruptvektors von der Peripherie an die CPU ... 94

6.2.1. Maskierbare und nichtmaskierbare Interrupts ..................... 96

6.2.2. Software-Interrupts (BIOS-Interrupt) ................................... 96

6.2.3. Interrupt Service Routinen (ISR) ....................................... 100

6.3. Der Programmable Interrupt-Controller 8259 (PIC) ....................... 101

6.3.1. Zusammenspiel zwischen CPU und 8259-Controller ........ 105

6.3.2. Moderne Interruptverfahren ............................................... 112

6.4. CPU interne Bearbeitung von Interrupts und ISRs ......................... 112

6.4.1. Der normale Programmfluss ............................................. 112

6.4.2. Ablaufsteuerung zur Behandlung von Ausnahmesituationen114

6.4.3. Ziel: Änderung des normalen Programmflusses ............... 117

6.4.4. Wo stehen die Startadressen? .......................................... 117

6.4.5. Interne Unterbrechungsursachen ...................................... 118

6.4.6. Externe Unterbrechungsursache ....................................... 119

6.5. Das MSP430 Interruptsystem ........................................................ 120

6.6. Behandlung eines Interrupts beim MSP430 ................................... 123

6.7. Binden eines Interrupts an eine Interrupt Service Routine ............. 126

6.8. Interrupt Vektoren (aus msp430x44x.h ) ........................................ 126

6.9. Beispiele und Übungen zum Interruptsystem MSP430I ................. 127

6.9.1. Anwendungsbeispiel I ....................................................... 127


6.9.2. Anwendungsbeispiel II ...................................................... 132

6.9.3. Anwendungsbeispiel III ..................................................... 133

6.9.4. Übung I .............................................................................. 135

6.9.5. Übung II ............................................................................. 137 Document History

Version, Date Author(s) email address Changes and other notes

17.3.2010 [email protected]

Embedded Ressourcen

Embedded Systems Internet Resources Die Embedded Systems Internet Resources Webseite ist ein Sammelsurium von Information über embedded Mikrocontollersysteme und Entwicklungssystemhersteller.

EDN Access Umfangreiche Datenbank mit fast allen 8/16/32/64 Bit Mikrocontrollern und Mikroprozessoren und DSPs mit Links zu den Herstellern und Datenblättern. Notwendig ist Registrierung bei der Zeitschrift EDN und ein cookie enabled Browser.

C51 Primer Der C51 Primer (englisch) ist ein einführender Text der beschreibt, wie C Programme für den 8051 zu schreiben sind. Die verschiedenen Speicher Modelle, special function register, die Architektur des 8051 werden im Detail beschrieben.

C166 Primer Der C166 Primer (englisch) liefert Informationen über die Siemens 166 (16Bit) Mikrocontroller Familie. Eine detailierte Referenz liefert Details der Interrupts, der I/O Ports, der Bus Modi und mehr.

8051 Frequent Asked Questions (FAQ) Russ Hersch's 8051 FAQ (englisch) liefert sehr viel nützliche Information über die 8051 Mikrocontrollerfamilie. Sehr viele Links zu allen möglichen 8051 Web Seiten sind vorhanden.

Embedded Systems Internet Resources Die Embedded Systems Internet Resources Webseite ist ein Sammelsurium von Information über embedded Mikrocontollersysteme und Entwicklungssystemhersteller.


Chip Directory Sehr umfangreiches Verzeichnis aller möglichen HalbleiterICs: Chip Directory. Praktisch jeder je produzierte Chip ist enthalten, zum großen Teil mit Links zu den jeweiligen Her-stellern.

Embedded Systems Programming Embedded Systems Programming Englischsprachige Zeitschrift speziell über Mikrocontrol-lersysteme. Die Webseite des Verlags beinhaltet eine Menge aktuelle Informationen sowie code listings von erschienenen Artikeln.

EDN Magazine (Electronic Design Network) At the EDN Magazine website, you can read articles and write letters to the editors. http://www.edn.com/blog/1560000156-770.html

EDN provides engineers and engineering managers with in-depth design features and deep technical information on microprocessors and other digital ICs, analog ICs, ASICs, computers and software, computer peripherals, test and measurement, components, power sources, interconnections and packaging, and much more.

MSP430 IAR EMBEDDED WORKBENCH Tutorial, for Texas Instruments’ MSP430 Family


1. ANWENDUNGSFELDER VON EMBEDDED SYSTEMEN

Automatisierung von Maschinen Automatisierung technischer Anlagen

Werkzeugmaschinen Kraftwerksanlagen

Industrieroboter (Dampferzeuger,

Sensorsysteme (Bildverarbeitung) Turbinen, Generatoren)

Kraftfahrzeuge Energieversorgungsanlagen

(Motorsteuerung, (Lastverteiler

Bremssystem, Netzleitsysteme)

Getriebesteuerung, Fertigungssysteme

Fahrtplanung, Stahlwerksanlagen

Abstandswarnsystem, usw.) Walzwerksanlagen

Prüfmaschinen Schienenverkehrssysteme

Messmaschinen (Fernbahnen,

Küchengeräte Stadtbahnen,

Waschmaschinen U-Bahnen)

Nähmaschinen Gasversorgungssysteme

Alarmanlagen Prüfstände, Prüffelder

Navigationssysteme Verfahrenstechnische Anlagen

Heizungssysteme Laborautomatisierung

Spielzeuge Gebäude- und haustechnische Anlagen,

Filmkameras Aufzüge

Telefonanrufbeantworter Intensivstation

Hochregallager

Verkehrstechnik

Papiermaschinen

Textilmaschinen

Beispiele für den Einsatz von Embedded Systemen im Auto - gestern und heute


- gestern


- und heute


- zukünftig

Beispiele für den Einsatz von Embedded Systemen in der Prozessautomatisierung

- Induistrieroboter mit 6 Achsen


- Hexapod

- Prozessperipherie


Beispiele für den Einsatz von Embedded Systemen für den Bereich „Home Control“

- Home Control

- Medizintechnik


Beispiele für den Einsatz von Embedded Systemen im Anwendungsfeld PAN/LON



Types of ZigBee Networks

ZigBee networks can be configured to operate in a variety of different ways to suit the application and environment. Supported topologies include:

Figure: Peer to Peer (Ad-hoc)

ZigBee nodes connect directly to each other for peer to peer communication

Figure: Star Configuration

Using a single PAN coordinator, each node connects directly to the central coordinator – all inter-node communications are passed through the coordinator.


Figure: Cluster Tree

A cluster tree network consists of a number of star networks connected whose central nodes are also in direct communications with the single PAN Coordinator.

Figure: Mesh Network

Using a set of routers and a single PAN coordinator, the network is formed into an interconnected mesh of routers and end nodes which pass information from node to node using the most cost effective path. Should any individual router become inaccessible, alternate routes can be discovered and used providing a robust and reliable network topography.


Bild: Architektur des ZigBee Protokollstack

Bild: Embedded Systeme in der Mikrosystemtechnik


Übung:

Wie viele eingebettete Systeme gibt es hier im Raum?

Mit wie vielen Embedded Systemen sind Sie heute bereits in Berührung gekommen?

2. BEGRIFFSDEFINITIONEN UND ANFORDERUNGEN

2.1. Ein einführendes Beispiel

Anwendungsbeispiel: Düsentriebwerkes

Bild: Aufbau eines Düsenstrahltriebwerkes

Funktionsweise eines Düsentriebwerkes: siehe www.rolls-royce.com/education/schools/how_things_work/journey02/flash.html


I. Begriffsdefinition: Embedded System

Druck p Embedded-System

Treibstoff-Stellventil

Technisches System

Bsp.: Temperatur- und Druckregelung eines Düsentriebwerkes

Tempertur Display (Cockpit)

Protokollierung(Blackbox)

Embedded System- ist ein mit SW ausgestatteter Mikroprozessor/Mikrocontroller, - ist ein Rechensystem, dass Teil einer größeren technischen Anordnung ist- ist auf einen bestimmten Zweck zugeschnitten- meist über die gesamte Lebenszeit unverändert- Bsp.: ABS, Motorsteuerung

HW- Mikrocontroller- IOs (dig, analog, ser, parall)

SW- (Echtzeit-)Betriebssystem- Applikationen

Bild: Definition Echtzeitbetrieb und Real-Time Systems

=> Ein Echtzeitsystem ist ein Rechensystem, dessen Korrektheit - nicht nur von der logischen Korrektheit der Ergebnisse sondern auch - von der Einhaltung vorgegebener Zeitbedingungen abhängt. Die Nichteinhaltung der vorgegebenen Zeitforderungen ist gleichbedeutend mit dem Ver-sagen des Systems.


Bild: Definition Echtzeit

2.2. Anforderungen an ein Echtzeit-Betriebssystem

2.2.1. Rechtzeitigkeit

Rechtzeitigkeit: Rechnersystem muss mit den im technischen Prozess ablaufenden Vorgängen Schritt halten, um Zeitbedingungen erfüllen zu können.

Das heißt: auf jedes Ereignis des Prozesses muss innerhalb einer vorgegebenen Zeit spanne reagiert werden. Das Ereignis muss in dieser Zeit erfasst, die Berechnungen ausgeführt und die Reaktion zum Prozess ausgegeben sein.

Reaktionszeiten werden von dem technischen Prozess bestimmt und müssen für je den auftretenden Ereignistyp spezifiziert werden.

Die Forderung nach Rechtzeitigkeit des Rechensystems bedeutet, dass

die Eingabedaten rechtzeitig abgerufen werden müssen und

dass die Ausgabedaten rechtzeitig in Bezug auf die Anforderungen des betreffenden technischen Prozesses verfügbar sein müssen.

Man unterscheidet 2 Kategorien von Zeitbedingungen

Absolutzeit-Bedingungen, z.B. um 13.30 soll ein Signal zur Abfahrt eines Zuges ausgegeben werden

Relativ-Zeitbedingungen, z.B. Nach dem Auftreten des Streckensignals soll das Stellsignal für die Weichenstellung innerhalb von 10sec. ausgegeben werden


Bild: Definitionen zur Rechtzeitigkeit

4 Fälle

Fall 1: Das erfassen eines Meßwertes oder die Ausgabe eines Stellsignals hat genau zu bestimmten Zeitpunkten zu erfolgen

Fall 2: Eine Funktion hat innerhalb eines Zeitfensters zu erfolgen (t1 + tDelta ) (Toleranzbereich)

Fall 3: Eine Funktion hat spätestens zu einem bestimmten Zeitpunkt zu erfolgen

Fall 4: Eine Aktion darf frühestens zu einem bestimmten Zeitpunkt erfolgen

Definition: Echtzeitbedingungen (harte u. weiche Echtzeit)

Harte Echtzeit (Hard Real-Time): Nichteinhaltung der Zeitbedingung wird als Fehler gewertet und fUhrt zu einem Versagen des Systems.

Weiche Echtzeit (Soft Real-Time): Ergebnis kann nach Ablauf der Zeitbedingung noch verwendet werden, ist allerdings mit Nachteilen verbunden (z.B. Verspätung, höhere Kosten). Zeitbedingung sollte nur selten überschritten werden.

Definition: Real-Time conditions (newsgroup.comp.realtime)

Hard Real-Time: Provides, without fail, a response to some kind of event within a specified time window (timeliness of result), The response must be predictable and independent of other operating System or application activities.


Soft Real-Time: It has reduces constraints on "Lateness", but still must operate quickly within foirly consistent time constraints. The response to the serviced events should be satisfactory, on average.

Laufzeitverzögerungen (Latenzzeiten) durch Betriebssystemaufrufe müssen von dem Be-triebssyste innerste Her genannt werden. Maximale Verzögerungszeiten müssen durch den Betriebssystem-Hersteller garantiert werden und im laufenden Betrieb eingehalten werden.

Harte und weiche Echtzeit-Systeme

Gegenüber weichen Echtzeit-Systemen müssen harte Echtzeit-Systeme eine höhere „Zeit-Qualität“ erfüllen. Sie sind charakterisiert durch:

Sie besitzen mindestens eine spezifizierte harte Echtzeitbedingung.

Harte Echtzeibedingungen müssen unter allen Systembelastungen (auch bei Sys-temfehlern) eingehalten werden, ansonsten liegt ein Systemversagen vor (siehe Def. 1.6).

Das Einhalten der Echtzeitbedingungen lässt sich trotz deterministischem Verhalten der

Hardware, des Betriebssystems und der Applikationen nicht vollständig testen.

Harte Echtzeitbedingungen haben keine Korrelation mit schneller Verarbeitung oder hoher Prozessor-Leistung.

Harte Echtzeitbedingungen sind selten und treten in der Regel verkoppelt mit weichen Echtzeitbedingungen auf.

Bei dem Design und der Bewertung von harten Echtzeitsystemen müssen nichtdetermini-stische Komponenten berücksichtigt werden:

2.2.2. Gleichzeitigkeit

Gleichzeitigkeit: Rechnersystem muss die Fähigkeit besitzen, mehrere gleichzeitig ab-laufende Vorgänge eines Systems zu bearbeiten.

Forderung kann durch parallel arbeitende Hardware-basierende Einheiten (Prozessoren, E/A-Einheiten, etc.) erfüllt werden.

Forderung kann auch durch die nebenläufige Abarbeitung von Rechenprozessen auf einem Prozessor erfüllt werden. Hierbei müssen die Verarbeitungszeiten im Vergleich zu den Abläufen des technischen Prozesses klein sind (quasi-parallele Verarbeitung).

Die Forderung nach Gleichzeitigkeit ergibt sich aus der Tatsache, dass Echtzeit-Rechensysteme auf Vorgänge in ihrer Umwelt reagieren müssen, die gleichzeitig ablaufen

z.B.: Schienenverkehrssystem: ein Prozessrechensystem muss auf die gleichzeitige Fahrt mehrerer Züge reagieren und entsprechend die Weichenstellung vornehmen, d..h. gleichzeitig anfallende Meßwerte müssen erfaßt und ausgewertet werden, und ggf. müssen auch gleichzeitig mehrere Stellsignale ausgegeben werden.


Oder ein Beisp. Aus dem Betrieb eines Rechners: Hier möchte man gleichzeitig ein Programm editieren, (d. h. am Bildschirm eingeben, ändern etc.) und ein gleichzeitig ein Peripheriegerät (z.B. Drucker) betätigen. Der Prozessor muss so zwischen dem EditierProzess und dem Druckprozess ständig hin und her schalten.

Wie lässt sich Gleichzeitigkeit herstellen?

Am einfachsten durch einen getrennten Rechner (z.B. Hardware-Druckerboxen: Spooler). In diesem Fall arbeiten dann die Programme des so entstehenden Mehrrechner-Systems echt parallel und gleichzeitig. (NT: sehr teuer)

Die Forderung nach Gleichzeitigkeit kann jedoch auch mit einem einzigen Computer näherungsweise erfüllt werden, wenn man voraussetzt, dass die Vorgänge in der Prozess-Umwelt langsam ablaufen gegenüber der Programmabarbeitung im Computer. Durch schnelles und intelligentes Umschalten in kurzen Zeitabständen gelingt es so gleichzeitig ablaufende Vorgänge in der „Umwelt“ gleichzeitig zu bedienenen.

Durch Verwendung eines Schedulers.

Bild: Anforderungen an ein Echtzeit-Betriebssystem

2.2.3. Vorhersehbarkeit (Determinismus)

Vorhersehbarkeit: Das System-Verhalten muss auch bei zufällig anfallenden Ereignissen deterministisch und vorhersagbar sein.

Bei gleichzeitigem Auftreten mehrerer Ereignisse, das zu einer Konkurrenzsituation bzgl. der Verarbeitung führt, muss das Verhalten bekannt und vorhersagbar sein. Die Bearbeitung der einzelnen Ereignisse darf nur in einer vorhersagbaren Form verzögert werden. Die Reaktionszeiten müssen weiterhin in den Rechtzeitigkeitsgrenzen liegen.


Nicht formal nachweisbar, wenn periodische Anforderungen (einplanbar) und unbekannte spontane Anforderungen (Signale, Alarme) gemischt auftreten. Logische und zeitliche Korrektheit einzelner Routinen reicht nicht aus, da Nebenläufigkeit und zufällige Verteilung von Ereignissen die Verifkationsmöglichkeiten beschränken.

Analyse für den schlechtesten Fall (worst case), d. h. für maximal zu erwartende Signalraten, notwendig. Hierzu müssen die Programmlaufzeiten bekannt sein.

3. AUFBAUSTRUKUR VON EMBEDDED SYSTEMEN

Hardware-Aufbaustruktur von Embedded Systemboards

On Chip-Peripherie

On Board Peripherie, Folie Komponentenaufbaustruktur

Softwarekomponenten: EBS-Kernel

3.1. Embedded Systemarchitekturen

- z. B. SoC - System on Chip

- Grundsätzliche Ansatz für das Design einer generischen Aufbaustruktur

- siehe Dissertation generischer Ansatz der Hardware-Aufbaustruktur

- siehe Hardwareaufbaustrukturen im Messebuch Embedded Systems 2003/2004

- Klassifikation von Hardwaresystemen

- Designansätze:

- Rein Hardwarebasierend mittels LCA, XPGAs etc. Mikroblaze etc. (siehe Beru-fungsvortrag an der FH Augsburg 2004), spezialisierte Hardware (Netzwerkpro-zessor)

- Hardware und Softwarebasierend (Universal-Embedded Board, wie x-Board, Tiny-Boards)

- Kriterien für die Auswahl eines Embeddedboard (Kosten des Enticklungssystems, laufende Lizenzkosten, Time-to-market Entwicklungszeiten und -unterstützung, Leistungsfähigkeit (Benchmarking) etc.

3.2. Vergleich Mikrocontroller versus Mikroprozessor

µC Chip Includes:

Central Processor

Program Memory

Data Memory

µP Chip Includes:

Central Processor

Separate Chips for:

Central Processor


I/O

Highly Integrated

Low Cost

Specialized Architectures

Program Memory

Data Memory

I/O

Highest Performance

Highest Cost

Bild: µController versus µProzessor

Bild: Bus orientierter Mikrocontroller, typischer Aufbau eines µControllers


Bild: Memory Read/Write Cycle

Vor- und Nachteile von Single Chip Mikrocontrollern

Advantages:

Fewer chips required

Lower cost and smaller

Lower power

Fewer connections

More user I/O pins

Reliability is higher

Disadvantages:

Reduced flexibility

Expansion is limited

Limited performance

Limited I/O

Design compromised to fit everything on one

chip

3.3. Hauptfunktionskomponenten eines Embedded Systems

Der Hardware-Core: Mikrocontroller

Mikrocontroller-OnChip Funktionseinheiten - Digitale I/O - Standard I/O - Capture- and Compare-Einheiten - PWM (Pulsweitenmodulierte Ausgänge) - Analoge I/O - AD/DA-Wandler - RS232-asynchrone und synchrone Einheiten


Das Interrupt-System (siehe Unterlagen Dr. Jacob)

- Interruptcontroller - Daisy-Chain - Mechanismus Interruptleitung, Interruptvektor und Interruptserviceroutine (ISR)

Das Speichersystem

- Speicherarten -> siehe Berufungsvortrag an der FH Augsburg - Flash-Speicher, z.B. für Images und Disklesssysteme - EPROM - DRAMs, SRAMs etc.

Kommunikationsadapter

- Digitale Chip-to-Chip-Bussysteme (I2C, SPI etc.) - Ethernet-Controller (Dallas D800C40 etc.) - Feldbus-Controller (Aufbau und Schnittstelle zum Mikrocontroller) - Ggf. USB, Wireless etc.

Signalkonditionierung

- Bsp. Signal-Conditioning--AD7710.pdf Bsp. Board

- 68000 Board aus dem Praktikum - Universal-Boards (Tiny, x-Boards, Board im Automobilbereich für den Embed-

dedbereich etc.) - Router-Board - Settop-Box Board

CPU MCU (MCU = CPU mit On-Chip Peripherie) On-Board Peripherie Schnittstellen Watchdog Diagnosemöglichkeiten mittels JTAG Memory Map eines Embedded Systems


Bild: MSP430x44x functional block diagrams

Zentraleinheit

Die Zentraleinheit (Central Processing Unit CPU) stellt den Rechnerkern dar, um den sich alles

dreht. Sie realisiert die Ablaufsteuerung des Rechners selbst, die Durchführung arithmetisch-

logischer Operationen, den Transfer von Daten und den Ablauf des Programms.

Bei der Familie MSP430 handelt es sich um eine 16-Bit-RISC-CPU mit verschiedenen universellen

Registern, einem breiten Spektrum an Adressierarten, einem kleinen, aber flexiblen Befehlssatz,

alles ausgelegt auf hohe Leistung bei besonders kleinem Stromverbrauch.

Zum Test des gesamten Systems und zur Programmierung ist die CPU von einer JTAG-

Schnittstelle umgeben, die es erlaubt, auf den gesamten Mikrocontroller mit nur vier Leitungen

effektiv zuzugreifen.

Peripherieeinheiten

Die Familie MSP430 zeichnet sich durch eine breite Palette intelligenter und voneinander und von

der CPU weitestgehend unabhängiger Peripherie aus, die die Realisierung komplexer Systeme mit

nur geringer externer Beschaltung erlaubt.

Die Peripherie ist in Modulen realisiert, die mit der CPU durch den Speicheradressbus MAB, den

Speicherdatenbus MDB und Unterbrechungsdienst- und -anforderungsleitungen verbunden sind.

Die Befehlsausführung bei 16-Bit-Modulen arbeitet ohne Einschränkungen (Watchdog, ADC,

TIMER A, Hardware-Multiplier). Die 8 bit-Peripheriemodule sind byteorientiert. Ihre SFR’s werden

ausnahmslos mit einem Datenbereich von 8 Bit betrieben.


"On-board"-Hardwaremodule"On chip"-Hardwaremodule

a)

Bild: Komponentenmodell eines mikrocontrollergestützten Embedded Systems

b)

V24

RS485

HSI

HSO

PIO

PWM

ADU

16 Mhz

Power-Control

Watchdog

Reset

Vcc Vbat

Vram

DAU

Vref

(Singl-Chip-Controller)Signal-Mikrocontroller

Komponente

Timer

HW-TimerSW-Timer

Kommunikations-Controller

Elementarglied

ProtokollCAN

ProtokollProfiBus

ProtokollSERCOS

Sensor

Temp.

Klassenschema

Objektschema

VentilDruck Relaisv .. ...

Aktor

- Technologie- Gehäusety p- Taktrate- etc.

- max. Zählerwert- Up /Down- .. .

- Name- Schn ittstelle- .. .

- ext./int.Trigger- Gated- .. .

- Reloaded- INT- .. .

Memory-Controller

EPROM

Flash, EEPROM

Analog

DA PWM HSI HSOPortAD

Binär

RAM

ROM

Memory- Adreßraum- Basisad resse- Datenwortbreite- Pr ogrammierausführun g- .. .

IOs Interface- Adreßraum- Basisad resse- Memor y-Mapp ed- .. .

- Adreßraum- Basisad res se- Memor y-Mapp ed- INT- .. .

64 kbyte

RAM

64 kbyte

EPROM

64 kbyte

FEPROM

InterfaceFeldbus

MemoryController(EPLD)

24 Mhz

24 bit Adressbus

16 bit Datenbus

Steuerbus

Treiber(Verstärker,Puffer)

(z.B. CAN)

Vprgm

HW-Timer 1

HW-Timer 2Interrupt / PTSController

RegisterFile

Control

ALUBlock

Control Block

Capture-Compare-Timer ..

Bild: Klassenschema und Objektscheme zur topologischen Modellierung eines Embed-ded Systems


Legende:

MCU- Mikrocontroller UnitFBC - Fieldbus Controller

Fe

ldb

us

?

?

?

?

FBC

FBC

MCU

MCU

COMMUNI_TASK

COMMUNI_TASK

PROCESS_TASK1

PROCESS_TASK1

RTM-

Kernel

RTM-

Kernel

SYST

EM

CALL INTERFACE

SYST

EM

CALL INTERFACE

FBC

WIN

DOWS

BIOS

MAIN

PROCESSORKON

FIGU

RATI

O N

FUNKTIONS-MANAGEMENT

DOS

-DIAGNOSE-

P ROJEKT-

M

AN

AG

EMENT

KOORD

INAT

ION

INIT

_RTM

INIT

_RTM

PROJEK

-

TIERUNG

SIMUL.

?

Bild: Komponenten eines verteilten intelligenten Sensor-/Aktorsystems


3.3.1. Mikrocontrollerfamilien (Auswahl)

Bild: 80C552/83C552 - Single-chip 8-bit microcontroller with 10-bit A/D, capture/compare timer, high-speed outputs, PWM


Mikrocontroller mit CAN-Interface

Bild: Typische Struktur von CAN-Knoten

Bild: C164CI - CAN-Schnittstelle


AT90CAN128

Bild: Block Diagram AT90CAN128


Soft CPU Cores for FPGA http://www.1-core.com/library/digital/soft-cpu-cores/soft-cpu-

cores.pdf Soft CPU cores are usually used to create an FPGA-based system-on-chip (SoC). In this case a CPU core controls the work of the circuit and does some random calculations, and the other parts of the circuit are responsible for interfacing and parallel processing.

Hard vs Soft CPU Cores There are two types of CPU cores for FPGA: hard and soft. Hard CPU core is a dedicated part of the integrated circuit, whereas soft CPU core is implemented utilizing general-purpose FPGA logic cells.


Bild: Block Diagram AT90CAN128

PSoC™ Mixed-Signal Array The PSoC™ family consists of many Mixed-Signal Array with On-Chip Controller devices. These devices are designed to replace multiple traditional MCU-based system components with one, low cost single-chip programmable component.

A PSoC device includes configurable blocks of analog and digital logic, as well as programmable interconnect. This architecture allows the user to create customized peripheral configurations, to match the requirements of each individual application.

Additionally, a fast CPU, Flash program memory, SRAM data memory, and configurable IO are included in a range of convenient pinouts.

Bild: Block Diagram Cypress PSoCTM CY8C21434


Bild: Digital System Block Diagram


Bild: Analog System Block Diagram


Weitere Mikrocontrollerfamilien

3.4. Beurteilungskriterien für die Auswahl eines Mikrocomputersystems

Datenformat (4, 8, 16, 32 bit) Befehlsvorrat, Adressierungsmöglichkeiten CPU-Struktur Mikroprogrammierbarkeit Geschwindigkeit Interrupt - Möglichkeiten Schnittstelleneigenschaften Speicherkonzept Versorgungsspannung Verfügbarkeit von Bausteinen Sicherung der Lieferfähigkeit (Zweitlieferant), Zukunftssicherheit des Systems Zusatz-Hard- und Software für Systementwicklung, Tool-Chain Unterstützung durch den Hersteller Dokumentations-und Ausbildungsangebot Preis


3.4.1. Auswahl geeigneter Mikrocontroller - Bsp. TI MSP430

Bild: Mikrocontroller- Derivate am Beispiel der MSP430 Roadmap

Bild: MSP430 Roadmap (Bsp)


Bild: Positionierung der Microkontrollerfamilie MSP430 (1)

Bild: Positionierung der Microkontrollerfamilie MSP430 (2)


Bild: MSP430 Mikrocontrollerfamilie (8MHz), Quelle: MSP430-slab034j.pdf

Bild: MSP430 Mikrocontrollerfamilie (16 MHz), Quelle: MSP430-slab034j.pdf

-> TI Product Selection Webseite


http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?&familyId=342&uiTemplateId=PP-T-GSPA_T&sectionId=95&tabId=1200&appId=null&viewDeviceCallingPage=null&totalCount=100&showAdditionalParameters=yes&lc=2000062&lc=2001227&lc=2001220&lc=2001219&lc=2000886&lc=2000121&lc=2001132&compare=yes&download=yes&sort=yes&customize=yes&paramResults=yes&paramCriteria=yes&familyTree=yes&military=no&baSystem=yes&paramTable=no&sortOption=&sortMode=&searchPaths=1000342&pageId=342&templateId=0&navigationId=0&family=mcu&paramTable=no&military=no&ul=MSP430FW427&ul=MSP430FW425&ul=MSP430FW423&ul=MSP430FG4619&ul=MSP430FG4618&ul=MSP430FG4617&ul=MSP430FG4616&ul=MSP430FG439&ul=MSP430FG438&ul=MSP430FG437&&uiTemplateId=PP-T-GSPA_T&sectionId=95&tabId=1200&appId=null&viewDeviceCallingPage=null#sdp

-> siehe auch Product Selection Guide TI MSP430.xls


-> µC-Familie am Bsp von MSP430, siehe pdf-Files von TI OTP-Chip (One-Time-Programmable


3.5. Der Adressraum der MSP430-Mikrocontrollerfamilie

Die MSP430-Familie arbeitet nur über einen Adressraum, der auf eine Adressbreite von 16 Bit festgelegt ist. Dieser Adressraum umfasst

alle Spezialregister der CPU und der weiteren im Chip integrierten peripheren Module,

den Schreib-Lese-Speicher, der zur Aufnahme des Stapelspeichers (Stack), vari-abler Daten und Programme verwendet wird,

den Programmspeicher

leere Bereiche ohne Speicher

Interruptvektoren

in einem 16-Bit-Bereich, also den Adressen zwischen 0 und 0FFFFH bzw. 0 bis 65535 dezimal.

Bild: Blockschaltbild MSP430


Bild: Feature List MSP430x43x und MSP430x44x

Bild: MSP430x44x Speicherorganisation (memory map)

Damit sind dieselben Befehle zur Speicherbearbeitung, für Peripherieaktivitäten und für Ein-/Ausgabeoperationen zuständig, und das mit allen Adressierungsarten.


In Zukunft soll der Speicher durch segmentierte Speicherblöcke erweitert werden. Dazu werden im Statusregister die führenden Adressbits von Codesegmenten (Pro-grammsegmenten) als Codesegmentzeiger (Code Segment Pointer CSP) und getrennt davon ein Teil der Datenadresse als Datenzeiger (Data Pointer DPP) gespeichert.

Separate Memory Address Spaces für

Programme - Non-volatile (nichtflüchtig, permanent)

Internal ROM

External EPROM

Daten - Volatile

External SRAM

Internal RAM

o General Purpose Registers

o Bit Addressable Registers

o Special Function Registers

3.5.1. MSP430 Memory Map im Detail

Memory Address Description

0FFE0h–0FFFFh Interrupt Vectors

0FFDFh End of code space - All device

0F800h Start of code space - 2K device

0F000h Start of code space - 4K device

0E000h Start of code space - 8K device

0D000h Start of code space - 12K device

0C000h Start of code space - 16K device

0A000h Start of code space - 24K device

08000h Start of code space - 32K device




010FFh End of Information Memory: Flash devices except 'F110 and 'F1101

0107Fh End of Information Memory: 'F110 and 'F1101

01000h Start of Information Memory: Flash devices only

0FFFh End of Boot Memory: Flash devices only

0C00h Start of Boot Memory: Flash devices only

09FFh End of RAM-2k devices

05FFh End of RAM-1k devices

03FFh End of RAM-512 byte devices

02FFh End of RAM-256 byte devices

027Fh End of RAM-128 byte devices

0200h Start of RAM-All devices

01B0h – 01FFh Unused (All devices)

01A0h – 01AFh ADC Control ('1xx and '4xx devices) / Unused ('3xx devices)

0160h – 017Fh Timer A (All devices)

0140h – 015Fh ADC Conversion ('1xx and '4xx devices) / Unused ('3xx devices)

0130h – 013Fh Multiplier (All devices)

0110h – 011Fh ADC ('3xx devices) / Unused ('1xx and '4xx devices)

0100h – 010Fh Unused (All devices)

00B0h – 00FFh Unused (All devices)

0090h – 00AFh LCD (Byte addressed, '4xx devices) / Unused ('1xx and '3xx devices)

0080h – 008Fh ADC memory control (Byte addressed, '1xx and '4xx devices) / Unused

('3xx devices)

0070h – 007Fh USART (Byte addressed, All devices)


0050h – 005Fh System Clock (Byte addressable, All devices) / Comparator ('1xx and

'4xx devices) / Brownout ('4xx devices) / EPROM and crystal buffer ('3xx

devices)

0040h – 004Fh Basic Timer and 8-bit Counter (Byte addressable, '3xx and '4xx devices)

/ Unused ('1xx devices)

0030h – 003Fh I/O ports 5 and 6 control (Byte addressable, '1xx and '4xx devices) / LCD

(Byte addressable, '3xx devices)

0020h – 002Fh I/O ports 1 and 2 control (Byte addressable, All devices)


0010h – 001Fh I/O ports 3 and 4 control (Byte addressable, All devices), I/O port 0 (Byte

addressable, '3xx devices)


0005h Module Enables 2 (Byte Addressable, all devices)

0004h Module Enables 1(Byte Addressable, all devices)

0003h Interrupt Flags 2 (Byte Addressable, all devices)

0002h Interrupt Flags 1 (Byte Addressable, all devices)

0001h Interrupt Enables 2 (Byte Addressable, all devices)

0000h Interrupt Enables 1 (Byte Addressable, all devices)

Bild: Memory Map (detailliert) All die physikalisch getrennten Speicherbereiche, sowohl die internen Bereiche mit Festwertspeicher (ROM,..), Schreib-/Lesespeicher (RAM,..), Spezialregistern (SFR) und Peripheriemodulen, als auch -wenn vorhanden- die externen Bereiche sind in einem einzigen Adressraum positioniert (mapped).

Für alle Prozessoren mit einer maximalen Größe des Adressraumes von 64 kByte (65.536 Bytes), gilt das “kleine Speichermodell” (small memory model).

Dieses Speichermodell benutzt einen eindimensionalen linearen Adressraum mit Adressen von Null (00000h) bis 65.535 (0FFFFh).

3.5.2. Das Device Description File msp430F449.ddf

;;/************************************************** ;; * Definitions of I/O register description file, ;; * interrupt/exception vectors, interrupt control registers, ;; * I/O register reset values. ;; * ;; * Copyright 2001-2003 IAR Systems. All rights reserved. ;; * $Revision: 1.9 $ ;; **************************************************/ ;; Memory information ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Used to define address zones within the MSP430 address space (Memory). ;; ;; Name may be almost anything ;; AdrSpace must be Memory ;; StartAdr start of memory block ;; EndAdr end of memory block ;; AccType type of access, read-only (R) or read-write (RW) [Memory] ;; Name AdrSpace StartAdr EndAdr AccType Memory0 = SFR Memory 0x0000 0x01FF RW Memory1 = RAM Memory 0x0200 0x09FF RW Memory2 = INFO Memory 0x1000 0x10FF R Memory3 = FLASH Memory 0x1100 0xFFDF R


;; I/O Register description file ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; [SfrInclude] File = MSP430F449.sfr ;; Interrupt definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; [InterruptList] ; Id Table Adr Prio Enable Pending Interrupt0 = BASICTIMER_VECTOR 0x00 2 IE2.BTIE IFG2.BTIFG Interrupt1 = PORT2_VECTOR 0x02 2 P2IE.P2IE_0 P2IFG.P2IFG_0 Interrupt2 = PORT2_VECTOR 0x02 2 P2IE.P2IE_1 P2IFG.P2IFG_1 Interrupt3 = PORT2_VECTOR 0x02 2 P2IE.P2IE_2 P2IFG.P2IFG_2 Interrupt4 = PORT2_VECTOR 0x02 2 P2IE.P2IE_3 P2IFG.P2IFG_3 Interrupt5 = PORT2_VECTOR 0x02 2 P2IE.P2IE_4 P2IFG.P2IFG_4 Interrupt6 = PORT2_VECTOR 0x02 2 P2IE.P2IE_5 P2IFG.P2IFG_5 Interrupt7 = PORT2_VECTOR 0x02 2 P2IE.P2IE_6 P2IFG.P2IFG_6 Interrupt8 = PORT2_VECTOR 0x02 2 P2IE.P2IE_7 P2IFG.P2IFG_7 Interrupt9 = USART1TX_VECTOR 0x04 2 IE2.UTXIE1 IFG2.UTXIFG1 Interrupt10 = USART1RX_VECTOR 0x06 2 IE2.URXIE1 IFG2.URXIFG1 Interrupt11 = PORT1_VECTOR 0x08 2 P1IE.P1IE_0 P1IFG.P1IFG_0 Interrupt12 = PORT1_VECTOR 0x08 2 P1IE.P1IE_1 P1IFG.P1IFG_1 Interrupt13 = PORT1_VECTOR 0x08 2 P1IE.P1IE_2 P1IFG.P1IFG_2 Interrupt14 = PORT1_VECTOR 0x08 2 P1IE.P1IE_3 P1IFG.P1IFG_3 Interrupt15 = PORT1_VECTOR 0x08 2 P1IE.P1IE_4 P1IFG.P1IFG_4 Interrupt16 = PORT1_VECTOR 0x08 2 P1IE.P1IE_5 P1IFG.P1IFG_5 Interrupt17 = PORT1_VECTOR 0x08 2 P1IE.P1IE_6 P1IFG.P1IFG_6 Interrupt18 = PORT1_VECTOR 0x08 2 P1IE.P1IE_7 P1IFG.P1IFG_7 Interrupt19 = TIMERA1_VECTOR 0x0A 2 TACCTL1.CCIE TACCTL1.CCIFG Interrupt20 = TIMERA1_VECTOR 0x0A 2 TACCTL2.CCIE TACCTL2.CCIFG Interrupt21 = TIMERA1_VECTOR 0x0A 2 TACTL.TAIE TACTL.TAIFG Interrupt22 = TIMERA0_VECTOR 0x0C 2 TACCTL0.CCIE TACCTL0.CCIFG Interrupt23 = ADC_VECTOR 0x0E 2 ADC12IE ADC12IFG Interrupt24 = USART0TX_VECTOR 0x10 2 IE1.UTXIE0 IFG1.UTXIFG0 Interrupt25 = USART0RX_VECTOR 0x12 2 IE1.URXIE0 IFG1.URXIFG0 Interrupt26 = WDT_VECTOR 0x14 2 IE1.WDTIE IFG1.WDTIFG Interrupt27 = COMPARATORA_VECTOR 0x16 2 CACTL1.CAIE CACTL1.CAIFG Interrupt28 = TIMERB1_VECTOR 0x18 2 TBCCTL1.CCIE TBCCTL1.CCIFG Interrupt29 = TIMERB1_VECTOR 0x18 2 TBCCTL2.CCIE TBCCTL2.CCIFG Interrupt30 = TIMERB1_VECTOR 0x18 2 TBCCTL3.CCIE TBCCTL3.CCIFG Interrupt31 = TIMERB1_VECTOR 0x18 2 TBCCTL4.CCIE TBCCTL4.CCIFG Interrupt32 = TIMERB1_VECTOR 0x18 2 TBCCTL5.CCIE TBCCTL5.CCIFG Interrupt33 = TIMERB1_VECTOR 0x18 2 TBCCTL6.CCIE TBCCTL6.CCIFG Interrupt34 = TIMERB1_VECTOR 0x18 2 TBCTL.TBIE TBCTL.TBIFG Interrupt35 = TIMERB0_VECTOR 0x1A 2 TBCCTL0.CCIE TBCCTL0.CCIFG Interrupt36 = NMI_VECTOR 0x1C 2 IE1.OFIE IFG1.NMIIFG Interrupt37 = RESET_VECTOR 0x1E 1 ;; End of file

3.5.3. Das Special Function Register File msp430F449.sfr

;;------------------------------------------------------------------------- ;; Definitions of peripheral I/O registers and bits ;; Copyright 1996-2003 IAR Systems. All rights reserved. ;; $Revision: 1.12 $ ;;------------------------------------------------------------------------- [Sfr] ;; Special Function sfr = "IE1", "Memory", 0x0000, 1, base=16 sfr = "IE1.WDTIE", "Memory", 0x0000, 1, base=16, bitRange=0 sfr = "IE1.OFIE", "Memory", 0x0000, 1, base=16, bitRange=1


sfr = "IE1.NMIIE", "Memory", 0x0000, 1, base=16, bitRange=4 sfr = "IE1.ACCVIE", "Memory", 0x0000, 1, base=16, bitRange=5 sfr = "IE1.URXIE0", "Memory", 0x0000, 1, base=16, bitRange=6 sfr = "IE1.UTXIE0", "Memory", 0x0000, 1, base=16, bitRange=7 sfr = "U0IE", "Memory", 0x0000, 1, base=16 sfr = "IFG1", "Memory", 0x0002, 1, base=16 sfr = "IFG1.WDTIFG", "Memory", 0x0002, 1, base=16, bitRange=0 sfr = "IFG1.OFIFG", "Memory", 0x0002, 1, base=16, bitRange=1 sfr = "IFG1.NMIIFG", "Memory", 0x0002, 1, base=16, bitRange=4 sfr = "IFG1.URXIFG0", "Memory", 0x0002, 1, base=16, bitRange=6 sfr = "IFG1.UTXIFG0", "Memory", 0x0002, 1, base=16, bitRange=7 sfr = "U0IFG", "Memory", 0x0002, 1, base=16 sfr = "ME1", "Memory", 0x0004, 1, base=16 sfr = "ME1.URXE0", "Memory", 0x0004, 1, base=16, bitRange=6 sfr = "ME1.UTXE0", "Memory", 0x0004, 1, base=16, bitRange=7 sfr = "U0ME", "Memory", 0x0004, 1, base=16 sfr = "U0ME.USPIE0", "Memory", 0x0004, 1, base=16, bitRange=6 sfr = "IE2", "Memory", 0x0001, 1, base=16 sfr = "IE2.URXIE1", "Memory", 0x0001, 1, base=16, bitRange=4 sfr = "IE2.UTXIE1", "Memory", 0x0001, 1, base=16, bitRange=5 sfr = "IE2.BTIE", "Memory", 0x0001, 1, base=16, bitRange=7 sfr = "U1IE", "Memory", 0x0001, 1, base=16 sfr = "IFG2", "Memory", 0x0003, 1, base=16 sfr = "IFG2.URXIFG1", "Memory", 0x0003, 1, base=16, bitRange=4 sfr = "IFG2.UTXIFG1", "Memory", 0x0003, 1, base=16, bitRange=5 sfr = "IFG2.BTIFG", "Memory", 0x0003, 1, base=16, bitRange=7 sfr = "U1IFG", "Memory", 0x0003, 1, base=16 sfr = "ME2", "Memory", 0x0005, 1, base=16 sfr = "ME2.URXE1", "Memory", 0x0005, 1, base=16, bitRange=6 sfr = "ME2.UTXE1", "Memory", 0x0005, 1, base=16, bitRange=7 sfr = "U1ME", "Memory", 0x0005, 1, base=16 sfr = "U1ME.USPIE1", "Memory", 0x0005, 1, base=16, bitRange=6 ;; Watchdog Timer sfr = "WDTCTL", "Memory", 0x0120, 2, base=16 sfr = "WDTCTL.WDTIS0", "Memory", 0x0120, 2, base=16, bitRange=0 sfr = "WDTCTL.WDTIS1", "Memory", 0x0120, 2, base=16, bitRange=1 sfr = "WDTCTL.WDTSSEL", "Memory", 0x0120, 2, base=16, bitRange=2 sfr = "WDTCTL.WDTCNTCL", "Memory", 0x0120, 2, base=16, bitRange=3 sfr = "WDTCTL.WDTTMSEL", "Memory", 0x0120, 2, base=16, bitRange=4 sfr = "WDTCTL.WDTNMI", "Memory", 0x0120, 2, base=16, bitRange=5 sfr = "WDTCTL.WDTNMIES", "Memory", 0x0120, 2, base=16, bitRange=6 sfr = "WDTCTL.WDTHOLD", "Memory", 0x0120, 2, base=16, bitRange=7 ;; Hardware Multiplier sfr = "MPY", "Memory", 0x0130, 2, base=16 sfr = "MPYS", "Memory", 0x0132, 2, base=16 sfr = "MAC", "Memory", 0x0134, 2, base=16 sfr = "MACS", "Memory", 0x0136, 2, base=16 sfr = "OP2", "Memory", 0x0138, 2, base=16 sfr = "RESLO", "Memory", 0x013A, 2, base=16 sfr = "RESHI", "Memory", 0x013C, 2, base=16


sfr = "SUMEXT", "Memory", 0x013E, 2, base=16 ;; Digital I/O Port1/2 sfr = "P1IN", "Memory", 0x0020, 1, base=16 sfr = "P1IN.P1IN_0", "Memory", 0x0020, 1, base=16, bitRange=0 sfr = "P1IN.P1IN_1", "Memory", 0x0020, 1, base=16, bitRange=1 sfr = "P1IN.P1IN_2", "Memory", 0x0020, 1, base=16, bitRange=2 sfr = "P1IN.P1IN_3", "Memory", 0x0020, 1, base=16, bitRange=3 sfr = "P1IN.P1IN_4", "Memory", 0x0020, 1, base=16, bitRange=4 sfr = "P1IN.P1IN_5", "Memory", 0x0020, 1, base=16, bitRange=5 sfr = "P1IN.P1IN_6", "Memory", 0x0020, 1, base=16, bitRange=6 sfr = "P1IN.P1IN_7", "Memory", 0x0020, 1, base=16, bitRange=7 sfr = "P1OUT", "Memory", 0x0021, 1, base=16 sfr = "P1OUT.P1OUT_0", "Memory", 0x0021, 1, base=16, bitRange=0 sfr = "P1OUT.P1OUT_1", "Memory", 0x0021, 1, base=16, bitRange=1 sfr = "P1OUT.P1OUT_2", "Memory", 0x0021, 1, base=16, bitRange=2 sfr = "P1OUT.P1OUT_3", "Memory", 0x0021, 1, base=16, bitRange=3 sfr = "P1OUT.P1OUT_4", "Memory", 0x0021, 1, base=16, bitRange=4 sfr = "P1OUT.P1OUT_5", "Memory", 0x0021, 1, base=16, bitRange=5 sfr = "P1OUT.P1OUT_6", "Memory", 0x0021, 1, base=16, bitRange=6 sfr = "P1OUT.P1OUT_7", "Memory", 0x0021, 1, base=16, bitRange=7 sfr = "P1DIR", "Memory", 0x0022, 1, base=16 sfr = "P1DIR.P1DIR_0", "Memory", 0x0022, 1, base=16, bitRange=0 sfr = "P1DIR.P1DIR_1", "Memory", 0x0022, 1, base=16, bitRange=1 sfr = "P1DIR.P1DIR_2", "Memory", 0x0022, 1, base=16, bitRange=2 sfr = "P1DIR.P1DIR_3", "Memory", 0x0022, 1, base=16, bitRange=3 sfr = "P1DIR.P1DIR_4", "Memory", 0x0022, 1, base=16, bitRange=4 sfr = "P1DIR.P1DIR_5", "Memory", 0x0022, 1, base=16, bitRange=5 sfr = "P1DIR.P1DIR_6", "Memory", 0x0022, 1, base=16, bitRange=6 sfr = "P1DIR.P1DIR_7", "Memory", 0x0022, 1, base=16, bitRange=7 sfr = "P1IFG", "Memory", 0x0023, 1, base=16 sfr = "P1IFG.P1IFG_0", "Memory", 0x0023, 1, base=16, bitRange=0 sfr = "P1IFG.P1IFG_1", "Memory", 0x0023, 1, base=16, bitRange=1 sfr = "P1IFG.P1IFG_2", "Memory", 0x0023, 1, base=16, bitRange=2 sfr = "P1IFG.P1IFG_3", "Memory", 0x0023, 1, base=16, bitRange=3 sfr = "P1IFG.P1IFG_4", "Memory", 0x0023, 1, base=16, bitRange=4 sfr = "P1IFG.P1IFG_5", "Memory", 0x0023, 1, base=16, bitRange=5 sfr = "P1IFG.P1IFG_6", "Memory", 0x0023, 1, base=16, bitRange=6 sfr = "P1IFG.P1IFG_7", "Memory", 0x0023, 1, base=16, bitRange=7 sfr = "P1IES", "Memory", 0x0024, 1, base=16 sfr = "P1IES.P1IES_0", "Memory", 0x0024, 1, base=16, bitRange=0 sfr = "P1IES.P1IES_1", "Memory", 0x0024, 1, base=16, bitRange=1 sfr = "P1IES.P1IES_2", "Memory", 0x0024, 1, base=16, bitRange=2 sfr = "P1IES.P1IES_3", "Memory", 0x0024, 1, base=16, bitRange=3 sfr = "P1IES.P1IES_4", "Memory", 0x0024, 1, base=16, bitRange=4 sfr = "P1IES.P1IES_5", "Memory", 0x0024, 1, base=16, bitRange=5 sfr = "P1IES.P1IES_6", "Memory", 0x0024, 1, base=16, bitRange=6 sfr = "P1IES.P1IES_7", "Memory", 0x0024, 1, base=16, bitRange=7 sfr = "P1IE", "Memory", 0x0025, 1, base=16 sfr = "P1IE.P1IE_0", "Memory", 0x0025, 1, base=16, bitRange=0 sfr = "P1IE.P1IE_1", "Memory", 0x0025, 1, base=16, bitRange=1 sfr = "P1IE.P1IE_2", "Memory", 0x0025, 1, base=16, bitRange=2 sfr = "P1IE.P1IE_3", "Memory", 0x0025, 1, base=16, bitRange=3 sfr = "P1IE.P1IE_4", "Memory", 0x0025, 1, base=16, bitRange=4 sfr = "P1IE.P1IE_5", "Memory", 0x0025, 1, base=16, bitRange=5 sfr = "P1IE.P1IE_6", "Memory", 0x0025, 1, base=16, bitRange=6 sfr = "P1IE.P1IE_7", "Memory", 0x0025, 1, base=16, bitRange=7


sfr = "P1SEL", "Memory", 0x0026, 1, base=16 sfr = "P1SEL.P1SEL_0", "Memory", 0x0026, 1, base=16, bitRange=0 sfr = "P1SEL.P1SEL_1", "Memory", 0x0026, 1, base=16, bitRange=1 sfr = "P1SEL.P1SEL_2", "Memory", 0x0026, 1, base=16, bitRange=2 sfr = "P1SEL.P1SEL_3", "Memory", 0x0026, 1, base=16, bitRange=3 sfr = "P1SEL.P1SEL_4", "Memory", 0x0026, 1, base=16, bitRange=4 sfr = "P1SEL.P1SEL_5", "Memory", 0x0026, 1, base=16, bitRange=5 sfr = "P1SEL.P1SEL_6", "Memory", 0x0026, 1, base=16, bitRange=6 sfr = "P1SEL.P1SEL_7", "Memory", 0x0026, 1, base=16, bitRange=7 sfr = "P2IN", "Memory", 0x0028, 1, base=16 sfr = "P2IN.P2IN_0", "Memory", 0x0028, 1, base=16, bitRange=0 sfr = "P2IN.P2IN_1", "Memory", 0x0028, 1, base=16, bitRange=1 sfr = "P2IN.P2IN_2", "Memory", 0x0028, 1, base=16, bitRange=2 sfr = "P2IN.P2IN_3", "Memory", 0x0028, 1, base=16, bitRange=3 sfr = "P2IN.P2IN_4", "Memory", 0x0028, 1, base=16, bitRange=4 sfr = "P2IN.P2IN_5", "Memory", 0x0028, 1, base=16, bitRange=5 sfr = "P2IN.P2IN_6", "Memory", 0x0028, 1, base=16, bitRange=6 sfr = "P2IN.P2IN_7", "Memory", 0x0028, 1, base=16, bitRange=7 sfr = "P2OUT", "Memory", 0x0029, 1, base=16 sfr = "P2OUT.P2OUT_0", "Memory", 0x0029, 1, base=16, bitRange=0 sfr = "P2OUT.P2OUT_1", "Memory", 0x0029, 1, base=16, bitRange=1 sfr = "P2OUT.P2OUT_2", "Memory", 0x0029, 1, base=16, bitRange=2 sfr = "P2OUT.P2OUT_3", "Memory", 0x0029, 1, base=16, bitRange=3 sfr = "P2OUT.P2OUT_4", "Memory", 0x0029, 1, base=16, bitRange=4 sfr = "P2OUT.P2OUT_5", "Memory", 0x0029, 1, base=16, bitRange=5 sfr = "P2OUT.P2OUT_6", "Memory", 0x0029, 1, base=16, bitRange=6 sfr = "P2OUT.P2OUT_7", "Memory", 0x0029, 1, base=16, bitRange=7 sfr = "P2DIR", "Memory", 0x002A, 1, base=16 sfr = "P2DIR.P2DIR_0", "Memory", 0x002A, 1, base=16, bitRange=0 sfr = "P2DIR.P2DIR_1", "Memory", 0x002A, 1, base=16, bitRange=1 sfr = "P2DIR.P2DIR_2", "Memory", 0x002A, 1, base=16, bitRange=2 sfr = "P2DIR.P2DIR_3", "Memory", 0x002A, 1, base=16, bitRange=3 sfr = "P2DIR.P2DIR_4", "Memory", 0x002A, 1, base=16, bitRange=4 sfr = "P2DIR.P2DIR_5", "Memory", 0x002A, 1, base=16, bitRange=5 sfr = "P2DIR.P2DIR_6", "Memory", 0x002A, 1, base=16, bitRange=6 sfr = "P2DIR.P2DIR_7", "Memory", 0x002A, 1, base=16, bitRange=7 sfr = "P2IFG", "Memory", 0x002B, 1, base=16 sfr = "P2IFG.P2IFG_0", "Memory", 0x002B, 1, base=16, bitRange=0 sfr = "P2IFG.P2IFG_1", "Memory", 0x002B, 1, base=16, bitRange=1 sfr = "P2IFG.P2IFG_2", "Memory", 0x002B, 1, base=16, bitRange=2 sfr = "P2IFG.P2IFG_3", "Memory", 0x002B, 1, base=16, bitRange=3 sfr = "P2IFG.P2IFG_4", "Memory", 0x002B, 1, base=16, bitRange=4 sfr = "P2IFG.P2IFG_5", "Memory", 0x002B, 1, base=16, bitRange=5 sfr = "P2IFG.P2IFG_6", "Memory", 0x002B, 1, base=16, bitRange=6 sfr = "P2IFG.P2IFG_7", "Memory", 0x002B, 1, base=16, bitRange=7 sfr = "P2IES", "Memory", 0x002C, 1, base=16 sfr = "P2IES.P2IES_0", "Memory", 0x002C, 1, base=16, bitRange=0 sfr = "P2IES.P2IES_1", "Memory", 0x002C, 1, base=16, bitRange=1 sfr = "P2IES.P2IES_2", "Memory", 0x002C, 1, base=16, bitRange=2 sfr = "P2IES.P2IES_3", "Memory", 0x002C, 1, base=16, bitRange=3 sfr = "P2IES.P2IES_4", "Memory", 0x002C, 1, base=16, bitRange=4 sfr = "P2IES.P2IES_5", "Memory", 0x002C, 1, base=16, bitRange=5 sfr = "P2IES.P2IES_6", "Memory", 0x002C, 1, base=16, bitRange=6 sfr = "P2IES.P2IES_7", "Memory", 0x002C, 1, base=16, bitRange=7 sfr = "P2IE", "Memory", 0x002D, 1, base=16 sfr = "P2IE.P2IE_0", "Memory", 0x002D, 1, base=16, bitRange=0 sfr = "P2IE.P2IE_1", "Memory", 0x002D, 1, base=16, bitRange=1


sfr = "P2IE.P2IE_2", "Memory", 0x002D, 1, base=16, bitRange=2 sfr = "P2IE.P2IE_3", "Memory", 0x002D, 1, base=16, bitRange=3 sfr = "P2IE.P2IE_4", "Memory", 0x002D, 1, base=16, bitRange=4 sfr = "P2IE.P2IE_5", "Memory", 0x002D, 1, base=16, bitRange=5 sfr = "P2IE.P2IE_6", "Memory", 0x002D, 1, base=16, bitRange=6 sfr = "P2IE.P2IE_7", "Memory", 0x002D, 1, base=16, bitRange=7 sfr = "P2SEL", "Memory", 0x002E, 1, base=16 sfr = "P2SEL.P2SEL_0", "Memory", 0x002E, 1, base=16, bitRange=0 sfr = "P2SEL.P2SEL_1", "Memory", 0x002E, 1, base=16, bitRange=1 sfr = "P2SEL.P2SEL_2", "Memory", 0x002E, 1, base=16, bitRange=2 sfr = "P2SEL.P2SEL_3", "Memory", 0x002E, 1, base=16, bitRange=3 sfr = "P2SEL.P2SEL_4", "Memory", 0x002E, 1, base=16, bitRange=4 sfr = "P2SEL.P2SEL_5", "Memory", 0x002E, 1, base=16, bitRange=5 sfr = "P2SEL.P2SEL_6", "Memory", 0x002E, 1, base=16, bitRange=6 sfr = "P2SEL.P2SEL_7", "Memory", 0x002E, 1, base=16, bitRange=7 ;; Digital I/O Port3/4 sfr = "P3IN", "Memory", 0x0018, 1, base=16 sfr = "P3IN.P3IN_0", "Memory", 0x0018, 1, base=16, bitRange=0 sfr = "P3IN.P3IN_1", "Memory", 0x0018, 1, base=16, bitRange=1 sfr = "P3IN.P3IN_2", "Memory", 0x0018, 1, base=16, bitRange=2 sfr = "P3IN.P3IN_3", "Memory", 0x0018, 1, base=16, bitRange=3 sfr = "P3IN.P3IN_4", "Memory", 0x0018, 1, base=16, bitRange=4 sfr = "P3IN.P3IN_5", "Memory", 0x0018, 1, base=16, bitRange=5 sfr = "P3IN.P3IN_6", "Memory", 0x0018, 1, base=16, bitRange=6 sfr = "P3IN.P3IN_7", "Memory", 0x0018, 1, base=16, bitRange=7 sfr = "P3OUT", "Memory", 0x0019, 1, base=16 sfr = "P3OUT.P3OUT_0", "Memory", 0x0019, 1, base=16, bitRange=0 sfr = "P3OUT.P3OUT_1", "Memory", 0x0019, 1, base=16, bitRange=1 sfr = "P3OUT.P3OUT_2", "Memory", 0x0019, 1, base=16, bitRange=2 sfr = "P3OUT.P3OUT_3", "Memory", 0x0019, 1, base=16, bitRange=3 sfr = "P3OUT.P3OUT_4", "Memory", 0x0019, 1, base=16, bitRange=4 sfr = "P3OUT.P3OUT_5", "Memory", 0x0019, 1, base=16, bitRange=5 sfr = "P3OUT.P3OUT_6", "Memory", 0x0019, 1, base=16, bitRange=6 sfr = "P3OUT.P3OUT_7", "Memory", 0x0019, 1, base=16, bitRange=7 sfr = "P3DIR", "Memory", 0x001A, 1, base=16 sfr = "P3DIR.P3DIR_0", "Memory", 0x001A, 1, base=16, bitRange=0 sfr = "P3DIR.P3DIR_1", "Memory", 0x001A, 1, base=16, bitRange=1 sfr = "P3DIR.P3DIR_2", "Memory", 0x001A, 1, base=16, bitRange=2 sfr = "P3DIR.P3DIR_3", "Memory", 0x001A, 1, base=16, bitRange=3 sfr = "P3DIR.P3DIR_4", "Memory", 0x001A, 1, base=16, bitRange=4 sfr = "P3DIR.P3DIR_5", "Memory", 0x001A, 1, base=16, bitRange=5 sfr = "P3DIR.P3DIR_6", "Memory", 0x001A, 1, base=16, bitRange=6 sfr = "P3DIR.P3DIR_7", "Memory", 0x001A, 1, base=16, bitRange=7 sfr = "P3SEL", "Memory", 0x001B, 1, base=16 sfr = "P3SEL.P3SEL_0", "Memory", 0x001B, 1, base=16, bitRange=0 sfr = "P3SEL.P3SEL_1", "Memory", 0x001B, 1, base=16, bitRange=1 sfr = "P3SEL.P3SEL_2", "Memory", 0x001B, 1, base=16, bitRange=2 sfr = "P3SEL.P3SEL_3", "Memory", 0x001B, 1, base=16, bitRange=3 sfr = "P3SEL.P3SEL_4", "Memory", 0x001B, 1, base=16, bitRange=4 sfr = "P3SEL.P3SEL_5", "Memory", 0x001B, 1, base=16, bitRange=5 sfr = "P3SEL.P3SEL_6", "Memory", 0x001B, 1, base=16, bitRange=6 sfr = "P3SEL.P3SEL_7", "Memory", 0x001B, 1, base=16, bitRange=7 sfr = "P4IN", "Memory", 0x001C, 1, base=16 sfr = "P4IN.P4IN_0", "Memory", 0x001C, 1, base=16, bitRange=0 sfr = "P4IN.P4IN_1", "Memory", 0x001C, 1, base=16, bitRange=1 sfr = "P4IN.P4IN_2", "Memory", 0x001C, 1, base=16, bitRange=2 sfr = "P4IN.P4IN_3", "Memory", 0x001C, 1, base=16, bitRange=3


sfr = "P4IN.P4IN_4", "Memory", 0x001C, 1, base=16, bitRange=4 sfr = "P4IN.P4IN_5", "Memory", 0x001C, 1, base=16, bitRange=5 sfr = "P4IN.P4IN_6", "Memory", 0x001C, 1, base=16, bitRange=6 sfr = "P4IN.P4IN_7", "Memory", 0x001C, 1, base=16, bitRange=7 sfr = "P4OUT", "Memory", 0x001D, 1, base=16 sfr = "P4OUT.P4OUT_0", "Memory", 0x001D, 1, base=16, bitRange=0 sfr = "P4OUT.P4OUT_1", "Memory", 0x001D, 1, base=16, bitRange=1 sfr = "P4OUT.P4OUT_2", "Memory", 0x001D, 1, base=16, bitRange=2 sfr = "P4OUT.P4OUT_3", "Memory", 0x001D, 1, base=16, bitRange=3 sfr = "P4OUT.P4OUT_4", "Memory", 0x001D, 1, base=16, bitRange=4 sfr = "P4OUT.P4OUT_5", "Memory", 0x001D, 1, base=16, bitRange=5 sfr = "P4OUT.P4OUT_6", "Memory", 0x001D, 1, base=16, bitRange=6 sfr = "P4OUT.P4OUT_7", "Memory", 0x001D, 1, base=16, bitRange=7 sfr = "P4DIR", "Memory", 0x001E, 1, base=16 sfr = "P4DIR.P4DIR_0", "Memory", 0x001E, 1, base=16, bitRange=0 sfr = "P4DIR.P4DIR_1", "Memory", 0x001E, 1, base=16, bitRange=1 sfr = "P4DIR.P4DIR_2", "Memory", 0x001E, 1, base=16, bitRange=2 sfr = "P4DIR.P4DIR_3", "Memory", 0x001E, 1, base=16, bitRange=3 sfr = "P4DIR.P4DIR_4", "Memory", 0x001E, 1, base=16, bitRange=4 sfr = "P4DIR.P4DIR_5", "Memory", 0x001E, 1, base=16, bitRange=5 sfr = "P4DIR.P4DIR_6", "Memory", 0x001E, 1, base=16, bitRange=6 sfr = "P4DIR.P4DIR_7", "Memory", 0x001E, 1, base=16, bitRange=7 sfr = "P4SEL", "Memory", 0x001F, 1, base=16 sfr = "P4SEL.P4SEL_0", "Memory", 0x001F, 1, base=16, bitRange=0 sfr = "P4SEL.P4SEL_1", "Memory", 0x001F, 1, base=16, bitRange=1 sfr = "P4SEL.P4SEL_2", "Memory", 0x001F, 1, base=16, bitRange=2 sfr = "P4SEL.P4SEL_3", "Memory", 0x001F, 1, base=16, bitRange=3 sfr = "P4SEL.P4SEL_4", "Memory", 0x001F, 1, base=16, bitRange=4 sfr = "P4SEL.P4SEL_5", "Memory", 0x001F, 1, base=16, bitRange=5 sfr = "P4SEL.P4SEL_6", "Memory", 0x001F, 1, base=16, bitRange=6 sfr = "P4SEL.P4SEL_7", "Memory", 0x001F, 1, base=16, bitRange=7 ;; Digital I/O Port5/6 sfr = "P5IN", "Memory", 0x0030, 1, base=16 sfr = "P5IN.P5IN_0", "Memory", 0x0030, 1, base=16, bitRange=0 sfr = "P5IN.P5IN_1", "Memory", 0x0030, 1, base=16, bitRange=1 sfr = "P5IN.P5IN_2", "Memory", 0x0030, 1, base=16, bitRange=2 sfr = "P5IN.P5IN_3", "Memory", 0x0030, 1, base=16, bitRange=3 sfr = "P5IN.P5IN_4", "Memory", 0x0030, 1, base=16, bitRange=4 sfr = "P5IN.P5IN_5", "Memory", 0x0030, 1, base=16, bitRange=5 sfr = "P5IN.P5IN_6", "Memory", 0x0030, 1, base=16, bitRange=6 sfr = "P5IN.P5IN_7", "Memory", 0x0030, 1, base=16, bitRange=7 sfr = "P5OUT", "Memory", 0x0031, 1, base=16 sfr = "P5OUT.P5OUT_0", "Memory", 0x0031, 1, base=16, bitRange=0 sfr = "P5OUT.P5OUT_1", "Memory", 0x0031, 1, base=16, bitRange=1 sfr = "P5OUT.P5OUT_2", "Memory", 0x0031, 1, base=16, bitRange=2 sfr = "P5OUT.P5OUT_3", "Memory", 0x0031, 1, base=16, bitRange=3 sfr = "P5OUT.P5OUT_4", "Memory", 0x0031, 1, base=16, bitRange=4 sfr = "P5OUT.P5OUT_5", "Memory", 0x0031, 1, base=16, bitRange=5 sfr = "P5OUT.P5OUT_6", "Memory", 0x0031, 1, base=16, bitRange=6 sfr = "P5OUT.P5OUT_7", "Memory", 0x0031, 1, base=16, bitRange=7 sfr = "P5DIR", "Memory", 0x0032, 1, base=16 sfr = "P5DIR.P5DIR_0", "Memory", 0x0032, 1, base=16, bitRange=0 sfr = "P5DIR.P5DIR_1", "Memory", 0x0032, 1, base=16, bitRange=1 sfr = "P5DIR.P5DIR_2", "Memory", 0x0032, 1, base=16, bitRange=2 sfr = "P5DIR.P5DIR_3", "Memory", 0x0032, 1, base=16, bitRange=3 sfr = "P5DIR.P5DIR_4", "Memory", 0x0032, 1, base=16, bitRange=4 sfr = "P5DIR.P5DIR_5", "Memory", 0x0032, 1, base=16, bitRange=5


sfr = "P5DIR.P5DIR_6", "Memory", 0x0032, 1, base=16, bitRange=6 sfr = "P5DIR.P5DIR_7", "Memory", 0x0032, 1, base=16, bitRange=7 sfr = "P5SEL", "Memory", 0x0033, 1, base=16 sfr = "P5SEL.P5SEL_0", "Memory", 0x0033, 1, base=16, bitRange=0 sfr = "P5SEL.P5SEL_1", "Memory", 0x0033, 1, base=16, bitRange=1 sfr = "P5SEL.P5SEL_2", "Memory", 0x0033, 1, base=16, bitRange=2 sfr = "P5SEL.P5SEL_3", "Memory", 0x0033, 1, base=16, bitRange=3 sfr = "P5SEL.P5SEL_4", "Memory", 0x0033, 1, base=16, bitRange=4 sfr = "P5SEL.P5SEL_5", "Memory", 0x0033, 1, base=16, bitRange=5 sfr = "P5SEL.P5SEL_6", "Memory", 0x0033, 1, base=16, bitRange=6 sfr = "P5SEL.P5SEL_7", "Memory", 0x0033, 1, base=16, bitRange=7 sfr = "P6IN", "Memory", 0x0034, 1, base=16 sfr = "P6IN.P6IN_0", "Memory", 0x0034, 1, base=16, bitRange=0 sfr = "P6IN.P6IN_1", "Memory", 0x0034, 1, base=16, bitRange=1 sfr = "P6IN.P6IN_2", "Memory", 0x0034, 1, base=16, bitRange=2 sfr = "P6IN.P6IN_3", "Memory", 0x0034, 1, base=16, bitRange=3 sfr = "P6IN.P6IN_4", "Memory", 0x0034, 1, base=16, bitRange=4 sfr = "P6IN.P6IN_5", "Memory", 0x0034, 1, base=16, bitRange=5 sfr = "P6IN.P6IN_6", "Memory", 0x0034, 1, base=16, bitRange=6 sfr = "P6IN.P6IN_7", "Memory", 0x0034, 1, base=16, bitRange=7 sfr = "P6OUT", "Memory", 0x0035, 1, base=16 sfr = "P6OUT.P6OUT_0", "Memory", 0x0035, 1, base=16, bitRange=0 sfr = "P6OUT.P6OUT_1", "Memory", 0x0035, 1, base=16, bitRange=1 sfr = "P6OUT.P6OUT_2", "Memory", 0x0035, 1, base=16, bitRange=2 sfr = "P6OUT.P6OUT_3", "Memory", 0x0035, 1, base=16, bitRange=3 sfr = "P6OUT.P6OUT_4", "Memory", 0x0035, 1, base=16, bitRange=4 sfr = "P6OUT.P6OUT_5", "Memory", 0x0035, 1, base=16, bitRange=5 sfr = "P6OUT.P6OUT_6", "Memory", 0x0035, 1, base=16, bitRange=6 sfr = "P6OUT.P6OUT_7", "Memory", 0x0035, 1, base=16, bitRange=7 sfr = "P6DIR", "Memory", 0x0036, 1, base=16 sfr = "P6DIR.P6DIR_0", "Memory", 0x0036, 1, base=16, bitRange=0 sfr = "P6DIR.P6DIR_1", "Memory", 0x0036, 1, base=16, bitRange=1 sfr = "P6DIR.P6DIR_2", "Memory", 0x0036, 1, base=16, bitRange=2 sfr = "P6DIR.P6DIR_3", "Memory", 0x0036, 1, base=16, bitRange=3 sfr = "P6DIR.P6DIR_4", "Memory", 0x0036, 1, base=16, bitRange=4 sfr = "P6DIR.P6DIR_5", "Memory", 0x0036, 1, base=16, bitRange=5 sfr = "P6DIR.P6DIR_6", "Memory", 0x0036, 1, base=16, bitRange=6 sfr = "P6DIR.P6DIR_7", "Memory", 0x0036, 1, base=16, bitRange=7 sfr = "P6SEL", "Memory", 0x0037, 1, base=16 sfr = "P6SEL.P6SEL_0", "Memory", 0x0037, 1, base=16, bitRange=0 sfr = "P6SEL.P6SEL_1", "Memory", 0x0037, 1, base=16, bitRange=1 sfr = "P6SEL.P6SEL_2", "Memory", 0x0037, 1, base=16, bitRange=2 sfr = "P6SEL.P6SEL_3", "Memory", 0x0037, 1, base=16, bitRange=3 sfr = "P6SEL.P6SEL_4", "Memory", 0x0037, 1, base=16, bitRange=4 sfr = "P6SEL.P6SEL_5", "Memory", 0x0037, 1, base=16, bitRange=5 sfr = "P6SEL.P6SEL_6", "Memory", 0x0037, 1, base=16, bitRange=6 sfr = "P6SEL.P6SEL_7", "Memory", 0x0037, 1, base=16, bitRange=7 ;; Basic Timer sfr = "BTCTL", "Memory", 0x0040, 1, base=16 sfr = "BTCTL.BTIP", "Memory", 0x0040, 1, base=16, bitRange=0-2 sfr = "BTCTL.BTFRFQ", "Memory", 0x0040, 1, base=16, bitRange=3-4 sfr = "BTCTL.BTDIV", "Memory", 0x0040, 1, base=16, bitRange=5 sfr = "BTCTL.BTHOLD", "Memory", 0x0040, 1, base=16, bitRange=6 sfr = "BTCTL.BTSSEL", "Memory", 0x0040, 1, base=16, bitRange=7 sfr = "BTCNT1", "Memory", 0x0046, 1, base=16 sfr = "BTCNT2", "Memory", 0x0047, 1, base=16


;; System Clock, FFL+ sfr = "SCFI0", "Memory", 0x0050, 1, base=16 sfr = "SCFI0.FN_2", "Memory", 0x0050, 1, base=16, bitRange=2 sfr = "SCFI0.FN_3", "Memory", 0x0050, 1, base=16, bitRange=3 sfr = "SCFI0.FN_4", "Memory", 0x0050, 1, base=16, bitRange=4 sfr = "SCFI0.FN_8", "Memory", 0x0050, 1, base=16, bitRange=5 sfr = "SCFI0.FLLD", "Memory", 0x0050, 1, base=16, bitRange=6-7 sfr = "SCFI1", "Memory", 0x0051, 1, base=16 sfr = "SCFQCTL", "Memory", 0x0052, 1, base=16 sfr = "FLL_CTL0", "Memory", 0x0053, 1, base=16 sfr = "FLL_CTL0.DCOF", "Memory", 0x0053, 1, base=16, bitRange=0 sfr = "FLL_CTL0.LFOF", "Memory", 0x0053, 1, base=16, bitRange=1 sfr = "FLL_CTL0.XT1OF", "Memory", 0x0053, 1, base=16, bitRange=2 sfr = "FLL_CTL0.XT2OF", "Memory", 0x0053, 1, base=16, bitRange=3 sfr = "FLL_CTL0.XCAP", "Memory", 0x0053, 1, base=16, bitRange=4-5 sfr = "FLL_CTL0.XTS_FLL", "Memory", 0x0053, 1, base=16, bitRange=6 sfr = "FLL_CTL0.DCOPLUS", "Memory", 0x0053, 1, base=16, bitRange=7 sfr = "FLL_CTL1", "Memory", 0x0054, 1, base=16 sfr = "FLL_CTL1.FFL_DIV", "Memory", 0x0054, 1, base=16, bitRange=0-1 sfr = "FLL_CTL1.SELS", "Memory", 0x0054, 1, base=16, bitRange=2 sfr = "FLL_CTL1.SELM", "Memory", 0x0054, 1, base=16, bitRange=3-4 sfr = "FLL_CTL1.XT2OFF", "Memory", 0x0054, 1, base=16, bitRange=5 sfr = "FLL_CTL1.SMCLKOFF", "Memory", 0x0054, 1, base=16, bitRange=6 ;; Brown-Out, Supply Voltage Supervision (SVS) sfr = "SVSCTL", "Memory", 0x0056, 1, base=16 sfr = "SVSCTL.SVSFG", "Memory", 0x0056, 1, base=16, bitRange=0 sfr = "SVSCTL.SVSOP", "Memory", 0x0056, 1, base=16, bitRange=1 sfr = "SVSCTL.SVSON", "Memory", 0x0056, 1, base=16, bitRange=2 sfr = "SVSCTL.PORON", "Memory", 0x0056, 1, base=16, bitRange=3 sfr = "SVSCTL.VLD", "Memory", 0x0056, 1, base=16, bitRange=4-7 ;; LCD Register sfr = "LCDCTL", "Memory", 0x0090, 1, base=16 sfr = "LCDCTL.LCDON", "Memory", 0x0090, 1, base=16, bitRange=0 sfr = "LCDCTL.LCDSON", "Memory", 0x0090, 1, base=16, bitRange=2 sfr = "LCDCTL.LCDMX0", "Memory", 0x0090, 1, base=16, bitRange=3 sfr = "LCDCTL.LCDMX1", "Memory", 0x0090, 1, base=16, bitRange=4 sfr = "LCDCTL.LCDP0", "Memory", 0x0090, 1, base=16, bitRange=5 sfr = "LCDCTL.LCDP1", "Memory", 0x0090, 1, base=16, bitRange=6 sfr = "LCDCTL.LCDP2", "Memory", 0x0090, 1, base=16, bitRange=7 sfr = "LCDM1", "Memory", 0x0091, 1, base=16 sfr = "LCDM2", "Memory", 0x0092, 1, base=16 sfr = "LCDM3", "Memory", 0x0093, 1, base=16 sfr = "LCDM4", "Memory", 0x0094, 1, base=16 sfr = "LCDM5", "Memory", 0x0095, 1, base=16 sfr = "LCDM6", "Memory", 0x0096, 1, base=16 sfr = "LCDM7", "Memory", 0x0097, 1, base=16 sfr = "LCDM8", "Memory", 0x0098, 1, base=16 sfr = "LCDM9", "Memory", 0x0099, 1, base=16 sfr = "LCDM10", "Memory", 0x009A, 1, base=16 sfr = "LCDM11", "Memory", 0x009B, 1, base=16 sfr = "LCDM12", "Memory", 0x009C, 1, base=16 sfr = "LCDM13", "Memory", 0x009D, 1, base=16 sfr = "LCDM14", "Memory", 0x009E, 1, base=16 sfr = "LCDM15", "Memory", 0x009F, 1, base=16 sfr = "LCDM16", "Memory", 0x00A0, 1, base=16 sfr = "LCDM17", "Memory", 0x00A1, 1, base=16


sfr = "LCDM18", "Memory", 0x00A2, 1, base=16 sfr = "LCDM19", "Memory", 0x00A3, 1, base=16 sfr = "LCDM20", "Memory", 0x00A4, 1, base=16 ;; USART 0 sfr = "U0CTL", "Memory", 0x0070, 1, base=16 sfr = "U0CTL.SWRST", "Memory", 0x0070, 1, base=16, bitRange=0 sfr = "U0CTL.MM", "Memory", 0x0070, 1, base=16, bitRange=1 sfr = "U0CTL.SYNC", "Memory", 0x0070, 1, base=16, bitRange=2 sfr = "U0CTL.LISTEN", "Memory", 0x0070, 1, base=16, bitRange=3 sfr = "U0CTL.CHAR", "Memory", 0x0070, 1, base=16, bitRange=4 sfr = "U0CTL.SPB", "Memory", 0x0070, 1, base=16, bitRange=5 sfr = "U0CTL.PEV", "Memory", 0x0070, 1, base=16, bitRange=6 sfr = "U0CTL.PENA", "Memory", 0x0070, 1, base=16, bitRange=7 sfr = "U0TCTL", "Memory", 0x0071, 1, base=16 sfr = "U0TCTL.TXEPT", "Memory", 0x0071, 1, base=16, bitRange=0 sfr = "U0TCTL.STC", "Memory", 0x0071, 1, base=16, bitRange=1 sfr = "U0TCTL.TXWAKE", "Memory", 0x0071, 1, base=16, bitRange=2 sfr = "U0TCTL.URXSE", "Memory", 0x0071, 1, base=16, bitRange=3 sfr = "U0TCTL.SSEL0", "Memory", 0x0071, 1, base=16, bitRange=4 sfr = "U0TCTL.SSEL1", "Memory", 0x0071, 1, base=16, bitRange=5 sfr = "U0TCTL.CKPL", "Memory", 0x0071, 1, base=16, bitRange=6 sfr = "U0TCTL.CKPH", "Memory", 0x0071, 1, base=16, bitRange=7 sfr = "U0RCTL", "Memory", 0x0072, 1, base=16 sfr = "U0RCTL.RXERR", "Memory", 0x0072, 1, base=16, bitRange=0 sfr = "U0RCTL.RXWAKE", "Memory", 0x0072, 1, base=16, bitRange=1 sfr = "U0RCTL.URXWIE", "Memory", 0x0072, 1, base=16, bitRange=2 sfr = "U0RCTL.URXEIE", "Memory", 0x0072, 1, base=16, bitRange=3 sfr = "U0RCTL.BRK", "Memory", 0x0072, 1, base=16, bitRange=4 sfr = "U0RCTL.OE", "Memory", 0x0072, 1, base=16, bitRange=5 sfr = "U0RCTL.PE", "Memory", 0x0072, 1, base=16, bitRange=6 sfr = "U0RCTL.FE", "Memory", 0x0072, 1, base=16, bitRange=7 sfr = "U0MCTL", "Memory", 0x0073, 1, base=16 sfr = "U0BR0", "Memory", 0x0074, 1, base=16 sfr = "U0BR1", "Memory", 0x0075, 1, base=16 sfr = "U0RXBUF", "Memory", 0x0076, 1, base=16 sfr = "U0TXBUF", "Memory", 0x0077, 1, base=16 ;; USART 1 sfr = "U1CTL", "Memory", 0x0078, 1, base=16 sfr = "U1CTL.SWRST", "Memory", 0x0078, 1, base=16, bitRange=0 sfr = "U1CTL.MM", "Memory", 0x0078, 1, base=16, bitRange=1 sfr = "U1CTL.SYNC", "Memory", 0x0078, 1, base=16, bitRange=2 sfr = "U1CTL.LISTEN", "Memory", 0x0078, 1, base=16, bitRange=3 sfr = "U1CTL.CHAR", "Memory", 0x0078, 1, base=16, bitRange=4 sfr = "U1CTL.SPB", "Memory", 0x0078, 1, base=16, bitRange=5 sfr = "U1CTL.PEV", "Memory", 0x0078, 1, base=16, bitRange=6 sfr = "U1CTL.PENA", "Memory", 0x0078, 1, base=16, bitRange=7 sfr = "U1TCTL", "Memory", 0x0079, 1, base=16 sfr = "U1TCTL.TXEPT", "Memory", 0x0079, 1, base=16, bitRange=0 sfr = "U1TCTL.STC", "Memory", 0x0079, 1, base=16, bitRange=1 sfr = "U1TCTL.TXWAKE", "Memory", 0x0079, 1, base=16, bitRange=2 sfr = "U1TCTL.URXSE", "Memory", 0x0079, 1, base=16, bitRange=3 sfr = "U1TCTL.SSEL0", "Memory", 0x0079, 1, base=16, bitRange=4 sfr = "U1TCTL.SSEL1", "Memory", 0x0079, 1, base=16, bitRange=5 sfr = "U1TCTL.CKPL", "Memory", 0x0079, 1, base=16, bitRange=6 sfr = "U1TCTL.CKPH", "Memory", 0x0079, 1, base=16, bitRange=7 sfr = "U1RCTL", "Memory", 0x007A, 1, base=16


sfr = "U1RCTL.RXERR", "Memory", 0x007A, 1, base=16, bitRange=0 sfr = "U1RCTL.RXWAKE", "Memory", 0x007A, 1, base=16, bitRange=1 sfr = "U1RCTL.URXWIE", "Memory", 0x007A, 1, base=16, bitRange=2 sfr = "U1RCTL.URXEIE", "Memory", 0x007A, 1, base=16, bitRange=3 sfr = "U1RCTL.BRK", "Memory", 0x007A, 1, base=16, bitRange=4 sfr = "U1RCTL.OE", "Memory", 0x007A, 1, base=16, bitRange=5 sfr = "U1RCTL.PE", "Memory", 0x007A, 1, base=16, bitRange=6 sfr = "U1RCTL.FE", "Memory", 0x007A, 1, base=16, bitRange=7 sfr = "U1MCTL", "Memory", 0x007B, 1, base=16 sfr = "U1BR0", "Memory", 0x007C, 1, base=16 sfr = "U1BR1", "Memory", 0x007D, 1, base=16 sfr = "U1RXBUF", "Memory", 0x007E, 1, base=16 sfr = "U1TXBUF", "Memory", 0x007F, 1, base=16 ;; Timer A sfr = "TAIV", "Memory", 0x012E, 2, base=16 sfr = "TAIV.IRQVEC", "Memory", 0x012E, 2, base=16, bitRange=1-3 sfr = "TACTL", "Memory", 0x0160, 2, base=16 sfr = "TACTL.TAIFG", "Memory", 0x0160, 2, base=16, bitRange=0 sfr = "TACTL.TAIE", "Memory", 0x0160, 2, base=16, bitRange=1 sfr = "TACTL.TACLR", "Memory", 0x0160, 2, base=16, bitRange=2 sfr = "TACTL.TAMC", "Memory", 0x0160, 2, base=16, bitRange=4-5 sfr = "TACTL.TAID", "Memory", 0x0160, 2, base=16, bitRange=6-7 sfr = "TACTL.TASSEL", "Memory", 0x0160, 2, base=16, bitRange=8-9 sfr = "TACCTL0", "Memory", 0x0162, 2, base=16 sfr = "TACCTL0.CCIFG", "Memory", 0x0162, 2, base=16, bitRange=0 sfr = "TACCTL0.COV", "Memory", 0x0162, 2, base=16, bitRange=1 sfr = "TACCTL0.OUT", "Memory", 0x0162, 2, base=16, bitRange=2 sfr = "TACCTL0.CCI", "Memory", 0x0162, 2, base=16, bitRange=3 sfr = "TACCTL0.CCIE", "Memory", 0x0162, 2, base=16, bitRange=4 sfr = "TACCTL0.OUTMOD", "Memory", 0x0162, 2, base=16, bitRange=5-7 sfr = "TACCTL0.CAP", "Memory", 0x0162, 2, base=16, bitRange=8 sfr = "TACCTL0.SCCI", "Memory", 0x0162, 2, base=16, bitRange=10 sfr = "TACCTL0.SCS", "Memory", 0x0162, 2, base=16, bitRange=11 sfr = "TACCTL0.CCIS", "Memory", 0x0162, 2, base=16, bitRange=12-13 sfr = "TACCTL0.CM", "Memory", 0x0162, 2, base=16, bitRange=14-15 sfr = "TACCTL1", "Memory", 0x0164, 2, base=16 sfr = "TACCTL1.CCIFG", "Memory", 0x0164, 2, base=16, bitRange=0 sfr = "TACCTL1.COV", "Memory", 0x0164, 2, base=16, bitRange=1 sfr = "TACCTL1.OUT", "Memory", 0x0164, 2, base=16, bitRange=2 sfr = "TACCTL1.CCI", "Memory", 0x0164, 2, base=16, bitRange=3 sfr = "TACCTL1.CCIE", "Memory", 0x0164, 2, base=16, bitRange=4 sfr = "TACCTL1.OUTMOD", "Memory", 0x0164, 2, base=16, bitRange=5-7 sfr = "TACCTL1.CAP", "Memory", 0x0164, 2, base=16, bitRange=8 sfr = "TACCTL1.SCCI", "Memory", 0x0164, 2, base=16, bitRange=10 sfr = "TACCTL1.SCS", "Memory", 0x0164, 2, base=16, bitRange=11 sfr = "TACCTL1.CCIS", "Memory", 0x0164, 2, base=16, bitRange=12-13 sfr = "TACCTL1.CM", "Memory", 0x0164, 2, base=16, bitRange=14-15 sfr = "TACCTL2", "Memory", 0x0166, 2, base=16 sfr = "TACCTL2.CCIFG", "Memory", 0x0166, 2, base=16, bitRange=0 sfr = "TACCTL2.COV", "Memory", 0x0166, 2, base=16, bitRange=1 sfr = "TACCTL2.OUT", "Memory", 0x0166, 2, base=16, bitRange=2 sfr = "TACCTL2.CCI", "Memory", 0x0166, 2, base=16, bitRange=3 sfr = "TACCTL2.CCIE", "Memory", 0x0166, 2, base=16, bitRange=4 sfr = "TACCTL2.OUTMOD", "Memory", 0x0166, 2, base=16, bitRange=5-7 sfr = "TACCTL2.CAP", "Memory", 0x0166, 2, base=16, bitRange=8 sfr = "TACCTL2.SCCI", "Memory", 0x0166, 2, base=16, bitRange=10 sfr = "TACCTL2.SCS", "Memory", 0x0166, 2, base=16, bitRange=11


sfr = "TACCTL2.CCIS", "Memory", 0x0166, 2, base=16, bitRange=12-13 sfr = "TACCTL2.CM", "Memory", 0x0166, 2, base=16, bitRange=14-15 sfr = "TAR", "Memory", 0x0170, 2, base=16 sfr = "TACCR0", "Memory", 0x0172, 2, base=16 sfr = "TACCR1", "Memory", 0x0174, 2, base=16 sfr = "TACCR2", "Memory", 0x0176, 2, base=16 ;; Timer B sfr = "TBIV", "Memory", 0x011E, 2, base=16 sfr = "TBIV.IRQVEC", "Memory", 0x011E, 2, base=16, bitRange=1-3 sfr = "TBCTL", "Memory", 0x0180, 2, base=16 sfr = "TBCTL.TBIFG", "Memory", 0x0180, 2, base=16, bitRange=0 sfr = "TBCTL.TBIE", "Memory", 0x0180, 2, base=16, bitRange=1 sfr = "TBCTL.TBCLR", "Memory", 0x0180, 2, base=16, bitRange=2 sfr = "TBCTL.TBMC", "Memory", 0x0180, 2, base=16, bitRange=4-5 sfr = "TBCTL.TBID", "Memory", 0x0180, 2, base=16, bitRange=6-7 sfr = "TBCTL.TBSSEL", "Memory", 0x0180, 2, base=16, bitRange=8-9 sfr = "TBCTL.TBCNTL", "Memory", 0x0180, 2, base=16, bitRange=11-12 sfr = "TBCTL.TBCLGRP", "Memory", 0x0180, 2, base=16, bitRange=13-14 sfr = "TBCCTL0", "Memory", 0x0182, 2, base=16 sfr = "TBCCTL0.CCIFG", "Memory", 0x0182, 2, base=16, bitRange=0 sfr = "TBCCTL0.COV", "Memory", 0x0182, 2, base=16, bitRange=1 sfr = "TBCCTL0.OUT", "Memory", 0x0182, 2, base=16, bitRange=2 sfr = "TBCCTL0.CCI", "Memory", 0x0182, 2, base=16, bitRange=3 sfr = "TBCCTL0.CCIE", "Memory", 0x0182, 2, base=16, bitRange=4 sfr = "TBCCTL0.OUTMOD", "Memory", 0x0182, 2, base=16, bitRange=5-7 sfr = "TBCCTL0.CAP", "Memory", 0x0182, 2, base=16, bitRange=8 sfr = "TBCCTL0.CLLD", "Memory", 0x0182, 2, base=16, bitRange=9-10 sfr = "TBCCTL0.SCS", "Memory", 0x0182, 2, base=16, bitRange=11 sfr = "TBCCTL0.CCIS", "Memory", 0x0182, 2, base=16, bitRange=12-13 sfr = "TBCCTL0.CM", "Memory", 0x0182, 2, base=16, bitRange=14-15 sfr = "TBCCTL1", "Memory", 0x0184, 2, base=16 sfr = "TBCCTL1.CCIFG", "Memory", 0x0184, 2, base=16, bitRange=0 sfr = "TBCCTL1.COV", "Memory", 0x0184, 2, base=16, bitRange=1 sfr = "TBCCTL1.OUT", "Memory", 0x0184, 2, base=16, bitRange=2 sfr = "TBCCTL1.CCI", "Memory", 0x0184, 2, base=16, bitRange=3 sfr = "TBCCTL1.CCIE", "Memory", 0x0184, 2, base=16, bitRange=4 sfr = "TBCCTL1.OUTMOD", "Memory", 0x0184, 2, base=16, bitRange=5-7 sfr = "TBCCTL1.CAP", "Memory", 0x0184, 2, base=16, bitRange=8 sfr = "TBCCTL1.CLLD", "Memory", 0x0184, 2, base=16, bitRange=9-10 sfr = "TBCCTL1.SCS", "Memory", 0x0184, 2, base=16, bitRange=11 sfr = "TBCCTL1.CCIS", "Memory", 0x0184, 2, base=16, bitRange=12-13 sfr = "TBCCTL1.CM", "Memory", 0x0184, 2, base=16, bitRange=14-15 sfr = "TBCCTL2", "Memory", 0x0186, 2, base=16 sfr = "TBCCTL2.CCIFG", "Memory", 0x0186, 2, base=16, bitRange=0 sfr = "TBCCTL2.COV", "Memory", 0x0186, 2, base=16, bitRange=1 sfr = "TBCCTL2.OUT", "Memory", 0x0186, 2, base=16, bitRange=2 sfr = "TBCCTL2.CCI", "Memory", 0x0186, 2, base=16, bitRange=3 sfr = "TBCCTL2.CCIE", "Memory", 0x0186, 2, base=16, bitRange=4 sfr = "TBCCTL2.OUTMOD", "Memory", 0x0186, 2, base=16, bitRange=5-7 sfr = "TBCCTL2.CAP", "Memory", 0x0186, 2, base=16, bitRange=8 sfr = "TBCCTL2.CLLD", "Memory", 0x0186, 2, base=16, bitRange=9-10 sfr = "TBCCTL2.SCS", "Memory", 0x0186, 2, base=16, bitRange=11 sfr = "TBCCTL2.CCIS", "Memory", 0x0186, 2, base=16, bitRange=12-13 sfr = "TBCCTL2.CM", "Memory", 0x0186, 2, base=16, bitRange=14-15 sfr = "TBCCTL3", "Memory", 0x0188, 2, base=16 sfr = "TBCCTL3.CCIFG", "Memory", 0x0188, 2, base=16, bitRange=0


sfr = "TBCCTL3.COV", "Memory", 0x0188, 2, base=16, bitRange=1 sfr = "TBCCTL3.OUT", "Memory", 0x0188, 2, base=16, bitRange=2 sfr = "TBCCTL3.CCI", "Memory", 0x0188, 2, base=16, bitRange=3 sfr = "TBCCTL3.CCIE", "Memory", 0x0188, 2, base=16, bitRange=4 sfr = "TBCCTL3.OUTMOD", "Memory", 0x0188, 2, base=16, bitRange=5-7 sfr = "TBCCTL3.CAP", "Memory", 0x0188, 2, base=16, bitRange=8 sfr = "TBCCTL3.CLLD", "Memory", 0x0188, 2, base=16, bitRange=9-10 sfr = "TBCCTL3.SCS", "Memory", 0x0188, 2, base=16, bitRange=11 sfr = "TBCCTL3.CCIS", "Memory", 0x0188, 2, base=16, bitRange=12-13 sfr = "TBCCTL3.CM", "Memory", 0x0188, 2, base=16, bitRange=14-15 sfr = "TBCCTL4", "Memory", 0x018A, 2, base=16 sfr = "TBCCTL4.CCIFG", "Memory", 0x018A, 2, base=16, bitRange=0 sfr = "TBCCTL4.COV", "Memory", 0x018A, 2, base=16, bitRange=1 sfr = "TBCCTL4.OUT", "Memory", 0x018A, 2, base=16, bitRange=2 sfr = "TBCCTL4.CCI", "Memory", 0x018A, 2, base=16, bitRange=3 sfr = "TBCCTL4.CCIE", "Memory", 0x018A, 2, base=16, bitRange=4 sfr = "TBCCTL4.OUTMOD", "Memory", 0x018A, 2, base=16, bitRange=5-7 sfr = "TBCCTL4.CAP", "Memory", 0x018A, 2, base=16, bitRange=8 sfr = "TBCCTL4.CLLD", "Memory", 0x018A, 2, base=16, bitRange=9-10 sfr = "TBCCTL4.SCS", "Memory", 0x018A, 2, base=16, bitRange=11 sfr = "TBCCTL4.CCIS", "Memory", 0x018A, 2, base=16, bitRange=12-13 sfr = "TBCCTL4.CM", "Memory", 0x018A, 2, base=16, bitRange=14-15 sfr = "TBCCTL5", "Memory", 0x018C, 2, base=16 sfr = "TBCCTL5.CCIFG", "Memory", 0x018C, 2, base=16, bitRange=0 sfr = "TBCCTL5.COV", "Memory", 0x018C, 2, base=16, bitRange=1 sfr = "TBCCTL5.OUT", "Memory", 0x018C, 2, base=16, bitRange=2 sfr = "TBCCTL5.CCI", "Memory", 0x018C, 2, base=16, bitRange=3 sfr = "TBCCTL5.CCIE", "Memory", 0x018C, 2, base=16, bitRange=4 sfr = "TBCCTL5.OUTMOD", "Memory", 0x018C, 2, base=16, bitRange=5-7 sfr = "TBCCTL5.CAP", "Memory", 0x018C, 2, base=16, bitRange=8 sfr = "TBCCTL5.CLLD", "Memory", 0x018C, 2, base=16, bitRange=9-10 sfr = "TBCCTL5.SCS", "Memory", 0x018C, 2, base=16, bitRange=11 sfr = "TBCCTL5.CCIS", "Memory", 0x018C, 2, base=16, bitRange=12-13 sfr = "TBCCTL5.CM", "Memory", 0x018C, 2, base=16, bitRange=14-15 sfr = "TBCCTL6", "Memory", 0x018E, 2, base=16 sfr = "TBCCTL6.CCIFG", "Memory", 0x018E, 2, base=16, bitRange=0 sfr = "TBCCTL6.COV", "Memory", 0x018E, 2, base=16, bitRange=1 sfr = "TBCCTL6.OUT", "Memory", 0x018E, 2, base=16, bitRange=2 sfr = "TBCCTL6.CCI", "Memory", 0x018E, 2, base=16, bitRange=3 sfr = "TBCCTL6.CCIE", "Memory", 0x018E, 2, base=16, bitRange=4 sfr = "TBCCTL6.OUTMOD", "Memory", 0x018E, 2, base=16, bitRange=5-7 sfr = "TBCCTL6.CAP", "Memory", 0x018E, 2, base=16, bitRange=8 sfr = "TBCCTL6.CLLD", "Memory", 0x018E, 2, base=16, bitRange=9-10 sfr = "TBCCTL6.SCS", "Memory", 0x018E, 2, base=16, bitRange=11 sfr = "TBCCTL6.CCIS", "Memory", 0x018E, 2, base=16, bitRange=12-13 sfr = "TBCCTL6.CM", "Memory", 0x018E, 2, base=16, bitRange=14-15 sfr = "TBR", "Memory", 0x0190, 2, base=16 sfr = "TBCCR0", "Memory", 0x0192, 2, base=16 sfr = "TBCCR1", "Memory", 0x0194, 2, base=16 sfr = "TBCCR2", "Memory", 0x0196, 2, base=16 sfr = "TBCCR3", "Memory", 0x0198, 2, base=16 sfr = "TBCCR4", "Memory", 0x019A, 2, base=16 sfr = "TBCCR5", "Memory", 0x019C, 2, base=16 sfr = "TBCCR6", "Memory", 0x019E, 2, base=16 ;; Comparator A sfr = "CACTL1", "Memory", 0x0059, 1, base=16 sfr = "CACTL1.CAIFG", "Memory", 0x0059, 1, base=16, bitRange=0 sfr = "CACTL1.CAIE", "Memory", 0x0059, 1, base=16, bitRange=1


sfr = "CACTL1.CAIES", "Memory", 0x0059, 1, base=16, bitRange=2 sfr = "CACTL1.CAON", "Memory", 0x0059, 1, base=16, bitRange=3 sfr = "CACTL1.CAREF0", "Memory", 0x0059, 1, base=16, bitRange=4 sfr = "CACTL1.CAREF1", "Memory", 0x0059, 1, base=16, bitRange=5 sfr = "CACTL1.CARSEL", "Memory", 0x0059, 1, base=16, bitRange=6 sfr = "CACTL1.CAEX", "Memory", 0x0059, 1, base=16, bitRange=7 sfr = "CACTL2", "Memory", 0x005A, 1, base=16 sfr = "CACTL2.CAOUT", "Memory", 0x005A, 1, base=16, bitRange=0 sfr = "CACTL2.CAF", "Memory", 0x005A, 1, base=16, bitRange=1 sfr = "CACTL2.P2CA0", "Memory", 0x005A, 1, base=16, bitRange=2 sfr = "CACTL2.P2CA1", "Memory", 0x005A, 1, base=16, bitRange=3 sfr = "CACTL2.CACTL24", "Memory", 0x005A, 1, base=16, bitRange=4 sfr = "CACTL2.CACTL25", "Memory", 0x005A, 1, base=16, bitRange=5 sfr = "CACTL2.CACTL26", "Memory", 0x005A, 1, base=16, bitRange=6 sfr = "CACTL2.CACTL27", "Memory", 0x005A, 1, base=16, bitRange=7 sfr = "CAPD", "Memory", 0x005B, 1, base=16 sfr = "CAPD.CAPD0", "Memory", 0x005B, 1, base=16, bitRange=0 sfr = "CAPD.CAPD1", "Memory", 0x005B, 1, base=16, bitRange=1 sfr = "CAPD.CAPD2", "Memory", 0x005B, 1, base=16, bitRange=2 sfr = "CAPD.CAPD3", "Memory", 0x005B, 1, base=16, bitRange=3 sfr = "CAPD.CAPD4", "Memory", 0x005B, 1, base=16, bitRange=4 sfr = "CAPD.CAPD5", "Memory", 0x005B, 1, base=16, bitRange=5 sfr = "CAPD.CAPD6", "Memory", 0x005B, 1, base=16, bitRange=6 sfr = "CAPD.CAPD7", "Memory", 0x005B, 1, base=16, bitRange=7 ;; ADC12 sfr = "ADC12CTL0", "Memory", 0x01A0, 2, base=16 sfr = "ADC12CTL0.ADC12SC", "Memory", 0x01A0, 2, base=16, bitRange=0 sfr = "ADC12CTL0.ENC", "Memory", 0x01A0, 2, base=16, bitRange=1 sfr = "ADC12CTL0.ADC12TOVIE", "Memory", 0x01A0, 2, base=16, bitRange=2 sfr = "ADC12CTL0.ADC12OVIE", "Memory", 0x01A0, 2, base=16, bitRange=3 sfr = "ADC12CTL0.ADC12ON", "Memory", 0x01A0, 2, base=16, bitRange=4 sfr = "ADC12CTL0.REFON", "Memory", 0x01A0, 2, base=16, bitRange=5 sfr = "ADC12CTL0.REF2_5V", "Memory", 0x01A0, 2, base=16, bitRange=6 sfr = "ADC12CTL0.MSC", "Memory", 0x01A0, 2, base=16, bitRange=7 sfr = "ADC12CTL0.SHT0", "Memory", 0x01A0, 2, base=16, bitRange=8-11 sfr = "ADC12CTL0.SHT1", "Memory", 0x01A0, 2, base=16, bitRange=12-15 sfr = "ADC12CTL1", "Memory", 0x01A2, 2, base=16 sfr = "ADC12CTL1.ADC12BUSY", "Memory", 0x01A2, 2, base=16, bitRange=0 sfr = "ADC12CTL1.CONSEQ", "Memory", 0x01A2, 2, base=16, bitRange=1-2 sfr = "ADC12CTL1.ADC12SSEL", "Memory", 0x01A2, 2, base=16, bitRange=3-4 sfr = "ADC12CTL1.ADC12DIV", "Memory", 0x01A2, 2, base=16, bitRange=5-7 sfr = "ADC12CTL1.ISSH", "Memory", 0x01A2, 2, base=16, bitRange=8 sfr = "ADC12CTL1.SHP", "Memory", 0x01A2, 2, base=16, bitRange=9 sfr = "ADC12CTL1.SHS", "Memory", 0x01A2, 2, base=16, bitRange=10-11 sfr = "ADC12CTL1.CSTARTADD", "Memory", 0x01A2, 2, base=16, bitRange=12-15 sfr = "ADC12IFG", "Memory", 0x01A4, 2, base=16 sfr = "ADC12IE", "Memory", 0x01A6, 2, base=16 sfr = "ADC12IV", "Memory", 0x01A8, 2, base=16 sfr = "ADC12MEM0", "Memory", 0x0140, 2, base=16 sfr = "ADC12MEM1", "Memory", 0x0142, 2, base=16 sfr = "ADC12MEM2", "Memory", 0x0144, 2, base=16 sfr = "ADC12MEM3", "Memory", 0x0146, 2, base=16 sfr = "ADC12MEM4", "Memory", 0x0148, 2, base=16 sfr = "ADC12MEM5", "Memory", 0x014A, 2, base=16 sfr = "ADC12MEM6", "Memory", 0x014C, 2, base=16 sfr = "ADC12MEM7", "Memory", 0x014E, 2, base=16 sfr = "ADC12MEM8", "Memory", 0x0150, 2, base=16 sfr = "ADC12MEM9", "Memory", 0x0152, 2, base=16


sfr = "ADC12MEM10", "Memory", 0x0154, 2, base=16 sfr = "ADC12MEM11", "Memory", 0x0156, 2, base=16 sfr = "ADC12MEM12", "Memory", 0x0158, 2, base=16 sfr = "ADC12MEM13", "Memory", 0x015A, 2, base=16 sfr = "ADC12MEM14", "Memory", 0x015C, 2, base=16 sfr = "ADC12MEM15", "Memory", 0x015E, 2, base=16 sfr = "ADC12MCTL0", "Memory", 0x0080, 1, base=16 sfr = "ADC12MCTL0.INCH", "Memory", 0x0080, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL0.SREF", "Memory", 0x0080, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL0.EOS", "Memory", 0x0080, 1, base=16, bitRange=7 sfr = "ADC12MCTL1", "Memory", 0x0081, 1, base=16 sfr = "ADC12MCTL1.INCH", "Memory", 0x0081, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL1.SREF", "Memory", 0x0081, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL1.EOS", "Memory", 0x0081, 1, base=16, bitRange=7 sfr = "ADC12MCTL2", "Memory", 0x0082, 1, base=16 sfr = "ADC12MCTL2.INCH", "Memory", 0x0082, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL2.SREF", "Memory", 0x0082, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL2.EOS", "Memory", 0x0082, 1, base=16, bitRange=7 sfr = "ADC12MCTL3", "Memory", 0x0083, 1, base=16 sfr = "ADC12MCTL3.INCH", "Memory", 0x0083, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL3.SREF", "Memory", 0x0083, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL3.EOS", "Memory", 0x0083, 1, base=16, bitRange=7 sfr = "ADC12MCTL4", "Memory", 0x0084, 1, base=16 sfr = "ADC12MCTL4.INCH", "Memory", 0x0084, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL4.SREF", "Memory", 0x0084, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL4.EOS", "Memory", 0x0084, 1, base=16, bitRange=7 sfr = "ADC12MCTL5", "Memory", 0x0085, 1, base=16 sfr = "ADC12MCTL5.INCH", "Memory", 0x0085, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL5.SREF", "Memory", 0x0085, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL5.EOS", "Memory", 0x0085, 1, base=16, bitRange=7 sfr = "ADC12MCTL6", "Memory", 0x0086, 1, base=16 sfr = "ADC12MCTL6.INCH", "Memory", 0x0086, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL6.SREF", "Memory", 0x0086, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL6.EOS", "Memory", 0x0086, 1, base=16, bitRange=7 sfr = "ADC12MCTL7", "Memory", 0x0087, 1, base=16 sfr = "ADC12MCTL7.INCH", "Memory", 0x0087, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL7.SREF", "Memory", 0x0087, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL7.EOS", "Memory", 0x0087, 1, base=16, bitRange=7 sfr = "ADC12MCTL8", "Memory", 0x0088, 1, base=16 sfr = "ADC12MCTL8.INCH", "Memory", 0x0088, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL8.SREF", "Memory", 0x0088, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL8.EOS", "Memory", 0x0088, 1, base=16, bitRange=7 sfr = "ADC12MCTL9", "Memory", 0x0089, 1, base=16 sfr = "ADC12MCTL9.INCH", "Memory", 0x0089, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL9.SREF", "Memory", 0x0089, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL9.EOS", "Memory", 0x0089, 1, base=16, bitRange=7 sfr = "ADC12MCTL10", "Memory", 0x008A, 1, base=16 sfr = "ADC12MCTL10.INCH", "Memory", 0x008A, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL10.SREF", "Memory", 0x008A, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL10.EOS", "Memory", 0x008A, 1, base=16, bitRange=7 sfr = "ADC12MCTL11", "Memory", 0x008B, 1, base=16


sfr = "ADC12MCTL11.INCH", "Memory", 0x008B, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL11.SREF", "Memory", 0x008B, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL11.EOS", "Memory", 0x008B, 1, base=16, bitRange=7 sfr = "ADC12MCTL12", "Memory", 0x008C, 1, base=16 sfr = "ADC12MCTL12.INCH", "Memory", 0x008C, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL12.SREF", "Memory", 0x008C, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL12.EOS", "Memory", 0x008C, 1, base=16, bitRange=7 sfr = "ADC12MCTL13", "Memory", 0x008D, 1, base=16 sfr = "ADC12MCTL13.INCH", "Memory", 0x008D, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL13.SREF", "Memory", 0x008D, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL13.EOS", "Memory", 0x008D, 1, base=16, bitRange=7 sfr = "ADC12MCTL14", "Memory", 0x008E, 1, base=16 sfr = "ADC12MCTL14.INCH", "Memory", 0x008E, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL14.SREF", "Memory", 0x008E, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL14.EOS", "Memory", 0x008E, 1, base=16, bitRange=7 sfr = "ADC12MCTL15", "Memory", 0x008F, 1, base=16 sfr = "ADC12MCTL15.INCH", "Memory", 0x008F, 1, base=16, bitRange=0-3 sfr = "ADC12MCTL15.SREF", "Memory", 0x008F, 1, base=16, bitRange=4-6 sfr = "ADC12MCTL15.EOS", "Memory", 0x008F, 1, base=16, bitRange=7 ;; Flash Memory sfr = "FCTL1", "Memory", 0x0128, 2, base=16 sfr = "FCTL1.ERASE", "Memory", 0x0128, 2, base=16, bitRange=1 sfr = "FCTL1.MERAS", "Memory", 0x0128, 2, base=16, bitRange=2 sfr = "FCTL1.WRT", "Memory", 0x0128, 2, base=16, bitRange=6 sfr = "FCTL1.BLKWRT", "Memory", 0x0128, 2, base=16, bitRange=7 sfr = "FCTL1.KEY", "Memory", 0x0128, 2, base=16, bitRange=8-15 sfr = "FCTL2", "Memory", 0x012A, 2, base=16 sfr = "FCTL2.FN0", "Memory", 0x012A, 2, base=16, bitRange=0 sfr = "FCTL2.FN1", "Memory", 0x012A, 2, base=16, bitRange=1 sfr = "FCTL2.FN2", "Memory", 0x012A, 2, base=16, bitRange=2 sfr = "FCTL2.FN3", "Memory", 0x012A, 2, base=16, bitRange=3 sfr = "FCTL2.FN4", "Memory", 0x012A, 2, base=16, bitRange=4 sfr = "FCTL2.FN5", "Memory", 0x012A, 2, base=16, bitRange=5 sfr = "FCTL2.SSEL0", "Memory", 0x012A, 2, base=16, bitRange=6 sfr = "FCTL2.SSEL1", "Memory", 0x012A, 2, base=16, bitRange=7 sfr = "FCTL2.KEY", "Memory", 0x012A, 2, base=16, bitRange=8-15 sfr = "FCTL3", "Memory", 0x012C, 2, base=16 sfr = "FCTL3.BUSY", "Memory", 0x012C, 2, base=16, bitRange=0 sfr = "FCTL3.KEYV", "Memory", 0x012C, 2, base=16, bitRange=1 sfr = "FCTL3.ACCVIFG", "Memory", 0x012C, 2, base=16, bitRange=2 sfr = "FCTL3.WAIT", "Memory", 0x012C, 2, base=16, bitRange=3 sfr = "FCTL3.LOCK", "Memory", 0x012C, 2, base=16, bitRange=4 sfr = "FCTL3.EMEX", "Memory", 0x012C, 2, base=16, bitRange=5 sfr = "FCTL3.KEY", "Memory", 0x012C, 2, base=16, bitRange=6-13 : ;;End of file


3.6. Mikrocontrollerspeicher

Bild: Merkmale von Speichertypen auf Halbleiterbasis

Der Speicher der MSP430-Familie ist vollständig auf dem Silizium-Chip enthalten.

Auf den gesamten Speicher wird über zwei 16-Bit-Busse zugegriffen:

Speicher-Adress-Bus (Memory Address Bus MAB) zur Bereitstellung der Speicherad-resse durch die CPU

Speicher-Daten-Bus (Memory Data Bus MDB) zum Lesen (Speicher => CPU) und Schreiben (CPU => Speicher)

Der Speicher ist technologisch einzuteilen in die beiden Arten

Festwertspeicher: ein Speicher, dessen Inhalt durch die CPU nicht beliebig geändert werden kann (ROM, OTPROM, EPROM, EEPROM,..)

Schreib-Lese-Speicher: ein Speicher, dessen Inhalt jederzeit geändert werden kann und der bei Abschaltung der Versorgungsspannung seinen Wert verliert (Random Access Memory RAM)

Festwertspeicher kann bei der Definition eines Familienmitgliedes entweder benutzerpro-grammierbar (One Time Programmable Read-Only Memory OTPROM, Ereasable Programmable Read-Only Memory EPROM) oder bei der Fertigung festgelegt (Read-Only Memory ROM) werden. Der Zugriff auf gewöhnlichen externen Speicher ist für spätere Familien mitglieder vorgesehen.Programmseitig ist der Speicher jedoch einzuteilen in Programmspeicher und Datenspeicher.

Programmspeicher


Der Zugriff auf den Programmspeicher ist beim Zugriff auf Anweisungen immer Word-orientiert, d. h. die CPU greift nur auf gerade Adressen wortweise mit jeweils 16 Bit zu. Daten können wortweise (16 Bit an gerader Adresse) oder byteweise (8 Bit an beliebiger Adresse) gelesen oder geschrieben werden.

Jeder Zugriff auf den Speicher benutzt den 16-Bit-Datenbus und soviele der nieder-wertigen Adressleitungen wie für die Speicherunterscheidung gerade benötigt werden. Speicherblöcke werden erst bei Zugriff automatisch selektiert und durch Modulaktivie-rungssignale (Module Enable Signals) aktiviert, um den Stromverbrauch des MSP430 möglichst klein zu halten.

Datenspeicher Der gesamte Befehlssatz arbeitet wort- oder byteorientiert. Alle Zugriffe auf den Stapel-speicher und den Programmzähler haben wortorientiert mit geraden Adressen zu erfolgen.

Spezialregister Der Betrieb der verschiedenen Module der MSP430-Familie wird im wesentlichen durch Informationen gesteuert, die in Spezialregistern (SFR) gespeichert sind. Die ver-schiedenen Bits in den SFR erlauben Unterbrechungen (Interrupts), liefern dem Programm Informationen über die Ursache einer Unterbrechung und steuern den Betrieb peripherer Module.

Angehaltene Peripheriegeräte stellen ihren Betrieb ein, um den Stromverbrauch zu mi-nimieren. Dabei bleiben alle in den Registern des Moduls enthaltenen Daten erhalten. Die SFR’s sind in zwei Adressbereichen untergebracht, einem für Byte-Register und einem für Word-Register.

3.7. Die CPU

Die CPU Register The 16-bit program counter (PC/R0) points to the next instruction to beexecuted. Each instruction uses an even number of bytes (two, four, or six),and the PC is incremented accordingly. Instruction accesses in the 64-KBaddress space are performed on word boundaries, and the PC is aligned toeven addresses. The PC can be addressed with all instructions and addressing modes.

Examples MOV #LABEL, PC ; Branch to address LABEL MOV LABEL, PC ; Branch to address contained in LABEL MOV @R14, PC ; Branch indirect to address in R14

Stack Pointer The stack pointer (SP/R1) is used by the CPU to store the return addressesof subroutine calls and interrupts. It uses a predecrement, postincrementscheme. In addition, the SP can be used by software with all instructions andaddressing modes.

Examples MOV 2(SP), R6 ; Item I2 −> R6


MOV R7, 0(SP) ; Overwrite TOS with R7 PUSH #0123h ; Put 0123h onto TOS POPR 8 ; R8 = 0123h

Bild: CPU Block Diagram

Status Register The status register (SR/R2), used as a source or destination register, can beused in the register mode only addressed with word instructions. The remain-ing combinations of addressing modes are used to support the constant gen-erator. Figure 3−6 shows the SR bits.


Bild: Description of Status Register Bits

3.7.1. Addressing Modes Seven addressing modes for the source operand and four addressing modesfor the destination operand can address the complete address space with noexceptions. The bit numbers in Table 3−3 describe the contents of the As(source) and Ad (destination) mode bits.


Bild: Seven Addressing Modes

3.7.2. The Instruction Set

Bild: Befehlsübersicht


Bild: MSP430 Instruction Set


Bild: Core Instruction Map

The source and destination of an instruction are defined by the following fields:


Double Operand (Format I) Instructions

Single Operand (Format II) Instructions


Jumps

The next Table lists and describes the jump instructions.


3.8. Kontrollfragen

What functions are in a microcontroller chip but NOT in a microprocessor? Interrupts, Instruction Decoder, Instruction Register Program memory, Data memory, I/O Program Counter, Registers, Data Bus Peripheral Devices, Address Bus, Data Bus

What buses are present in a microcontroller system? Address, Data, and Control Input and Output Address and Instruction Address, Data and Bluebird

From what point of reference are the terms "read" and "write" defined? The data bus The I/O Device The CPU The Memory

What is the purpose of the address decoder? To translate logical addresses to physical addresses. It selects the appropriate CPU register. It recognizes addresses of individual devices connected to the bus and enables the

devices when they are selected. It decodes the instructions.


4. DER SOFTWARE BUILD PROZESS BEI EMBEDDED SYSTEMEN

Bild: Toolchain

Compiler Die Aufgabe des Compilers liegt darin, den in einer Hochsprache abgefassten Quellcode, in Assembler-Quellcode zu übersetzen. Die vielen problemorientierten, für Menschen lesbaren Hochsprachen, müssen von Compilern in eine prozessorspezifische Maschinensprache übersetzt werden, die von dem Computer direkt verarbeitet werden kann.

Assembler Der Assembler ist das Werkzeug, das den Assembler-Sourcecode (meistens erzeugt vom Compiler) in Maschinensprache übersetzt, in einen so genannten Objectcode. Dies ist die Sprache des Prozessors, die für Menschen nur sehr schwer lesbar ist.

Der Zwischenschritt von Compiler und Assembler über den Assembler-Sourcecode ist auf den ersten Blick unnötig. Tatsächlich gibt es ältere Compiler, die diesen Schritt auslassen. Es hat sich jedoch gezeigt, dass dieser Zwischenschritt sinnvoll ist, da sehr viel Flexibilität


erreicht werden kann. Zum Beispiel ist es möglich, Teile von Programmen in verschiedenen Hochsprachen zu schreiben, diese mit entsprechenden Compilern in Assembler-Sourcecode zu übersetzen und dann mit einem Assembler den Objektcode für den Prozessor zu erzeugen.

Es wird so auch möglich Optimierungen oder Fehlerbehebungen durchzuführen, zu denen der Compiler nicht in der Lage ist.

Linker Der vom Assembler generierte Objektcode liegt in Bruchstücken vor. Die Aufgabe des Linkers besteht nun darin, alle benötigten Stücke zu sammeln und zusammenzufügen (engl. to link = verbinden, koppeln). Dabei können die einzelnen Object-Codedateien aus verschiedenen Source-Code Dateien stammen und von verschiedenen Compilern (Pascal, C/C++) erzeugt worden sein.

Softwareroutinen, die nicht benötigt werden, z. B. unbenutzte Teile einer Softwarebib-liothek (Library), können so weggelassen werden, um das ausführbare Programm möglichst klein zu halten.

Das Resultat des Linkers sind Gruppierungen von Bruchstücken, die Gemeinsamkeiten aufweisen wie z. B. gemeinsam genutzter Speicher etc.. Dies kann die Vorstufe zu einem ausführbaren Programm oder aber eine Softwarebibliothek (library) sein.

Locator Als letzte Station tritt der Locator in Aktion. Er ist es, der die vom Linker erzeugten Gruppen an den richtigen Stellen platziert (engl. to locate = fixieren, siedeln). Somit ist ein ausführbares Programm erzeugt und bereit zur Ausführung.

Debugger

Der Begriff debugging bezeichnet den Prozess des Auffindens von Softwarefehlern, d. h. Bugs zu finden und zu entfernen. Mittels spezieller Tools kann der Entwickler das Programm Schritt für Schritt ausführen und alle logischen Abläufe überprüfen.


C Source-Code schreiben

Bloodshed Dev-C++ IDE

*.dev Dev-C++Projektdatei

*.c C-Quellcodedateien

*.h MSPGCCHeaderdateien

*.o Objektdateien

Linken

MSPGCC Linker

*.lib MSPGCCBibliothekdateien

*.exe Programmdatei

Dev

-C+

+:M

enü-

>A

usfü

hren

->K

ompi

liere

n

Autom

atisierter Ablauf. K

eine Interaktion nötig.

Makefile.winKompilieren

MSPGCC Crosscompiler

Vorgang

Programmname

Hilfsdatei

Datei

Legende:

Bild: Ablaufdiagramm: Vom Quellcode zur Programmdatei


Lokalisieren und Verifizierender Programmdatei

Windows Explorer

*.exe Programmdatei

Programm im Debuggerladen

Insight Debugger

Verbindung zum Targetherstellen

gdbProxy

Programm simulieren

Insight Simulator

Hardwareinteraktion

MSP430-449STK

Sourcecode abändern

Bloodshed Dev-C++ IDES

iehe Ablaufplan

Vorgang

Programmname/Objekt

Datei

Legende:

Bild: Programm Simulation/Debugging


4.1. Entwicklungsschritte für ein Mikrocomputersystem

Problemdefinition: Leistungsumfang des Systems definieren, Datenflussplan erstellen (SADT); Requirementsanalyse (Functional, Non-Functional, System, Software, Hardware-, GUI- Requirements)

Wirtschaftlichkeitsprüfung (Realisierungsbeschluss):

Abschätzen von Geschwindigkeit, Speicherbedarf, Bauelementeaufwand, Prüfung auf technische und wirtschaftliche Realisierbarkeit

Systemanalyse: Problemstruktur analysieren, Use Cases definieren, Klassendesign u. Transaktionsdiagramme erstelen (UML) Programmablaufplan erstellen, Blockschaltbild der Schaltung

Hardwareentwicklung: Kauf/Eigenentwicklung

Softwareentwicklung: Detaillierter Programmablaufplan, Codieren, Programmeingabe, Übersetzen, Simulation, Debugging

Modultest, Integrationstest, Systemtest, Fehlerkorrektur:

Anbindung des Prozesses, Test des Zusammenspiels

Dokumentation: Hardware, Software

4.2. IAR Debug- und Testverfahren im Überblick

The IAR C-SPY Debugger can be used for debugging either a software target system or a hardware target system. The figure below shows an overview of C-SPY and possible target systems.


Bild: IAR C-SPY Debugger and target systems

DEBUGGER

The debugger, for instance C-SPY, is the program that you use for debugging your ap-plications on a target system.

TARGET SYSTEM

The target system is the system on which you execute your application when you are debugging it. The target system can consist of hardware, either an evaluation board or your own hardware design. It can also be completely or partially simulated by software. Each type of target system needs a dedicated C-SPY driver.

USER APPLICATION

A user-application is the software you have developed and which you want to debug using the IAR C-SPY Debugger.

4.2.1. IAR C-SPY Debugger Sysytems

The IAR C-SPY Debugger consists of both a general part which provides a basic set of C-SPY features, and a driver. The C-SPY driver is the part that provides communication with and control of the target system. The driver also provides the user interface—menus, windows, and dialog boxes—to the functions provided by the target system, for instance, special breakpoints. The following C-SPY drivers are provided:

Simulator driver


ROM-monitor driver

Emulator driver

If you have more than one C-SPY driver installed on your computer you can easily switch between them just by choosing the appropriate driver from within the IAR Embedded Workbench.

ROM-MONITOR PROGRAM

The ROM-monitor program is a piece of firmware that must be loaded to non-volatile memory on your target hardware; it runs in parallel with your application. The ROM-monitor communicates with the debugger and provides services needed for debugging the application, for instance stepping and breakpoints.

Adapting C-SPY to target hardware by the DEVICE DESCRIPTION FILE

C-SPY handles several of the target-specific adaptations by using device description files provided with the product. They contain device-specific information such as:

Memory information for device-specific memory zones

Definitions of memory-mapped peripheral units, device-specific CPU registers, and groups of these

Definitions for interrupt simulation in the simulator.

You can find customized device description files for each MSP430 device in the 430\config directory.

Memory Zones

To view memory conveniently, the C-SPY Debugger uses device-specific memory zones. By default there is only one address zone in the debugger, Memory, which covers the whole MSP430 memory range. If you load a device description file, additional zones that adhere better to the specific device memory layout are defined.

Figure: Memory Zones for MSP430F149

If your hardware does not have the same memory layout as the device description file, you can define customized zones by adding them to the appropriate file.


Memory zones are used in several contexts, perhaps most notably in the Memory and Disassembly windows. The Zone box in these windows allows you to choose which memory zone to display.

4.2.2. Test im EPROM

S ource C ode sch re iben

E d ito r / ID E

S ource C o de kom p ilie ren

C om p ile r

T es t im E P R O M

Z ie lha rdw are

E P R O M B renne r

Bild: Test im EPROM


Bild: Entwicklungszyklus mit Emulation Hardware

Editor gibt eventuell über Syntax Highlightning und Intelli-Sense Hinweise über Programmier-fehler. Der Compiler stellt formale Programmierfehler fest

Nachdem der kompilierte Code in ein übertragungsfähiges Format überführt wurde, wird ein EPROM geschrieben und in der Zielhardware eingebaut. Tritt ein Fehler auf, muss dass Programm modifiziert, erneut kompiliert, neu gebrannt und nochmals eingebaut werden, dies solange bis alle Fehler aufgefunden wurden. Insgesamt ein sehr aufwendiges Verfahren und veraltet.

4.2.3. Test im Monitor

Bild: Kommunikation bei der Monitor-Testumgebung


Source Code schreiben

Source Code kompilieren

Test im Monitorprogramm

Zielhardware

Monitor

Compiler

Editor / IDE

Bild: Debugging im Monitor

Editor gibt eventuell über Syntax Highlightning und Intelli-Sense Hinweise über Programmier-fehler. Compiler stellt formale Programmierfehler fest.

Mit der Hilfe des Monitorprogramms in der Zielhardware kann der compilierte Code übertra-gen werden. Die Monitorbefehle ermöglichen das Setzen von Haltepunkten an markanten Stellen und erlauben eine schrittweise Ausführung des Anwenderprogramms; ferner können Speicherinhalte editiert werden.

Der Einsatz eines Monitorprogramms ermöglichte komfortableres Debugging, ist aber heute von moderneren Verfahren wie JTAG abgelöst worden.

4.2.4. Test im Simulator



Editor / IDE

Editor gibt eventuell über Syntax Highlightning und Intelli-Sense Hinweise über Programmierfehler


Compiler

Compiler stellt formale Programmierfehler fest

Test im Simulator

Simulator / In-Circuit Emulator (ICE)

Monitor, EPROM Brenner, JTAG

Test in Zielhardware

Zielhardware

Vor dem Test in der eigentlichen Zielhardware können in der Simulation des Mikrokontrollers bereits Fehler beseitigt werden. Wird heute häufig eingesetzt, da es sehr effizient ist.

Bild: Test im Simulator

4.2.5. Debugging mit dem JTAG Interface



Editor / IDE

Editor gibt eventuell über Syntax Highlightning und Intelli-Sense Hinweise über Programmierfehler


Compiler

Compiler stellt formale Programmierfehler fest

Test mit JTAG

Zielhardware

Der kompilierte Code kann mit der Boundary Scan Technik (JTAG) auf einfachster Weise in die Zielhardware geschrieben werden und das Interface erlaubt die vollständige Kontrolle des Mikrocontrollers. Die komfortabelste Methode des Debuggens; sehr schnell und effizient.

JTAG

Bild: Test mit JTAG

Das JTAG Interface oder auch als BDM (Background Debug Mode) Interface bezeichnet, macht sich die Boundary Scan Methode zu Nutzen.

In der Anfangszeit hatte man für das Debugging nur wenige Tools wie z. B. Oszilloskope zur Verfügung. Die später eingesetzten Emulatoren, spezielle Prozessoren für die Entwicklung mit herausgeführten Kontakten, waren für größere Prozessoren nicht mehr einsetzbar.

Das BDM/JTAG Interface ist auch bei komplexen CPUs verwendbar. Dabei hat das JTAG Entwicklungswerkzeug den Prozessor vollkommen im Griff und die darauf aufsetzende Debugoberfläche steuert wiederum das JTAG Interface. Idealerweise kann man so direkt aus der Integrierten Entwicklungsoberfläche heraus Software debuggen.

Der Programmcode kann editiert, compiliert, auf die Zielhardware übertragen und an-schließend direkt im Prozessor debugged werden. Über ein paralleles oder serielles Inter-face kann man direkt auf den Speicher und auf die Register zugreifen. So ist es möglich, die Reaktionen der Hardware auszulesen, oder irgendwelche Zustände extern herbeizuführen um beispielsweise eine spezielle Situation auszutesten.

Über die Debuggeroberfläche kann Schritt für Schritt der Sourcecode ausgeführt werden und man hat dabei volle Kontrolle, ob man in Unterfunktionen verzweigen möchte, oder zu bestimmten Stellen springen möchte.

Mit so genannten Breakpoints ist es möglich, Haltepunkte innerhalb des Sourcecodes zu setzen, um während des Programmablaufs an dieser Stelle eine Pause zu machen, um sich in aller Ruhe den aktuellen Zustand anschauen zu können und kann bei Bedarf auch


Register abzuändern, um z. B. einen konditionalen Sprung auszuführen, der durch eine falsche Rechenoperation doch nicht erreicht wurde.

Bild: Schaltplan JTAG Interface

Bild: Pinbbelegung JTAG Interface


Bild: Schaltplan des Evaluation Boards MSP430-449STK

4.3. Building Salco RTOS Applications

Salvo applications are typically built in one of two ways, as a library build, or as a source-code build.

The most important salvo files are as follows:

salvo.h This is Salvo’s main header file and must be included in any source file that uses Salvo services. It should not be modified by the user. This file in turn includes salvocfg.h.

mem.c This is a major file, supplied with Salvo. It holds global objects, which define characteristics for the features used, like tasks, semaphores and so on. It should not be modified by the user, although the contents of salvocfg.h impact upon it.

salvocfg.h This file, written by the user, determines much of the configuration of the system for the application. It sets certain key elements, like which library is to be used, and how many tasks and events there will be.


Bild: Salvo Build Process Overview

In a source-code build, a Salvo application is built from user source code (C and As-sembly) and from Salvo source code (C and Assembly, where applicable), including Salvo’s mem.c.

The user C source code makes calls to Salvo services that are contained in the Salvo source code. Again, Salvo’s global objects (i.e. its task control blocks, etc.) are in \salvo\src\mem.c.

In a source-code build, all of Salvo’s source-code modules must be re-compiled each time the project’s Salvo configuration - defined in the project’s salvocfg.h file - is changed.

The next Figure presents an overview of the Salvo source-code build process.

In a source-code build, the configuration options in the project’s salvocfg.h affect the user C source files and all of Salvo’s C source files, where the desired user services are contained.

Each configuration option that the user wishes to set to a nondefault value must be defined in salvocfg.h. All other configuration options are automatically set to their default values in salvo.h. As in a library build, certain configuration options (e.g. OSTASKS) set the sizes of Salvo’s various global objects (e.g. the number of task control blocks).


Bild: Salvo Source-Code Build Overview

Benefits of Different Build Types

Library builds have the advantage that all of the Salvo services are available in the library, and the linker will add only those necessary when building the application.


The disadvantage is that if a different library configuration is required, both the salvocfg.h and the project file must be edited to ensure a match between the desired library and the library that linker sees.

With a source-code build, Salvo can be completely reconfigured just by simply adding or changing entries in salvocfg.h, and by adding the required Salvo source files to the project.

Another benefit of library builds is that rebuilding a project within a Makefile-driven system is faster, since the library need not be rebuilt when allowable changes (e.g. changing the number of tasks) are made to salvocfg.h.

5. LOW POWER OPERATING MODES

The MSP430 operating modes support various advanced requirements for ultralow power and ultralow energy consumption. The intelligent management of the operations during the different module operation modes and CPU states achieves this. The requirements are fully supported during interrupt event handling. An interrupt event awakens the system from each of the various operating modes and returns with the RETI instruction to the mode that was selected before the interrupt event. The clocks used are ACLK, SMCLK, and MCLK.

ACLK is the crystal frequency, MCLK and SMCLK are either multiples of ACLK or come from the crystal oscillators. MCLK and SMCLK are used as the system clock and subsystem clock.

Um effektiv Leistung einzusparen, gibt es ein ganzes Bündel an Details, die bei der Familie MSP430 berücksichtigt worden sind. Das reicht vom Verbrauch von Quarzos-zillatoren in Abhängigkeit von Oszillator schaltung, Anschwing dauer und Schwingfrequenz bis zur schaltungstechnischen Auslegung von Ein-/Ausgängen

Bild: Operation Modes


The software can conBild several operating modes:

Active mode AM; SCG1=0, SCG0=0, OscOff=0, CPUOff=0: CPU clocks are active

Low-power mode 0 (LPM0); SCG1=0, SCG0=0, OscOff=0, CPUOff=1:

CPU is disabled

ACLK and SMCLK remain active. MCLK is disabled

FLL+ Loop control remains active


CPU is disabled

FLL+ Loop control is disabled

ACLK and SMCLK remain active. MCLK is disabled


CPU is disabled

MCLK and FLL+ loop control and DCOCLK are disabled

DCO’s dc-generator remains enabled

ACLK remains active


CPU is disabled

MCLK, FLL+ loop control, and DCOCLK are disabled

DCO’s dc-generator is disabled

ACLK remains active

Low-power mode 4 (LPM4); SCG1=X, SCG0=X, OscOff=1, CPUOff=1:

CPU is disabled

ACLK is disabled

MCLK, FLL+ loop control, and DCOCLK are disabled

DCO’s dc-generator is disabled

Crystal oscillator is stopped


Bild: Betriebszustände und Übergangsbedingungen

6. INTERRUPTS UND INTERRUPT SERVICE ROUTINEN (ISR)

Ziele:

Begriffsdefinition


Shared Interrupt (Wired OR auf Basis von Open Collector Schaltungen) NMI (maskable, non maskable) Message-Signaled Interrupts

Unterschiedliche Arten von Interrupts Hardware-, Softwareinterrupts (DOS 21h, BIOS 10h)

BIOS-Interrupts Exceptions (Fault, Trap, Abort)

Interrupt-Controller Kaskadierte Interruptcontroller Bsp.: 8259 Vermittlung an den PC Wired OR-Shared Interrupt

Einsatzgebiete von Interrupts Anwendungsbsp.: Gegenüberstelung Polling - Interruptbasierende Verarbeitung Wake on LAN Diagnosebearbeitung und Power Save

Funktionsweise IRQ -> Interruptvektortabelle -> ISR C -> ASM -> HexCode bei der Implementierung von Interrupts am MSP430xx Interruptvektoren „umbiegen“

IRQs am Systembus Bsp: Interrupt-Ressourcen im PC

Bsp.: Interrupts beim MSP430, Auflösung der Makroanweisung #pragma

Literatur und Weblinks

http://www.bjoern-koester.de/iogrundlagen/index.html http://www.atwillys.de/imp/prj/index.htm

6.1. Begriffsdefinitionen, unterschiedliche Arten von Interrupts

Das englische Wort "Interrupt" bedeutet einfach Unterbrechung. Diese Bezeichnung ver-wendet man allgemein für Anweisungen an den PC-Hauptprozessor, den gerade laufen-den Prozess zu unterbrechen und (vorübergehend) einen anderen Befehl abzuarbeiten.

Es werden begrifflich verschiedene Arten von Interrupts unterschieden, auf die nachste-hend eingegangen werden soll.

6.1.1. Hardware-Interrupts (“Interrupt Request”-Leitungen)

Über Interrupt Requests (Abkürzung IRQ, englisch für „Unterbrechungsanforderung“) wird in Mikrocomputern eine Unterbrechung eines Prozessors ausgelöst, in der Regel ausge-


hend von Peripheriegeräten im System. Der Prozessor unterbricht dann seine derzeitige Aufgabe und führt die Unterbrechungsroutine (Interrupt Service Routine = ISR) aus. Da-nach wird die zuvor unterbrochene Aufgabe fortgesetzt.

Bsp:

Der serielle Schnittstellenbaustein UART generiert einen Interrupt Request (IRQ), wenn ein Zeichen über das COM-Interface empfangen hat. Die dem IRW zugeordnete Unterbre-chungsroutine (ISR) kann nun das jeweilige Zeichen von dem UART-Baustein lesen und z.B. in den Hauptspeicher (Arbeitsspeicher) übertragen.

Weitere Beispiele, in denen Geräte einen Interrupt Request generieren:

Netzwerkkarte: wenn Daten empfangen wurden und im Puffer bereitliegen

Festplatte: wenn die vorher angeforderten Daten gelesen wurden und abholbereit sind (das Lesen von der Festplatte dauert relativ lange)

Interrupt Request oder IRQ

Als IRQ bezeichnet man eine elektrisches Signal, das eine PC-Hardwarekomponente auslösen kann, um die CPU zur Abarbeitung von Befehlen aufzufordern. So meldet etwa ein SCSI- oder EIDE-Hostadapter dem Hauptprozessor, dass angeforderte Daten bereit-stehen und jetzt verarbeitet werden müssen. Auch eine Soundkarte teilt über einen IRQ mit, dass sie jetzt neue Daten benötigt, die die CPU berechnen oder aus dem Speicher liefern soll.

Die CPU besitzt nur einen Eingang für Interruptanforderungen. Um zu entscheiden, welche Hardwarekomponente die Aufmerksamkeit des Prozessor braucht, gibt es eine festgelegte Vorgehensweise: Ein spezieller Controller im Chipsatz, der Programmable Interrupt Cont-roller (PIC), stellt mehrere Eingänge für IRQ-Anforderungen von Hardwarekomponenten zur Verfügung.

Löst nun eine Hardwarekomponente einen IRQ aus, so schickt der PIC seinerseits eine Interruptanforderung an die CPU und übermittelt dieser gleichzeitig eine Speicheradresse (siehe Vektorisierung von Interrupts), an der die jetzt auszuführenden Anweisungen ste-hen. Diese arbeitet die CPU dann ab.

Der PIC hat sich historisch aus der XT-Architektur entwickelt. Damals bot er nur acht Ein-gänge (IRQ 0-7). Mit der AT-Architektur kam ein zweiter PIC hinzu, der an den IRQ2 des ersten PIC angeschlossen ist. In modernen Chipsätzen ist diese Bauform nicht mehr vor-handen, aber die Funktionsweise blieb so.

Die Nummerierung der IRQs gibt die Priorität dieser IRQs an; diese ist aber nicht absolut zu nehmen.

Die meisten der 15 verschiedenen IRQs sind fest belegt, andere lassen sich je nach Kon-figuration des PC unterschiedlich nutzen:

IRQ0 besitzt jedoch in beiden Fällen stets die höchste und IRQ15 ebenfalls die niedrigste Priorität.

IRQ typische Bedeutung Alternativen


00 Systemtaktgeber

01 Tastatur-Controller

02 programmierbarer Interrupt-Controller alte Modems, EGA, COM3, COM4

03 serielle Schnittstelle COM2 (E/A-Bereich 02F8) COM4, Modems, SK, NWK

04 serielle Schnittstelle COM1 (E/A-Bereich 03F8) COM3, Modems, SK, NWK

05 frei, oft Soundkarte (Soundblaster-Emulation) oder LPT2

LPT2, LPT3, COM3/4, Modems, NWK

06 Floppy-Controller

07 parallele (Drucker-)Schnittstelle LPT1 (E/A-Be-reich 0378)

LPT2, COM3/4, Modems, SK, NWK

08 Echtzeituhr

09 frei SK, NWK, SCSI, PCI

10 frei SK, NWK, SCSI, 2.+4. IDE, PCI

11 frei SK, NWK, SCSI, VGA, 3.+4. IDE, PCI

12 PS/2-Mausanschluss SK, NWK, SCSI, VGA, 3. IDE, PCI

13 Math.-Coprozessor (ob separat oder in CPU integ-riert)

14 1. IDE-Channel (primärer IDE-Kanal) SCSI

15 2. IDE-Channeln (sekundärer IDE-Kanal) NWK, SCSI

Für Komponenten, die über den ISA-Bus angeschlossen sind, muss aus elektrischen Gründen jeweils eine eigene, ungeteilte IRQ-Leitung zur Verfügung stehen.

Es gibt nur eine Ausnahme, das sind die COM-Ports: Stehen mehr als zwei serielle Schnittstellen zur Verfügung, so teilen sich

COM1 und COM3 den IRQ4 und

COM2 und COM4 den IRQ3;

Die E/A-Bereiche von COM1 und COM3 bzw. COM2 und COM4 sind jedoch verschieden. Eine tatsächlich gleichzeitige Benutzung der IRQ-Leitung etwa durch COM1 und COM3 kann bei höheren Datenübertragungsraten zu Problemen führen.


Bild: Bsp.: Interruptliste eines Pentium-Rechners

6.2. Übertragung des Interruptvektors von der Peripherie an die CPU

Übertragung des Interruptvektors von der Peripherie an die CPU: Vektorisierung

Das Verzweigen zur Interrupt-Service-Routine wird allgemein mit Vektorisierung von Interrupts bezeichnet. Bei der Vektorisierung gibt es viele Möglichkeiten, von denen hier die wichtigsten vorgestellt werden:

1. Die Interruptquelle legt den CALL-Befehl auf den Datenbus. Dieser wird vom Pro-zessor gelesen und wird daraufhin decodiert und ausgeführt.

2. Die Interruptquelle legt nicht den CALL-Befehl selbst, sondern seine (Speicher-) Ad-resse auf den Datenbus. Der Prozessor liest mit dieser Adresse den CALL-Befehl aus dem Speicher, decodiert den Befehl und führt ihn aus.


3. Anstelle des ganzen Befehls legt die Interruptquelle nur die im benötigten Befehl be-findliche Adresse auf den Datenbus. Dies ist schließlich gleich der Adresse der Ser-vice-Routine. Der Prozessor liest die Service-Routine und verzweigt direkt zum Mik-roprogramm des CALL-Befehls (oder gar zu einem bestimmten Mikroprogramm für den Interrupt). Die Decodierung entfällt.

4. Statt der Adresse der Service-Routine wird nur die Vektornummer auf den Datenbus gelegt. Durch den Interrupt wird die Vektornummer bestimmt. In der im Speicher be-findlichen Vektortabelle werden die Startadressen der jeweiligen Service-Routinen festgehalten. (Vgl. Abschnitt ). Die Adresse der Service-Routine wird vom Prozessor aus dem Speicher gelesen und verzweigt direkt zum Mikroprogramm des CALL-Befehls (oder zu einem bestimmen Mikroprogramm für den Interrupt). Solche Inter-rupts nennt man Vektor-Interrupts.

5. Anders als in 4. legt die Interruptquelle keine Angabe für die Service-Routine auf den Datenbus. Die Vektornummer ist für den jeweiligen Interrupt prozessorintern gespeichert, so dass sie nicht erst (prozessorextern, z.B. über den Speicher) gele-sen werden muss. Der Prozessor benutzt die Vektornummer unmittelbar zur Indizie-rung der Vektortabelle. Man nennt diese Interrupts Autovektor-Interrupts.


Bewertung der Methoden:

In der Praxis wird die Vektormethode 4. und 5. am häufigsten eingesetzt. Durch sie ent-steht ein großer Hardware-Aufwand, da für jede Interrupt-Anforderung ein Eingang am Prozessor vorgesehen sein muss.

Flexibler sind jedoch die ersten drei Methoden, weil mehrere mögliche ISR auf einen ein-zigen Interrupt angewendet werden können. Die Effizienz ist allerdings geringer.

6.2.1. Maskierbare und nichtmaskierbare Interrupts

Maskierbare Interrupts (maskable Interrupts) Wenn durch einen Interrupt das Hardware-Interruptsignal INT=1 gesetzt ist, kann es bei einem Hardwaretest zu Problemen führen. Im unmittelbaren Befehlszyklus nach Aus-führung der Service-Routine wird wieder derselbe Interrupt ausgelöst, auch wenn die Peripherie diesen nicht erwünscht hat. Folglich muss ein zusätzliches Bit untergebracht werden, welches das Interruptsignal unwirksam macht. Ein solches Bit heißt Maskenbit, da das Interruptsignal ,,maskiert`` wird.

Für den Prozessor ist das Interruptsignal, solange es maskiert ist, praktisch unsichtbar.

Das Entfernen (,,Demaskieren``) des Interrupts sollte erst nach Abarbeitung der Ser-vice-Routine erfolgen, da damit zeitgleich auch das Interrupt-Pending-Bit gelöscht wird.

Nicht maskierbare Interrupts (non-maskable Interrupt, NMI) Neben den maskierbaren Interrupts gibt es aber auch solche, die sich nicht maskieren lassen. Es handelt sich um nicht-maskierbare Interrupts (NMI).

NMIs können nicht ausmaskiert werden. Auch die Software besitzt keine Möglichkeit, diese Interrupts zu unterbinden. Sie sind in der Lage, bereits laufende (maskierbare) Interrupts zu unterbrechen. NMIs haben stets die höchste Priorität und sind nur für die schlimmsten Ereignisse konzipiert worden. Ausgelöst werden sie z. B. bei unmittelbar bevorstehendem Stromverlust oder bei Speicher(zugriffs)fehlern (Page Faults).

Die NMIs muss die CPU unmittelbar verarbeiten, da sie bei zeitkritischen Unterbre-chungsanforderungen zum Einsatz kommen.

6.2.2. Software-Interrupts (BIOS-Interrupt)


Literatur und Weblinks:

Interruptliste siehe Buch: „PC Intern - Systemprogrammierung“, Michael Tischer

http://www.fh-wedel.de/~bek/asm/interrupts.html

Über die so genannten BIOS-Interrupts stellt das BIOS bestimmte Funktionen bereit. Diese nutzt das Betriebssystem oder irgend ein Programm durch Aufruf des BIOS-Inter-rupts, ähnlich wie ein Unterprogramm. Bekannt ist etwa der INT 13h, über den man große Festplatten ansprechen kann.

Bild: Schichtenmodell zum MS-DOS Betriebssystem

Software-Interrupts beim PC, z.B.

Interrupt 10h - BIOS (Bildschirm)

Interrupt 16h - BIOS (Tastatur)

Interrupt 21h - DOS (Betriebssystemfunktionen)

BIOS-Interrupt zur Tastaturabfrage: Interrupt 16h

Funktion 00h - Zeichen auslesen Funktion 01h - Prüfen, ob Zeichen vorhanden ist


Bild: Funktion 01h - Prüfen, ob Zeichen vorhanden ist

BIOS-Interrupt zur Bildschirmansteuerung: Interrupt 10h

Funktion 00h - Setzen des Videomodus Funktion 02h - Positionierung des Cursors Funktion 03h - Auslesen der Cursorposition Funktion 09h - Schreiben eines Zeichens / Farbe Funktion 0Eh - Schreiben eines Zeichens

Bild: BIOS-Interrupt 10h, Funktion 03h - Auslesen der Cursorposition

DOS-Interrupts zum Aufruf von Betriebssystemfunktionen: Interrupt 21h


Funktion 02h - Ausgabe eines Zeichens Funktion 09h - Ausgabe einer Zeichenkette Funktion 0Ah - Eingabe einer Zeichenkette Funktion 31h - Programm speicherresident beenden Funktion 3Ch - Datei erstellen Funktion 3Dh - Datei öffnen Funktion 3Eh - Datei schließen Funktion 3Fh - Datei lesen Funktion 40h - Datei beschreiben Funktion 41h - Datei löschen Funktion 42h - Dateizeiger bewegen Funktion 49h - RAM-Speicher freigeben Funktion 4Ch - Programm mit Ende-Code beenden Funktion 4Eh - Ersten Verzeichniseintrag suchen Funktion 4Fh - Nächsten Verzeichniseintrag suchen

Bild: DOS-Interrupt 21h, Funktion 41h - Datei löschen


Bild: DOS-Interrupt 21h, Funktion 4Eh - Ersten Verzeichniseintrag suchen

6.2.3. Interrupt Service Routinen (ISR)

Heutzutage ist es undenkbar, nur eine einzige Interruptanfrage bearbeiten zu können. Es wird nach einem Verfahren gesucht, welches es ermöglicht, auch mehrere unterschiedli-che Interruptquellen zu gestatten. Unabhängig von der Art des Tests (Soft- oder Hard-ware) springt der Prozessor zu einem Programm, das der Interruptquelle zugeordnet ist. Diese Ausnahmeroutine bezeichnet man als die (Interrupt-)Service-Routine, ISR. Eine ISR ist eine Art Unterprogramm, welches sich an einer bestimmten Stelle im Speicher befindet.


Ähnlich laufen auch die Unterprogrammaufrufe durch CALL- und RETURN-Befehle ab. Durch das IRQ-Signal (entspricht dem CALL) wird zu einer bestimmten ISR verzweigt und die Rücksprungadresse zum bisherigen Prozess auf dem Stack abgelegt.

Der Assembler-Befehl RETI (RETURN) bewirkt die Rückkehr. Damit es zu keinen Konflik-ten mit den aktuellen Statusregistern des Prozessors kommt, muss ein Unterprogramm in einer ISR reentrant (wiedereintrittsfest) sein. Konkret heißt das, dass am Anfang der ISR die Statusregister und der Programmzähler auf dem Stack abgelegt werden. Vor der Rückkehr werden diese wieder vom Stack zurückgelesen. Es gibt einen speziellen RETURN-Befehl für Interrupts, den EOI-Befehl (End Of Interrupt).

Nachdem die Service-Routine abgearbeitet worden ist, kehrt der Prozessor wieder an die Stelle im Normalprogramm zurück, das er abgearbeitet hatte, bevor der Interrupt einsetzte. Nun wird das Normalprogramm reaktiviert. Der Aufruf von Interrupts ist daher schematisch gleichbedeutend mit der Quasi-Parallelverarbeitung von Prozessen.

Bild: Quasi-Parallelität von Prozessen.

Werden die Prozesse wie in Abbildung “verschachtelt“ und jeweils “verzahnt“ ausgeführt, so haben wir eine stückchenweise Parallelverarbeitung. Man spricht dann auch von Quasi-Parallelität. Voraussetzung dafür ist allerdings die „Unterbrechbarkeit“ des Prozessors - und damit der einzelnen Prozesse. Eine derart asynchrone Unterbrechung wird als (Pro-zessor-)Interrupt bezeichnet. Asynchron daher, weil der Interrupt nicht synchron, d.h. zu vorhersehbarer Zeit, sondern zu ganz bestimmten externen Ereignissen - und damit asyn-chron - eintrifft.

6.3. Der Programmable Interrupt-Controller 8259 (PIC)

Im Folgenden wird der Programmable Interrupt-Controller 8259 PIC von INTEL vorgestellt, der in der Praxis eine große Rolle spielt.


Bild: Ankopplung des Interruptcontrollers 8259 an die CPU

Peripheriebausteine Timer-Baustein (8253) Paralleles Interface (8255) Serielles Interface (8251) DMA-Controller (8237) Programmierbare Interruptsteuerung (8259)

Bild: Blockschaltbild des PIC 8259

PICs typically have a common set of registers: Interrupt Request Register (IRR), In-Ser-vice Register (ISR), Interrupt Mask Register (IMR). The IRR specifies which interrupts are


pending acknowledgement, and is typically a symbolic register which can not be directly accessed. The ISR register specifies which interrupts have been acknowledged, but are still waiting for an End Of Interrupt (EOI). The IMR specifies which interrupts are to be ignored and not acknowledged. A simple register schema such as this allows up to two distict interrupt requests to be outstanding at one time, one waiting for acknowledgement, and one waiting for EOI.

There are a number of common priority schemas in PICs including hard priorities, specific priorities, and rotating priorities.

Interrupt may be edge triggered or level triggered.

There are a number of common ways of acknowledgeing an interrupt has completed when an EOI is issued. These include specifying which interrupt completed, using an implied in-terrupt which has completed (usually the highest priority pending in the ISR), and treating interrupt acknowledgement as the EOI.

Bild: Stark vereinfachter Aufbau des 8259 PIC Interrupt-Controller von INTEL und dessen Anbindung an die CPU

Sein Aufbau und seine Funktionsweise ist sehr trivial und daher leicht nachzuvollziehen. Aber dennoch verfügt er über alle bisher besprochenen Features. Er kann einzeln bis zu 8 externe Interruptquellen verwalten, kann diese priorisieren, maskieren und erkennt, welche Interrupts gerade hängend (pending) sind und welcher gerade bedient (ge,,service``d) wird.

8259 PIC intern

Bild: codierte Interrupt-Vektornummer

Die codierte Interrupt-Vektornummer ist in den niederwertigen 3 Bits angegeben. Die 5 üb-rigen Bits dienen als Offset des ersten IRQ (IRQ0) in der Vektortabelle, der bei Initialisie-rung des Interrupt-Controllers geändert werden kann („Umbiegen von Interrupts“). Die Vektornummer berechnet sich durch Offset + IRQ-Nummer.

Der Prozessor holt die Interrupt-Vektornummer vom Datenbus und ruft die entsprechende Interrupt-Service-Routine auf. Nach Beenden der Service-Routine wird ein EOI-Befehl an den Controller übergeben. Das ISR-Bit wird dann gelöscht.


In einer anderen Betriebsart, die den Normalfall darstellt, wird direkt beim Ausklingen des zweiten /INTA-Signals das ISR-Bit automatisch gelöscht. Befindet sich noch ein gesetztes Bit im PR, so beginnt dieser Vorgang von vorn. Eine Ausnahme besteht dann, wenn der PR erkennt, dass während der Abarbeitung einer Interrupt-Service-Routine ein weiterer Interrupt höherer Priorität angefordert wird. In diesem Fall wird die Interrupt-Service-Rou-tine - entsprechend dem Abbruch eines Normalprogramms - abgebrochen und die neue Routine aufgerufen.

Kaskadierung von Interrupt-Controllern

Bild: Zwei kaskadierte 8259 PIC Interrupt-Controller

Der ursprüngliche 8-Bit IBM-PC und der PC/XT besaßen nur einen einzigen IC, daher konnten nur 8 Hardware-Interrupts unterstützt werden. Wenig später, mit dem IBM PC/AT 16-Bit ISA-Bus, wurde aus Gründen der Abwärtskompatibilität ein zweiter PIC mit dem be-reits vorhandenen zusammengeschaltet („kaskadiert“).

Da die INTEL 80x86-Prozessorserie aber nur über eine einzige INT-Leitung verfügt, wurde der zweite PIC (PIC2) an den IRQ2-Anschluß des ersten PIC (PIC1) angeschlossen. Folg-lich sind insgesamt 15 Hardware-Interrupts implementiert.

Sind in einem System zwei PIC Interrupt-Controller kaskadiert, so ist einer Master und der andere Slave. Erreichen den Master Interruptanforderungen auf den Leitungen IRi, ändert sich nichts im Vergleich zu einem Single-Betrieb. Wenn eine Anforderung auf die Leitun-gen des Slave eintrifft, dann wird INT signalisiert. INT ist nicht - wie bisher - mit dem Pro-zessor, sondern mit dem Master-PIC verbunden. Im IRR-Register wird das 2. Bit gesetzt und gegen die ISR- und IMR-Register verglichen. Anschließend, wenn nichts dagegen spricht, wird der Slave durch die CASi-Leitungen „aktiviert“. Wenn im folgenden der Pro-zessor sein /INTA-Signal setzt, um den Interrupt zu bestätigen, fühlt sich nur der Slave da-von angesprochen. Der Master „ruht“ währenddessen. Der Rest geschieht analog zum


Single-Betrieb.

Es ist denkbar, bis zu 8 Slaves an einem Master zu betreiben. In diesem Fall können bis zu 64 Interrupts verwaltet werden.

6.3.1. Zusammenspiel zwischen CPU und 8259-Controller

Bild: Der Industry Standard Architecture (ISA)-Bus

Zuallererst stellt sich natürlich die Frage, welche Aufgabe der Interrupt-Controller hat. In der Prozessorbeschreibung wurde bereits auf die Möglichkeit der Programmunterbrechung (Interrupts) durch externe Signale hingewiesen. Dazu besitzt der 80486 zwei Interruptein-gänge. Der eine Eingang (NMI) ist für besonders wichtige Unterbrechungen vorgesehen.


Der andere Eingang (INTR) ist für alle sonstigen Unterbrechungsquellen gedacht. Da es nur einen Eingang gibt, muss dafür gesorgt werden, dass der Prozessor die einzelnen Quellen unterscheiden kann. Eine Möglichkeit wäre, die Quellen vom Behandlungspro-gramm der Reihe nach abfragen zu lassen. Dieses Verfahren kostet aber Zeit und macht daher den eigentlichen Vorteil von Unterbrechungen, die schnelle Reaktion auf Ereignisse, wieder zunichte. Eine andere, schnellere Möglichkeit wird bei Prozessoren der 80x86 Fa-milie verwendet. Während der Interruptbestätigung erwartet der Prozessor die Nummer des Interrupts, der bearbeitet werden soll. Mit dieser Nummer, auch Vektor genannt, wird die Startadresse des Behandlungsprogramms ermittelt (siehe Kapitel 3.5). Damit ist die Unterscheidung der verschiedenen Quellen geregelt. Es gibt aber noch ein weiteres Problem, die Dringlichkeit eines Interrupts. So wollen schnelle Peripheriegeräte, wie z.B. Festplatten, möglichst sofort bedient werden, während die Datenübertragung an einen Drucker sicher nicht so dringend ist. Es wird also eine logische Schaltung benötigt, die dafür sorgt, dass wichtige Interrupts bevorzugt behandelt werden, den verschiedenen Quellen also unterschiedliche Prioritäten zuordnet.

Damit wären die Aufgaben des Interrupt-Controllers bekannt: o Erzeugen des Interruptvektors, entsprechend der anfordernden Quelle o Zuordnen von Prioritäten zu den verschiedenen Quellen..

Der 8259-A Interrupt-Controller erledigt die genannten Aufgaben. Dazu besitzt er acht In-terrupteingänge mit unterschiedlicher Priorität. Wenn die acht Eingänge nicht ausreichen, können mehrere Controller verwendet werden. Dabei wird einer als Master-Controller defi-niert, welcher dem Prozessor Interrupts signalisiert. An den Master-Controller können dann bis zu acht Slave-Controller angeschlossen werden. Dazu werden die Eingänge des Masters mit den Interruptausgängen der Slave-Controller verbunden. Man spricht hier auch von einer Kaskadierung der Interruptcontroller. Zu diesem Thema folgen später noch einige Erläuterungen. Jetzt soll erst einmal der Aufbau und die Funktionsweise des Cont-rollers allgemein beschrieben werden. Das folgende Bild zeigt den schematischen Aufbau des Controllers.


Bild: Blockschaltbild des PIC 8259

Der Baustein besitzt, wie in Abbildung 7.1 zu sehen ist, einen 8 Bit breiten Datenbus zur Verbindung mit dem Prozessor. Die Auswahl des Bausteins erfolgt durch einen LOW-Pe-gel am CS\ -Eingang. Der Baustein belegt zwei Adressen, die über den Pegel am Eingang A0 unterschieden werden. Zum Schreiben von Daten wird der Eingang WR\ auf Low-Pegel gelegt. Eine steigende Flanke überträgt das an den Datenleitungen anliegende Byte in das ausgewählte Register. Soll ein Byte gelesen werden, wird der RD\ - Eingang auf Low-Pe-gel gelegt, ungefähr 200ns später aktiviert der Baustein seinen Bustreiber und legt das angeforderte Byte auf den Datenbus. Der INT-Ausgang wird mit dem INTR-Eingang des Prozessors verbunden. Ein High-Pegel zeigt eine Interruptanforderung an. Die Bestätigung des Prozessors wird dem Controller durch einen Low-Pegel am INTA-Eingang angezeigt. Die mit IR0 bis IR7 bezeichneten Leitungen sind die Interrupteingänge. Die Leitungen CAS0 bis CAS2 sind nur dann von Bedeutung, wenn die Controller kaskadiert werden. Beim Master sind sie Ausgänge, beim Slave Eingänge. Alle Slaves sind über diese Leitun-gen mit dem Master verbunden.

Nun zur Funktionsweise des Controllers. Eine Unterbrechung wird an den acht Eingängen durch den Übergang von Low- zu High-Pegel (steigende Flanke) angefordert. Die Anforde-rungen werden im Interrupt-Request-Register (IRR) gespeichert. Der Inhalt des Interrupt-Mask-Register (IMR) entscheidet nun, ob die Anforderungen beachtet werden oder nicht. In diesem Register ist für jeden Eingang ein Freigabebit vorhanden, dabei entspricht die Bitnummer der Nummer des Eingangs (Bit 7 für IR 7 usw.). Ein Eingang ist gesperrt, wenn das dazugehörende Bit gesetzt ist. Wenn die entsprechenden Eingänge freigegeben sind, wird, sofern mehrere Anforderungen vorliegen (maximal acht möglich) vom Prioritätsdeko-


der die Anforderung mit der höchsten Priorität ermittelt und weitergeleitet. Dann wird ge-prüft, ob zur Zeit ein Interrupt höherer oder gleicher Priorität (gleicher Eingang) behandelt wird. Dazu wird für jeden Eingang ein Bit im Interrupt-In-Service-Register (ISR) geführt, welches gesetzt ist, wenn ein Interrupt von diesem Eingang zur Zeit bearbeitet wird. Ist kein Interrupt gleicher oder höherer Priorität in Arbeit, so signalisiert der Controller dem Prozessor die Anforderung über die INT-Leitung. Diese Anforderung bleibt solange beste-hen, bis der Prozessor durch einen ersten Low-Impuls am INTA-Eingang den Interrupt bestätigt. Durch diesen Impuls wird die Anforderung auf der INT-Leitung zurückgenom-men, der Zustand des Interrupt-Request-Registers eingefroren, das heißt keine jetzt fol-gende Anforderung gespeichert, und das zugehörige Bit im In-Service-Register gesetzt. Durch einen zweiten Low-Impuls auf der INTALeitung fordert der Prozessor danach den Interruptvekor vom Controller an. Nach der Übertragung des Vektors wird die Anforderung im IRR gelöscht und das Register freigegeben.

Sobald die Behandlung des Interrupts beendet ist, muss das dem Controller mitgeteilt werden, damit dieser das entsprechende Bit im ISR zurücksetzt. Dazu wird dem Controller ein spezielles Steuerwort mit Namen EOI (End of Interrupt) übertragen. Dieser löscht dar-aufhin im ISR das Bit mit der höchsten Priorität und damit der letzten erfolgreichen Anfor-derung.

In einem System mit mehreren, kaskadierten Interruptcontrollern laufen prinzipiell die glei-chen Vorgänge ab. Die Slave-Controller durchlaufen alle genannten Phasen bis zur Akti-vierung der INT-Ausgänge. Diese fordern daraufhin Interrupts beim Mastercontroller an, welcher die Anforderung mit der höchsten Priorität an den Prozessor weiterleitet. Wird diese bestätigt (INTA-Impuls), so wählt der Master über die Leitungen CAS0 bis CAS2 den dazugehörenden Slave-Controller aus, der dann mit Erscheinen des zweiten INTA-Impul-ses die entsprechende Vektornummer ausgibt. Damit die ISR-Bits zurückgesetzt werden, muss der EOI-Befehl sowohl an den Master- als auch an den Slave-Controller geschickt werden. Man beachte außerdem, dass sämtliche Anforderungen eines Slaves ignoriert werden, wenn der von diesem verwendete Eingang des Masters nicht freigegeben ist.

Bild: System mit mehreren, kaskadierten 8259A Interruptcontrollern

Die bisherige Beschreibung läßt schon erahnen, dass die Programmierung des 8259A


recht kompliziert ist. Dies liegt zum Einen an den verschiedenen Betriebsarten, (einzelner Controller oder kaskadiert, dann entweder Master oder Slave), außerdem ist der Controller nicht nur für die Prozessoren der 80x86 Familie, sondern auch für die älteren Prozessoren 8080 und 8085 ausgelegt. Zum Anderen belegt er nur zwei Adressen. Bei der Program-mierung müssen die einzelnen Steuer- und Datenbytes daher in einer bestimmten Rei-henfolge übertragen werden. Bei AT-kompatiblen Rechnern unter MS-DOS wird einem die Programmierung allerdings vom Betriebssystem abgenommen. Dadurch sind die verwen-deten Interruptvektoren und die Prioritäten der Eingänge festgelegt.

In einem AT-kompatiblen Rechner sind zwei Controller des Typs 8259A vorhanden. Die Priorität nimmt mit steigender Nummer des Eingangs ab. Der Slave-Controller fordert In-terrupts am IR2-Eingang des Masters an, daher fügen sich seine acht Eingänge mit ihrer Priorität zwischen den Eingängen IR1 und IR3 ein.

Die folgende Tabelle gibt alle Interrupteingänge in absteigender Priorität an. Außerdem wird die Zuordnung der jeweiligen Controllereingänge zu den Interruptleitungen des AT-Rechnersystems und eventuell deren Verwendung angegeben.

Bild: Zuordnung der Interruptleitungen zu den Controllereingängen

Vektortabelle

Die Vektortabelle enthält die Startadressen der Interrupt-Service-Routinen. Die Indizes werden Vektornummern (VN) genannt. Die (Interrupt-)Vektortabelle ist meistens im unte-ren Adreßbereich des Hauptspeichers abgelegt und besitzt die Offset-Adressen 0000 bis 1023. Es ergeben sich 256 verschiedene Vektoreinträge, wenn jeder Eintrag 4 Byte groß ist. Besitzt man bereits die Vektornummer, so kann man daraus die Offsetstartadresse der ISR berechnen:

Offset-Adresse der ISR = Vektornummer (VN) · 4

VN Adresse Belegung

00h 000h - 003h (CPU) Division durch Null


08h 020h - 023h (IRQ0) Timer

09h 024h - 027h (IRQ1) Tastatur

0Ah 028h - 02Bh (IRQ2) [Anschluß von PIC2]

0Bh 02Ch - 02Fh (IRQ3) COM2

0Ch 030h - 033h (IRQ4) COM1

0Dh 034h - 037h (IRQ5) Festplatte

0Eh 038h - 03Bh (IRQ6) Floppy

0Fh 03Ch - 03Fh (IRQ7) Drucker

16h 058h - 05Bh (BIOS) Tastaturabfrage

21h 084h -087h (DOS) DOS-Funktion au-frufen

70h 1C0h - 1C3h (IRQ8) [Echtzeituhr]

71h 1C4h - 1C7h (IRQ9)

72h 1C8h - 1CBh (IRQ10)

73h 1CCh - 1CFh (IRQ11)

74h 1D0h - 1D3h (IRQ12)

75h 1D4h - 1D7h (IRQ13) [80287 NMI]

76h 1D8h - 1DBh (IRQ14) [Festplatte]

77h 1DCh - 1DFh (IRQ15)

Bild: Vektortabelle beim IBM-PC/AT

Wie in der Vektortabelle eines üblichen IBM-PC/AT in Abbildung zu ersehen ist, befinden sich die Startadressen der ISR, die sich in erster Linie um die Überwachung des System kümmern (u.a. Traps) unter den obersten Tabellenplätzen. Anschließend folgen diejeni-gen, die für bestimmte Hardware-Komponenten reserviert sind (u.a. FPU, MMU). Bei je-dem Auftreten eines maskierbaren5 Interrupts prüft der Prozessor zunächst, ob das Inter-rupt Enable Bit (IEB) in seinem Statusregister gesetzt ist. Erst wenn dies der Fall ist, gibt der Prozessor das INTA-Signal (Interrupt Acknowledge) an den Interrupt-Controller durch (vgl. Abschnitt ).


Bild: /INTA-Impulse zur Übertragung der Interrupt-Vektoradresse


6.3.2. Moderne Interruptverfahren

Bisher: IRQ-Signalisierung und -Verarbeitung

Jetzt: IRQ-Übertragug

Message signaled Interrupts (MSI) beim PCI-X System

Interrupt-Pakete mit Routing-Fähigkeiten (Hyper-Transport)

6.4. CPU interne Bearbeitung von Interrupts und ISRs

6.4.1. Der normale Programmfluss

Für alle Prozessoren gilt folgender Programmablauf

Bild: Allgemeiner Programmablauf eines Prozessors

Prozessorstart = Eintritt in diese Schleife

Befehlszähler

zeigt auf den nächsten Befehl im Speicher

Befehlszählereinstellung ist Kern der Programmsteuerung

Befehlszähler folgt normalerweise den hintereinanderliegenden Befehlen im Speicher

Befehlszähler kann auch durch Maschinenbefehle eingestellt werden, z. B. durch programmsteuernde Sprung- und Verzweigungsbefehle (JMP etc.)

Befehlszähler kann auch durch Eingriffe von außen verändert werden, z. B. durch Anforderung an die Programmsteuerung von außen (Interrupt); aber: Programmunterbrechung erfordert Zwischenspeicherung des Befehlzählerstandes


Start

Befehlszählerzurücksetzen

Maschinenbefehlholen

Befehlszähler gemäßSchrittweite einstellen

programmsteuernderMaschinenbefehl?

Maschinenbefehl gemäßOperation ausführen

Befehlszähler gemäßMaschinenbefehl einstellen

Interrupt?

- aktuellen Befehlszählerstand retten- Befehlszählerstand gemäß Interrupt einstellen

Umfasst auch Rücksprungvon Interrupt d.h. Restaurieren des Befehlszählers

nein

nein

ja

ja

Bild: Programmablauf eines Prozessors im Detail

Die Absicht eines oder mehrerer I/O-Prozesse, Prozessorleistung zu erhalten, muss erst beim Prozessor angemeldet werden. Der Vorteil: Die Peripherie wird solange vernachläs-sigt (ignoriert), bis ein I/O-Gerät für einen Datentransfer bereit ist und dies dem Prozessor durch eine Interrupt-Anforderung (Interrupt-Request, IRQ) wissen läßt. Interrupts werden allgemein unterteilt in:


o Prozessorsynchrone Interrupts. Sie werden durch eine Folge konkreter Be-fehlsausführungen vom Prozessor selbst ausgelöst, man nennt sie auch Traps. Sie erfolgen selbstverständlich synchron zum Prozessortakt. Bsp.: Division durch Null.

o Prozessorasynchrone Interrupts. Sie werden von der Peripherie ausgelöst. Wenn man allgemein von Interrupts spricht, dann sind damit die prozessorasynchronen Inter-rupts gemeint. Mit dieser Sorte von Interrupts wollen wir uns im folgenden beschäfti-gen. Bsp.: Controller-Interrupt.

Der Prozessor wird beim Auftreten eines Interrupts dazu veranlaßt, sein aktuell laufendes Programm (Normalprogramm) zu unterbrechen. Gäbe es nur ein Programm, welches auf jeden Interruptaufruf reagieren soll, so hätten wir gar kein Problem, dieses zu ermitteln. In der Praxis gibt es aber eine Vielzahl solcher Programme, deshalb muss nach Eingang des IRQs getestet werden, welches Programm anstelle des Normalprogramms auszuführen ist. Gehen wir zunächst davon aus, dass es nur einen einzigen IRQ gibt. Dazu muss die Ablaufsteuerung des Fetching (Holephase des Prozessors) um eine Interrupt-Erkennung erweitert werden. Ein IRQ kann, wie wir oben schon festgehalten haben, asynchron, d.h. zu beliebiger Zeit während eines Prozessorzyklus eintreffen. Damit der Prozessor nicht voll und ganz aus der Rolle gebracht wird, wird die Interruptanforderung zunächst zwi-schen gespeichert - man sagt, sie ist hängend (pending). Das Testen des peripheren Sig-nals wird bei neueren Prozessoren hardwareseitig vom Mikroprogramm eines jeden Be-fehls übernommen. Hierbei wird ein Statusbit abgefragt, das Interrupt-Pending-Bit. Zur Implementierung ist also eine Interruptleitung (INT) nötig, die das Peripheriegerät über ei-nen Interrupt-Controller mit dem Prozessor verbindet. Hinzu kommt noch eine Quittungs-leitung (INTA, Interrupt Acknowledge), die den Interrupt bestätigt.

Die Alternative zu dem Hardware-Test ist ein Software-Test, der über PIO den Zustand der entsprechenden Peripherieregister abfragt (Polling). Die speziellen Steuerleitungen zum Prozessor sind dann zwar nicht nötig, aber ein solcher Interrupt-Handler ist wegen den in Abschnitt bereits genannten Performance-Gründen nicht angebracht.

6.4.2. Ablaufsteuerung zur Behandlung von Ausnahmesituationen

Programmunterbrechungen können durch Signale aus der Rechnerumgebung (z.B. vom gesteuerten Prozess) ausgelöst werden, um quasi "die Aufmerksamkeit" des Rechners auf sich zu lenken. Insbesondere auf dringende, aber relativ selten auftretende Ereignisse können so die entsprechenden Programme (Interrupt Service Routinen) schnell reagieren. In der Regel führt die Ablaufsteuerung nach der Beendigung des gerade ausgeführten Befehls die Programmunterbrechung durch und setzt nach der Abarbeitung der Interrupt Service Routine (ISR) das unterbrochene Programm fort.

Die Aufgaben der Interruptbehandlung im Einzelnen:

a) Aufnehmen und Überprüfen der Unterbrechungsanforderung: Im einfachsten Fall hat das Unterbrechungswerk nur eine einzige Eingangsleitung für die Unterbrechungsanforderungen. Diese führt auf ein Flip-Flop, das durch ein Anforderungssignal auf 1 gesetzt wird und bei Bedienung des Interrupts sofort wieder gelöscht werden muß um evtl. weitere Interrupt-Anforderungen aufnehmen zu können. Dieses FF ist notwendig, um die zu beliebigen Zeitpunkten ankommenden Interrupt-Anforderungen (Interrupt-Request) so lange zu speichern, bis sie vom Leitwerk am Ende der Befehlszyklen abgefragt werden.


Häufig darf jedoch eine Interrupt-Anforderung nicht sofort zur Unterbrechung führen, z.B. während der Ausführung zeitkritischer Programmabschnitte. Eine einfache Möglichkeit besteht in der "Maskierung" des Signals mit Hilfe eines Masken-FF's und eines Gatters. Nur wenn das Masken-FF gesetzt ist, führt eine "anstehende" Unterbrechungsanforderung auch zu einem Interrupt. Das Masken-FF kann i.a. durch Maschinenbefehle gesetzt und gelöscht werden ("enable" bzw. "disable interrupt").

b) Identifizierung des Interrupt-Verursachers: Typische Anwendungen mit mehreren Quellen für Interrupt-Anforderungen verlangen, daß für jedes Signal auch ein spezifisches Unterbrechungs-Bearbeitungs-Programm (ISR = Interrupt Service Routine) vorhanden ist, da ja auf jedes Signal anders zu reagieren ist. Damit ergibt sich das Problem der Interrupt-Identifizierung als Voraussetzung für die Zuordnung der richtigen ISR und für das Löschen des richtigen Interrupt-Anforderungs-Flip-Flops. Die beiden wichtigsten Grundprinzipien der Interrupt-Identifizierung sind:

Polling: Der Interrupt-Verursacher kann sich nicht selbst zu erkennen geben; am Prozessor erscheint lediglich das Anforderungssignal und es ist die Aufgabe des Interrupt-Bearbeitungs-Programms, über eine Kette von Abfragen an die in Frage kommenden Peripherie-Bausteine, den aktuellen Interrupt-Verursacher herauszufinden. Mit "Abfragen" ist hier das Lesen der Statusregister der Peripheriebausteine gemeint, in denen die Tatsache der Interrupt-Anforderung jeweils in einem bestimmten gesetzten Bit (Interrupt-Request-Bit) vermerkt ist.

Interrupt-Vectoring: Der Interruptverursacher liefert (im Zuge der Bussequenzen bei der Interrupt-Annahme durch den Prozessor) einen "Kenn-Code" mit ab (meist über den Datenbus), an dem der Prozessor erkennen kann, um welchen Interrupt es sich handelt. Dieser sogen. "Interrupt-Vektor" wird i.a. gleich als (indirekte) Startadresse der zugehörigen ISR verwendet. Damit entfällt das zeitraubende Abfragen, die sogenannte Interrupt-Reaktionszeit wird kürzer.

c) Vorrangsteuerung der Interruptverursacher: Nicht alle Interrupts sind mit der gleichen Dringlichkeit zu bearbeiten; so muß z.B. die Interrupt-Anforderung, die den Zusammenbruch der Netzspannung anzeigt, vorrangig behandelt werden gegenüber einer Interrupt-Anforderung, die lediglich zur Übernahme eines Datenwortes von einer Eingabeschnittstelle auffordert.

d) Retten und Rückspeichern des Prozessorzustandes: Wenn eine Programmunterbrechung ausgeführt werden soll, so muß auf jeden Fall der Zustand des Prozessors gerettet werden. Denn das Interrupt-Service-Programm benutzt ja ebenfalls den Prozessor und verändert dabei dessen Zustand. Soll


anschließend das unterbrochene Programm fortgesetzt werden, so ist es unbedingt nötig, vorher den Zustand wieder herzustellen, wie er bei Auftreten der Unterbrechung herrschte. Die Prozessorzustände, die während einer Befehlsausführung durchlaufen werden, sind nur sehr aufwendig zu beschreiben (z. B. mitten in einer Multiplikation). Entsprechend groß wäre der Aufwand zur Rettung des Prozessorzustandes, wenn man Unterbrechungen mitten im Befehlszyklus zuließe. Man läßt deshalb Unterbrechungen i. a. nur am Ende eines Befehls zu, denn dann ist der Prozessorzustand vollständig durch den Inhalt der Prozessorregister definiert. In einer typischen Interrupt-Service-Routine werden die Inhalte von Prozessor-Re-gistern verändert. Aber selbst wenn keine derartigen Befehle in der ISR vorkommen, so müssen doch zumindest zwei Register gerettet werden: der Programmzähler und das Prozessor-Status-Register, denn die Inhalte dieser Register ändern sich in jedem Fall. Man bezeichnet diese beiden Register auch als "Zustandsvektor". Die einfachste Möglichkeit, den Zustandsvektor zu retten, besteht darin, ihn in bestimmte reservierte Speicherzellen zu schreiben, und ihn von dort nach Beendigung der ISR wieder zu lesen. Dies hat den offensichtlichen Nachteil, daß keine Verschachtelung (Nesting) von Programmunterbrechungen möglich ist, d.h. man müßte das Unterbrechen einer ISR verbieten, weil sonst der gerettete Zustandsvektor überschrieben würde. Wesentlich besser eignet sich zum Retten des Zustandsvektors ein sogenannter Kellerspeicher (engl. stack, oder auch LIFO = last in first out). Das Stackprinzip kann hardwaremäßig realisiert sein (spezielle Chips) oder in einem reservierten Bereich des normalen Arbeitsspeichers nachgebildet sein. Zu diesem Zweck existiert ein Zeigerregister, das immer den letzten Eintrag im Stack adressiert (Stackpointer zeigt immer auf den "Top of Stack", d.h. auf den letzten Eintrag). Mit jeder neuen (geschachtelten) Programmunterbrechung wächst der Kellerspeicher um die entsprechenden Einträge, mit jedem Rücksprung in ein vorher unterbrochenes Programm reduziert er sich wieder entsprechend, so daß das zuletzt unterbrochene Programm nach Beendigung des laufenden wieder aufgenommen wird. Der Stack wächst und schrumpft mit jedem Eintreten/Verlassen von ISRs, man sagt, der Stack "pulsiert". Häufig müssen außer den beiden o.g. Registern (PC und Prozessor-Status-Register) auch noch andere gerettet und rückgespeichert werden, nämlich dann, wenn sie von der ISR verändert werden. Auch hier bringt die Verwendung eines Stacks die gleichen Vorteile wie oben erwähnt. Da diese Register jedoch nicht immer gerettet werden müssen besteht hier die Möglichkeit, sie entweder genau wie den Zustandsvektor per Hardware (d.h. per Ablaufsteuerung) zu retten oder per Maschinenbefehl(e), also programmgesteuert. Während bei der Hardware-Lösung sämtliche Register gerettet werden müssen (sie "weiß" je nicht, welche es sein müssen), kann die programmierte Lösung sich auf genau die Register beschränken, die in der ISR verändert werden (der Programmierer weiß welche - hoffentlich!). Die sicherere und meist auch schnellere, jedoch auch aufwendigere Methode ist die Hardware-Lösung.

Die Notwendigkeit, bei der Ausführung einer Programmunterbrechung zunächst den Zustand des unterbrochenen Programms zu retten, kann also eine Reihe von Transportoperationen benötigen; vom Moment des Eintreffens der Unterbrechnungsanforderung vergeht daher einige Zeit, die Interrupt-Reaktionszeit, bis der erste produktive Befehl der ISR ausgeführt


wird. Diese Reaktionszeit setzt sich aus den folgenden Komponenten zusammen:

T1: Durchschaltezeit (der Anforderung bis zur Unterbrechungsanmeldung) aufgrund einer gesetzten Sperre (z.B. auch dann, wenn gerade eine Interrupt-Service-Routine bearbeitet wird). Diese Zeit kann u.U. recht lang sein!

T2: Wartezeit bis zur Beendigung des gerade ausgeführten Befehls (maximal die des längsten vorkommenden Befehls)

T3: Zeit zum Retten des Programm-Zustandes und Laden des Unterbrechungs-Vektors. Selbst wenn die Durchschaltung der Anforderung unmittelbar erfolgt (T1 = 0, weil keine Sperre gesetzt ist), kann die Summe von T2 und T3 für zeitkritische Echtzeit-anforderungen doch noch zu groß sein.

6.4.3. Ziel: Änderung des normalen Programmflusses

vorübergehende Unterbrechungen und Einfügen einer Prozedur (Interrupt Service Routine)

verschachtelte Ausnahmebehandlung

bei schwerem Fehler (division by zero) Abbruch -> Rückkehr in einen definierten Zu-stand

Behandlung einer Ausnahmesituation, d.h. Unterbrechung des laufenden Programms nach Beenden des laufenden Befehls. Ausführen einer Interrupt-Serviceroutine (ISR):

Abspeichern des Programmstatus

Setzen BZ auf feste oder vektorisierte Adresse

Sperren weiterer Interrupts

Auslösung durch Flanke oder Pegel

Lokalisierung durch Polling oder HW-Vektor (z.B. bei 8080)

Abarbeiten der ISR

Restaurieren des Programmstatus und Fortsetzung des Programms

6.4.4. Wo stehen die Startadressen?

unter reservierten Adressen (6800: Reset $FFFE - $FFFF, Interrupt $FFFC - $FFFD)

in einer verschiebbaren Tabelle (Interrupt Vektor Tabelle) im Hauptspeicher (typ. für 32-bit-Prozessoren);

in RISC-Prozessoren enthält die Tabelle statt der Adressen Befehlsfolgen zum La-den der Adresse mit anschließendem Sprung


6.4.5. Interne Unterbrechungsursachen

Software-Interrupt, Supervisor-Call

SWI n (INT n, SVC n) (n - Parameter zur Auswahl der Behandlungs-Routine; Bsp. für PC INT$21 Rückkehr zu DOS)

ähnlich einem Prozedur-Aufruf nur, dass die Aufrufadresse durch das System und nicht durch das Programm bereitgestellt wird; genutzt zum Ansprechen peripherer Komponenten und Betriebssystemdienste; Ziel ist die Schaffung eindeutiger Soft-wareschnittstellen (vgl. Softwarelayer BIOS, DOS, COMMAND/WINDOWS)

Prozessoren mit mehreren Privilegebenen Übergang vom Nutzer- in den Betriebs-system-Modus

Ausnahmesituationen bei der Befehlsabarbeitung (instruction exceptions, traps)

a) Einfügen einer Prozedur

o Einzelschritt-Modus, Einzelschritt-(single step) Flag gesetzt: Einfügen einer Pro-zedur nach jedem abgeschlossenen Befehl; genutzt für Inbetriebnahme, Test und Fehlersuche (Debugging)

b) Beseitigung der Ursache und Befehlswiederholung

o Seitenfehler (page segment fault): adressiertes Befehlswort, adressierte Daten nicht im Speicher; Behebung: laden der Seite; Problem: rückgängig machen nachfolgender, bereits gestarteter Befehle

o kurze Pipeline

Bild: Seitenfehler-Behandlung in Prozessoren mit Pipeline-Verarbeitung

c) Abbruch der aktuellen Aufgabe und Fortsetzung ab einer definierten Adresse

o ungültiger Befehlscode

o privilegierte Operation im Nutzermodus

o Verletzung der Zugriffsrechte auf den Speicher, Überschreitung der Speicher-grenzen

o Division durch Null, Überlauf, Überschreitung von Feldgrenzen


6.4.6. Externe Unterbrechungsursache

Unterbrechungsursachen

Reset: Initialisieren aller Register, Laden einer Anfangsadresse

NMI, nicht unterbrechbarer Interrupt: wird zur Fehlerbehandlung genutzt, z. B. zum Anschluß eines Watchdogs

Bild: Watchdog: Überwachung, ob das Programm innerhalb bestimmter Zeitbereiche vorgegebene Aufgaben erfüllt

INT, maskierbarer Interrupt: Einsatz zur Kommunikation mit peripheren Einheiten

o Maskierung deshalb, weil - der Start einer Interrupt-Behandlung nicht unterbrochen und ebenso - Aufgaben mit Echtzeitansprüchen nicht unterbrochen werden dürfen

o Interrupt-Freigabe durch Flags im Statusregister - Interrupt-(I-) Flag: Interrupt-Annahme blockiert/erlaubt (dissabled/enabled) - Interrupt-Maske (0xFF23): mehrere Interrupt-Eingänge zur Codierung einer Prioritätsebene

Problem: INT-Unterscheidung mehrerer Interrupt-Quellen

Überprüfen des/der Interrupt-Flags

wenn Annahme erlaubt, signalisieren der Interrupt-Annahme über den Steuerbus an alle Komponenten

Komponente mit Forderung legt einen Vektor (typ. 8 bit) auf den Datenbus

der Prozessor liest den Vektor und wählt entsprechend die Startadresse

Problem: INT-zeitgleich mehrere Anforderungen

Prozessor kann nur eine Ausnahmesituation zu einem Zeitpunkt annehmen und bear-beiten

Prioritätslogik: zentral/dezentral


Bild: Daisy-Chain und Prioritäts-Decoder beim Motorola 68000

Polling: gesteuert durch Software fragt der Prozessor nacheinander alle potentiellen Interrupt-Quellen ab

Abfrage: Geräte besitzen Interrupt-Flag-Register, die vom Prozessor adressiert und gelesen werden können, ein Bit eines Registers ist entweder gesetzt oder rückgesetzt, wenn Interrupt angefordert wird

Nachteil: relativ hohe Anzahl der Verarbeitungsschritte für die Interrupt-Annahme

6.5. Das MSP430 Interruptsystem

Die Interrupt-Vektortabelle steht meist am Ende der Speicherorganization eines Em-bedded Systems und beinhaltet die Zeiger auf die Interrupt Service Routinen (ISR), d. h. in dieser Tabelle befinden sich die Anfangsadressen der Unterbrechungsroutinen.

Bild: Interrupt Priority

Die Anordnung innerhalb der Tabelle ist für alle Programme der MSP430-Familie immer gleich. Der Inhalt, d. h. die Anfangsadresse der Interruptroutine kann jedoch un-


terschiedlich sein und hängt von dem restlichen Anwendungsrprogramm ab.

Die Interrupt-Vektoren liegen im Adressbereich 0FFE0H bis 0FFFEH, also am Ende des ROM-Speichers. Jeder Vektor enthält eine 16-Bit-Adresse der zugehörigen Interrupt-Service-Routine.

Der MSP430 unterstützt 16 Ausnahmevektoren (exception vectors), angefangen bei 0xFFE0 bis zu 0xFFFF.

Es existieren 14 maskierbare Interrupts, die den On-Chip-Peripherieeinheiten zugewiesen sind (siehe Bild Interrupt Vektor Tabelle). Alle maskierbaren Interrupts können ab-geschaltet werden, indem das GIE Bit (Global Interrupt Flag) im Statusregister gelöscht wird.

Vector Address

Priority '11xx and '12xx '13x and '14x '3xx '4xx

0xFFE0 Lowest Unused Unused Port 0 Basic Timer

0xFFE2 1 Unused Port 2 Basic Timer Port 2

0xFFE4 2 Port 1 USART1 Tx Port 1 USART1 Tx ('44x only)

0xFFE6 3 Port 2 USART1 Rx Port 2 USART1 Rx ('44x only)

0xFFE8 4 Unused Port 1 Timer / Port ('32x and '33x)

Port 1

0xFFEA 5 ADC10 Timer A ADC ('32x and '33x) / Timer/Port ('31x)

Timer A

0xFFEC 6 USART0 Tx ('12xx only)

Timer A USART Tx Timer A

0xFFEE 7 USART0 Rx ('12xx only)

ADC USART Rx ADC ('43x and '44x only)

0xFFF0 8 Timer A USART0 Tx Timer A USART0 Tx ('43x and '44x only)

0xFFF2 9 Timer A USART Rx Timer A USART0 Rx ('43x and '44x only)

0xFFF4 10 Watchdog Timer Watchdog Timer Watchdog Timer Watchdog Timer

0xFFF6 11 Comparator Comparator Comparator Comparator

0xFFF8 12 Unused Timer B Dedicated I/O Timer B ('43x and '44x only)

0xFFFA 13 Unused Timer B Dedicated I/O Timer_B ('43x and '44x only)

0xFFFC 14 Oscillator / Flash / NMI

Oscillator / Flash / NMI




0xFFFE 15

Highest

Hard Re-set/Watchdog




Bild: Interrupt-Vektoren in der MSP430 Mikrocontrollerfamilie

Die ersten 14 Interrupts können maskiert, d. h. individuell ab- oder zugeschaltet werden durch das enable/disable Flag in den Peripherieregistern der Hardwaremodule.

Die letzten beiden Interrupts sind nichtmaskierbar: 0xFFFC ist der NMI (non maskable interrupt) Vektor und 0xFFFE ist der Resetvektor.

Zu diesen gehören:

Der RST/NMI Pin kann dazu konfiguriert werden, dass er einen NMI statt auslöst, an-statt an dem Prozessor das Reset-Signal auszulösen und einen Neustart zu pro-vozieren, wenn die NMI-Leitung auf Low gezogen wird.

Flash Zugriffsverletzung (access violation)

Ein Fehler im Oszillator tritt auf. Die neueren Modelle des MSP430 benutzen einen auf den Chip integrierten Taktgenerator namens FLL (frequency locked loop). Dieser kann programmiert werden um einen weiten Beeich an Kerntaktfrequenzen zu generieren, die an den externen Quarz (in der Regel ein 32kHz Quarz, wie er auch in Uhren zu finden ist) phasengebunden gekoppelt ist. Wenn die Frequenzabstimmung die äußersten Limits tangiert, und die FLL-Schaltung nicht mehr adaptieren kann, wird ein Fehler im Oszillator bekannt gegeben.

Andere MSP 430 Modelle benutzen ein anderes Oszillator Modul. Hier wird das Fehlerflag gesetzt, wenn der Oszillator überhaupt nicht mehr schwingt. Die CPU kann dann versuchen auf einen 2. Oszillator umzustellen, sollte dieser Fehlerfall eintreten.

Quelle

Flag System Adresse Priorität

- Power-Up - ext. Reset - Watchdog

WDTIFG Reset 0FFFEh highest 15

NMI Ozillator-fehler

NMIIFG OFIFG

Non-maskable (non)maskable Mehrfachquelle

0FFFCh 14

P0.0 P0IFG.0 maskable 0FFFAh 13

P0.1 P0IFG.1 maskable 0FFF8h 12

maskable 0FFF6h 11

Watchdog timer WDTIF G maskable 0FFF4h 10

maskable 0FFF2h 9


maskable 0FFF0h 8

maskable 0FFEEh 7

maskable 0FFECh 6

ADC ADCIFG maskable 0FFEAh 5

Timer/Port maskable 0FFE8h 4

maskable 0FFE6h 3

maskable 0FFE4h 2

Basic Timer BTIFG maskable 0FFE2h 1

Port 0 Bits 2..7 P0IFG.2 7 maskable Mehrfachquelle

0FFE0h 0, low

Bild: Maskable and non-maskable Interrupts

6.6. Behandlung eines Interrupts beim MSP430

Wenn ein Interrupt auftritt, wird zunächst der Befehlszähler (PC, program counter) von der nächsten Instruction und das Prozessor Status Register (SR) auf den Stack geschoben.

Der Ablauf des Interrupts ist wie folgt:

Push PC auf den Stack.

Push SR auf den Stack.

Lösche das Statusregister (SCG1, C, N, V und Z, mit Ausnahme von SCG0), Stelle die Interrupts (GIE) und das Energiemanagement (CPUOff, OSCOOff) ab.

Wenn nur eine Interruptquelle vorliegt, wird das entsprechende Interrupt Request Bit wieder zurückgesetzt. (Gibt es mehrere Interruptauslöser, wird er beibehalten um von der Software abgefragt werden zu können. Wenn NMI vorliegt, werden die enable Bits für die 3 NMI Quellen gelöscht.)

Der Interrupt Vektor mit der höchsten Priorität aller aktivierten Interrupts wird in den Programm Counter der CPU geladen.

Führe die ISR (Interrupt Handler) aus

RETI (return from interrupt) restauriert den alten Zustand des Statusregisters und der Programm Counters.

Mann kann Interruptbehandlungsroutinen verschachteln, indem man innerhalb einer Interrupt Service Routine die gegenwärtige Interruptquelle deaktiviert und das GIE Bit wieder auf 1 setzt.

Beachte: Es gibt keine Ausnahmebehandlungsmöglichkeiten für interne Prozessorfehler wie „divide by zero“ oder einem Adressierungsfehler. Jedoch wird ein Reset ausgelöst, wenn man in nicht beschreibbare Peripherieregister schreibt.


Bild: Interrupt Processing

Bild: Interrupt-Verschachtelung (Interrupt Nesting)

Use of InterruptsInterrupts are the best way to control program flow based on events.


Unfortunately, they are also the best way to lose program flow control, based on events. Some guidelines and suggestions for most effective use of interrupts are:

Always use the “reti” (return of interrupt)-instruction. If the code manually re-enables interrupts and performs a jump or branch to a common location, the stack will eventually overfill RAM space.

Make sure all unused interrupts are disabled.

Generally speaking, your code should not need to manually tinker with the GIE bit via the EINT and DINT instructions. However, do not hesitate to turn interrupts on and off individually. Only keep the locally necessary interrupts enabled at each state of the controller code (e. g. only have the USART interrupts enabled while transmitting or receiving data).

Plan for the unplanned. Send disabled, and even nonexistent, interrupts to an “Invalid Interrupt” label, with some code to track the interrupt, and a reti instruction. Theoretically, if you followed the previous suggestion, this shouldn’t matter that much. Out here in the real world, though, it quite often does. We are all human, and sometimes we humans program incorrect constants into peripheral control registers or interrupt enable flags. If the code tracks and reports which interrupt was triggered, finding the source of the bug can often be done in minutes. If the code doesn’t take this into account, the program counter will simply go wandering off the reservation, and your debugging time could stretch into days. This step is almost free, in terms of time and space to program, but it makes your code significantly more robust.

Another way to handle the unexpected source interrupt is to put onlya reti instruction at the Invalid Interrupt label. I recommend against this approach, as it masks the problem, rather than fixing it.

Interrupt handling in C is a bit different. Simply write the ISR (interrupt service routine), and any C compiler will handle the vectoring, pushing and popping of CPU registers it uses, and the return instruction. I still use a standard template for interrupts (see Example: C Language Interrupt Handler Function Template). A few interesting notes on this example:

o There is no interrupt routine for the POR (0FFFEh). The com-piler should handle this automatically, and vector to your main().

o All of the interrupt routines consist of an infinite, do-nothingloop. Remember, this is simply a starting point. I will typicallywrite new routines for the interrupts I am using, and leave theendless loop in the others. That way, when I am testing code withan emulator or JTAG debugger, unexpected interrupts becomevery easy to identify. After the code is performing as expected, Ichange those eternal loops to something more structured andsensible.

o The interrupt function structure in this example is for the IARtools that I use. It can vary from one compiler to the next.

Example: C Language Interrupt Handler Function Template

(MSP430F14x Family)

interrupt [0x02] void dummy_Port2_Interrupt(void)


{ while (1)

{} }

interrupt [0x04] void dummy_USART1tx_Interrupt(void) { while (1) {} }

interrupt [0x06] void dummy_USART1rx_Interrupt(void) { while (1) {} }

6.7. Binden eines Interrupts an eine Interrupt Service Routine

(entnommen aus: IAR C Compiler Reference manual)

The MSP430 microcontroller supports many interrupt sources. For each interrupt source, an interrupt routine can be written. Each interrupt routine is associated with a vector number which is specified in the MSP430 microcontroller documentation from the chip manufacturer.

The iochip.h header file, which corresponds to the selected derivative, contains prede-fined names for the existing exception vectors.

To define an interrupt function, the __interrupt keyword and the #pragma vector directive can be used, for example:

#pragma vector=0x14__interrupt void my_interrupt_routine()

{

/* Do something */

} Note: An interrupt function must have the return type void, and it cannot specify any parameters.

When an interrupt function is defined with a vector, the processor interrupt vector table is populated. It is also possible to define an interrupt function without a vector. This is useful if an application is capable of populating or changing the interrupt vector table at runtime. See the chip manufacturer’s MSP430 microcontroller documentation for more information about the interrupt vector table.

The interrupt vector is the offset into the interrupt vector table.

For the MSP430 microcontroller, the interrupt vector table always starts at the address 0xFFE0.

6.8. Interrupt Vektoren (aus msp430x44x.h )


// entnommen aus msp430x44x.h

/************************************************************

* Interrupt Vectors (offset from 0xFFE0)

************************************************************/

#define BASICTIMER_VECTOR (0 * 2u) /* 0xFFE0 Basic Timer */

#define PORT2_VECTOR (1 * 2u) /* 0xFFE2 Port 2 */

#define USART1TX_VECTOR (2 * 2u) /* 0xFFE4 USART 1 Transmit */

#define USART1RX_VECTOR (3 * 2u) /* 0xFFE6 USART 1 Receive */

#define PORT1_VECTOR (4 * 2u) /* 0xFFE8 Port 1 */

#define TIMERA1_VECTOR (5 * 2u) /* 0xFFEA Timer A CC1-2, TA */

#define TIMERA0_VECTOR (6 * 2u) /* 0xFFEC Timer A CC0 */

#define ADC_VECTOR (7 * 2u) /* 0xFFEE ADC */

#define USART0TX_VECTOR (8 * 2u) /* 0xFFF0 USART 0 Transmit */

#define USART0RX_VECTOR (9 * 2u) /* 0xFFF2 USART 0 Receive */

#define WDT_VECTOR (10 * 2u) /* 0xFFF4 Watchdog Timer */

#define COMPARATORA_VECTOR (11 * 2u) /* 0xFFF6 Comparator A */

#define TIMERB1_VECTOR (12 * 2u) /* 0xFFF8 Timer B CC1-6, TB */

#define TIMERB0_VECTOR (13 * 2u) /* 0xFFFA Timer B CC0 */

#define NMI_VECTOR (14 * 2u) /* 0xFFFC Non-maskable */

#define RESET_VECTOR (15 * 2u) /* 0xFFFE Reset [Highest Priority] */

#define UART1TX_VECTOR USART1TX_VECTOR

#define UART1RX_VECTOR USART1RX_VECTOR

#define UART0TX_VECTOR USART0TX_VECTOR

#define UART0RX_VECTOR USART0RX_VECTOR

/************************************************************

6.9. Beispiele und Übungen zum Interruptsystem MSP430I

6.9.1. Anwendungsbeispiel I



Bild: USARTx functional block diagram



Bild: USARTx functional block diagram



// Das Programm sendet das über die V24-Schnittstelle empfangene Zeichen wieder zurück

// (Echo Betrieb).

#include <msp430x44x.h>

void init_uart(void)

{

// Einstellung der Baudrate

// Modulationsregister U1MCTL

U1BR0= 0x03;

U1BR1= 0x00;

U1MCTL= 0x4A;

U1TCTL=0x10; // SSEL0 defined in msp430x44x.hs

U1CTL=0x10;

// Module Enabel Register

ME2 |= 0x30;

P4SEL |= 0x03; // Bit 0 und 1 == 1 -> Peripheral module function

P4DIR |= 0x01; // Bit 0 Output (Transmit)

}

void main(void)

{

char zeichen; // Speicher für empfangenes Zeichen

WDTCTL = WDTPW + WDTHOLD; // Stop watchdog timer

init_uart(); // Serielle Schnittstellenparameter setzen

while(1)

{

while ( (IFG2 & URXIFG1) ==0 ); // Warten, bis Zeichen eintrifft; Interrupt Flag Register 2 lesen

zeichen = RXBUF1; // empfangenes Zeichen im Speicher lesen

while ( (IFG2 & UTXIFG1) ==0 ); // Ist Transmitter frei für ein neues Datum? ; IFG2 lesen

TXBUF1 = zeichen; // Zeichen in Transmit Buffer schreiben

}

} // end main

// Interruptroutine serieller Empfang

#pragma vector = UART1RX_VECTOR

__interrupt void usart1_rx (void)


{

IE2 = IE2 ^ URXIE1; // Interrupt für seriellen Empfang abschalten

( (char*) buffer ) [buffer_counter++] = RXBUF1; // Zeichen in Puffer lesen und

// Pufferzähler erhöhen

If ( RXBUF1 == 0x0d ) // Abfrage ob Return gesendet wurde

{

flag=1; // Flag zum Auslesen des Puffers setzen

( (char*) buffer) [buffer_counter] = 0; // Nullcharakter ans Ende vom String anfügen

}

else // kein Return gesendet

{ if ((buffer_counter+1)%10 == 0) // Ist Puffer voll?

{

// können weitere 10 Byte an buffer anhängt werden?

If ( (buffer_tmp = realloc (buffer, buffer_counter+1+10) ) == 0)

flag=1; // wenn nicht möglich, dann Speicher auslesen aktivieren

}

}

If (flag==0)

IE2 = IE2 | URXIE1; // Interrupt für Empfang freigeben,

// wenn nicht der Puffer ausgelesen werden soll

}

6.9.2. Anwendungsbeispiel II

//*************************************************************************** // MSP-FET430P440 Demo - Timer A Toggle P5.1, CCR0 upmode ISR, 32kHz ACLK // // Description; Toggle P5.1 using software and the TA_0 ISR. Timer A is // configured in an upmode, thus the the timer will overflow when TAR counts // to CCR0. In this example, CCR0 is loaded with 1000. // Toggle rate = 32768/(2*1000) = 16.384 // ACLK = TACLK = LFXT1 = 32768, MCLK = SMCLK = DCO = 32xACLK = 1.048576MHz // //*An external watch crystal on XIN XOUT is required for ACLK*// // // MSP430F449 // --------------- // /|\| XIN|- // | | | 32kHz // --|RST XOUT|- // | | // | P5.1|-->LED //************************************************************************** #include <msp430x44x.h> void main(void) { WDTCTL = WDTPW + WDTHOLD; // Stop WDT FLL_CTL0 = FLL_CTL0 | XCAP14PF; // Configure load caps P5DIR = P5DIR | 0x02; // Set P5.1 to output direction


TACTL = TASSEL0 + TACLR; // ACLK, clear TAR CCTL0 = CCIE; // CCR0 interrupt enabled

CCR0 = 1000; TACTL = TACTL | MC0; // Start Timer A in upmode _EINT(); // Enable interrupts for (;;) { _BIS_SR(LPM3_bits); // Enter LPM3 } } // Timer A0 interrupt service routine #pragma vector=TIMERA0_VECTOR __interrupt void Timer A (void) { P5OUT = P5OUT ^ 0x02; // Toggle P5.1 using exclusive-OR }

6.9.3. Anwendungsbeispiel III

Literatur und Weblinks: Siehe auch http://www.atwillys.de/imp/msp430/pwm430/index.htm Siehe auch Praktikumsversuch: Embedded Systems Erzeugung eines PWM-Signals und Signalisierung an einer LED #include <msp430x44x.h> #include <stdlib.h> #include <stdio.h> #include <string.h> // Globale Variblen void *buffer; // Vektor auf Puffer für Serielles einlesen void *buffer_tmp; // Temporera Vektor unsigned short buffer_counter; // Zähler für Puffergröße unsigned char flag=0; // Flag zum Auswerten von Buffer // Initialisierung der V24 Schnittstelle void init_Uart(void) { // Auswählen der Clock Source U1TCTL=0x10; //ACLK ausgewählt // Einstellung der BAUD-rate 9600 Baud U1BR0= 0x03; U1BR1= 0x00; U1MCTL= 0x4A; // Einstellen der Schnittstellenparameter U1CTL=0x10; // N,8,1 eingestellt // Module Enabel Register ME2 |= 0x30; //enable Transmit und recieve IE2 |= URXIE1; // Enable USART0 RX interrupt


// I/O Port Einstellungen P4SEL |= 0x03; // Bit 0 und 1 == 1 -> Peripheral module function P4DIR |= 0x01; // Bit 0 Output (Transmit) } // Initialisierung des Timer A als PWM mit CCR 0 void init_timer_A_PWM(void) { … (zu füllen durch Aufgabenstellung 1) } // Einen String über RS232 versenden void send_string_V24(char *sendstring) { unsigned int sleng, i; // Varible Stinglänge sleng und Zähler i sleng=strlen(sendstring); //festellen der Stringlänge for(i=0;i<sleng;i++) { while((IFG2 & UTXIFG1)==0); // Ist Transmitter frei für neue Daten? TXBUF1=sendstring[i]; // char senden } while((IFG2 & UTXIFG1)==0); // Ist Transmitter frei für neue Daten? TXBUF1=0xA; // LF senden while((IFG2 & UTXIFG1)==0); // Ist Transmitter frei für neue Daten? TXBUF1=0xD; // CR senden } void main(void) { unsigned int wert; // Varible zum auslesen des Zahlenwertes aus dem String WDTCTL = WDTPW + WDTHOLD; // Stop Watchdog init_Uart(); // V24 initialisieren P5DIR |= 0x80; // P5.7 als Ausgang konfigurieren init_timer_A_PWM(); // Timer A als PWM initialisieren buffer_counter=0; // Pufferzähler auf löschen buffer=malloc(10); // Speicherplatz für 10 Zeichen reservieren _EINT(); // allgemeinen Interuptfreigabe for(;;) { if(flag) // flag != 0 -> Eingabe über V24 mit CR abgeschlossen { //... (zu füllen durch Aufgabenstellung 2) flag=0; // flag wieder zurücksetzen buffer_counter=0; // Pufferzähler löschen IE2 |= URXIE1; // Interrupt für Seriellenempfang wieder

// freigeben } } } //Interruptroutine Timerüberlauf #pragma vector=TIMERA1_VECTOR __interrupt void Timer_A1(void) { P5OUT &= 0x7F; // P5.7 aus TACTL ^= 0x0001; // lösche Timerüberlauf Flag } // Interuptroutine Compareregister 0 #pragma vector=TIMERA0_VECTOR __interrupt void Timer_A (void) { P5OUT |= 0x80; // P5.7 ein


} // Interruptroutine serieller Empfang #pragma vector=UART1RX_VECTOR __interrupt void usart1_rx (void) { IE2 ^= URXIE1; // Interrupt für seriellen Empfang abschalten ((char*)buffer)[buffer_counter++]=RXBUF1; // Zeichen in Puffer lesen und Pufferzähler erhöhen if(RXBUF1==0x0d) // Abfrage ob Return gesendet wurde { flag=1; // Flag zum auslesen des Puffers setzen ((char*)buffer)[buffer_counter]=0; // Nullcharakter ans Ende vom String anfügen } else { if((buffer_counter+1)%10==0) // Ist Puffer voll? { if((buffer_tmp=realloc(buffer,buffer_counter+1+10))==0) // weitere 10 Byte am Anschluß von Buffer reservieren { flag=1; // Wenn kein Speicherplatz mehr frei war, // Speicher auslesen aktivieren } } }

if(flag==0) IE2 |= URXIE1; // Interrupt für Empfang freigeben, wenn // nicht der Puffer ausgelesen werden soll }

6.9.4. Übung I

Fragen:

a) Durch welche Leitung fordert der Programmable Inerrupt Controller PIC 8259 die Unterbrechung bei der CPU an?

b) Durch welche Leitung zeigt die CPU an, wann der Interrupt erfolgen kann?

c) Welche Voraussetzungen müssen in der CPU vorliegen, damit die Unterbrechung erfolgen und abgearbeitet werden kann?

d) Was versteht man unter „nestet interrupts“? Wo liegen die Gefahren von „nestet


interrupts” und wie können diese vermieden werden?

e) Beschreiben Sie die Kommunikation des Interruptsteuerbausteins PIC 8259 A mit der CPU im 8086-Modus.

f) Erläutern Sie den Unterschied zwischen Software- und Hardware-Interrupts. Wo werden diese insbesondere verwendet?

g) Beschreiben Sie den Zweck und die Funktion der Vektortabelle? Wie berechnet sich die Einsprungadresse für die IRQ-Adresse eines externen Interrupts?

h) Beschreiben Sie den Begriff „shared IRQ“.

i) Beschreiben Sie den Einsatz und die Wirkungsweise des DOS Multiplex-Interrupts 2Fh.


6.9.5. Übung II

Gegeben ist der nachstehende Programmausschnitt mit dem Quellcode der Interruptservice-routine void usart1_rx(void) sowie zwei Auszüge (Hex-Dumps mit Disassemblierung) aus dem Speicherabbild.

Bitte geben Sie an, wie sich der Stackpointer bei Eintreffen des Interrupts UART1RX_VECTOR verändert und welche Werte auf dem Stack liegen. Wählen Sie selbst eine beliebige Stack-Basisadresse.


Bild: Disassembler Programmausschnitt

Bild: Interrupt-Vektor-Tabelle MSP430

Documents

Embedded Systemarchitekturen und …€¦ · · 2014-04-14Embedded Systemarchitekturen und Echtzeitbetriebssysteme 2 4.2. IAR Debug- und Testverfahren im Überblick..... 76 4.2.1