Hardwarenahe_Programmierung_in_C_V1_2

Hardwarenahe Programmierung in C 

mit dem µP-Kit 68332 

Dieses Skript beinhaltet eine Einführung in die hardwarenahe Programmierung in 

C, am Beispiel des 68332 von Motorola. Gute Kenntnisse in der Programmiersprache 

C werden vorausgesetzt 

Ivo Oesch 

Mai 2004 

April 2005 

Mai 2006


Inhaltsverzeichnis 

1 Einführung....................................................................................................................................3 

1.1 Verschieden Computersysteme ............................................................................................3 

1.1.1 Universalrechner (PC)..................................................................................................3 

1.1.2 Grossrechner.................................................................................................................3 

1.1.3 Mikrocomputer.............................................................................................................3 

1.1.4 Echtzeitrechner.............................................................................................................3 

1.2 Technische Prozesse.............................................................................................................4 

1.3 Datenfluss zwischen Echtzeitrechner und technischem Prozess..........................................5 

2 Mikroprozessorsysteme................................................................................................................6 

2.1 Aufbau eines Mikroprozessorsystems..................................................................................6 

2.2 Adressraum...........................................................................................................................6 

2.3 Speicherorganisation ............................................................................................................7 

2.3.1 Little Endian / Big Endian............................................................................................7 

2.4 Speicherverwaltung unter einer Hochsprache ......................................................................8 

2.5 Zugriff auf Hardware............................................................................................................8 

3 Direkter Speicherzugriff mit C.....................................................................................................9 

3.1 Benutzung von Pointer .........................................................................................................9 

3.2 Compileroptimierungen unterdrücken .................................................................................9 

3.3 Aufgabe 1: ..........................................................................................................................12 

3.3.1 Initialisierung der TPU...............................................................................................12 

3.3.2 Ansteuerung der LED.................................................................................................12 

3.3.3 Lesen der Schalter und Tastenzustände:.....................................................................12 

3.4 Die serielle RS232 Schnittstelle.........................................................................................13 

3.5 Aufgabe 2 ...........................................................................................................................14 

3.6 Umlenken der Ein- und Ausgabefunktionen in C. .............................................................15 

3.7 Aufgabe 3 ...........................................................................................................................16 

3.8 Weitere Anpassungen der Standardbibliothek ...................................................................16 

4 Startupcode.................................................................................................................................17 

5 Interrupts ....................................................................................................................................18 

5.1 Einführung..........................................................................................................................18 

5.2 Definition einer Interruptroutine ........................................................................................19 

5.3 Sperren von Interrupts ........................................................................................................19 

5.4 Interrupthandling beim 68xxx............................................................................................21 

5.4.1 Interruptvektoren ........................................................................................................22 

5.5 Aufgabe 4 ...........................................................................................................................25 

5.6 Aufgabe 5 ...........................................................................................................................25 

5.7 Interrupts und Standardbibliothek......................................................................................25 

Anhang A Bitzugriff...........................................................................................................................26 

Anhang B Zahlensysteme...................................................................................................................29 

Das Kapitel 1 wurde mit freundlicher Genehmigung dem Skript 'Informatik 3', September 2003 von Roger Weber* 

entnommen. (Mit kleinen Änderungen) 

* Professor für Technische Informatik, HTI Burgdorf 

Gedruckt am 23.05.2006 11:27:00 Letzte Änderung am: 23. Mai 2006 Version 1.2, I. Oesch 2/33


1 Einführung 

1.1 Verschieden Computersysteme 

1.1.1 Universalrechner (PC) 

Universalrechner sind Rechnersysteme für den allgemeine Einsatz. Sie sind standardisiert, werden 

in grossen Volumen hergestellt, und es gibt für fast alle denkbaren Einsätze bereits existierende 

Software. 

1.1.2 Grossrechner 

Grossrechner werden vor allem für sehr rechenintensive Arbeiten wie Simulationen (Wettervorhersage, 

Modellierung von physikalischen Prozessen, usw.) oder bei riesigen Datenmengen verwendet. 

Sie werden nur in kleinen Stückzahlen oder als Einzelanfertigung produziert, und es gibt auch nur 

selten bereits existierende Software dazu. Diese Rechner werden meist auf den jeweiligen Einsatz 

hin konstruiert, und auch die entsprechende Software und Compiler werden jeweils speziell dafür 

geschrieben. 

1.1.3 Mikrocomputer 

Mikrocomputer sind kleine Rechner, welche meist auf Steuerungsaufgaben spezialisiert sind, oft 

bereits mit vielen Ein- und Ausgabeleitungen ausgestattet, und mit zusätzlichen Ein- Ausgabemöglichkeiten 

erweitert werden können. Sie werden als Einplatinencomputer, als Module, ohne Gehäuse 

oder in Industrietauglichen Gehäusen gefertigt. Auf nicht notwendige Komponenten wie Graphikkarten 

(Monitoranschluss), Tastatur, Harddisks und ähnliches wird verzichtet, diese können aber bei 

einigen Systemen nachgerüstet werden. Das Prinzip ist: So einfach wie möglich, und sowenig Bauteile 

wie nötig. 

1.1.4 Echtzeitrechner 

Für die Steuerung von technischen Prozessen werden Echtzeitrechner eingesetzt. Diese erfüllen 

folgende Kriterien: 

• Einhaltung einer zeitlichen Abfolge 

• Definierte, schnelle Bearbeitungs- und Reaktionszeiten 

• Zeitdeterministisch (Vorhersagbares und reproduzierbares Zeitverhalten) 

Je nach Komplexität des Prozesses kommen folgende Rechner zum Einsatz: 

• Grossrechner 

• PC / SPS 

• Mikrocomputer 

Mikrocomputer können weiter unterteilt werden in: 

• Single Chip µC (in einem Chip integriert) 

• Single Board µC (auf einer gedruckten Schaltung mit anderen Bauelementen) 



Im Gegensatz zu Echtzeitrechnern erfüllen allgemein datenverarbeitende Rechner die Echtzeit- 

Kriterien normalerweise nicht (z.B. Windows-PC zur Textverarbeitung). Dies ist aber vor allem 

auch eine Frage des Betriebsystemes. 

In diesem Skript werden ausschliesslich Mikrocomputer behandelt. Mögliche Einsatzgebiete sind: 

• Telekommunikation (Zentralen, Endgeräte ...) 

• Medizinaltechnik (Blutzuckermessgerät, Hörgeräte, Implantate ...) 

• Sicherheitstechnik (Brandmeldeanlagen, Bahnübergänge ...) 

• Industrieautomation (Sensoren, Aktoren, Steuerungen von Anlagen...) 

• Automobilindustrie, Bahnen, Flugzeuge 

• Consumer-Elektronik (Fotoapparat, Drucker, Hifi ...) 

Mikrocomputer in den oben genannten Anwendungen werden oft auch als 'Embedded Controller' 

bezeichnet, da sie 'eingebettet' in einem Gerät arbeiten. 

1.2 Technische Prozesse 

Die folgende Abbildung zeigt einen groben Überblick über das Zusammenspiel zwischen Echtzeitrechner 

und technischem Prozess: 

Sensoren 

techn. 

Prozess 

Echtzeitrechner 

User 

Interface 

Aktoren 

Zusammenspiel zwischen Echtzeitrechner und technischem Prozess 

Der Prozess ist Quelle und Senke der Prozessdaten. Der Rechner liest über Sensoren den Zustand 

des Prozesses ein. Über Aktoren kann er den Zustand des Prozesses beeinflussen. Der Anwender hat 

die Möglichkeit, über ein User-Interface den Prozess zu beeinflussen (Konfiguration, Parametrisierung) 

oder Zustände des Prozesses abzufragen. 

Beispiele für Sensoren: 

• mechanische, induktive oder optische Schalter 

• A/D Wandler 

• Temperatursensoren, Drucksensoren 

Beispiele für Aktoren: 

• Ventile 

• Motoren 

• Anzeigen, LED 

• Relais 

• D/A Wandler 



1.3 Datenfluss zwischen Echtzeitrechner und technischem Prozess 

Die folgende Abbildung zeigt die detaillierte Darstellung des Datenflusses zwischen Echtzeitrechner 

und technischem Prozess: 

Echtzeitrechner 

Regelungs-Algorithmus 

Prozess-Abbild 

Ausgabe- 

Daten 

Eingabe- 

Daten 

Ereignisse 

Stell- 

Grössen 

Prozess- 

Kennwerte 

Prozess- 

Parameter 

Mess- 

Grössen 

diskrete 

Ereignisse 

Prozess- 

Input 

technischer 

Prozess 

Prozess- 

Output 

Stör- 

Grössen 

Rückwirkung 

Datenfluss zwischen Echtzeitrechner und technischem Prozess 

Der Prozess besitzt einen Input und einen Output. Dies können sowohl Informationen als auch Materialien 

sein. Weiter wird der Prozess durch Störgrössen sowie Rückwirkungen des Outputs beeinflusst. 

Dem Prozess werden zudem Kennwerte und Parameter mitgegeben. 

Der Echtzeitrechner erstellt anhand der Messgrössen sowie diskreter Ereignisse ein Prozessabbild. 

Mit Hilfe eines Regelungsalgorithmus berechnet der Echtzeitrechner die Stellgrössen des Prozesses 

und sorgt so für dessen korrekten Ablauf. 



2 Mikroprozessorsysteme 

2.1 Aufbau eines Mikroprozessorsystems 

Ein allgemeines Mikroprozessorsystem setzt sich aus Prozessor (CPU), RAM (Daten und Programmspeicher), 

ROM (Programmspeicher) und Peripherie zusammen. Die verschiedenen Komponenten 

sind über ein Bussystem miteinander verbunden 

CPU 

Bus für Instruktionen und Daten 

Programm- 

Speicher 

Daten- 

Speicher 

Peripherie 

2.2 Adressraum 

Der Speicher eines Prozessors besteht üblicherweise aus einer Menge von Bytes, die von 0 an 

durchnumeriert sind. Die Nummer einer Speicherzelle wird dabei als ihre Adresse bezeichnet, und 

der Bereich aller möglichen Nummern eines Prozessors als Adressraum des Prozessors. Die Adresse 

wird als binäre Nummer auf den Bus ausgegeben, und die Breite des Busses (Nebst der Prozessorarchitektur) 

legt fest, welches die grösstmögliche Adresse ist. Mit 16 Bit kann man von 0 bis 65535 

(2^16-1) zählen, also 64 KB (Kilobytes, 1 KB = 1024 Bytes) adressieren. Mit 24 Bit können 16 MB 

(Megabytes, 1 MB = 1024 KB), und mit 32 Bit 4 GB (Gigabytes, 1 GB = 1024 MB) adressiert werden. 

Normalerweise ist jedoch nicht jede adressierbare Speicherzelle auch wirklich vorhanden, oft 

existieren auch 'Löcher' im Adressraum in welchen nichts vorhanden ist. 

Die effektive Zuordnung von Adressbereichen zu RAM, ROM und Pheripheriebausteinen wird 

durch Hardwareschaltkreise erledigt, manchmal unter Zuhilfenahme von spezialisierten Pheripheriebausteinen 

(Was in einem gewissen Umfang eine softwaremässige Konfiguration ermöglicht). 

Oft wird der Speicher eines Prozessorsystems mit einer Memorymap dargestellt, aus welcher klar 

ersichtlich ist, wo was liegt. In einem Mikrokontrollersystem findet man üblicherweise ROM (Hier 

ist der Programmcode dauerhaft abgespeichert), RAM (Hier werden Variablen und Daten abgelegt) 

und Peripherie (Damit kommuniziert das System mit der Aussenwelt). Und meist auch Bereiche, an 

denen gar nichts steht, die also leer sind. (Z. B. für zukünftige Erweiterungen reservierte Bereiche). 



Beispiel einer Memorymap 

0xFFFFFF 

0xF80000 

0xF7FFFF 

0xF00000 

0xFFFFFF 

0xFFFFE0 

0xFFFFDF 

0xFFFF80 

0xFFFF7F 

0x028000 

0x027FFF 

0x020000 

0x01FFFF 

0x000400 

0x0003FF 

0x000000 

ROM 

Unbenutzt 

Timer 

UART 

Unbenutzt 

RAM 

(Akkugepuffert) 

RAM 

RAM 

(Vektortabelle) 

Üblicherweise beginnt die Darstellung einer Memorymap am unteren Ende bei 0, sie kann aber 

durchaus auch in der anderen Richtung dargestellt werden. 

2.3 Speicherorganisation 

Der Speicher fast aller Mikroprozessoren ist Byteweise organisiert, das heisst, dass 16-Bit und 32- 

Bit Variablen mehrere Bytes im Speicher belegen. Aus Effizienzgründen sollten 16-Bit Werte immer 

auf geraden, und 32-Bit Werte immer auf durch 4 teilbaren Adressen liegen (Dies ist bei einigen 

Prozessoren sogar Pflicht). Damit ist gewährleistet, dass bei 16-Bit, resp. 32-Bit breiten Datenbussen 

immer alle Bits auf einmal gelesen werden können, ansonsten sind mehrere Zugriffe notwendig. 

2.3.1 Little Endian / Big Endian 

Es gibt zwei gängige Möglichkeiten, wie 16 und 32-Bit Werte im Speicher abgelegt werden. Beim 

ersten Format (Little Endian) werden die Bits 0-7 an der Adresse n, die Bits 8-15 an der Adresse 

n+1 und entsprechend die Bits 24-31 an der Adresse n+3 abgelegt. Beim zweiten Format (Big Endian) 

ist es gerade umgekehrt, die Bits 23-31 liegen auf der Adresse n und die Bits 0-7 auf der Adresse 

n+3. 



Little Endian 

Big Endian 

32-Bit Wert (long) 

Bit 0-7 Bit 8-15 Bit 16-23 Bit 24-31 

n n+1 n+2 n+3 

32-Bit Wert (long) 

Bit 24-31 Bit 16-23 Bit 8-15 Bit 0-7 

n n+1 n+2 n+3 

n+4 

n+3 

Bit 24-31 

n+2 

Bit 16-23 

n+1 

Bit 8-15 

n 

Bit 1-7 

n-1 

n-2 

n+4 

n+3 

Bit 1-7 

n+2 

Bit 8-15 

n+1 

Bit 16-23 

n 

Bit 24-31 

n-1 

n-2 

Der Wert 0x12345678 würde also jeweils wie folgt im Speicher abgelegt werden: 

0x78, 0x56, 0x34, 0x12 0x12, 0x34, 0x56, 0x78 

n n+1 n+2 n+3 n n+1 n+2 n+3 

Der im Unterricht eingesetzte Prozessor 68332 gehört in die Klasse der Big Endian Prozessoren. 

Das heisst, das an den tieferen Adressen die höherwertigen Bytes stehen. 

2.4 Speicherverwaltung unter einer Hochsprache 

Normalerweise wird die Verwaltung des Speichers vom Compiler übernommen, kann aber durch 

den Benutzer mit diversen Compiler- und Linker- Einstellungen gesteuert werden. Wenn man direkt 

auf die HW zugreift, muss man sich selbst um die korrekten Zugriffe kümmern (D.h. definieren ob 

man auf 8 oder 16-Bit zugreifen will, und an welcher Adresse nun welches Byte steht). 

2.5 Zugriff auf Hardware 

Sobald man Programme für Mikrocontroller oder selbst gebaute Hardware schreibt, wird es unumgänglich, 

vom Code direkt auf die Hardware zuzugreifen. Meistens sind die Funktionen der Hardware 

über Register (=Bestimmte Speicherzellen) erreichbar, die häufig (aber nicht immer) irgendwo 

im Speicherbereich stehen. Das heisst, dass an bestimmten Stellen im Prozessorspeicher kein RAM 

(Arbeitsspeicher), sondern eben diese Peripherieregister eingeblendet werden. Die genaue Funktion 

und Bedeutung dieser Register muss jeweils der entsprechenden Dokumentation entnommen werden. 



3 Direkter Speicherzugriff mit C 

Um in C auf Hardware zugreifen zu können müssen Pointer, Assemblermodule oder Assemblereinschlüsse 

verwendet werden. Solange die Hardware im normalen Speicherbereich eingeblendet ist, 

können Pointer verwendet werden, wenn die Hardware nicht direkt adressierbar ist (Eigener Adressraum, 

Prozessorregister, spezielle Prozessorbefehle) muss auf Assembler ausgewichen werden. Hier 

wird nur die Variante mit Pointer besprochen. 

3.1 Benutzung von Pointer 

Via Pointer kann in C auf jede beliebige Speicheradresse zugegriffen werden, aber man muss darauf 

achten, den passenden Pointertypen zu verwenden. 

Unser System (68332) ist ein 32/16-Bit System, und besitzt unter der Tasking Entwicklungsumgebung 

folgende Datentypen: char 8 Bit, int 32 Bit, long 32 Bit, short int 16 Bit. 

8-Bit breite HW-Register müssen somit durch einen unsigned char Pointer, 16-Bit Register 

durch einen unsigned short int Pointer und 32-Bit Register durch einen unsigned long 

int Pointer angesprochen werden. 

Um zum Beispiel auf die Adresse 0x00f1278 (Könnte z. B. ein Parallelport sein) den 16-Bit Wert 

0x1234 zu schreiben können folgende Codevarianten benutzt werden: 

Direkt: 

*((unsigned short int*)0x00f1278 ) = 0x1234; 

/* Umwandeln der Zahl 0x00f1278 in eine Adresse und darauf zugreifen */ 

Via Pointer 

/* Pointervariable definieren */ 

unsigned short int *Parallelport; 

/* Pointer auf Adresse zeigen lassen */ 

Parallelport = (unsigned short int*)0x00f1278; 

/* Und Wert dorthin schreiben wo der Pointer hinzeigt */ 

*Parallelport = 0x1234; 

Mit Hilfe eines Makros 

/* Koennte in einer Headerdatei stehen */ 

#define Parallelport *((unsigned short int*)0x00f1278 ) 

/* Benutzung des Makros im Code */ 

Parallelport = 0x1234; 

3.2 Compileroptimierungen unterdrücken 

Im Zusammenhang mit direktem Zugriff auf Hardware und Zusammenarbeit mit Interrupts gewinnt 

das Schlüsselwort volatile an Bedeutung. Alle guten Compiler versuchen, möglichst optimalen 

Code zu erzeugen, dazu gehört auch, überflüssigen oder redundanten Code zu entfernen. Dazu einige 

Beispiele: 



Das folgende Codestück 

while (Parallelport == 0) { 

i++; /* Warten bis Parallelport bereit */ 

} 

könnte vom Compiler zu der Form 

if (Parallelport == 0) { /* Testen ob Parallelport 0 ist */ 

while (1) { 

i++; /* Falls ja in Endlosschleife eintreten */ 

} 

} 

optimiert werden, um die Speicherzugriffe auf die Variable Parallelport zu minimieren und schnelleren 

Code zu Erzeugen (Aus der Sicht des Compilers kann die Variable Parallelport ihren Inhalt ja 

nicht ändern). Solange die Variable Parallelport ihren Wert nicht 'magisch' ändert, sind die beiden 

Codevarianten identisch, aber die zweite ist schneller. 

Ein weiteres Beispiel wäre die Sequenz 

Parallelport = 0; 

while (Parallelport == 0) { 


} 

Welche zu 

Parallelport = 0; 

while (1) { 


} 

optimiert werden kann, hier 'weiss' der Compiler ja, dass die Variable Parallelport den Wert 0 hat, 

und kann sich so auch noch die Abfrage (if) sparen. 

Ein anderes Beispiel wäre eine Sequenz zum ausgeben eines Bitmusters: 

Parallelport = 0; /* Alle Leitungen auf 0 setzen */ 

Parallelport = 1; /* Clock auf 1 setzen */ 


Parallelport = 2; /* Datenleitung auf 1 setzen */ 




welche vom Compiler zu 


optimiert werden kann, da schliesslich nur die letzte Anweisung den Wert dauerhaft setzt, und die 

Werte alle vorherigen Zuweisungen überschrieben werden. 



Um den Compiler dazu zu zwingen, jeden Schreib oder Lesezugriff wirklich und sofort durchzuführen, 

also alle Optimierungen für eine bestimmte Variable zu unterlassen, muss man diese Variable 

als volatile ('flüchtig/unbeständig') definieren. 

Die Definitionen der Variablen Parallelport müssten also jeweils wie folgt mit volatile ergänzt 

werden: 

Direkt: 

*((volatile unsigned short int*)0x00f1278 ) = 0x1234; 

Via Pointer 

/* Pointervariable definieren */ 

volatile unsigned short int *Parallelport; 

/* Pointer auf Adresse zeigen lassen */ 

Parallelport = (volatile unsigned short int*)0x00f1278; 

/* Und Wert dorthin schreiben wo der Pointer hinzeigt */ 

*Parallelport = 0x1234; 

Mit Hilfe eines Makros 

/* Koennte in einer Headerdatei stehen */ 

#define Parallelport *((volatile unsigned short int*)0x00f1278) 

/* Benutzung des Makros im Code */ 

Parallelport = 0x1234; 

Grundsätzlich sollte man alle Variablen, die unbemerkt vom Compiler ihren Zustand ändern, oder 

deren Änderungen direkt Hardware beeinflusst, immer als volatile deklarieren. Das heisst: Alle 

Variablen, welche mit Hardware verbunden sind, und alle Variablen, welche von Interruptroutinen 

verändert werden. 

Oft funktioniert der Code auch ohne volatile einwandfrei, aber nach einer Ergänzung oder Änderung 

des Codes treten plötzlich Probleme auf, welche meist nur sporadisch auftreten und oft 

kaum zu lokalisieren sind. 

Normalerweise gehen die vom Compiler ausgeführten Optimierungen noch viel weiter als die oben 

angegebenen Beispiele. Eine Variable kann unter Umständen bereits zu Beginn einer Funktion in 

ein Prozessorregister (=Schneller lokaler Speicher vom Prozessor) geladen werden, alle weiteren 

Zugriffe erfolgen anschliessend auf dieses Register, und erst am Ende der Funktion wird der Inhalt 

des Registers in den Speicher zurückgeschrieben. Der Code wird dadurch natürlich viel effizienter 

und schneller, besonders wenn die Variable oft verwendet wird, aber wenn dabei Zugriffe auf 

Hardware unterdrückt werden, funktioniert der Code nicht mehr korrekt. 



3.3 Aufgabe 1: 

Schreiben Sie ein Programm, welches die Schalter S1 bis S4 vom Kit einliest, und den Zustand der 

Schalter auf den Led's L1 bis L4 ausgibt. Hinweis, schreiben Sie zuerst ein Programm, das nur die 

LED ansteuert, und fügen sie erst nach erfolgreichem Test den Code zum Auslesen der Schalterzustände 

hinzu. 

Das Einlesen der Schalter und Ausgeben der LED-Zustände erfolgt über die TPU, dies ist ein komplexer 

Mikrosequenzer, der eigentlich viel mehr kann als nur die Ein- und Ausgabe von einfachen 

Pegeln. Deshalb ist auch die Initialisierung dieser Einheit recht aufwendig. 

3.3.1 Initialisierung der TPU 

Zur Initialisierung der TPU müssen etwa 36 Register korrekt initialisiert werden, deshalb wird ein 

Modul (tpufuncs) zur Initialisierung der TPU zur Verfügung gestellt. 

3.3.2 Ansteuerung der LED 

Zur Ansteuerung der Leds L1 bis L4 ist folgender Ablauf nötig (Ablauf unbedingt einhalten!): 

- In das Register HSRR1 den gewünschten LED-Zustandscode schreiben 

- Das Register HSQR1auf 0 setzen 

- Das Register CPR1 auf 0xFFFF setzen 

Der Ledzustandscode besteht für jede LED aus zwei Bits. Bit 0 und 1 steuern die Led L1, Bit 2 und 

3 die Led L2 usw. Dabei bedeuten die Bitkombinationen 01 Einschalten, und 10 Ausschalten der 

entsprechenden Led: 

0 0 0 0 0 0 0 0 Led L4 Led L3 Led L2 Led L1 

Bit 15 Bit 8 Bit 7 Bit 0 

Die benötigten Register liegen auf folgenden Adressen: 

HSRR1: 16-Bit Register, auf Adresse 0xFFFE1A 

HSQR1: 16-Bit Register, auf Adresse 0xFFFE16 

CPR1: 16-Bit Register, auf Adresse 0xFFFE1E 

Die restlichen Register der TPU bitte nicht verändern. 

3.3.3 Lesen der Schalter und Tastenzustände: 

Der Zustand der Schalter S1 bis S4 ist jeweils im Bit 7 der Register PL8 bis PL11 abgelegt, der Zustand 

der Tasten T1 bis T4 ist im Bit 7 der Register PL12 bis PL15 abgelegt. (Achtung, Tasten sind 

Null-aktiv) 

Die benötigten Register liegen auf folgenden Adressen: 

PL8: 16-Bit Register, auf Adresse 0xFFFF82 

PL9: 16-Bit Register, auf Adresse 0xFFFF92 

PL10: 16-Bit Register, auf Adresse 0xFFFFA2 

PL11: 16-Bit Register, auf Adresse 0xFFFFB2 

PL12: 16-Bit Register, auf Adresse 0xFFFFC2 

PL13: 16-Bit Register, auf Adresse 0xFFFFD2 

PL14: 16-Bit Register, auf Adresse 0xFFFFE2 

PL15: 16-Bit Register, auf Adresse 0xFFFFF2 



3.4 Die serielle RS232 Schnittstelle 

RS-232 ist eine serielle Übertragung, bei der die Datenbytes mit dem LSB (Bit 0) voran übertragen 

werden. Der Beginn einer Übertragung wird durch ein 'Startbit', einem Bit mit dem Wert 0, angezeigt. 

Anschliessend folgen die Datenbytes, und zum Abschluss folgen ein oder 2 Stoppbits (Bits 

mit dem Wert 1). Zwischen dem letzten Datenbit und dem Stoppbit kann noch ein Paritätsbit eingefügt 

werden. 

Die Datenleitung hat im Ruhezustand den Wert 1, so kann jederzeit das Startbit einer neuen Übertragung 

detektiert werden. 

Bei einer normgerechten RS232-Verbindung besitzt die logische 1 den Pegel von -12Vund die logische 

0 einen Pegel von +12V. 

Damit ergibt sich für eine Beispielübertragung folgendes Zeit/Spannungsdiagramm. (Achtung -12V 

entspricht einer logischen 1 und +12V einer logischen 0!) 

+12V 

-12V 

Idle 

Start 

Bit 

D0 D1 D2 D3 D4 D5 D6 D7 P 

Datenbits 

Parity 

Bit 

Stop 

Bit 

Idle 

Zur Verbindung zwischen Sender und Empfänger reichen 2 Leitungen aus, eine Datenleitung und 

eine Masseleitung. Wenn in beide Richtungen kommuniziert werden soll, braucht es eine weitere 

Datenleitung, also insgesamt 3 Leitungen. Die Anschlüsse werden mit folgenden Kürzeln bezeichnet: 

Masse mit Gnd (Pin 5), Datenausgang mit TxD (Pin 3) und Dateneingang mit RxD (Pin 2), die 

Pinangaben gelten jeweils für den 9-Poligen D-Sub Stecker. Dabei muss jeweils TxD mit RxD des 

Kommunikationspartners verbunden werden. Die serielle Schnittstelle besitzt noch weitere Steuerleitungen, 

auf die aber hier nicht weiter eingegangen wird. (Diese dienen zum 'Hardware Handshaking', 

und erlauben dem Empfänger, den Sender zu stoppen, wenn die Daten zu schnell eintreffen. 

Wenn man kein Handshaking benötigt, muss es entweder Softwaremässig ausgeschaltet werden, 

oder aber die Steuerleitungen am Stecker müssen entsprechend ausgekreuzt werden.) 

Damit sich Sender und Empfänger verstehen, müssen beide dasselbe Format benutzen. Das heisst, 

dass die Bitbreite, die Anzahl Datenbits und die Art der Parität bei beiden gleich konfiguriert werden 

muss. Die Bitbreite wird über die Baudrate (=Anzahl Bits pro Sekunde) definiert. 

Üblicherweise muss aber das Protokoll für die serielle Schnittstelle nicht selbst programmiert werden 

(Ausnahme: kleine Mikrokontroller oder Kostenersparnis durch Softwareemulation und Verzicht 

auf einen UART-Baustein), sondern es werden Hardwarebausteine (UARTs, 'Universal Asynchronous 

Receiver and Transmitter') eingesetzte, welche die Kommunikation und die Umwandlung 

von Seriell nach Parallel und zurück übernehmen. 



3.5 Aufgabe 2 

Schreiben Sie ein Programm, welches Zeichen über die serielle Schnittstelle empfängt und selbst 

wieder Zeichen über die serielle Schnittstelle ausgibt. Starten sie auf dem PC ein Terminalprogramm 

(Ein Terminalprogramm emuliert ein Terminal, das heisst, es stellt alle über die serielle 

Schnittstelle empfangenen Zeichen auf dem Bildschirm dar, und sendet alle Tastendrücke über die 

serielle Schnittstelle weiter.), verbinden Sie ihr Kit mit der seriellen Schnittstelle vom PC und konfigurieren 

Sie das Terminalprogramm auf 9600 Baud, 8 Datenbit, 1 Stoppbit, keine Parität (9600 

1N8) und kein Handshaking. Das Terminalprogramm zeigt Ihnen anschliessend alle Zeichen an, die 

über die serielle Schnittstelle eintreffen, und sendet alle Tastendrücke über die serielle Schnittstelle. 

Zum Testen des Terminalprogramms können sie auch Pin 2 mit Pin 3 in Richtung PC kurzschliessen 

(Büroklammer oder ähnliches), anschliessend sollten Sie im Terminalprogramm Ihre eigenen 

Tastendrücke sehen (Oder doppelt sehen wenn das lokale Echo aktiviert ist). 

Genauere Informationen über die Register der seriellen Schnittstelle des Kits und deren Konfiguration 

können sie dem Dokument MC68332UM.pdf ab Kapitel D.4 'Queued Serial Module' (Seite 

D18) entnehmen. Sie müssen die Register SCCR0 und SCCR1 korrekt konfigurieren, der Systemtakt 

beträgt 16.666666 MHz (Wird zur Berechnung der Baudrate benötigt). 

Im Register SCSR können Sie mit den Bits TDRE und RDRF feststellen, ob Sie das nächste Byte 

senden dürfen, oder ob neue Daten eingetroffen sind. Daten senden und empfangen Sie über das 

Register SCDR, wobei nur die unteren 8 Bits verwendet werden. Alles was Sie in dieses Register 

schreiben wird gesendet (Ausser wenn Sie bereits einen neuen Wert in das Register schreiben, bevor 

der alte Wert gesendet wurde). Und alles was empfangen wird, können Sie aus diesem Register lesen 

(Ausser wenn Sie zulange warten, dann kann ein alter Wert durch einen neuen überschrieben 

werden). 

Die Register der seriellen Schnittstelle befinden sich auf den folgenden Adressen: 

Zugriffsmode Breite Adresse Registername 

S 16 Bit 0xFFFC00 QSMCR 

S 16 Bit 0xFFFC04 QSM INTERRUPT LEVEL (QILR) QSM INTERRUPT VECTOR (QIVR) 

S/U 16 Bit 0xFFFC08 SCI CONTROL 0 (SCCR0) 

S/U 16 Bit 0xFFFC0A SCI CONTROL 1 (SCCR1) 

S/U 16 Bit 0xFFFC0C SCI STATUS (SCSR) 

S/U 16 Bit 0xFFFC0E SCI DATA (SCDR) 

Der Zugriffsmode ist für diese Übung nicht von Bedeutung. 



3.6 Umlenken der Ein- und Ausgabefunktionen in C. 

In einem Mikroprozessorsystem gibt es im Allgemeinen weder ein Dateisystem, noch andere standardisierte 

Ein- und Ausgabefunktionen. Die Standartbibliothek von C ist jedoch so aufgebaut, dass 

es sehr einfach ist, sämtliche Ein- und Ausgaben auf die passende Hardware umzulenken. Es müssen 

im einfachsten Fall nur die Funktionen putc() und getc() (und ev. ungetc()) selbst geschrieben 

werden, alle anderen Funktionen wie z. B. printf(), scanf() oder gets() rufen 

diese Funktionen auf. 

Wenn man ein Dateisystem und mehrere Ein-/Ausgabekanäle unterstützen möchte, muss man zusätzlich 

noch fopen(), fclose() und andere spezielle Dateizugriffsfunktionen wie ftell() 

oder fseek() selbst schreiben. Natürlich brauchen nur diejenigen Funktionen geschrieben zu 

werden, welche man auch wirklich benötigt. 

Wenn man kein Dateisystem nachbildet, kann man bei den Funktionen getc() und putc() das 

stream (FILE *) Argument ignorieren. Um die Ein und Ausgaben in unserem Kit umzulenken, 

müssten die beiden Funktionen also ungefähr wie folgt definiert werden: 

int putc (int c, FILE *stream) 

{ 

SendByteToSerialPort(c); 

return c; /* Sollte im Fehlerfall noch EOF zurueckgeben */ 

} 

int getc (FILE *stream) 

{ 

/* naechstes Zeichen zurueckliefern (Oder EOF im Fehlerfall)*/ 

return GetByteFromSerialPort(); 

} 

Wichtig: Die Funktion getc() muss solange warten, bis ein Zeichen von der seriellen Schnittstelle 

eintrifft, oder einen Fehlercode (EOF) zurückliefern. Sie darf nicht 'einfach so' zurückkehren, wenn 

kein Zeichen eingetroffen ist. 

Die Funktionen SendByteToSerialPort(c) und GetByteFromSerialPort() müssen vom Anwender 

selbst geschrieben werden, und sollen ein Zeichen auf die serielle Schnittstelle schreiben, resp. ein 

Zeichen von dieser Lesen. Anstelle des Funktionsaufrufs kann natürlich auch direkt der Code zum 

Schreiben und Lesen der UART-HArdware eingesetzt werden. 

Da die höheren Eingabefunktionen wie scanf() auch die Funktion ungetc() verwenden, sollte 

diese ebenfalls noch implementiert werden. ungetc() legt ein zuviel gelesenes Zeichen wieder in 

den Eingabepuffer zurück (ungetc() darf natürlich auch mehr als ein Zeichen zurücklegen, der 

Standard fordert einfach ein Minimum von einem Zeichen. 

Somit müssten die Funktionen etwa wie folgt definiert werden: 



int putc (int c, FILE *stream) 

{ 

SendByteToSerialPort(c); 

return c; /* Sollte im Fehlerfall noch EOF zurueckgeben */ 

} 

static int UngottenCharacter = -1; 

int getc (FILE *stream) 

{ 

int Zeichen = 0; 

/* auf ein mit ungetc() zurückgelegtes Zeichen testen */ 

if (UngottenCharacter >= 0) { 

} 

/* zurueckgelegtes Zeichen benutzen und Buffer wieder loeschen */ 

Zeichen = UngottenCharacter; 

UngottenCharacter = -1; 

} else { 

/* naechstes Zeichen zurueckliefern (Oder EOF im Fehlerfall)*/ 

Zeichen = GetByteFromSerialPort(); 

} 

return Zeichen; 

int ungetc (int Zeichen, FILE *stream) 

{ 

/* das Zeichen zuruecklegen, es wird nur ein Zeichen behalten…*/ 

UngottenCharacter = Zeichen; 

return Zeichen; /* Sollte im Fehlerfall noch EOF zurueckgeben */ 

} 

3.7 Aufgabe 3 

Sorgen Sie dafür, dass sämtliche Ein- und Ausgaben über die serielle Schnittstelle erfolgen, und 

bringen sie ein paar Ihrer älteren Programme mit Text Ein- und Ausgabe aus dem C-Unterricht auf 

dem Kit zum laufen. 

3.8 Weitere Anpassungen der Standardbibliothek 

Um die gesamte Funktionalität der Standartbibliothek auf einem Mikrocomputersystem zur Verfügung 

zu haben, müssen noch weitere Anpassungen vorgenommen werden: 

Neben der Ein- und Ausgabe müssen noch die Funktionen für die dynamische Speicherverwaltung, 

sowie die Funktionen die mit Zeiten arbeiten (time.h) angepasst werden. Natürlich auch nur falls sie 

benötigt werden. 

Um die dynamische Speicherverwaltung an die jeweilige Hardware anzupassen müssen gelegentlich 

die Funktionen malloc() und free() modifiziert oder komplett selbst geschrieben werden, 

meist reichen aber Einstellungen in den Linkeroptionen, man muss nur definieren, welcher Speicherbereich 

von der Speicherverwaltung benutzt werden darf. 

Um die Funktionen für die Zeitverwaltung (time.h) anzupassen empfiehlt sich die Konsultation der 

Dokumentation zum Entwicklungssystem. 



4 Startupcode 

Bevor ein C-Programm zu laufen beginnt (main() aufgerufen wird) müssen einige Initialisierungsaufgaben 

erledigt werden. Diese sind hochgradig Prozessorspezifisch und müssen meistens (mind. 

teilweise) in Assembler programmiert werden. Dazu gehören üblicherweise die Initialisierung der 

globalen und statischen Variablen (In C++ auch der statischen Objekte), Initialisierung gewisser 

Bibliotheksfunktionen, Initialisierung der Standard Ein/-Ausgabefunktionen, Minimalkonfiguration 

der Hardware und Initialisierung spezieller Prozessorregister (Einschalten und Konfiguration des 

RAM, falls nötig, eventuell ein kurzer Systemtest), und schliesslich Initialisieren des Stack- und 

Framepointers (zur Verwaltung von Unterprogrammaufrufen und lokalen Variablen). Erst jetzt kann 

und wird die Funktion main() aufgerufen. 

In unserem System befindet sich der Startupcode in der Datei pmn332.68k. Nach einem Reset wird 

zuerst in diesen Initialisierungscode gesprungen, und erst von hier aus main() aufgerufen. 

Auf die genaue Funktion dieses Assemblercodes wird hier nicht weiter eingegangen, in dieser Datei 

sollten sie keine Änderungen vornehmen. 

Der grundsätzliche Ablauf nach dem Einschalten der Speisung sieht bei einem Autonomen System 

etwa wie folgt aus (Vorausgesetzt der Programmcode befindet sich in einem ROM). 

Ablauf: 

Reset 

Startupcode 

Bibliothek und Runtimesystem 

Initialisieren 

main() 

Ende 

Bei Programmen für Mikrocontroller kehrt die Funktion main() normalerweise nie zurück, sondern 

arbeitet in einer Endlosschlaufe die Prozesssteuerungsaufgaben ab. 

Wenn main() doch einmal zurückkehren sollte, ist nicht genau definiert was geschieht. Meist wird 

einfach in eine Endlosschlaufe gesprungen, aber es wäre auch sinnvoll, das System zurückzusetzen 

und wieder von vorne zu beginnen. 

Bei einem PC ist klar was nach dem Ende von main() geschieht: Das Programm ist zu Ende, es werden 

alle Fenster des Programms geschlossen und das System wartet auf weitere Benutzereingaben, 

oder fährt herunter, wenn auch das Betriebssystem selbst beendet wird. 

Bei Mikrokontrollern gibt es üblicherweise kein solches übergeordnetes System, und so muss sich 

der Entwickler selbst überlegen, was er in diesem Falle tun will. (Möglichst etwas Sinnvolles, das 

die Sicherheit und die Stabilität des zu steuernden Prozesses nicht beeinträchtigt. Ein Navigationssystem 

sollte sich vielleicht wieder neu initialisieren oder das Fahrzeug anhalten, aber nicht einfach 

anhalten und das Fahrzeug in die letztgewählte Richtung weiterfahren lassen). 



5 Interrupts 

5.1 Einführung 

Interrupts sind ein wichtiges Hilfsmittel, um Echtzeitanforderungen zu erfüllen. Ein Interrupt wird 

immer durch ein (meist externes) Ereignis ausgelöst und unterbricht das laufende Programm zu einem 

beliebigen Zeitpunkt. 

Tritt ein Interrupt auf, so wird augenblicklich ein spezielles Unterprogramm aufgerufen, welches 

das entsprechende Ereignis behandelt. In diesem Zusammenhang spricht man von einer 'Interrupt 

Service Routine', kurz ISR. Die Unterbrechungsanforderung wird 'Interrupt Request' genannt. Wenn 

die Interruptroutine zu Ende ist (Das Ende der Funktion oder ein return erreicht), wird im unterbrochenen 

Programm weitergefahren, als ob nichts geschehen wäre. 

Beispiel für einen Interrupt aus dem täglichen Leben: 

Sie sitzen vor dem Computer und schreiben an einem Stück Programmcode. Plötzlich 

kommt ein Kollege, der Ihnen eine Frage stellt. Sie unterbrechen das Programmieren 

und beantworten dem Kollegen seine Frage, anschliessend arbeiten Sie an Ihrem Programm 

weiter. Es wäre auch möglich, dass, während Sie mit dem Kollegen sprechen Sie 

ein Lehrer unterbricht und fragt was los ist. (Die Unterbrechung wird durch eine weitere 

Unterbrechung unterbrochen.) 

Wenn Sie gerade mitten im Schreiben von einem schwierigen Stück Code sind, kann es 

auch sein dass Sie nicht gestört werden wollen, dann ignorieren Sie Ihren Kollegen oder 

sagen Ihm, dass er kurz warten soll. (Aber wenn der Lehrer erscheint, werden Sie Ihre 

Arbeit vielleicht dennoch unterbrechen). 

Schematische Darstellung eines Interrupt Requests: 

Hauptprogramm 

Interruptroutine 

Kontext 

sichern 

Ereignis 

Interrupt Request 

laufende 

Instruktion 

erste 

Instruktion 

nächste 

Instruktion 

letzte 

Instruktion 

Kontext wiederherstellen 

Der 'Kontext' ist der aktuelle Zustand vom Hauptprogramm (Prozessorregister, Stack) und die Interruptroutine 

muss sicherstellen, dass das Hauptprogramm am Ende der Interruptroutine so weiterfährt, 

als ob nichts geschehen wäre. 

Wie wenn Sie auf einem Notizzettel festhalten, woran Sie gerade gearbeitet haben und 

was Sie als nächstes tun wollten, bevor Sie sich Ihrem Kollegen zuwenden. 



5.2 Definition einer Interruptroutine 

Da eine Interruptroutine ein laufendes Programm zu einem beliebigen Zeitpunkt unterbrechen kann, 

muss der Compiler für eine Interruptroutine speziellen Code erzeugen. Bei normalen Unterprogrammen 

weiss der Compiler immer genau, wann sie auftreten, und welche internen Daten (Prozessorregister) 

er sichern muss. Bei Interruptroutinen ist das nicht bekannt, deshalb müssen zu Beginn 

der Routine vorsorglich alle wichtigen Daten gerettet, und am Ende der Routine wieder hergestellt 

werden. Dazu muss man aber dem Compiler sagen, dass es sich um eine Interruptroutine handelt. 

Dies ist in der Sprache C nicht vorgesehen, deshalb hat jeder Compilerhersteller seine eigene 

Spracherweiterung dazu. Einige erwarten ein Schlüsselwort wie interrupt, __int, 

interupt_nn oder #pragma interrupt. Die genaue Syntax muss man dem jeweiligen 

Compilerhandbuch entnehmen. Bei Tasking muss man das Schlüsselwort _IH der Funktion voranstellen, 

die Funktion darf zudem keinen Rückgabewert und keine Argumente besitzen. Mit Tasking 

müsste also ein Interrupthandler wie folgt definiert werden: 

_IH void TimerInterruptHandler(void) /* Wird regelmaessig alle */ 

{ /* 100ms vom Timer */ 

Timeout--; /* Interrupt aufgerufen */ 

if (Timeout 0) { 

Magic = 1.0 / (float)Timeout; 

} 

} 

In obigem Beispiel kann ein Division durch Null Fehler auftreten! Weshalb? 



Weil der Interrupt gerade nach der Abfrage auftreten könnte, und Timeout von 1 auf 0 dekrementieren 

könnte, bevor die Division durchgeführt wird. 

Um das zu umgehen muss dieses Stück Code von Interrupts geschützt werden: 

_IH void TimerInterruptHandler(void) 

{ 

Timeout--; 

} 

void Trouble (void) 

{ 

DisableInterrupts(); 

if (Timeout > 0) { 


} 

EnableInterrupts(); 

} 

Das ist schon viel Besser, hat aber immer noch ein kleines Problem. Wenn die Interrupts beim Aufruf 

der Funktion Trouble() bereits ausgeschaltet waren, sind sie nach dem Aufruf der Funktion wieder 

eingeschaltet, was normalerweise nicht erwünscht ist. Deshalb gibt es meist noch eine Funktion, 

mit der man herausfinden kann, ob die Interrupts im Moment gesperrt oder freigegeben sind. Optimal 

würde der Code also wie folgt aussehen: 


{ 

Timeout--; 

} 


{ 

int OldInterruptState; 

} 

OldInterruptState = GetInterruptState(); 

DisableInterrupts(); 



} 

/* Enable Interrupts only if they were enabled before */ 

if (OldInterruptState == 1) { 

EnableInterrupts(); 

} 

ACHTUNG 

Auch scheinbar sicherer Code wie a++ oder a = a + 1 muss geschützt werden, weil dieser nicht 

in eine einzige, sondern üblicherweise in eine Folge von mehreren Prozessoranweisungen (Lesen, 

Inkrementieren, Schreiben) übersetzt wird, die auch unterbrochen werden kann. Bei einigen Prozessoren 

gibt es für diese Fälle spezielle 'atomare' Instruktionen, welche nicht unterbrochen werden 

können. Aber um diese einsetzen zu können sind wieder Compilererweiterungen erforderlich, welche 

dem entsprechenden Compilerhandbuch entnommen werden müssen. 



5.4 Interrupthandling beim 68xxx 

Bei unserem System läuft es im Prinzip genau so wie im vorigen Kapitel beschrieben. Die Prozessoren 

der 68000er Reihe haben zusätzlich noch eine Interruptpriorisierung, das heisst dass jeder Interrupt 

eine Priorität von 1 bis 7 besitzt, und beim Sperren von Interrupts die Priorität angeben wird, 

bis zu welcher Interrupts unterdrückt werden. Interrupts mit der Priorität 7 können gar nicht unterdrückt 

werden, und sollten nur für wichtige Ereignisse wie Stromausfall oder ähnliches benutzt werden. 

Die aktuell zugelassene Priorität wird in der Interruptmaske des Statusregisters vom Prozessor abgelegt. 

In der Programmiersprache C gibt es aber keine direkte Möglichkeit, auf Prozessorregister zuzugreifen, 

also müsste man Assemblereinschlüsse dazu verwenden. Der Taskingcompiler stellt aber 

Funktionen zum Lesen und Schreiben der Interruptmaske zur Verfügung, so muss nicht auf Assembler 

zurückgegriffen werden. 

Zum Lesen der aktuellen Interruptmaske dient die Funktion _GPL(), sie liefert eine Zahl zwischen 0 

bis 7 (0 = alle Interrupts erlaubt, 7 = alle bis auf Priorität 7 gesperrt (Priorität 7 ist flankengesteuert), 

6 = alle bis auf Priorität 7 gesperrt (Priorität 7 ist Pegelgesteuert), 5 = alle bis auf Priorität 6 und 7 

gesperrt, usw.). 

Zum Setzen der Interruptmaske (Sperren der Interrupts) dient die Funktion _SPL(). Um alle Interrupts 

(bis auf Level 7) zu sperren müsste also _SPL(7) benutzt werden. Um alle Interrupts zu erlauben 

müsste _SPL(0) benutzt werden. 

Für unser System würde das Beispiel aus dem vorherigen Kapitel wie folgt aussehen: 


{ 

Timeout--; 

} 


{ 

int OldInterruptLevel; 

OldInterruptLevel= _GPL(); /* Alten Zustand merken */ 

_SPL(7); /* Interupts sperren */ 



} 

} 

/* Alten Zustand wieder herstellen */ 

_SPL(OldInterruptLevel); 

Pegelgesteuerte Interrupts versus Flankengetriggerte Interrupts: 

Pegelgesteuerte Interrupts werden vom Prozessor solange erkannt, wie der entsprechende Pegel anliegt. 

Das heisst der Prozessor springt gleich wieder in die Interruptroutine, wenn der Interrupt nach 

dem Ende (Oder der Freigabe der entsprechenden Priorität) immer noch anliegt. 

Bei flankengetriggerten Interrupts reagiert der Prozessor auf einen Wechsel von inaktiv auf aktiv, es 

wird nur der Wechsel beachtet, der Pegel spielt keine Rolle. Flankengetriggerte Interrupts können 

oft nicht gesperrt werden. Falls doch merkt sich der Prozessor den Pegelwechsel, und springt nach 

der Freigabe des Interrupts gleich in die entsprechende Routine (Aber nur einmal pro Flanke, wenn 

im gesperrten Zustand mehrere Flanken auftreten, wird nur eine gespeichert). 



5.4.1 Interruptvektoren 

Das Definieren einer Interruptroutine alleine reicht noch nicht aus, der Prozessor muss auch wissen, 

welche Routine er im Falle eines Interrupts aufrufen soll. Das Prinzip ist bei allen Prozessoren dasselbe. 

Entweder gibt es irgendwo im Speicher eine Tabelle, in welcher die Adressen der Funktionen 

eingetragen werden müssen, oder der Prozessor springt an eine vom Prozessorhersteller vordefinierte 

Adresse, und es ist die Aufgabe des Programmierers dafür zu sorgen, dass an dieser Stelle sinnvoller 

Programmcode steht. 

Die 68000er Familie arbeitet mit einer Vektortabelle, welche im folgenden vorgestellt wird. 

In der Tabelle ist Platz für 256 Interruptroutinen vorgesehen. An jedem Platz steht die Anfangsadresse 

(Zeiger auf die Funktion) der jeweiligen Interruptroutine. Die ersten 64 Einträge (0 bis 63) 

sind für Systemzwecke vordefiniert und behandeln spezielle Ereignisse wie unerlaubte Speicherzugriffe, 

Illegale Instruktionen, Reset, Trapinsstruktionen, Division durch Null, uninitialisierte Interrupts 

und weitere. 

Der Anwender kann (Und sollte) auch Behandlungsroutinen für diese Ereignisse schreiben, welche 

sinnvoll darauf reagieren. Das kann im einfachsten Fall das Einschalten einer Fehler-Led und Anhalten 

des Prozessors sein. 

Die restlichen 192 Einträge (64-255) sind zur freien Verfügung für den Benutzer. Jeder Peripheriebausten, 

der einen Interrupt auslösen kann, muss der CPU mitteilen, welcher Vektor benutzt werden 

soll. Diese Vektornummer muss ebenfalls vom Benutzer in ein Register des Peripheriebausteins 

programmiert werden. Für Peripheriebausteine, die keinen Vektor liefern können, gibt es für die 7 

Interruptprioritätsstufen je einen 'Autovektor' in den reservierten 64 Tabelleneinträgen. 

Die Vektortabelle beginnt üblicherweise bei der Adresse 0x000000, kann aber vom Programmierer 

an einen beliebigen Ort im Speicher plaziert werden. Dies muss aber in Assembler geschrieben werden, 

und erfolgt am besten im Startupcode. 

Prinzipieller Aufbau des Interrupthandlings: 

Memory des Prozessors 

Timer 

Vektornummer 

Zeitzähler 

78 

123994 

Code für Timerinterrupt 

Tastenüberwacher 

Vektornummer 75 

Tastencode 1001 

Code für Tasteninterrupt 

CPU 

Vektortabelle 78 

76 

75 

74 



Jedem Peripheriebaustein wird eine eigene Vektornummer für seine Interrupts zugeteilt. Anschliessend 

wird in der Interruptvektortabelle am entsprechenden Platz die Adresse der dazugehörigen 

Interruptroutine eingetragen. Die Interruptvektortabelle kann man sich unter C als ein Array von 

Zeigern auf Funktionen vorstellen, und so muss auch auf sie zugegriffen werden. (Da in der Tabelle 

Adressen eingetragen werden, und jede Adresse 4 Bytes (32 Bit) Platz belegt, ist die Adresse des 

Eintrags gleich der vierfachen Vektornummer). 

Um eine Handlerfunktion in die Vektortabelle eintragen zu können, muss die Eintragsadresse in 

einen Zeiger auf einen Zeiger auf eine Funktion die void zurückliefert und keine Argumente hat 

umgewandelt werden (uff!). 

Nehmen wir an, wir wollen den TimerInterupthandler auf den Vektor 129 setzen, dann ergäbe sich 

folgender Code: 

*((void (**)(void))(129*4)) = TimerInterruptHandler; 

Zur Erinnerung: 

int *p; ist ein Zeiger auf einen int. 

int **p; ist ein Zeiger auf einen Zeiger auf einen int. 

void (*p)(void); 

void (**p)(void); 

ist ein Zeiger auf eine Funktion der Form void f(void). 

ist ein Zeiger auf einen Zeiger auf eine Funktion der Form void 

f(void). 

Der Umwandlungsoperator (Cast-Operator) sieht immer gleich aus wie die entsprechende Variablendeklaration, nur dass 

der Variablenname weggelassen wird, und der ganze Ausdruck in Klammern gesetzt wird. 

(int *)123; 

Wandelt die Zahl 123 in einen Zeiger auf int (Adresse) um. 

(void (*)(void))123; Wandelt die Zahl 123 in einen Zeiger auf eine Funktion der Form 

void f(void).um. 

(void (**)(void))123; Wandelt die Zahl 123 in einen Zeiger auf einen Zeiger auf eine 

Funktion der Form void f(void) um. 

*((int *)123) = 17; Wandelt die Zahl 123 in einen Zeiger auf int (Adresse) um, und 

schreibt 17 an diese Adresse. An der Adresse 123 im Speicher steht 

also jetzt der Wert 17. 

*((void (**)(void))123) = f; Wandelt die Zahl 123 in einen Zeiger auf einen Zeiger 

auf eine Funktion der Form void f(void) um und schreibt die Adresse 

der Funktion f dorthin. An der Adresse 123 im Speicher steht also 

nun die Adresse der Funktion f (Oder anders gesagt, ein Zeiger 

auf die Funktion f). 

Mit einem Makro kann man das ganze etwas 'entschärfen': 

#define SET_INTERRUPT_HANDLER(VectorNumber, Handler) \ 

(*((void (**)(void)) (4*VectorNumber)) = Handler) 

SET_INTERRUPT_HANDLER(129, TimerInterruptHandler); 

(Mit einem '\' kann eine Makrodefinition auf die nächste Zeile erweitert werden, die beiden Zeilen werden von Compiler 

[resp. Präprozessor] als eine einzige Zeile betrachtet.) 



Und mit Typedefs wird das ganze noch einmal etwas besser lesbar: 

typedef void (*Handler)(void); /* Zeiger auf Funktion */ 

typedef Handler *HandlePtr; /* Zeiger auf Zeiger auf fkt */ 

*((HandlePtr) (4*129)) = TimerInterruptHandler; 

/* Oder mit Makros */ 

#define SET_INTERRUPT_HANDLER(VectorNumber, Handler) \ 

(*((HandlePtr)(4*VectorNumber)) = Handler) 

SET_INTERRUPT_HANDLER(129, TimerInterruptHandler); 

Oder wenn man das ganze Arraymässig betrachtet (Was durchaus sinnvoll ist, da die Interruptvektortabelle 

schliesslich nichts anderes als ein Array von 256 Zeiger auf Funktionen ist), ergibt sich 

folgender Code: 


Handler *VektorTabelle = (Handler *)0; /* Tabelle beginnt bei */ 

/* Adresse 0 */ 

VektorTabelle[129] = TimerInterruptHandler; 

/* Weitere Eintraege sind jetzt einfach moeglich */ 

VektorTabelle[134] = TastenInterruptHandler; 

VektorTabelle[156] = PowerLossInterruptHandler; 

Unbenutzte Einträge lässt man am Besten auf einen Defaulthandler verweisen, welcher eine Fehlermeldung 

ausgibt, das System stoppt oder eine andere, sinnvolle Massnahme ergreift. 



5.5 Aufgabe 4 

Schreiben Sie ein Programm, welches mit Hilfe des Timerinterrupts eine oder mehrere Led blinken 

lässt. Nebenbei soll das Programm noch Ein und Ausgaben via serielle Schnittstelle tätigen, z. B. 

mit scanf() zwei Zahlen einlesen, und deren Summe mit printf() ausgeben. 

Genauere Informationen über die Register des Timers des Kits und dessen Konfiguration können sie 

dem Dokument MC68332UM.pdf ab Kapitel 4.2.11, 'Periodic Interrupt Timer' (Seite 4-7) sowie 

Kapitel D.2.13 und D.2.14 (Seite D-11) entnehmen. Sie müssen die Register PICR und PITR korrekt 

konfigurieren, der Basistakt des Timers beträgt 32768Hz. 

Die Register des Timers befinden sich auf den folgenden Adressen: 

Zugriffsmode Breite Adresse Registername 

S/U 16 Bit 0xFFFA22 PICR 

S/U 16 Bit 0xFFFA24 PITR 

Der Zugriffsmode ist für diese Übung nicht von Bedeutung. 

5.6 Aufgabe 5 

Erweitern Sie Ihr Programm so, dass die Ein- und Ausgaben über die Serielle Schnittstelle ebenfalls 

mit Interrupts erledigt werden. Eingehende Zeichen sollen in einem Buffer abgelegt werden, und zu 

sendende Zeichen aus einem Buffer gelesen werden. Das Hauptprogramm (putc() und getc()) soll 

aus diesen Buffer lesen und schreiben. Damit wird das Hauptprogramm von der seriellen Schnittstelle 

entkoppelt, und es gehen keine Zeichen verloren, wenn das Hauptprogramm nicht augenblicklich 

reagiert. 

Hinweis: Die Empfangs- und Sendebuffer können sie als Arrays implementieren. 

Wenn ganze Telegramme gepuffert werden sollen, empfiehlt sich der Einsatz von Listen, es muss 

aber sichergestellt sein, dass das Erzeugen von Listenelementen sicher und schnell ist, was bei Malloc 

nicht unbedingt garantiert ist. (Zudem muss auch sichergestellt werden, dass malloc() und free() 

aus Interruptroutinen heraus verwendet werden dürfen). 

5.7 Interrupts und Standardbibliothek 

Auf die Verwendung von Funktionen aus der Standardbibliothek sollte grundsätzlich verzichtet 

werden. Erstens sollte eine Interruptroutine möglichst kurz sein und deshalb möglichst wenig andere 

Funktionen aufrufen, und zum anderen dürfen nur Funktionen verwendet werden, welche reentrant 

sind (Also aufgerufen werden dürfen, während sie bereits am laufen sind). Wenn z. B. gerade mit 

printf() etwas auf dem Bildschirm ausgegeben wird, und jetzt ein Interrupt auftritt welcher seinerseits 

etwas mit printf() ausgibt, ist das Chaos garantiert. Ganz abgesehen davon, dass die printf()- 

Funktion viel zu lang ist, um aus Interrupts aufgerufen zu werden. 


Anhang A Bitzugriff 

Bei der hardwarenahen Programmierung muss oft auf einzelne Bits zugegriffen werden. Dazu bieten 

sich zwei Möglichkeiten an. Einerseits die Bitmaskierung mit den bitweisen logischen Operatoren 

| und &, andererseits der Einsatz von Bitfeldern. 

Bitmaskierung 

Um in der Variablen 'Value' das Bit mit der Nummer n zu setzen, kann folgende Anweisung verwendet 

werden: 

Value = Value | (1


Bitfelder 

Peripherieregister können zur einfacheren Handhabung auch auf Bitfelder abgebildet werden, da 

Bitfelder aber sehr Compilerabhängig sind, muss jeweils die Compilerdokumentation zu Rate gezogen 

werden, bevor man sich für deren Einsatz entscheidet. 

Nach Standard belegen Bitfelder immer ein vielfaches eines ints, also ergeben sich schon Probleme, 

wenn ein int 32 Bit breit ist, aber die Peripherieregister nur 16 Bit breit sind. Bei vielen Compiler 

kann deshalb die Grösse der Bitfelder separat festgelegt werden. 

Ebenfalls nicht festgelegt ist die Zuordnung der Bits, also ob der Compiler die Bits von links nach 

rechts (31-0) oder rechts nach links (0-31) vergibt. 

Als Beispiel dient folgendes Register (An Adresse 0xFF1230): 

x x Err EI x OE Q Pp0 Richtung F S Bitzähler 

Bit 15 Bit 8 Bit 7 Bit 0 

x = unbenutzt 

Umgesetzt in C ergibt sich folgendes Bitfeld, wenn der Compiler die Zuteilung bei Bit 0 beginnt: 

struct DemoRegister { 

unsigned int BitZaehler : 4; /* 4 Bits */ 

unsigned int S : 1; /* 1 Bit */ 

unsigned int F : 1; /* 1 Bit */ 

unsigned int Richtung : 2; /* 2 Bits */ 

unsigned int Pp : 1; /* 1 Bit */ 

unsigned int Q : 1; /* 1 Bit */ 

unsigned int OE : 1; /* 1 Bit */ 

unsigned int x : 1; /* 1 Bit, unbenutzt */ 

unsigned int EI : 1; /* 1 Bit */ 

unsigned int Err : 1; /* 1 Bit */ 

}; 

/* Zeiger auf Register definieren und setzen */ 

volatile struct DemoRegister *Register; 

Register = (volatile struct DemoRegister *) 0xFF1230; 

/* Auf die Bits des Registers zugreifen */ 

Register->F = 0; 

if (Register->Richtung == 2) { 

Register->BitZaehler = 10; 

} 

while (Register->F == 0) {}; /* Warten bis Bit gesetzt */ 

Achtung: Auch wenn der Code einfach aussieht, der Compiler erzeugt daraus ähnlichen Code wie 

im vorigen Kapitel 'Bitmaskierung' vorgestellt wurde. Eine einfache Zuweisung wird also zu einer 

Folge von Schiebeoperationen und bitweisen Verknüpfungen. 

Bei unbenutzten Bits in einem Bitfeld kann der Name auch weggelassen werden, also 

unsigned int : 1; /* 1 Bit, unbenutzt */ 



Schattenregister 

Da Hardwareregister nicht immer gelesen werden können, man aber bei Bit Setz- und Löschoperationen 

den aktuellen Zustand des Registers kennen muss, wird für dieses Problem eine Lösung benötigt. 

Die einfachste Lösung ist die Einführung eines 'Schattenregisters', das ist einfach eine (statische) 

Variable, auf welche parallel zum Register immer alle Schreiboperationen durchgeführt werden, 

und anstelle des Registers wird aus dieser Variablen gelesen. 

Das führt zu folgendem Code: 

static unsigned int ShadowRegister; 

/* Initialisierung */ 

ShadowRegister = 0; /* Schattenregister und */ 

Register = 0; /* Echtes Register initialisieren */ 

/* Ein Bit setzen */ 

ShadowRegister = ShadowRegister | (1 4 wird zu 0xF8000000 

0x80000000u >> 4 wird zu 0x08000000 

Deshalb beim Rechtsschieben immer auf das Vorzeichen achten, und am Besten unsigned Datentypen 

verwenden. 

Probleme beim Casten (Umwandeln) 

Beim Umwandeln eines kleinen Datentypen in einen grösseren muss man beachten, dass bei vorzeichenbehafteten 

Zahlen das Vorzeichen dupliziert wird (Vorzeichenrichtige Erweiterung), was oft zu 

Problemen führt. 

Beispiel: 

char Byte = 0x80; /* Annahme: char ist signed */ 

Value = 0x00430000; 

Value = Value | (Byte


Anhang B Zahlensysteme 

Die meisten Mikroprozessoren rechnen im Binärsystem. Im Normalfall bemerkt man als Programmierer 

in einer Hochsprache nicht viel davon (Ausser bei den Datentypen). 

Sobald man aber auf Hardware zugreift, sind Kenntnisse der Zahlensysteme und der internen Repräsentation 

der Zahlen von Vorteil. 

Gegenüberstellung der Zahlensysteme 

Unser Dezimalsystem hat als Basis die Zahl 10, und besteht aus den Ziffern 0 bis 9. Das Binärsystem 

besitzt die Basis 2 und besteht aus den Ziffern 0 und 1. Und das Hexadezimalsystem benutzt 

die Basis 16, und die Ziffern 0 bis 9 sowie A bis F. 

Dezimal Hexadezimal Binär 

00 

01 

02 

03 

04 

05 

06 

07 

08 

09 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

00 

01 

02 

03 

04 

05 

06 

07 

08 

09 

0A 

0B 

0C 

0D 

0E 

0F 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

00000 

00001 

00010 

00011 

00100 

00101 

00110 

00111 

01000 

01001 

01010 

01011 

01100 

01101 

01110 

01111 

10000 

10001 

10010 

10011 

10100 

10101 

10110 

10111 

11000 

11001 

11010 

Nebenstehend die Zahlen von 0 bis 26 in den 

verschiedenen Systemen einander gegenübergestellt. 

Zahlen können sehr einfach vom Hexadezimal 

ins Binärsystem und zurück konvertiert werden, 

da eine Ziffer des Hexadezimalsystems 

immer 4 Bit im Binärsystem entspricht. Man 

muss also nur die Binärzahl in Vierergruppen 

unterteilen, und den Gruppen jeweils eine 

Hexziffer zuweisen, oder für jede Hexziffer 

vier Bits schreiben. (Der grau hinterlegte Bereich 

der Tabelle kann zur Umwandlung einer 

Hexziffer benutzt werden) 

Die Umwandlung von Dezimal in Binär und 

umgekehrt ist viel schwieriger. 

Deshalb wird bei der hardwarenahen Programmierung 

meist das Hexadezimalsystem 

angewandt. (Auch weil die Zahlen so kürzer 

und leichter lesbar sind als in der Binärdarstellung) 

Negative Zahlen werden intern meist in der sogenannten Zweierkomplementdarstellung gespeichert. 

Dabei zeigt das höchstwertige Bit an, ob die Zahl positiv oder negativ ist. Nachfolgend eine kleine 

Tabelle positiver und negativer Zahlen, mit den jeweiligen Binär, resp. Hezadezimale repräsentationen. 

Dezimal Hex, 16-Bit, vorzeichenbehaftet (Hex) Binär 

+32767 0x7FFF 0111 1111 1111 1111 

+255 0x00FF 0000 0000 1111 1111 

+16 0x0010 0000 0000 0001 0000 

+1 0x0001 0000 0000 0000 0001 

0 0x0000 0000 0000 0000 0000 

-1 0xFFFF (0x10000 - 0x0001) 1111 1111 1111 1111 

-16 0xFFF0 (0x10000 - 0x0010) 1111 1111 1111 0000 

-255 0xFF01 (0x10000 - 0x00FF) 1111 1111 0000 0001 

-32768 0x8000 (0x10000 - 0x8000) 1000 0000 0000 0000 



Fliesskommazahlen 

Um einen grösseren Dynamikbereich zu erhalten, werden Fliesskommazahlen eingesetzt. Diese bestehen 

aus einer Mantisse und einem Exponenten. Solche Zahlen sind aus dem wissenschaftlichen 

Umfeld nicht wegzudenken. Ein Beispiel wäre 123.45*10 9 welches auch als 123.45E9 geschrieben 

werden kann. 

Im Computer kommt auch für Fliesskommazahlen wieder das Binärsystem zum Zug. Fliesskommazahlen 

werden intern im Format nnnnnn*2 eeee . gespeichert, wobei nnnnn und eeee jeweils Binärzahlen 

sind. Die meisten Computer und Compiler benutzen das im IEEE 754 Standard festgelegte Format 

zum Speichern von Fliesskommazahlen. 

Der Standard legt grundsätzlich ein 32-Bit Format (Single Precision / float) und ein 64-Bit Format 

(Double Precision / double) fest. (Zusätzlich werden noch erweiterte Formate definiert). 

Name Vorzeichen (s) Exponent (e) Mantisse (m) Offset (b) 

Single Precision 1 [Bit 31] 8 [Bits 30-23] 23 [Bits 22-00] 127 

Double Precision 1 [Bit 63] 11 [Bits 62-52] 52 [Bits 51-00] 1023 

Beispiel für Single Precision: 

s eeeeeeee mmmmmmmmmmmmmmmmmmmmmmm 

Bit 31 Bit 0 

Das Dezimaläquivalent einer solchen Fliesskommazahl berechnet sich zu (-1) s * 1.m * 2 (e-b) . 

Vor dem Abspeichern wird die Zahl 'normalisiert', das heisst sie wird in die Form 1.xxx * 2 y (im 

Binärsystem) gebracht. Der Exponent wird dabei so gewählt, dass die Mantisse genau eine Vorkommastelle 

mit dem Wert 1 hat (Ausser bei dem Wert 0). Und weil diese Vorkommastelle immer 

1 ist, wird sie nicht mit abgespeichert. So können mit 23 Mantissenbits eigentlich 24 Bits gespeichert 

werden. Von der Mantisse wird immer der Betrag abgespeichert. Der Exponent wird nicht 

direkt abgespeichert, sondern es wird noch ein Offset dazu addiert, so dass der abgespeicherte Wert 

immer positiv ist. Bei Single Precision wird also für den Exponenten 0 der Wert 127 abgespeichert. 

Die Werte -127 und 128 sind reserviert für Spezialfälle und dürfen für normale Exponenten nicht 

verwendet werden. Zahlen, welche mit dem zulässigen Exponentenbereich (-126 bis +127) nicht 

dargestellt werden können, werden in Unendlich, Null oder 'Denormalisierten Zahlen' umgewandelt. 

Spezielle Werte 

Null: 

Der Wert Null wird durch ein Exponentenfeld von 0 und einem Mantissenfeld von 0 dargestellt. 

Das Vorzeichenbit wird berücksichtigt, es gibt also +0 und -0, welche bei Vergleichen aber als identisch 

angesehen werden. 

Denormalisiert: 

Wenn das Exponentenfeld 0 ist, aber die Mantisse von Null verschieden, liegt eine Denormalisierte 

Zahl vor. Dies ist eine Zahl, welche keine führende 1 vor dem Dezimalpunkt hat (Weil sie zu klein 

zum normalisieren war). Null ist also ein Spezielafall einer denormalisierten Zahl. 



Unendlich: 

Wenn das Exponentenfeld aus lauter 1, und Mantisse 0 ist, liegt ein unendlicher Wert vor. Mit unendlichen 

Werten kann normal gerechnet werden, das verhalten ist genau definiert. Das Vorzeichenbit 

unterscheidet zwischen positiv und negativ Unendlich. 

Not A Number (NaN) 

Der Wert NaN repräsentiert eine ungültige Zahl. (Z. B. als Ergebnis einer undefinierten mathematischen 

Operation). Wenn an einer Berechnung eine NaN beteiligt ist, wird das Ergebnis wieder zu 

einer NaN. Eine NaN erkennt man an einem Exponentenfeld aus lauter 1 und einer von Null verschiedenen 

Mantisse. Man uneterscheidet noch zwischen SNaN (Signaling NaN, können Fehlermeldungen 

auslösen) und QNaN (Quiet NaN, ohne Meldung). QNaN sind für undefinierte mathematische 

Operationen gedacht, und SNaN für unerlaubte Operationen, oder zum Füllen von uninitialisiertem 

Speicher. 

Hier nocheinmal kurz zusammengefasst die verschieden Bedeutungen nach IEEE 754: 

Vorz. Exponent (e) Fraction (f) Wert 

0 00..00 00..00 +0 

0 00..00 

0 

00..01 

: 

11..10 

00..01 

: 

11..11 

XX..XX 

0 11..11 00..00 +Unendlich 

0 11..11 

00..01 

: 

01..11 

0 11..11 

10..00 

: 

11..11 

1 00..00 00..00 -0 

1 00..00 

00..01 

: 

11..11 

1 

00..01 

: 

11..10 

XX..XX 

1 11..11 00..00 -Unendlich 

1 11..11 

00..01 

: 

01..11 

1 11..11 

10..00 

: 

11.11 

Positive denormalisierte Zahl 0.f × 2 (-b+1) 

Positive normalisierte Zahl 1.f × 2 (e-b) 

SNaN (Signaling not a Number) 

'Meldende' Ungültige Zahl. 

QNaN (Quiet not a Number) 

'Stille' Ungültige Zahl 

Negative denormalisierte Zahl -0.f × 2 (-b+1) 

Negative normalisierte Zahl -1.f × 2 (e-b) 

SNaN (Signaling not a Number) 

'Meldende' Ungültige Zahl. 

QNaN (Quiet not a Number) 

'Stille' Ungültige Zahl 

Achtung, da Fliesskommazahlen nur eine beschränkte Auflösung haben, muss auf Probleme wie 

Auslöschung signifikannter Stellen geachtet werden. Auch sollte man nie auf Gleichheit testen, 

sondern immer auf einen Bereich (statt a == b besser (fabs((a - b)/a) < epsilon, wobei epsilon der 

gewünschten, mit der Auflösung [24/53 Bit] noch möglichen Genauigkeit entspricht) 



Anhang C Interrupts 

Um sich den grundsätzlichen Ablauf des Interupthandling vorzustellen, kann man sich folgenden 

Ablauf denken: Man nimmt einfach an, dass der Prozessor nach jeder ausgeführten Instruktion kurz 

überprüft, ob ein Interruptereignis eingetroffen ist. Falls sich ein Interrupt ereignet hat, wird umgehend 

die entsprechende Handlerfunktion aufgerufen (Noch bevor die nächste Instruktion ausgeführt 

wird). Mit der nächsten Instruktion wird erst nach Beendigung der Handlerfunktion weitergefahren. 

Nur um sich das Prinzip vorzustellen, kann man sich folgenden Code 

....... 

a = b * 3; 

while (a < 77) { 

a = a * a; 

b --; 

} 

....... 

in diesen Code umgesetzt vorstellen: 

....... 

if (InteruptPending) { /* Interruptroutine ausführen, falls nötig */ 

HandleInterrupt(); 

} 

a = b * 3; 



} 

while (a < 77) { 



} 

a = a * a; 



} 

b --; 



} 

} 



} 

....... 

Selbstverständlich wird in der Realität nicht Extracode eingefügt, sondern die Abfrage und der Aufruf 

der Interruptfunktion erfolgt automatisch durch die Hardware im Prozessor. Zudem erfolgt die 

Abfrage natürlich nicht nach jedem C-Befehl, sondern nach jedem Maschinensprachebefehl. Und 

weil die meisten C-Befehle in mehrere Maschinensprachebefehle umgesetzt werden, kann die Unterbrechung 

auch mitten in einem C-Befehl erfolgen. (Bei a = b * c; zum Beispiel nach der Multiplikation, 

aber vor der Zuweisung). Und gerade dieses Unterbrechen einer Anweisung führt zu den 

gängigen Problemen, welche ein zeitweises Ausschalten (Disable/Enable) von Unterbrechungen 

erfordern. 




Handler *HandlerTable= (Handler *)0; /* Tabelle beginnt bei */ 

/* Adresse 0 */ 

void HandleInterrupt(void) 

{ 

if (InterruptEnabled) { /* Nur weiter wenn Interupts */ 

int Index = 0; /* erlaubt sind */ 

Index = GetVectorNumberFromHardware(); /* Vektornummer von */ 

/* Pheripherie holen */ 

HandlerTable[Index](); /* Und passenden Handler via */ 

} /* Tabelle aufrufen */ 

}

Hardwarenahe_Programmierung_in_C_V1_2

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?