est Bewegung durch eine 3D-Landschaft mit ... - David Zaadstra

est 

Alexander Fuchs 

David Zaadstra 

Bewegung durch eine 

3D-Landschaft mit 

Steuerung durch 

Fernbedienung 

Projektarbeit 2002 

Berufskolleg 

Elektronikschule Tettnang

est 

Alexander Fuchs, BKIK2/1 

David Zaadstra, BKIK2/1 

Bewegung durch eine 

3D-Landschaft mit 

Steuerung durch 

Fernbedienung 

Betreuer: 

Projektarbeit 2002 

Berufskolleg 

Herr Hambsch 

Herr Czok 

Elektronikschule Tettnang 

Oberhofer Str. 25, 88069 Tettnang, http://www.elektronikschule.de

Projektarbeit 2002, BKIK 2/1 

David Zaadstra, Alexander Fuchs 

Bewegung durch eine 3D-Landschaft mit Fernbedienung 


Inhaltsverzeichnis 

Vorwort 3 

1. Zusammenfassung 4 

1.1 Deutsch 

1.2 English (summary) 

2. Arbeitsprozessbericht 6 

3. Projektaufbau 7 

3.1 Blockschaltbild 

4. Fernbedienung 8 

4.1 Die Signale der Fernbedienung 

4.2 Die Infrarot-Protokolle 

4.2.1 RC-5 

4.2.2 RECS80 

4.2.3 NEC 

4.3 Die Empfängerdiode SFH 5110 

5. Dekodierung der Signale mit dem Mikrocontroller 14 

5.1 Der einzulesende Datensatz 

5.2 Das Assemblerprogramm 

5.2.1 Funktion 

5.2.2 PAP 

5.2.3 Code 

6. Kommunikation Mikrokontroller -> PC 46 

6.1 Empfang der Daten mit den Communications-Funktionen des Win32-API 

6.2 Die MTV24-Klasse 

7. Die ManiaTech 3D-Engine 50 

7.1 Einführung in (Echtzeit-)3D-Grafik 

7.1.1 Polygone 

7.1.2 Darstellung von Dreiecken 

7.1.3 Transformationen 

7.1.4 Texturen und Farben 

7.1.5 Licht 

7.1.6 Zeichnen („Rendern“) von Grafik 

7.2 Struktur der Engine 

7.3 Arbeitsweise der Engine 

8. Die Landschaft 60 

8.1 Das Optionsmenü 

8.2 Laden der Landschaft 

8.3 Erzeugung der 3D-Daten 

8.4 Der Himmel 

8.5 Der Demomodus 

- 1 -





8.6 Die Kontrollen 

8.6.1 Fernbedienung 

8.6.2 Tastatur 

8.7 Das Hauptprogramm 

8.7.1 Das Struktogramm 

8.7.2 Der Code 

9. Schlussbemerkung 79 

10. Anhang 80 

10.1 Literaturverweise 

10.2 Datenblatt SFH 5110 

- 2 -





Vorwort 

Nachdem wir davon ausgehen, dass die meisten Leser prinzipiell kein Vorwort lesen, halten 

wir uns so kurz wie möglich, um der Dokumentation unseres Projektes nicht im Wege zu 

stehen (und in der Hoffnung, dass das Vorwort zumindest überflogen wird.) 

Die Idee zu unserem Projekt hat sich recht schnell entwickelt. Da wir uns sowieso schon 

vorher mit 3D-Grafik beschäftigt hatten, war der Entschluss, eine 3D-Landschaft zu 

programmieren, schnell gefasst. Um aber eine größere Bandbreite unseres Fächerbereiches 

abzudecken, entschieden wir uns, zusätzlich auch Anwendungen aus der Elektronik und der 

Informationstechnik mit einzubeziehen. So stand also der Entschluss, mittels Steuerung durch 

eine kabellose Bedieneinheit eine virtuelle 3D-Welt zu bewegen. 

Dies kann heute viele verschiedene Anwendungen in Industrie, Heim- und 

Präsentationstechnik, wie z.B. Wettersimulationen oder Modelldarstellungen von 

Fahrzeugprototypen, finden. 

Danke an Daniel „sirleto“ Renkel, der die Texturen und die Höhenkarte für die Landschaft zur 

Verfügung stellte, sowie an Jason Shankel, dessen Filterfunktionen im Landschaftscode zum 

Einsatz kommen. 

- 3 -





1. Zusammenfassung 

1.1 Deutsch 

Das Projekt ist in zwei Teilen zu sehen: Der Empfang und die Dekodierung der 

Fernbedienungssignale mit dem Mikrocontroller und die 3D-Landschaft auf dem PC. Die IR- 

Signale der Fernbedienung werden durch das IR-Empfängerbauteil SFH5110 erkannt, das 

Datensignal vom Trägersignal getrennt und als TTL-Impulsfolge an den Mikrocontroller 

80C535 weitergegeben. Dieser misst die Impulslängen des Signals, speichert sie, wandelt sie 

in ein internes Format um und vergleicht dieses mit einem Datensatz von Signalen, die zuvor 

von uns aufgenommen wurden. Wurde das Signal erkannt, wird die Nummer des Signals per 

V24 an den COM1-Port des PCs gesendet. 

Der Tastencode wird vom Windowsprogramm mit den Windows-Communications- 

Funktionen empfangen. Den Nummern sind verschiedene Aktionen zugeordnet, z.B. vorwärts 

bewegen oder rechts drehen. So kann man sich durch die dreidimensionale Landschaft 

bewegen. Diese Landschaft wird durch eine Höhenkarte repräsentiert, die aus einer Bitmap 

ausgelesen wird. Diese Höhendaten werden in 3D-Daten umgewandelt und mittels der 

ManiaTech 3D-Engine 1 dargestellt. Diese Engine basiert auf Direct3D und ermöglicht die 

Darstellung und Verwaltung der 3D-Grafik, ohne aber direkte Interaktion mit der 

darunterliegenden API zu erfordern. Das PC-Programm stellt ausserdem beim Start ein 

Optionsmenü zur Verfügung, das eine Konfiguration der Grafikeinstellungen erlaubt. 

1 Unter einer (3D-)Engine versteht man im Allgemeinen eine Ansammlung von Klassen und/oder Funktionen, 

die in einem System miteinander interagieren, um bestimmte Aufgaben (z.B. die Darstellung von 3D-Grafik) zu 

vereinfachen, zu abstrahieren (von darunter liegenden APIs oder dem OS) und zu systematisieren. Der 

Unterschied zu einer Library besteht im Wesentlichen darin, dass Interaktion zwischen den Funktionen/Klassen 

besteht, sodass das Programm zu einem großen Teil von der Engine angetrieben wird. Bei einer Library dagegen 

liegt die Hauptarbeit beim Programm, es wird lediglich Funktionalität aus der Library verwendet. 

Es sei darauf hingewiesen, dass es auch andere Interpretationen des Begriffs Engine gibt, von denen sich diese 

Definition durchaus unterscheiden kann. 

- 4 -





1.2 English (summary) 

The project can be viewed in two parts: firstly the reception and decoding of remote signals 

with the help of a microcontroller, secondly the 3D-scenery on the PC monitor. The IRsignals 

of the remote control are detected and interpreted by the IR receiver component 'SFH 

5110', which then separates the data signal from the carrier signal and subsequently transmits 

it by way of a TTL pulse sequence to the micro controller ‘80C535’. After saving the data the 

micro controller measures impulse duration, transforms them into an internal format, and 

compares it to a data set of signals which have been recorded prior to this process. After 

having been interpreted , the number of the signal will be sent to COM1 port of the PC by 

way of V24. 

The keycode is received by the windows program with the help of the Windows 

communications functions. Various actions are assigned to a variety of numbers, e.g. forward 

movement or right-hand turning. This enables a user to 'move' in a three-dimensional 

landscape. This landscape is represented by a heightmap, which is read out from a bitmap. 

The altitude information is transformed into 3D data and presented by the ManiaTech 3Dengine 

1 . This engine is based on Direct3D and permits the presentation and management of 

3D graphics without needing direct interaction with the underlying API. Apart from that the 

program offers an option menu at startup, which allows configuration of the graphic settings. 

1 A (3D-)engine is commonly understood as a set of classes and/or functions which interact in a system to 

simplify, abstract (from underlying APIs or the OS) and systemise certain tasks (e.g. displaying 3D graphics). 

The difference to a library is that there is interaction between the functions/classes so that the program is largely 

driven by the engine. Contrary when using a library the main work still has to be done by the program; it merely 

uses functionality from the library. Note that there are different interpretations of the term engine which may 

differ from this definition. 

- 5 -





2. Arbeitsprozessbericht 

Das Projekt ist in zwei großen Teilen anzusehen, für die je einer von uns zuständig war: Herr 

Fuchs für die Fernbedienung und Herr Zaadstra für die Landschaft und den übrigen PC-Code. 

Jedoch haben wir uns auch teilweise mit der Arbeit des Anderen befasst. 

Hier eine chronologisch sortierte Auflistung unserer Tätigkeiten: 

Wann: Wer: Was: 

6.2.2002 Zaadstra Definition der MTLandscape-Klasse 

6.2.2002 Fuchs Experimente zum Empfang des IR-Signals mittels 

schuleigener (und nicht geeigneter) IR-Bauteile 

8.-13.2.2002 Zaadstra erster Prototyp der Landschaft, Laden der rohen 

Vertexdaten 

13.2.2002 Fuchs Suchen nach anderen Lösungen zum Empfang des 

Signals SFH5110 

16.2.2002 Zaadstra „Rundflug“ über die Landschaft 

20.2.2002 Fuchs Aufnehmen und Drucken der Signale der Fernbedienung 

22. - 23.2.2002 Zaadstra Hinzufügen der Vertexfarben basierend auf Höhe 

27.2.2002 Fuchs Entwicklung der Grundkonstruktion des Assembler- 

Programms 

2.3.2002 Zaadstra Tastatursteuerung 

6.3.2002 Fuchs Erweiterung des Assembler-Programms 

13. + 16.3.2002 Zaadstra testweise Programmierung des Optionsfensters mit MFC 

13.3.2002 Fuchs Debuggen und Testen des Programms und der Makros 

20.3.2002 Zaadstra Hinzufügen der Landschaftstexturen 

20.3.2002 Fuchs Debuggen und Testen des Programms und der Makros 

22. + 23.3.2002 Zaadstra Programmierung des Himmels 

29. - 31.3.2002 Zaadstra Entwicklung der MTV24-Klasse 

6. - 13.4.2002 Zaadstra Programmierung des Demomodus 

1. - 12.4.2002 Fuchs Dokumentation, Abschnitte 3-5 

1. - 12.4.2002 Zaadstra Dokumentation, Abschnitte 6-8 

13. + 14.4. 2002 beide Dokumentation, übrige Abschnitte 

- 6 -





3. Projektaufbau 

Die IR-Fernbedienung sendet per IR-Diode eine auf eine Trägerfrequenz aufmodulierte 

Signalfolge, die durch die IR-Empfängerdiode SFH 5110 erkannt und per TTL-Signal auf 

Port 1.1 des Mikrocontrollers 80C535 eingespeist wird. 

Dieser ist so programmiert, dass er die Signale der Fernbedienung dekodiert, vergleicht, 

erkennt und ein Steuerzeichen per V24-Protokoll an den COM1-Port des PCs sendet. 

Auf dem PC wird durch selbst entwickelte Routinen innerhalb des Programmaufbaus der 3D- 

Engine auf die Communications - Funktionen der Win32-API zugegriffen, die ausgelesenen 

Daten werden dem Programmablauf der 3D-Engine zur Verfügung gestellt. 

3.1 Blockschaltbild 

- 7 -





4. Fernbedienung 

Um unser Projekt „interaktiv“ zu gestalten und um den Anwender unabhängig von 

Computerperipherie (Maus, Tastatur) zu machen, entschieden wir uns, die Ansteuerung der 

Grafik-Engine, wie unter Punkt 3.1 zu erkennen ist, über eine externe Infrarotfernbedienung 

abzuwickeln. 

In diesem Fall verwenden wir die Infrarot-Fernbedienung eines handelsüblichen 

Satellitenreceivers vom Typ UFD200 der Marke Kathrein, welche keines der unter Punkt 4.2 

beschriebenen Protokolle unterstützt. Wir entschieden uns bewusst für eine solche, nicht 

programmierbare Fernbedienung, um unser Assemblerprogramm des Mikrocontrollers 

speziell für diese Fernbedienung abstimmen zu können, und um zu zeigen, dass man auf diese 

Art und Weise der Dekodierung nicht auf IR-Fernbedienungen angewiesen ist, die eines der 

öffentlich standardisierten Protokolle unterstützen. 

4.1 Die Signale der Fernbedienung 

Bei den Signalen der verwendeten Kathrein IR-Fernbedienung muss zwischen 2 Tasten- und 

somit auch 2 unterschiedlichen Signalarten unterschieden werden: 

- Signale generiert durch einfachen Tastendruck 

- Signale generiert durch dauerhaften Tastendruck 

Dabei sind nur 4 von insgesamt 26 Tasten in der Lage, einen dauerhaften Tastendruck zu 

senden, nämlich die „Lautstärke hoch“, die „Lautstärke runter“, die „Kanal hoch“ und die 

„Kanal runter“ Taste. Dies erscheint logisch, da man bei der Bedienung eines 

Satellitenreceivers die Zahlentasten immer nur einmal kurz drückt, bei der Regelung der 

Lautstärke jedoch länger auf der entsprechenden Taste bleibt. 

Diese Eigenschaft wird bei der Ansteuerung der 3D-Engine genutzt, indem die Tasten, die nur 

einfachen Druck zulassen, als Steuertasten für Einstellungen der Engine nutzen werden. 

Tasten, die jedoch zusätzlich auch das Signal für das „Gedrückthalten“ der Taste senden 

werden für Funktionen der Engine wie „vor“, „zurück“, „links drehen“ und „rechts drehen“ 

verwendet. 

Aufgrund der Komplexität der Signale von „Einfachtasten“ sind nun unterhalb die 4 

Signalfolgen, der genannten „Dauertasten“ bei Gedrückthalten abgebildet: 

- 8 -





Lautstärke hoch: 

Lautstärke runter: 

- 9 -





Kanal hoch: 

Kanal runter: 

- 10 -





Mehr zu den Signalen und ihrer Interpretation im Assemblerprogramm ist unter Punkt 5 

beschrieben. 

4.2 Infrarot-Protokolle 

Fernbedienungen verwenden im Allgemeinen Infrarotdioden, die bei einer Wellenlänge von 

950 nm arbeiten. Die eigentliche Information wird nach unterschiedlichen Verfahren auf eine 

Trägerfrequenz zwischen 30 kHz und 40 kHz aufmoduliert. Durch die Verwendung eines 

Trägers lässt sich das Nutzsignal besser von Störimpulsen unterscheiden, denn beispielsweise 

Leuchtstoffröhren strahlen nicht unerheblich im Infrarot-Bereich. 

Die Aufgabe der Empfängerdiode ist es, die Trägerfrequenz und das darauf übertragene 

Datensignal zu erkennen. Durch die hohe Empfindlichkeit der Empfänger erreicht man auch 

ohne große Sendeleistung eine relativ große Reichweite. Da Reflexion an Wänden oft zur 

Übertragung ausreicht, ist nicht einmal direkter Sichtkontakt zwischen Sender und Empfänger 

nötig. 

Wellenlänge und Trägerfrequenz sind leider die einzigen Faktoren, die bei verschiedenen 

Herstellern von Fernbedienungen vergleichbar sind. Damit der IR-Empfänger den 

Tastendruck auf der Fernbedienung richtig interpretieren kann, müssen die IR-Signale in 

geeigneter Weise kodiert sein. Doch bereits bei der Kodierung der Daten gibt es zwischen 

verschiedenen Herstellern wesentliche Unterschiede. Die gebräuchlichsten Protokolle für 

Infrarotbedienungen sind jedoch RC-5, RECS 80 und NEC. 

4.2.1 RC-5 

Dieses Verfahren nutzt zur Datenübermittlung die so genannte ‘biphase’ Kodierung. Dabei 

hat jedes Bit ein Zeitfenster, welches in zwei Phasen gleicher Dauer unterteilt ist. Die logische 

‘0’ wird durch einen Lichtimpuls gefolgt von einer Pause, die logische ‘1’ entsprechend durch 

eine Pause gefolgt von einem Lichtimpuls kodiert. Dadurch ergibt sich ein für RC-5-Systeme 

charakteristisches Signal mit je zwei unterschiedlichen Impuls- und Pausenlängen. Ein 

einzelnes Datenpaket ist unterteilt in ein Startbit, ein Togglebit, fünf Systembits, die das 

Empfangsgerät spezifizieren, und sechs Befehlsbits, die die eigentliche Befehlsinformation 

enthalten. Das neuere RC-6-Protokoll funktioniert analog, halbiert jedoch die Signallängen, 

sodass die Datenpakete länger ausfallen können. 

- 11 -





4.2.2 RECS 80 

Das RECS-80-Protokoll kodiert einzelne Bits durch unterschiedlich lange Pausen, die 

Lichtimpulsen konstanter Länge (140,8 µs) folgen. Die für den Bit-Wert entscheidenden 

Pausen zwischen den Lichtimpulsen betragen für die ‘0’ 5,06 ms und für die ‘1’ 7,59 ms. Es 

werden elf Bits lange Datenpakete verschickt: ein Startbit, ein Togglebit, drei Bits für das 

Subsystem und sechs Bits für das Kommando. Obwohl die Datenpakete für die Übertragung 

je nach Kommando unterschiedlich lange brauchen, ist die Gesamtlänge mit Pause bis zur 

nächsten Wiederholung des Signals konstant. 

Das Togglebit bei RECS 80 und RC-5 hat eine spezielle Funktion. Um besser zwischen 

mehreren aufeinander folgenden Tastendrücken und einem einzigen langen Tastendruck auf 

der Fernbedienung unterscheiden zu können, wechselt dieses Bit bei jedem Tastendruck 

seinen Zustand. 

4.2.3 NEC 

Der NEC-Standard funktioniert ähnlich wie RECS 80, wobei sich die Länge der Impulse und 

Pausen unterscheidet. Die Datenpakete sind 32 Bit lang, aufgeteilt in 16 Bit für Adressierung 

und 16 Bit für Daten. Meist sind die letzten 8 Bit dieser Teilpakete das bitweise Komplement 

der ersten acht, um Übertragungsfehler erkennen zu können. 

Leider existieren neben den drei beschriebenen Standards noch etliche andere Ansätze, die 

meist nicht öffentlich dokumentiert sind. So setzt Sony ein Verfahren ein, bei dem die Länge 

der Lichtimpulse selbst für den Bitwert entscheidend ist. Viele andere Hersteller setzen 

Varianten von RECS 80 und NEC ein, die sich in der Länge der Impulse und Pausen, in der 

Anzahl und Semantik der Datenbits und in der Methode, lange Tastendrücke kenntlich zu 

machen unterscheiden. Weit verbreitet ist auch das Aussenden eines langen Header-Signals, 

welches dem Empfänger erlaubt, sich auf das folgende Signal einzumessen. 

- 12 -





4.3 Die Empfängerdiode SFH 5110 

Die Empfängerdiode SFH 5110 setzt bei der Aufmodulierung des Nutzsignals auf eine 

Trägerfrequenz an. Ihre Aufgabe ist es, das Trägersignal und das darauf aufmodulierte 

Datensignal zu erkennen, voneinander zu unterscheiden und das Datensignal per TTL-Pegel 

auszugeben. 

Im Bauteil integriert sind Fotodiode, Vorverstärker, automatische Verstärkungsregelung, 

Bandpass-Filter und Demodulator. Als Anwendung wird der Empfang von 

Fernbedienungssignalen von TV, Videorekordern, HiFi, Satellitenempfängern und CD- 

Spielern angegeben. 

An dieser Stelle sei auch auf das Datenblatt von SFH 5110/5111 im Anhang unter Punkt 9.1 

verwiesen. 

- 13 -





5. Dekodierung der Signale mit dem Mikrocontroller 

Da wie gesagt die verwendete Kathrein Fernbedienung keines der oben beschriebenen 

Protokolle unterstützt, waren wir gezwungen, eine eigene Art der Interpretation der Signale zu 

entwickeln und im Assemblerprogramm anzuwenden. 

Dabei fiel uns auf, dass im Signalverlauf eines Tastendruckes auf der Fernbedienung immer 

ein einheitliches Muster auftritt: 

einheitliches 

Header-Signal 

Datenbits 

ca. 9 ms ca. 5 ms ca. 1,5 ms ca. 0,5 ms 

Zu Beginn des Signalverlaufs wird immer ein bei allen Tasten einheitlich langes Header- 

Signal gesendet. Die dann nachfolgenden Datenbits haben immer entweder die Länge 1,5 ms 

oder 0,5 ms. 

Die Interpretation der Signallängen erfolgt dann nach folgendem Muster: 

X X 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 X 

X = wird nicht berücksichtigt 

0 = Bitzeit 0,5 ms 

1 = Bitzeit 1,5 ms 

Die somit gewonnene Binärzahlreihenfolge „00000001 01000000“ wird dann in Bytes 

eingeteilt und kann so einfach mit den eingelesenen Datensätzen verglichen werden. 

- 14 -





5.1 Der einzulesende Datensatz 

Damit der Mikrocontroller das empfangene Signal interpretieren, vergleichen und erkennen 

kann, muss er einen Datensatz, in dem alle Signale der Fernbedienung entschlüsselt und 

interpretiert aufgelistet sind, zur Verfügung haben. 

Den folgenden Datensatz erhielten wir, indem wir uns durch eine Variation des Assembler- 

Programms die Bitzeiten aller Signale per V24 am PC-Monitor anzeigen ließen: 

Ausschnitt aus dem Datensatz: 

; Anzahl der Signale 

db 27 

;Dummy 

db 00h, 00h, 00h, 00h, 00h, 00h 

; OL2 

db 44h, 40h, 00h, 00h, 00h, 00h 

Tastenname 

; OR2 

db 54h, 40h, 00h, 00h, 00h, 00h 

; UL2 

db 14h, 40h, 00h, 00h, 00h, 00h 

; UR2 

db 01h, 40h, 00h, 00h, 00h, 00h 

In Hexadezimale Form 

umgewandelte Bitfolge 

Der gesamte Datensatz steht in genau dieser Schreibweise in einer Textdatei und wird am 

Ende des Quellcodes eingebunden. Über eine Marke kann dann auf die Daten zugegriffen 

werden. 

- 15 -





5.2 Das Assemblerprogramm 

Das Assemblerprogramm ist in 80535-Assembler geschrieben und umfasst, Kommentare 

eingeschlossen, etwa 600 Zeilen selbst entwickelten Code. 

Die Aufgabe dieses Assemblerprogramms ist es, die Signalfolge, welche von der Diode SFH 

5110 auf Port 1.1 des Mikrocontrollers eingespeist wird, zu interpretieren, zu vergleichen und 

zu erkennen. Anschließend soll die Nummer des erkannten Signals per V24 an den COM - 

Port des PCs gesendet werden. 

Das Programm besteht aus 

- Hauptprogramm 

- Interrupt-Programm 

sowie aus den Makros 

- WAIT_HIGH 

- SAVE 

- POSTPROCESSDATA 

- benutzt: ENCODE 

- COMPARE 

- benutzt: COMPAREONE 

- SENDAKKU 

die per .inc-Datei in das Hauptprogramm inkludiert werden. Entwickelt wurde das Programm 

unter der Entwicklungsumgebung µVision der Firma Keil. 

5.2.1 Funktion 

Um, wie unter Punkt 5 bemerkt, das auf Port 1.1 eingespeiste Signal dekodieren zu können 

muss der Mikrocontroller also im Signalverlauf das Header-Signal und die 2 

unterschiedlichen Bitzeiten messen, speichern, in Bits umwandeln, vergleichen und erkennen 

können. Da hier ein äußerst knappes Timing eingehalten werden muss, werden während des 

Signalverlaufs ausschließlich die Impulslängen durch den Timer 0 im Interrupt-Modus in 

0,1ms – Schritten gemessen, in die Register R0 und R1 addiert und anschließend durch das 

Makro „SAVE“ in den externen Speicher gespeichert. Die Impulslänge eines Low-Impulses 

wird dabei immer in R0, die Länge eines High-Impulses in R1 aufaddiert. 

Um immer erst genau bei Beginn eines Signals die Messung zu starten, setzt das Makro 

„WAIT_HIGH“ einen ca. 10ms langen High-Impuls voraus, welcher nur zwischen dem 

- 16 -





Anfang und dem Ende zweier Signale sein kann. Außerdem beendet es sich erst bei 

Abbrechen des High-Impulses, also bei Beginn des Headers eines Signals. 

Ist ein Signalverlauf komplett vermessen und gespeichert (wird durch einen High-Impuls > 

5ms erkannt), werden die bis zu 50 einzelnen Bytes, in denen die Impulszeiten gespeichert 

sind, durch das Makro POSTPROCESSDATA in 6 Bytes nach der unter Punkt 5 

beschriebenen Methode dekodiert. 

Speicherstelle: 

Inhalt: 

Länge der Impulse 

in 0,1 ms 

C000h C0001h C0002h C0003h C0004h 

90h 50h 5h 15h 15h 

X X 0 1 1 

Interpretation in Nullen und Einsen 

POSTPROCESSDATA hängt außerdem grundsätzlich 4 Bytes mit dem Inhalt „0“ an die 

Signale an, da, wie gesagt, 4 der 26 Signale kürzer sind und nur 2 Bytes umfassen. 

Stehen also im externen Speicher ab der Adresse C000h die 6 Bytes des empfangenen und 

gewandelten Signals, können sie durch das Makro COMPARE mit den Signalen im 

gespeicherten Datensatz verglichen werden. Wird das empfangene Signal erkannt, hinterlässt 

COMPARE im Akkumulator die Nummer des Signals (ist gleichzeitig auch die Stelle an der 

das Signal im Datensatz steht). Ist das Signal mit keinem der gespeicherten Signale identisch 

wird 27d im Akku hinterlassen. 

Schließlich wird durch das Makro SENDAKKU der Inhalt des Akkumulators per V24 an den 

COM1 – Port des PCs gesendet und an den Anfang des Programmverlaufs gesprungen. 

5.2.2 PAP 

- 17 -





Hauptprogramm 

Start 

Start des Programms 

SP #80h 

Der Stackpointer wird gesetzt 

Interrupts 

initialisieren 

Die Interrupt-Einstellungen werden so gesetzt, 

dass Timer 0 in den Interrupt gehen kann 

R7 #0 

R7 ist der Indikator dafür, ob das Signal zu Ende 

ist, oder noch andauert. Es wird im Interrupt- 

Programm beschrieben 

WAIT_HIGH 

Um genau den Anfang des Signals abzupassen 

wartet Wait_High auf ein ca. 10ms langes High 

Timer 0 starten 

TH0 #FFh 

TL0 #9Bh 

R2 #0 

Der Timer 0 wird so initialisiert, dass er genau 

0,1ms bis zum Überlauf braucht 

In R2 wird die Anzahl der Impulse + Pausen 

abgelegt 

R1 #0 

Jedes mal wenn High anliegt und der Timer 

überläuft werden in R1 die High-Impulslängen 

hochgezählt 

A #0 

R0 #0 

A indiziert dem Timer, ob er High (R1) oder Low 

(R0) hochzählen soll. 0 bedeutet Low, 1 bedeutet 

High. A wird mit 0 initialisiert, da als erstes ein 

langes Low am Anfang des Signals steht 

Jedes mal wenn Low anliegt und der Timer 

überläuft werden in R0 die Low-Impulslängen 

hochgezählt 

B R1 

Die Länge des letzten High-Impulses wird B 

übergeben, damit SAVE sie speichern kann 

- 18 -





SAVE 

SAVE speichert die Länge des letzten Impulses 

im externen Datenspeicher ab C000h 

P1.1 = = 0 

nein 

A #1 

ja 

Warten, bis der Low-Impuls vorbei ist und 

gleichzeitiges hochzählen von R0 im Timer - 

Interrupt 

Der Low-Impuls ist vorbei, jetzt liegt High an. 

Der Timer muss das durch A erkennen und damit 

R1 hochzählen 

R1 #0 

R1 für das Zählen säubern 

B #R0 

SAVE 

Während des Messens des anliegenden Impulses 

ist Zeit, die Länge letzten Low-Impuls zu 

speichern 

R7 = = 0 

ja 

nein 

Wenn der Timer R7 gesetzt hat, ist das Signal 

vorbei und es wird an den Anfang gesprungen 

ja 

P1.1 = = 1 

nein 

Liegt das Signal noch an, warten bis der High- 

Impuls vorbei ist und messen seiner Länge. Ist der 

High-Impuls vorbei, wird wieder zu LOW 

gesprungen. 

- 19 -





Interrupt-Programm 

Start 

Timerwerte setzen 

TH0 #FFh 

TL0 #9Bh 

Timerwerte neu setzen 

A = = 0 

ja 

R0 R0 + 1 

nein 

Ist A = 0, so liegt Low an, R0 muss inkrementiert 

werden 

Ist A = 1, liegt High an und R1 muss 

inkrementiert werden 

R0 inkrementieren 

TF0 0 

TF0 für nächsten Interrupt wieder löschen 

reti 

Zurückspringen ins Hauptprogramm 

R1 R1 + 1 

High liegt an, also R1 inkrementieren 

R1 = = 50 

nein 

TF0 0 

ja 

Liegt High schon länger als 5ms an, ist das Signal 

vorbei und folgende Routinen werden eingeleitet 

Das Signal ist noch nicht vorbei, TF0 für nächsten 

Interrupt löschen 

reti 

Zurücksprung ins Hauptprogramm 

- 20 -





EAL 0 

Das Signal ist vorbei, nichts muss gemessen 

werden, deshalb ausschalten der Interrupts 

POSTPROCESSDATA 

Dieses Makro wandelt die einzelnen 

Impulslängen ins Bits und Bytes und schreibt sie 

an C000h 

DPTR auf 

Datensätze 

stellen 

Der DPTR wird auf die eingelesen Datensätze 

gestellt 

A 1. Datensatz 

DPTR DPTR + 1 

An 1. Stelle steht die Anzahl der Signale, diese 

wird in den Akku geschoben, da das folgende 

Makro diese benötigt 

Für das folgende Makro den DPTR 

inkrementieren 

COMPARE 

SENDAKKU 

Dieses Makro vergleicht das empfangene Signal 

mit den Signalen des eingelesnen Datensatzes und 

gibt die Nummer des erkannten Signals im Akku 

zurück 

Senden der Signalnummer an den PC 

R7 #1 

Indizieren, dass Signal vorbei ist und ins 

Hauptprogramm zurückspringen 

- 21 -





Makro WAIT_HIGH 

Start 

Register 

sichern 

Dieses Makro wartet auf ein ca. 10ms langes 

High, danach wartet es auf den 1. Low-Impuls 

eines Signals, so wird garantiert, dass genau der 

Anfang des Signals abgepasst wird 

Alle verwendeten Register auf den Stack schieben 

R0 #0 

R1 #0 

R0 und R1 stellen einen 16 Bit-Wert dar. R0 ist 

das Lowbyte, R1 ist das Highbyte 

R0 R0 + 1 

Lowbyte inkrementieren 

C = = 1 

ja 

R1 R1 + 1 

nein 

Ist das Lowbyte übergelaufen, wurde das Cary- 

Bit gesetzt. Dann muss zusätzlich das Highbyte 

inkrementiert werden 

Highbyte inkrementieren 

P1.1 = = 1 

ja 

nein 

Kontrolle: Liegt immer noch High an? 

Wenn nicht, Rücksprung 

nein 

R1 = = 4 

Wenn R1 = 4 ist, also ca. 10ms vorüber sind muss 

nur noch auf das 1. Low eines Signals gewartet 

werden 

P1.1 = = 1 

ja 

So lang warten, bis 1. Low eines Signals anliegt 

Register 

restaurieren 

Alle verwendeten Register restaurieren 

ENDM 

- 22 - 

Rücksprung ins Hauptprogramm





Makro SAVE 

Start 

Dieses Makro speichert die im Hauptprogramm 

gemessenen Impulslängen im externen 

Datenspeicher ab C000h 

Register 

sichern 

Alle verwendeten Register sichern 

R2 R2 + 1 

In R2 steht die Anzahl der gespeicherten Impuls + 

Pausenlängen, deshalb jetzt inkrementieren 

DPTR DPTR + 1 

Den Datenpointer inkrementieren, damit nächstes 

Byte geschrieben werden kann 

A B 

In B steht der zu speichernde Wert 

@DPTR A 

Speichern 

Register 



ENDM 

Rücksprung ins Hauptprogramm 

- 23 -





Makro 


Start 

Register 

sichern 

Dieses Makro wandelt mit Hilfe des Makro 

Encode die gespeicherten Impulslängen in Bits 

und Bytes und speichert diese an die alte Stelle an 

C000h 


R0 #0 

R1 #0 

R7 #0 

In R0 wird die Anzahl der Impulse + Pausen 

gespeichert. 

R1 ist der Zähler für die 8 Bits eines Bytes. 

R7 ist der 2. dpl-Zeiger. 

Alle Register werden gelöscht. 

DPTR #C004h 

Die ersten 4 Bytes werden übersprungen, da diese 

immer gleich und irrelevant sind 

R2 R2 - 4 

Entsprechend wird auch die Anzahl der zu 

wandelnden Impulslängen um 4 verringert 

R0 R0 + 1 

R0 wird auf die 1. Impulslänge gesetzt 

ACC 

Der Akku wird durch push gesichert 

A @DPTR 

Die 1. Signallänge wird aus dem externen 

Speicher geholt 

ENCODE 

Dieses Makro setzt das Carry-Bit, wenn der 

Impuls eine logische 1 darstellt, ansonsten löscht 

es dieses 

ACC 

Der Akku wird durch pop restauriert 

C A 

Das Carry-Bit wird nun in den Akku geshiftet 

- 24 -





DPTR DPTR + 1 

Der DPTR wird eine Impulslänge weitergerückt 

R1 R1 - 1 

R1 überwacht, dass 8 Bits in ein Byte kommen, 

wird also jetzt dekrementiert 

R1 = = 0 

ja 

DPL 

nein 

Entscheidung: Sind bereits 8 Impulslängen in Bits 

gewandelt und in den Akku geshiftet worden? 

Wenn ja wird jetzt speichert, wenn nein weiter 

gesprungen 

Dazu wird der DPL gesichert 

DPL R7 

und der 2. dpl-Zeiger R7 verwendet 

@DPTR A 

Das volle Byte wird in den externen Speicher 

geschrieben 

R7 R7 + 1 

Der 2. dpl-Zeiger wird weitergerückt 

DPL 

Jetzt wird der ursprüngliche DPL wieder 

restauriert... 

R1 #8 

...und R1 wieder 8 geschrieben, damit wieder von 

vorn begonnen werden kann, falls noch nicht alle 

Impulslängen gewandelt sind 

R2 R2 -1 

Eine Impulslänge wurde gewandelt, also den 

Zähler dekrementieren 

R2 = = 0 

nein 

Entscheidung: Wurden alle Impulslängen 

gewandelt? Wenn nicht: noch mal von vorn 

ja 

- 25 -





ACC 

DPH #C0h 

Es wurden alle Impulslängen gewandelt. Nun 

kann damit begonnen werden, die kürzeren 

Signale durch Anhängen von Nullen auf gleiche 

Länge mit den längeren Signalen zu bringen. 

Dazu Akku sichern 

und den DPTR an das Ende des gewandelten 

Signals stellen 

DPL R7 

R7 #4 

Es sollen pauschal 4 Nullen angehängt werden, 

egal ob kurzes Signal oder langes. R7 dient als 

Zähler 

A #0 

Die anzuhängende Null in Akku schreiben 

@DPTR A 

und in den externen Datenspeicher schieben 

DPL DPL + 1 

Eine Speicherstelle weiter rücken 

R7 R7 - 1 

Den Zähler dekrementieren 

R7 = = 0 

ja 

Register 


nein 

und entscheiden, ob alle 4 Nullen geschrieben 

wurden 

Zum Schluss alle verwendeten Register 


ENDM 


- 26 -





Makro ENCODE 

Start 

Dieses Makro wird ausschließlich im Makro 

Postprocessdata verwendet. Es dient dazu, die 2 

unterschiedlichen Impulslängen in Bits zu 

kodieren. Dazu wird entweder das Carry-Bit 

gesetzt oder nicht. Die Impulslänge wird im Akku 

erwartet 

A = = #13|#14|#15|#16|#17 

ja 

Entscheidung: 

Ist die Impulslänge etwa 1,5ms lang, Carry 

setzen, ansonsten nächster Vergleich 

nein 

A = = #3 | #4 | #5 | #6 | #7 

Entscheidung: 

Ist die Impulslänge etwa 0,5ms lang, Carry-Bit 

löschen, da es eine logische 0 bedeutet 

C 0 

C 1 

ENDM 

Rücksprung ins Makro Postprocessdata 

- 27 -





Makro COMPARE 

Start 

Dieses Makro vergleicht mit Hilfe des Makros 

Compareone die Signale des eingelesenen 

Datensatzes mit dem empfangenen Signal bei 

C000h. Die Anzahl der Signale im Datensatz wird 

im Akku erwartet, auch wird erwartet dass der 

DPTR auf das 1. Signal zeigt 

Register 

sichern 

Alle verwendeten Register werden gesichert 

R0 #0 

R0 ist die Nummer des gefundenen Signals und 

wird im Hauptprogramm an den PC gesendet 

R2 A 

Die Anzahl der Signale im Datensatz wird in R2 

gesichert 

COMPAREONE 

Dieses Makro vergleicht das Signal, auf dessen 

Anfang DPTR zeigt mit dem empfangenen Signal 

bei C000h und gibt b = 1 für identisch oder b = 0 

für verschieden zurück 

R3 B 

Das Ergebnis wird in R3 gesichert 

R3 = = 0 

ja 

R0 R0 + 1 

nein 

Entscheidung: ist das Signal im Datensatz 

identisch mit dem empfangenen Signal? 

Wenn nein, die Nummer des Signals 

inkrementieren 

DPTR DPTR + 6 

Den DPTR 6 Bytes weiterstellen, auf nächstes 

Signal im Datensatz 

R2 R2 - 1 

und die Anzahl der noch zu vergleichenden 

Signale dekrementieren 

- 28 -





nein 

ja 

R2 = = 0 

A R0 

Entscheidung: wurden bereits alle Signale 

verglichen? Wenn nein, nächstes Signal 

vergleichen 

Die Nummer des gefundenen Signals in den Akku 

schieben. Wenn das empfangene Signal mit 

keinem der Signale im Datensatz identisch war, 

steht jetzt in R0 die 27, da alle 26 Signale 

verglichen wurden 

Register 



ENDM 


- 29 -





Makro COMPAREONE 

Start 

Dieses Makro wird ausschließlich im Makro 

Compare verwendet. Es vergleicht immer nur 1 

Signal (6 Bytes) des Datensatzes mit dem 

empfangenen Signal an C000h und setzt dann B = 

1, wenn identisch und B = 0, wenn verschieden. 

Dieses Makro erwartet den auf den Datensatz 

eingestellten DPTR 

Register 

sichern 


R1 #6 

R1 ist der Zähler für die Bytes, also 6 

hineinschreiben 

R2 #0 

R2 ist der 2. dpl-Zeiger, er wird gebraucht, um 

zwischen der dem Datensatz und dem Signal bei 

C000h hin- und her zuspringen 

A @DPTR 

Das 1. Bytes des Signals im Datensatz wird 

gelesen 

R0 A 

...und in R0 gesichert 

DPTR DPTR + 1 

Den DPTR auf das nächste Byte stellen 

DPTR 

Und sichern 

DPH #C0h 

Jetzt wird der DPTR auf das Signal an C000h 

gestellt 

DPL R2 

R2 R2 + 1 

Der 2. dpl-Zeiger wird weitergestellt 

A @DPTR 

Jetzt wird das 1. Byte des empfangenen Signals 

aus dem externen Speicher geholt 

- 30 -





DPTR 

Der alte DPTR, welcher auf das Signal im 

Datensatz zeigt wird restauriert 

nein 

A = = R0 

ja 

R1 R1 - 1 

Nun wird verglichen ob das Byte des 

empfangenen Signals identisch mit dem Byte des 

Signals im Datensatz ist 

Wenn ja, Bytezähler weiterstellen 

Und nächstes Byte vergleichen 

R1 = = 0 

nein 

ja 

B #1 

B #0 

Wenn nein, in B die 0 für unidentisch schreiben 

Register 



ENDM 

Und ins Makro Compare zurück springen 

- 31 -





Makro SENDAKKU 

Dieses Makro sendet den Inhalt des Akkus per 

V24 und wartet auf Grund der Trägheit des PCs 

Start 

Register 

sichern 

Alle verwendeten Register werden gesichert 

SBUF A 

Den Inhalt des Akkus in das Senderegister 

schreiben 

Ti = = 1 

ja 

Ti 0 

nein 

Ist die Sendung vorüber? 

Sendeflag wieder löschen 

R6 #20 

Ab hier ist eine Verzögerung von ca. 10ms 

eingebaut, wegen der Trägheit des PCs 

R5 #250 

R5 R5 - 1 

R5 = = 0 

ja 

R6 R6 - 1 

nein 

- 32 -





R6 = = 0 

nein 

ja 

Register 


ENDM 

- 33 -





; Programmname : Fernbed.a51 

; ProgFunktion : Auswerten der ankommenden Fernbedienungssignale und 

; Weiterleiten an den PC 

; Programmierer : Alexander Fuchs und David Zaadstra 

; Datum : 26.2.2002 - 3.4.2002 

$ ERRORPRINT 

$ NOSYMBOLS 

$ NOMOD51 

$ NOLIST 

$ INCLUDE (reg515.INC) 

$ INCLUDE(macros.inc) 

$ LIST 

;-------------------------------------------------------------------------- 

ORG 400BH 

jmp 

INT_TIMER0 

;------------------------------------------------------ 

ORG 4100H 

; serielle Kommunikation vorbereiten 

InitV24 

; Stackpointer initialisieren 

mov SP,#80h 

; Interrupts initialisieren 

setb eal 

setb et0 

START: 

; wenn R7 != 0, dann Signal vorbei 

mov r7, #0 

; auf langes High warten (bevor das Signal beginnt) 

WAIT_HIGH 

; Timer 0 starten 

setb eal 

mov tmod, #1 

mov th0, #0ffh 

mov tl0, #9bh 

setb tr0 

; in R2 wird die Zahl der Impulse + Pausen abgelegt 

mov r2, #0 

; hier werden die Impulslängen gespeichert 

mov dptr, #0c000h 

; in R1 werden die High-Impulslängen gezählt 

; in R0 werden die Low-Impulslängen gezählt 

mov R1, #0 

- 34 -





LO: 

mov a, #0 ; a wird in der Timerroutine abgefragt 

; 0=LOW, alles andere=>HIGH 

mov R0, #0 ; R0 enthält die Anzahl der vergangenen 0,1ms 

mov b,r1 ; R1 enthält die Bitlänge des letzten 

; High-Impulses 

SAVE 

; Speichern des Wertes im externen Speicher 

jnb FERN, $ ; warten auf High und zählen der Länge durch 

; Timer-Interrupt 

HI: 

mov a, #1 ; damit Interrupt über High bescheid weiss 

mov R1, #0 ; R1 enthält die Anzahl der vergangenen 0,1ms 

mov b,r0 ; R0 enthält die Bitlänge des letzten 

; Low-Impulses 

SAVE 

; Speichern der Bitlänge im externen Speicher 

HI_GO: 

; Hier wird durch R7 überprüft, ob Signal zu Ende ist 

; wenn ja, jmp zu START 

push acc 

mov a, r7 

jz HI_GO2 

pop acc 

jmp START 

HI_GO2: 

pop 

jb 

acc 

FERN, HI_GO ; warten auf Low und zählen der Länge durch 

; Timer-Interrupt 

jmp LO ; Nach jedem High folgt ein Low! 

;------------------------------------------------------ 

; INTERRUPT-PROGRAMM 

INT_TIMER0: 

; Timer-Wert neu setzen 

mov TH0, #0FFh ; Werte sind so gewählt, dass Timer immer 

mov TL0, #9bh ; nach 0,1 ms in Interrupt geht 

; hier wird durch Akku ermittelt, ob High oder Low anliegt 

; liegt Low an, wird R0 hochgezählt 

; liegt High an, wird R1 hochgezählt 

jz TEMP 

jmp TEMP2 

TEMP: ljmp ADDLOW 

TEMP2: 

inc R1 

; Abfrage: falls Zeit größer 5ms => Signal zu Ende, 

; also verarbeiten und senden 

cjne R1, #50, TEMP3 

jmp TEMP4 

TEMP3: ljmp NOTEND 

TEMP4: 

- 35 -





clr eal ; Interrupts ausschalten 

push acc 

; sichern 

; Dieses Makro wandelt die 2 untersch. Impulslängen in Bits und Bytes 

; und schreibt diese an die alte Stelle an C000h 


; jetzt wird der Datensatz eingelesen 

; an 1. Stelle steht die Anzahl der Signale 

mov dptr, #keys_data 

movx a, @dptr 

inc dptr 

; Dieses Makro vergleicht das empfangene Signal an C000 

; mit den Signalen im Datensatz 

COMPARE 

; das gefundene Signal steht im Akku 

SENDAKKU 

pop 

acc 

mov R7, #1 ; Signal zu Ende (R7 als Indikator) 

jmp NOTEND 

ADDLOW: 

inc R0 

NOTEND: 

clr tf0 

reti 

keys_data: 

$ INCLUDE(tasten.inc) 

end 

- 36 -





;-------------------------------------------------------------------------- 

; Diese Makro-Datei enthält Makros, die für unsere Fernbedienungsabfrage 

; benutzt werden. Das Input-Signal wird auf FERN(P1.1) erwartet. 

; 

; Folgende Makros sind enthalten: 

; 

; Wait_High 

; Print 

; Save 

; Encode 

; Postprocessdata 

; Compare 

; Compareone 

; Sendakku 

; 

;-------------------------------------------------------------------------- 

FERN EQU P1.1 

$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; W A I T _ H I G H 

; Dieses Makro wartet auf das High-Signal (ca 10ms), das vor bzw nach jedem 

; Signal der Fernbedienung kommt. 

;-------------------------------------------------------------------------- 

WAIT_HIGH 

MACRO 

local reset,addition,notcarry 

push 00 

push 01 

; r0 und r1 repräsentieren einen 16bit-Wert 

; r0 ist das lowbyte, r1 das highbyte 

reset: 

mov r0, #0 

mov r1, #0 

addition: 

; 16bit-Wert um eins erhöhen 

inc r0 

jnc notcarry 

inc r1 

notcarry: 

jnb FERN, reset ; wenn das Low-signal abbricht, 

; Reset und erneut warten 

cjne r1, #4, addition ; bei r1 = 5 (also ca 10ms) abbrechen, 

; ansonsten weiteraddieren 

jb FERN, $ ; auf das Header-Low warten 

pop 01 

pop 00 

ENDM 

;////////////////////////////////////////////////////////////////////////// 

- 37 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; P R I N T 

; gibt die Codes der Impuls- und Pausenzeiten aus 

;-------------------------------------------------------------------------- 

PRINT MACRO 

local m1 

m1: 

push acc 

mov r2, dpl 


movx a, @dptr 

SENDADEZ 

mov a, #' ' 

SENDA 

inc dptr 

djnz r2, m1 

ENDM 

mov 

SENDA 

mov 

SENDA 

mov 

SENDA 

pop 

a, #'E' 

a, #'N' 

a, #'D' 

acc 

;////////////////////////////////////////////////////////////////////////// 

- 38 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; S A V E 

; speichert den Wert des b-Registers im externen Speicher. Anzahl der 

bisher 

; gespeicherten Werte werden in r2 gezählt 

;-------------------------------------------------------------------------- 

SAVE MACRO 

push acc 

inc r2 

inc dptr 

mov a, b 

movx @dptr, a 

ENDM 

pop 

acc 

;////////////////////////////////////////////////////////////////////////// 

- 39 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; E N C O D E 

; wird in Postprocessdata verwendet 

; wandelt ein Signalbyte von der Fernbedienung in ein Bit um 

; 1,4ms / 1,5ms / 1,6ms --> log. 1 

; 4ms / 5ms / 6ms --> log. 0 

; das Byte wird im Akku erwartet 

;-------------------------------------------------------------------------- 

ENCODE MACRO 

local NOTHIGH1, NOTHIGH2, NOTHIGH3, NOTLOW1, NOTLOW2, NOTLOW3, HI, 

LO, ENDMACRO 

usw. 

; eine einfache Vergleichsroutine: 

; trifft die erste Bedingung nich zu, wird zur Nächsten gesprungen 

cjne a, #13, NOTHIGH4 

jmp HI 

NOTHIGH4: 


jmp HI 

NOTHIGH1: 


jmp HI 

NOTHIGH2: 


jmp HI 

NOTHIGH3: 


jmp HI 

NOTHIGH5: 

cjne a, #3, NOTLOW4 

jmp LO 

NOTLOW4: 


jmp LO 

NOTLOW1: 


jmp LO 

NOTLOW2: 


jmp LO 

NOTLOW3: 


jmp LO 

NOTLOW5: 

HI: 

setb c 

jmp ENDMACRO 

LO: 

clr c 

ENDMACRO: 

ENDM 

;////////////////////////////////////////////////////////////////////////// 

- 40 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; P O S T P R O C E S S D A T A 

; wandelt mit Hilfe von Encode die gespeicherten Impulslängen in Bits und 

Bytes 

; und schreibt diese an die alte Stelle an C000h 

;-------------------------------------------------------------------------- 

POSTPROCESSDATA MACRO 

local NOT_ALL_READ, BYTE_NOT_FULL, temp, temp2, notcarry, 

bitset, bitnotset, NULL_FILL 

push 00 

push 01 

push 07 

mov r0, #0 ; Anzahl der Impulse/Pausen 

mov r1, #8 ; mit R1 wird immer ein Byte runtergezählt 

mov r7, #0 ; dpl-Zeiger 

; die ersten 4 Bytes überspringen, da diese immer gleich sind 


; entsprechend auch die Anzahl der gelesenen Bytes um 4 verringern 

push acc 

mov a, r2 

subb a, #4 

mov r2, a 

pop acc 

NOT_ALL_READ: 

inc 

r0 

; Byte aus dem Speicher holen und in Bit wandeln 

push acc 

movx a, @dptr 

ENCODE 

; setzt P5.1, wenn Byte log.1 darstellt 

pop acc 

; Bit in den Akku shiften 

rlc a 

; eine Speicherstelle weiterrücken 

inc dptr 

notcarry: 

; prüfen ob ein Byte voll ist (nach 8 geshifteten Bits) 

djnz r1, BYTE_NOT_FULL 

; Byte voll, also schreiben 

push dpl 

mov dpl, r7 

movx @dptr, a 

- 41 -





inc 

pop 

r7 

dpl 

mov r1, #8 ; Bytezähler zurücksetzen 

BYTE_NOT_FULL: 

; wenn noch nicht alle Bytes gelesen und gewandelt sind, 

; wieder nach oben springen 

djnz r2, temp 

jmp temp2 

temp: 

ljmp NOT_ALL_READ 

temp2: 

mov 

a, r0 

; Anzahl der Bytes = gelesene Bytes / 8, weil jedes Byte nur noch ein 

Bit ist 

rr a 

rr a 

rr a 

; mit Nullen auffüllen (für die kürzeren Codes) 

push acc 

mov dph,#0c0h 

mov dpl, r7 

mov r7, #4 

NULL_FILL: 

mov a, #0 

movx @dptr, a 

inc dptr 

djnz r7, NULL_FILL 

pop acc 

ENDM 

pop 07 

pop 01 

pop 00 

;////////////////////////////////////////////////////////////////////////// 

- 42 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; C O M P A R E 

; vergleicht mit Hilfe von Compareone die Datensätze, die bei dptr 

anfangen, mit 

; dem Signal bei C000 und gibt die Nummer des gefundenen Signals im Akku 

zurück 

; die Gesamtanzahl der Signale im Datensatz wird im Akku erwartet 

;-------------------------------------------------------------------------- 

COMPARE MACRO 

local nextsignal 

push 00 

push 01 

push 02 

push 03 

push b 

push dph 

push dpl 

mov r0, #0 ; R0 ist der Index des Signals/Datensatzes 

mov r2, a ; R2 = Anzahl der Signale im Datensatz 

nextsignal: 

; gibt bei Übereinstimmung der Signale b = 1, ansonsten b = 0 zurück 

COMPAREONE 

mov r3, b 

cjne r3, #0, signalfound 

inc r0 ; nächstes Signal vergleichen 

; den dptr um 6 erhöhen (nächstes Signal) 

inc dptr 

inc dptr 

inc dptr 

inc dptr 

inc dptr 

inc dptr 

djnz r2, nextsignal 

signalfound: 

; wenn kein Signal gefunden wurde, wird 27d zurückgegeben 

mov a, r0 

pop dpl 

pop dph 

pop b 

pop 03 

pop 02 

pop 01 

pop 00 

ENDM 

;////////////////////////////////////////////////////////////////////////// 

- 43 -





$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

; C O M P A R E O N E 

; wird in Compare verwendet 

; vergleicht immer nur 1 Signal (6 Bytes) des Datensatzes mit dem 

empfangenen 

; Signal 

; hinterlässt bei Übereinstimmung des Signals b = 1 

; ansonsten b = 0 

;-------------------------------------------------------------------------- 

COMPAREONE MACRO 

local m1, m2, signalfalse 

push 00 

push 01 

push 02 

push acc 

push dph 

push dpl 

; sichern 

mov r1, #6 ; Anzahl der Bytes pro Signal 

m2: 

mov r2, #0h ; dpl-Zeiger 

movx a,@dptr ; Datensatzbyte holen, dptr ist von 

; Compare gestellt 

mov r0,a ; zum Vergleichen in R0 schieben 

inc dptr ; auf nächstes Byte stellen 

push dph 

push dpl 

mov dph,#0C0h ; empfangenes Byte holen 

mov dpl, r2 

inc r2 

movx a,@dptr 

pop 

pop 

dpl 

dph 

subb a,r0 

jz m1 

; vergleichen 

m1: 

sind 

mov b, #0 ; Signale nicht identisch 

jmp signalfalse 

djnz r1, m2 

; so lange, bis 6 Bytes eines Signals verglichen 

mov b, #1 ; Signal identisch 

signalfalse: 

pop dpl 

pop dph 

pop acc 

pop 02 

pop 01 

pop 00 

- 44 -





ENDM 

;////////////////////////////////////////////////////////////////////////// 

$EJECT 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

;S E N D A K K U 

;sendet den Inhalt des Akkus per V24. 

;-------------------------------------------------------------------------- 

SENDAKKU MACRO 

local m1 

push 05 

push 06 

mov sbuf,a ; Zeichen an serielle Schnittstelle 

jnb ti,$ ; warten bis Sendung fertig ist 

clr ti ; Sendeflag zurücksetzen 

; ca 10ms warten, wegen Trägheit des Terminals 

mov 

r6,#20 

m1: mov r5,#250 

djnz r5,$ 

djnz r6,m1 

pop 06 

pop 05 

ENDM 

;////////////////////////////////////////////////////////////////////////// 

;////////////////////////////////////////////////////////////////////////// 

;-------------------------------------------------------------------------- 

;I N I T V 2 4 

;initialisiert die Schnittstelle auf 9600 Baud, 1 Stoppbit und 

;keine Parity 

;-------------------------------------------------------------------------- 

InitV24 MACRO 

setb bd ;Baudratengenerator (ADCON) 

orl pcon,#80h ;Baudrate auf 9600 

mov scon,#50H ;Mode 1 wählen+REN 

ENDM 

;////////////////////////////////////////////////////////////////////////// 

- 45 -





6. Kommunikation Mikrokontroller -> PC 

6.1 Empfang der Daten mit den Communications-Funktionen der Win32-API 

Das Win32 API der Microsoft Windows Betriebssysteme stellt unter dem Bereich 

„Communications“ Funktionen zur Verfügung, die es ermöglichen, Daten über die seriellen 

Schnittstellen auszutauschen. 

Die Kommunikation zu einer der seriellen Schnittstellen wird über die Funktion 

CreateFile aufgebaut. Die Schnittstelle wird also wie eine Datei angesprochen. 

Der Unterschied liegt nur in den Parametern, die bei der Initialisierung übergeben werden. 

Will man zum Beispiel COM1 ansprechen, sieht die Initialisierung so aus: 

CODE: 

DCB dcb; 

HANDLE com; 

DWORD error; 

BOOL success; 

com = CreateFile( 

"COM1", 

// Kontrollstruktur für die serielle Schnittstelle 

// Handle der Schnittstelle 

// für zurückgegebene Fehlercodes 

// COM1 öffnen 

GENERIC_READ | 

GENERIC_WRITE, 

// lesen und schreiben 

0, // exklusiver Zugriff 

NULL, 

OPEN_EXISTING, 

// keine Sicherheitsattribute 

// muss bei der seriellen Schnittstelle 

// verwendet werden 

0, // kein asynchroner Zugriff 

); 

NULL 

// muss bei der seriellen Schnittstelle 

// verwendet werden 

// Ist das zurückgegebene Handle gültig? 

if (com == INVALID_HANDLE_VALUE) 

{ 

error = GetLastError(); //Fehlercode holen 

// hier Fehlerbehandlung einfügen 

} 

- 46 -





success = GetCommState(com, &dcb); 

// Ist der Aufruf fehlgeschlagen? 

if (!success) 

{ 


} 

/* Nun setzen wir die wichtigsten Parameter der Kontrollstruktur. Die Baudrate setzen wir auf 

9600, die Bytegröße auf 8, ein Stoppbit, kein Parity. Die übrigen Werte sind schon gesetzt, denn 

wir haben sie ja mit GetCommState() geholt. */ 

dcb.BaudRate = 9600; 

dcb.ByteSize = 8; 

dcb.Parity = NOPARITY; 

dcb.StopBits = ONESTOPBIT; 

success = SetCommState(com, &dcb); 

// Ist der Aufruf fehlgeschlagen? 

if (!success) 

{ 


} 

Ein Byte zu lesen ist nun ganz einfach: 

CODE: 

char byte; 

int bytesread; 

ReadFile( 

com, // Handle 

&byte, // Zeiger auf den Speicher des Bytes, das gelesen wird 

1, // Anzahl der zu lesenden Bytes 

&bytesread, // Anzahl der gelesenen Bytes (wird von der Funktion gesetzt) 

NULL // für unsere Zwecke unwichtig 

); 

// Wenn nun in bytesread eine 1 steht, haben wir in der Variable byte unser gelesenes 

// Byte. Ansonsten sind noch keine Daten an der Schnittstelle angekommen. 

Jedoch ist nach der Initialisierung (bevor wir wie oben die Bytes lesen) noch ein weiterer 

Schritt erforderlich, damit die Abfrage der Schnittstelle in Echtzeit ablaufen kann. 

- 47 -





Das Problem ist, dass es standardmäßig beim Lesen und Schreiben auf die Schnittstelle 

keinen Timeout gibt. D.h. wenn wir ein Byte lesen wollen, aber keines vorhanden ist, bleiben 

wir in der ReadFile-Funktion hängen bis ein Byte kommt. Dies ist natürlich nicht erwünscht. 

Deshalb setzen wir den Timeout so, dass ein Byte zurückgeliefert wird, sofern es vorhanden 

ist. Ansonsten soll es direkt weitergehen mit dem Programm. 

Der Timeout wird folgendermaßen verändert: 

CODE: 

COMMTIMEOUTS timeout; 

if(!GetCommTimeouts(com, &timeout)) 

{ 


} 

timeout.ReadTotalTimeoutConstant = 1; 

timeout.ReadTotalTimeoutMultiplier = 0; 

timeout.ReadIntervalTimeout = 1; 

if(!SetCommTimeouts(com, &timeout)) 

{ 


} 

Der ReadIntervalTimeout gibt an, wie viel Zeit zwischen der Ankunft von 2 Bytes 

verstreichen darf, die ReadTotalTimeoutConstant gibt an, wie lange der Lesevorgang 

insgesamt dauern darf. 

Optimal wäre natürlich ein Wert von 0. Dieser ist jedoch reserviert und bedeutet, dass es 

keinen Timeout gibt. Deshalb werden beide Werte auf 1 gesetzt. Damit hätten wir aber immer 

noch 1ms Wartezeit, was zwar nicht sehr viel ist, den Programmfluss aber dennoch 

verlangsamt. Deshalb wird der ReadTotalTimeoutMultiplier auf 0 gesetzt. Wie am Namen 

unschwer zu erkennen ist, stellt diese Variable einen Vervielfacher dar. Somit werden die 

Timeout-Werte mit 0 multipliziert, wodurch wir das gewünschte Verhalten erzielt haben: Ist 

ein Zeichen da, lesen wir es, ansonsten wird die Funktion direkt verlassen. 

- 48 -





6.2 Die MTV24-Klasse 

Diese Klasse wurde geschrieben, um die V24-Kommunikation sauber in das objektorientierte 

Konzept unseres Codes einzufügen. Die MTV24-Klasse selbst stellt nur ein Interface dar. 

Bisher ist nur das Lesen vorgesehen, da wir für unser Projekt nicht mehr als das brauchten, 

jedoch könnte sie auch leicht erweitert werden. 

Davon abgeleitet ist die MTV24Windows-Klasse, die die Implementation für unsere 

Plattform, nämlich Windows, bereitstellt. 

Da der Windows-Code zum Initialisieren und Lesen der seriellen Schnittstelle bereits im 

vorigen Abschnitt behandelt wurde, gehen wir hier nicht noch einmal darauf ein. 

Den Code zu beiden Klassen finden Sie im Verzeichnis Communications. 

- 49 -





7. Die ManiaTech 3D-Engine 

Die ManiaTech 3D-Engine ist eine Eigenentwicklung, die ich (David Zaadstra) schon vor der 

Projektarbeit in Angriff genommen habe. Sie soll das Arbeiten mit 3D-Grafik erleichtern. 

Nur geringe Teile der Engine wurden während der Projektarbeit verändert. Da sie ausserdem 

fast gar nicht dokumentiert ist und ich sie evtl. später einmal zu kommerziellen Zwecken 

einsetzen möchte, habe ich mich dagegen entschieden, den Quellcode zu veröffentlichen. Auf 

der Projekt-CD sind nur die Libraries zu finden. 

Um Sie jedoch nicht ganz im Unklaren zu lassen, finden Sie nachfolgend eine Einführung in 

die 3D-Grafik und einen kurzen Überblick über die Struktur und Arbeitsweise der Engine. 

7.1 Einführung in (Echtzeit-)3D-Grafik 

7.1.1 Polygone 

Wenn man heutzutage von 3D-Grafik spricht, meint man normalerweise Polygongrafik. 

Andere Methoden zur Darstellung von dreidimensionalen Objekten, wie z.B. die 

Voxelgrafik 2 , werden nur noch selten genutzt. Aktuelle Grafikkarten sind auf die Darstellung 

von Polygongrafiken optimiert. Der Begriff Polygongrafik ist an sich aber auch nicht ganz 

richtig, denn poly = viel und gon = Eck, also Vieleckgrafik. Praktisch werden jedoch nur 

Dreiecke 3 von der Hardware verarbeitet (Im folgenden werden wir deshalb den Begriff 

Polygongrafik nur in Bezug auf Dreiecke benutzen.). Ein Dreieck hat den Vorteil, dass es die 

simpelste geometrische Form ist, die auch eine Fläche hat. Simpel heisst, dass Dreiecke nicht 

komplex werden können und zudem immer alle Eckpunkte auf einer Ebene liegen. Dies ist 

bei Vier- oder Mehrecken nicht immer der Fall. 

Bei Vierecken beispielsweise entstehen drei Richtungsvektoren (der vierte ist abhängig von 2 

anderen), die linear unabhängig sein können. Ist dies der Fall, so erhalten wir einen Raum, 

keine Ebene. Dies ist unerwünscht, da somit das Zeichnen nicht so einfach zu machen ist. 

In anderen ungünstigen Fällen können die Eckpunkte eines Vierecks über Kreuz liegen oder 

eine konkave Form bilden. Auch diese Fälle sind zum Zeichnen der Grafik zu kompliziert. 

Zur Veranschaulichung folgende Beispiele: 

2 Voxel ist die Abkürzung für Volume Element (abgeleitet von Pixel = Picture Element). Ein Voxel stellt nichts 

weiter als einen Punkt im Raum dar, der eine Farbe haben kann, so wie ein Pixel auf einer Ebene. Möchte man 

hochaufgelöste Objekte aus Voxeln haben, entsteht ein immenser Speicherbedarf. Vereinfachte Voxelgrafiken 

wurden schon zur Darstellung von Heightmaps verwendet, z.B. in Outcast[6] und Comanche [7] 

3 APIs wie OpenGL erlauben auch andere geometrische Formen, hierzu sei aber auf weiterführende Literatur 

verwiesen[5] 

- 50 -





Solche Formen ergeben zusammengenommen viele Spezialfälle. Ein Dreieck lässt sich 

dagegen sehr leicht zeichnen, indem man für jede Zeile, die sich auf dem Bildschirm ergibt, 

den Anfangs- und Endpunkt findet und diesen Bereich zeichnet. Diesen Algorithmus 

bezeichnet man als „Scanline Rasterization“. Nähere Informationen dazu finden Sie unter [1]. 

Ein Dreieck stellt also die beste geometrische Form zur Darstellung von dreidimensionalen 

Objekten dar, da es keine simplere Möglichkeit gibt, eine Fläche darzustellen, und sich 

dennoch alle erdenklichen Gebilde aus Dreiecken zusammensetzen lassen. 

7.1.2 Darstellung von Dreiecken: 

In aktueller Hardware werden die Polygone durch Vertizes und Indizes repräsentiert. Ein 

Vertex ist nichts anderes als ein Ortsvektor (mit Zusatzinformationen, doch dazu später 

mehr.). Die Indizes dienen dazu, die Vertizes anzugeben, die ein Dreieck bilden. 

DirectX (auch OpenGL) bietet hierfür Vertex- und Indexbuffer. Haben wir z.B. einen 

Vertexbuffer (der ebenso wie der Indexbuffer nichts anderes als ein Array ist), der drei 

Ortsvektoren des dreidimensionalen Raumes enthält, dann können wir mit einem Indexbuffer, 

der drei Ganzzahlvariablen enthält, ein Dreieck bilden. Im Pseudocode sähe das in etwa so 

aus: 

Vertexbuffer vb[3] 

// hier den Vertexbuffer mit Ortsvektoren füllen 

Indexbuffer ib[3] 

ib[0] = 0 

ib[1] = 1 

ib[2] = 2 

Anschließend ruft man eine Routine zum Zeichnen auf, der man die beiden Arrays übergibt. 

Diese verweist dann mit den ersten 3 Indexbuffer-Einträgen auf die entsprechenden Einträge 

im Vertexbuffer, sodass aus den 3 Vertizes ein Dreieck entsteht. 

Einschub: 

- 51 -





In diesem Fall ist es natürlich nicht sehr sinnvoll, einen Indexbuffer zu benutzen, da die 

Grafikkarte die drei Vektoren ja auch ohne Indexbuffer einfach einlesen könnte (dies lässt sich 

auch so machen.). Jedoch kommt es normalerweise nicht vor, dass man einzelne Dreiecke 

zeichnet; in der Praxis grenzen meist mehrere Dreiecke aneinander, sodass Vertizes mehrfach 

durch die Indizes referenziert werden. Dies spart erstens Platz, da ein Index weniger Speicher 

braucht als ein Vertex, zweitens ermöglicht das Indizieren der Grafikkarte, Cache- 

Optimierungen durchzuführen, hierzu sei jedoch wieder auf weiterführende Literatur 

verwiesen. 

7.1.3 Transformationen: 

Die Positionen der Dreiecke im dreidimensionalen Raum sind nun festgelegt. Es fehlt 

allerdings noch ein Schritt, um die Vertizes auf den zweidimensionalen Bildschirm zu 

projizieren. Hierzu verwenden wir eine Matrix, mit der jeder Vertex multipliziert wird. Diese 

Matrix nennt sich Projektionsmatrix. Eine Projektionsmatrix sieht folgendermaßen aus: 

wobei 

und 

V bezeichnet den Viewport. Das ist der Bildausschnitt, der gezeichnet wird. V W bezeichnet 

die Breite, V H die Höhe des Bereichs. Normalerweise ist dies die Bildschirmauflösung bzw. 

die Größe des Fensters, z.B. V W = 640 und V H = 480. 

Z n und Z f geben die Entfernung der sogenannten „clipping planes“ an. Das sind die Ebenen, 

an denen der Sichtbereich endet. Diese Ebenen liegen orthogonal zum Sichtvektor des 

- 52 -





Betrachters. Z n ist die „near” bzw. „ front clipping plane “, Z f die „far” bzw. „ back clipping 

plane “. Der Sichtbereich wird auch als „viewing frustum“ bezeichnet. Ein solches „frustum“ 

sieht so aus: 

Nach der Projektionstransformation befinden sich die Koordinaten der Vertizes im Bereich 

von (-1,-1,0) bis (1,1,1). Liegen sie nicht in diesem Bereich, werden sie nicht gezeichnet, 

denn sie sind ja nicht sichtbar. 

In der Praxis werden auch noch andere Transformationen verwendet. Dies sind die „world 

transform“ und die „view transform“. Die world transform wird verwendet, um ein Objekt 

(eine Ansammlung zusammengehörender Vertizes) zu transformieren. Hat man z.B. ein 3D- 

Modell eines Menschen, möchte man dieses unabhängig vom Rest der Welt bewegen. Somit 

hat man normalerweise für jedes Objekt eine „world matrix“. 

Die „view matrix“ ist in der Regel nur einmal vorhanden. Sie repräsentiert die „Kamera“, also 

die Position des Betrachters. Bewegt sich der Betrachter beispielsweise 5 Einheiten in z- 

Richtung, muss die view matrix die Vertizes um 5 Einheiten in die entgegengesetzte Richtung 

bewegen. 

Die drei Transformationen werden in folgender Reihenfolge ausgeführt: 

- world transform 

- view transform 

- projection transform 

Um den Rechenaufwand gering zu halten, werden üblicherweise zuerst die Matrizen 

miteinander und anschließend die resultierende Matrix mit den Vertizes multipliziert. 

Weiterführende Informationen zu Transformationen gibt es z.B. unter [2] und [3]. 

- 53 -





7.1.4 Texturen und Farben: 

Nun wissen wir, wie wir die Position eines Dreieckes (bzw. seiner Eckpunkte) bestimmen, 

doch diese Dreiecke haben noch keine Farbe. 

Zum „Färben“ der Dreiecke gibt es zwei Möglichkeiten: 

1. Vertexfarben: 

Zu den oben erwähnten Zusatzinformationen in einem Vertex gehört unter anderem 

auch eine Farbe. Diese Farbe ist eine 32Bit-Ganzzahlvariable, die jeweils 8 Bit für die 

Rot-, Grün-, Blau- und Alphakomponente enthält. Alpha bedeutet Transparenz und 

ermöglicht, (teilweise) transparente Dreiecke zu zeichnen. 

Beim Zeichnen eines Dreiecks werden die Vertexfarben interpoliert. 

2. Texturen: 

Eine Textur stellt ein 1- bis 3-dimensionales Feld von Farbwerten dar. In der Praxis 

werden fast nur 2D-Texturen, also „Bilder“, verwendet. Ein Vertex hat hierzu 

Koordinaten gespeichert (von derselben Dimension wie die 

Textur), die bestimmen, welcher Teil des Bildes auf dem Vertex liegt. 

Dementsprechend liegen auf dem Rest des Dreiecks die dazwischenliegenden Pixel. 

Hierzu eine Illustration: 

- 54 -





7.1.5 Licht: 

Eine weitere wichtige Komponente in der 3D-Grafik sind Lichtquellen. 

Es gibt verschiedene Sorten von Lichtquellen, der Einfachheit halber beschränken wir uns 

jedoch auf die simpelste, das sogenannte „directional light“. Eine solche Lichtquelle hat nur 

eine Richtung und eine Farbe. Die Position des Lichtes wird ignoriert. Der Lichteinfall wird 

so berechnet, als wäre das Licht unendlich weit entfernt und die Strahlen damit parallel. 

Eine Lichtquelle wirkt nun je nach Beleuchtungsmodell („lighting model“) unterschiedlich 

auf die Farbe eines Dreiecks (bzw. eines Pixels des Dreiecks) ein. Es gibt zwei 

Beleuchtungsmodelle, die direkt von aktueller Hardware unterstützt werden. 

1. Flat Shading: 

Nehmen wir an, unser Dreieck ist gegeben durch die drei Ortsvektoren von drei 

Vertizes a, b und c. Dann ist die Normale des Dreiecks das Vektorprodukt von (ba)x(c-a). 

Die Lichtintensität wird bestimmt durch das Skalarprodukt dieser Normale 

mit dem Richtungsvektor der Lichtquelle. Die Farbwerte der Pixel des Dreiecks 

werden nun mit dem Skalarprodukt multipliziert. Wenn Lichtvektor und Normale 

übereinstimmen, ist das Skalarprodukt 1 und damit die volle Lichtintensität gegeben. 

Sind die Vektoren >= 90° auseinander, ist die Lichtintensität





7.1.6 Zeichnen („Rendern“) von Grafik: 

Das eigentliche Rendern der Grafik wird meist vollständig von der Grafikkarte übernommen. 

Der Programmierer tut in der Regel folgendes: 

- Er legt die Vertex- und Indexbuffer an und füllt diese mit seinen Daten. 

- Er lädt Texturen und weist die API an, diese beim Rendern zu verwenden. 

- Er setzt Transformationsmatrizen. 

Den Rest erledigt dann die Grafikkarte. Sie transformiert die Vertizes basierend auf den 

gegebenen Matrizen. Ergebnis ist die Pixelposition der Vertizes auf dem Bildschirm. Der 

Bildschirmbereich wird anschließend mit den Farbwerten gefüllt, die sich durch Vertexfarben, 

Texturen und Lichteinfall ergeben. 

Die ganze Bandbreite der Echtzeit-3D-Grafik lässt sich auf so wenigen Seiten nicht 

vermitteln, dazu ist ein ganzes Buch nötig. Glücklicherweise wurden solche Bücher schon 

von anderen Leute verfasst. Einen sehr guten Überblick über den Bereich der Echtzeit-3D- 

Grafik, des „Realtime Rendering“, bietet das gleichnamige Buch [4]. 

- 56 -





7.2 Struktur der Engine 

Die ManiaTech 3D-Engine ist stark objektorientiert. Sie ist so konzipiert, dass sie gut 

erweiterbar und portierbar ist. Zu diesem Zweck gibt es verschiedene Interface- und 

Basisklassen, von denen man ableiten kann, um neue Funktionalität hinzuzufügen, ohne 

bestehenden Code ändern zu müssen. Ein Diagramm zur Veranschaulichung: 

Dieses Diagramm enthält nur einen Teil der Klassen, aus denen die Engine besteht. Diese 

Klassen sind jedoch die wesentlichsten, die zur Realisierung des Projektes notwendig waren 

und reichen aus, um den Aufbau der Engine grob zu verdeutlichen. 

In der Basis der Engine gibt es grundlegende Klassen wie MTShared oder MTManager. Die 

MTShared-Klasse beispielsweise sorgt für das „Reference Counting“ 1 , die MTManager- 

Klasse implementiert eine Singleton-Klasse 2 als Template. 

1 Die Anzahl der Referenzen auf das Objekt wird gezählt. Benötigt eine andere Klasse das Objekt, erhöht es den 

Zähler mit AddRef(), will sie das Objekt freigeben, so dekrementiert sie den Zähler mit Release(). Sinkt der 

Zähler auf 0, so löscht sich das Objekt selbst. 

2 Ein Singleton ist eine Klasse, die nur eine Instanz besitzt. Über die static-Methode GetInstance() bekommt man 

den Pointer auf diese Instanz. 

- 57 -





Andere Klassen wie MTRenderContext, MTVertexBuffer, etc. stellen Interfaceklassen dar, 

die keine (oder nur wenig) Implementation besitzen. Die Implementation erfolgt dann durch 

die abgeleiteten Klassen MTRenderContextDirect3D8, etc. Dies hat den Vorteil, dass sich 

verschiedene Implementationen benutzen lassen, ohne dass der Code des Benutzers geändert 

werden muss. 

Einschub: 

Solche Prinzipien verwenden auch kommerzielle Programme wie z.B. WinAmp. Dort 

werden DLLs für verschiedene Musikformate in einem eigenen Verzeichnis 

gespeichert. Das Programm sucht dann nach einer DLL für das Dateiformat, das der 

Benutzer abspielen möchte. Diese DLL implementiert die Funktion(en) oder Klasse(n) 

zum Abspielen der Sounddatei. 

Klassen wie MTVertexBuffer sind von MTRenderContext abhängig und müssen daher auch 

von dieser Klasse erstellt werden. Ruft der Benutzer also die entsprechende Methode zum 

Erstellen eines VertexBuffers auf, erfolgt das Erstellen durch die implementierende Klasse, in 

diesem Fall MTRenderContextDirect3D8. Sie erstellt eine Instanz von 

MTVertexBufferDirect3D8, gibt aber einen Pointer auf MTVertexBuffer zurück, sodass die 

Implementation verborgen bleibt. 

- 58 -





7.3 Arbeitsweise der Engine 

Die wichtigsten Klassen zum Rendern von Grafik sind der MTRenderManager, der 

MTRenderContext sowie MTRenderable. 

Der MTRenderManager verwaltet verschiedene MTRenderContexts. Dazu benötigt er nur 

einen Pointer auf die Funktion, die einen solchen erstellt. Diese Funktion kann z.B aus einer 

DLL geladen werden, sodass die Implementation des MTRenderContexts jederzeit 

ausgetauscht werden kann, ohne dass das Programm geändert wird. 

Der MTRenderContext ist nun für das Rendern von Grafik zuständig. Hierzu hat er eine Liste 

von MTRenderable-Objekten. Ein MTRenderable ist nur ein Interface, das eine Funktion zum 

Rendern zur Verfügung stellt. So ist es möglich, jederzeit neue Klassen von MTRenderable 

abzuleiten und rendern zu lassen, ohne die MTRenderContext-Klasse zu verändern. 

Das gesamte Rendern der Engine geschieht also durch einen Aufruf der Render-Funktion von 

MTRenderManager. Dieser wiederum ruft die Render-Funktion aller MTRenderContexts auf, 

die wiederum alle MTRenderable-Objekte rendern. 

- 59 -





8. Die Landschaft 

Die Landschaft liegt als ausführbare Windows-Datei vor, die mit Microsoft Visual C++ 6 

entwickelt wurde. Sie besteht aus einem Optionsmenü, das mit Hilfe des MFC- 

Klassenassistenten von Visual C++ erstellt wurde. 

Die beiden Hauptaufgaben des Programms sind das Zeichnen der 3D-Grafik sowie der 

Empfang der Bytes von der V24-Schnittstelle und das Ausführen der entsprechenden 

Aktionen. 

Der Benutzer hat die Möglichkeit, sich als Betrachter entweder laufend oder fliegend in der 

Landschaft zu bewegen. Weiterhin steht ein Demomodus zur Verfügung, in dem sich der 

Betrachter auf einer zufallsbasierten Flugbahn bewegt. 

Da der C++-Code relativ umfangreich ist, wird nur der Code des Hauptprogramms der 

Dokumentation beigefügt. Die Funktion der anderen Programmteile wird nur beschrieben, 

ohne auf die technischen Details einzugehen; der interessierte Leser kann sich den Code auf 

der zugehörigen CD-ROM anschauen. 

8.1 Das Optionsmenü 

Das Optionsmenü ermöglicht die Konfiguration der Grafik und Steuerung sowie die Auswahl 

einer anderen Höhenkarte. 

Das Erstellen eines solchen Dialoges gestaltet sich recht einfach: Die Steuerelemente wie z.B. 

Buttons oder Kontrollkästchen lassen sich im Resourceneditor von Visual C++ auf einfachste 

Weise platzieren und editieren. Mit dem MFC-Klassenassistenten lassen sich den 

Steuerelementen Objekte zuweisen – jedes Steuerelement hat eine eigene Klasse. So lassen 

sich beim Start des Programms die gewählten Einstellungen abfragen und auswählen. 

Beispielsweise gibt es die für Kontrollkästchen die Klasse CButton, mit deren Methode 

GetCheck() sich der Status als bool-Variable abfragen lässt, also angewählt oder nicht 

angewählt. 

Als Optionen stehen zur Verfügung: 

1. Grafikoptionen: 

- Es lässt sich die Auflösung wählen. Zur Auswahl stehen, 640*480, 800*600 und 

1024*768 

- Das Programm kann im Vollbild- oder im Fenstermodus gestartet werden. 

- 60 -





- Antialiasing (Kantenglättung) kann aktiviert werden, sofern die Grafikkarte dies 

beherrscht. 

2. Steuerungsoptionen: 

Die Steuerung per Tastatur und per Fernbedienung lassen sich einzeln ein- oder 

ausschalten. 

3. Laden einer Heightmap: 

Es lässt sich statt der beigefügten Höhenkarte eine andere laden. Diese muss im 24bit- 

BMP-Format vorliegen. 

8.2 Laden der Landschaft 

Die Landschaft liegt in einem Graustufenbild im bmp-Format vor. Höhenwerte werden durch 

unterschiedliche Graustufen repräsentiert. Der Einfachheit halber haben wir uns für eine 

24bit-Bitmap entschieden. Dies erspart uns das Laden einer Farbpalette (wie es bei einer 8bit- 

Bitmap der Fall wäre) und ermöglicht uns, die Höhe eines Punktes der Landschaft direkt aus 

den RGB-Werten zu lesen. Da bei jedem Grauton Rot-, Grün- und Blau-Anteil gleich sind, 

verschwendet die Datei natürlich Platz. Jedoch benutzen wir für unser Projekt ohnehin nur 

eine 257*257 Bitmap, was den benötigten Festplattenplatz vernachlässigbar macht. 

Das Laden der Bitmap gestaltet sich relativ simpel. Das bmp-Format hat einen 54 Byte 

großen Header. Dessen Daten sind für unsere Zwecke unwichtig, lediglich die Höhe und 

Breite der Bitmap werden gelesen, sodass wir ohne weiteres auch Bitmaps anderer Größe 

verwenden könnten (wichtig ist nur, dass die Größe 2 n + 1 ist). 

Danach folgen in der Datei nur die RGB-Werte, jeweils 1 Byte für Rot-, Grün- und Blau- 

Komponente. Zu beachten ist nur, dass nach jeder Zeile der Bitmap so viele Bytes gelesen 

werden, dass die Gesamtanzahl der gelesenen Farbbytes durch 4 teilbar ist. 

Der Code, der die Bitmap liest, befindet sich in der Datei Landscape.cpp in der Funktion 

LoadHeightFile. 

- 61 -





8.3 Erzeugung der 3D-Daten 

Zunächst muss natürlich ein Vertexbuffer erzeugt werden. Dies geschieht mit einem simplen 

Aufruf der Methode CreateVertexBuffer der Klasse MTRenderContext. Die Anzahl der 

Vertizes ergibt sich aus dem Produkt von Höhe und Breite der Landschaft. 

Positionsdaten: 

Auch das Erzeugen der Positionsdaten gestaltet sich einfach. Die x- und die z-Position des 

Vertex ergeben sich von selbst, da wir ein quadratisches Feld von Höhenwerten haben. Die x- 

und z-Position sind also nur die Indizes in dieses Feld. Die y-Position ist der Wert an der 

entsprechenden Stelle im Feld. 

Normalen: 

Die Vertexnormalen werden berechnet, indem die Normalen der anliegenden Polygone 

gemittelt werden. 

Farbwerte: 

Die Farbwerte ergeben sich aus der Höhe der Landschaft. Es gibt 4 Höhenbereiche: Zu unterst 

Sand, dann Gras, Fels und Schnee. Jeder dieser Bereiche fängt auf einer bestimmten Höhe an 

und hat eine Farbe zugeordnet. Farbwerte auf dazwischenliegenden Höhen werden linear aus 

den beiden angrenzenden Bereichen interpoliert. 

Texturkoordinaten: 

Auch die Texturkoordinaten sind höhenabhängig. Jeder der Farbbereiche hat auch eine Textur 

zugeordnet. Diese Texturen sind sogenannte Detailtexturen; sie enthalten Graustufen, die mit 

den Vertexfarben gemischt werden, sodass diese unterschiedliche Tönungen erhalten und 

damit detaillierter wirken. Alle 4 „logischen“ Texturen sind in einer „physikalischen“ 

enthalten. Welche logische Textur benutzt wird, hängt also nur von den Koordinaten ab. 

Es werden zwei Texturen verwendet und gemischt, damit die harten Übergänge zwischen den 

Höhenstufen verschwinden. 

Den Code zur Erzeugung der Daten finden Sie in der Funktion CreateChunks in der Datei 

Landscape.cpp. 

- 62 -





8.4 Der Himmel 

Der Himmel wird durch einen Würfel um den Betrachter herum repräsentiert. Dies mag nicht 

besonders realistisch klingen, doch eine gute Textur erweckt mit dieser Methode durchaus 

einen glaubwürdigen Eindruck, und dieses Verfahren wird auch in vielen Computerspielen 

eingesetzt. Ein solcher Himmel nennt sich Skybox. 

Die Berechnung des Himmels ist sehr einfach. Es werden sechs Seiten aus jeweils vier 

Vertizes erzeugt. Jede Seite besteht demnach aus zwei Polygonen und bekommt eine Textur 

zugewiesen. Die Texturen fügen sich nahtlos aneinander, sodass die geometrische Form des 

Würfels nicht zu erkennen ist. 

Wichtig ist, dass die Box sich mit dem Betrachter mitbewegt, damit der Himmel immer gleich 

weit entfernt aussieht und somit einen glaubwürdigen Eindruck eines Horizonts erweckt. 

Den Code finden Sie in den Dateien Skybox.h und Skybox.cpp. 

8.5 Der Demomodus 

Neben der Möglichkeit, durch die Landschaft zu laufen und zu fliegen, gibt es auch einen 

Demomodus. In diesem Modus bewegt sich der Betrachter auf einer zufallsberechneten 

Flugbahn. Dies funktioniert so, dass eine Anzahl von Wegpunkten berechnet wird, die dann 

als Splinekurve 1 interpoliert werden, sodass der Betrachter sich auf runden Bahnen durch die 

Welt bewegt. Die Berechnung der Wegpunkte erfolgt so, dass der Betrachter nicht mit der 

Landschaft kollidiert und diese auch nicht verlässt. Ausserdem ist eine maximale Flughöhe 

vorgegeben. Im Demomodus hat der Betrachter keine weiteren Möglichkeiten zur Steuerung. 

Er kann nur den Modus verlassen oder das Programm beenden. 

1 Es werden sogenannte Hermite Splines verwendet. Diese lassen sich ganz einfach aus der Differentialrechnung 

herleiten. Mehr dazu unter [8] 

- 63 -





8.6 Die Kontrollen 

Das Programm lässt sich per Tastatur, Fernbedienung oder beidem steuern. Hier die 

Tastenbelegungen: 

8.6.1 Fernbedienung: 

Beenden des Programms 

E/A 

Store 

vorwärts bewegen 

1 2 3 

4 5 6 

7 8 9 

nach oben drehen 

nach unten drehen 

nach rechts drehen 

rückwärts bewegen 

nach links drehen 

Demo-Rundflug 

starten/beenden 

Index Timer Radio 

Mute TV/Sat A/B 

laufen/fliegen 

umschalten 

Audio 

Video 

- 64 -





8.6.2 Tastatur: 

W 

S 

D 

F 

↑ 

↓ 

← 

→ 

Vorwärts bewegen 

Rückwärts bewegen 

Demo-Rundflug starten / beenden 

Laufen/fliegen umschalten 

Nach oben drehen 

Nach unten drehen 

Nach links drehen 

Nach rechts drehen 

8.7 Das Hauptprogramm 

Das Hauptprogramm wird aufgerufen sobald im Optionsmenü der OK-Button betätigt wird. 

Es findet in der OnOk()-Methode des Optionsdialoges statt, wird also beim Klick automatisch 

aufgerufen. 

Da wir nichts davon halten, jede Programmzeile in ein Struktogramm zu übertragen, haben 

wir das Struktogramm stark vereinfacht, sodass die Vorgehensweise, aber nicht unmittelbar 

der Code, ersichtlich wird. Danach folgt der ausführlich dokumentierte Code, wobei wir von 

Visual C++ automatisch generierten Code ausgelassen haben, da dieser unwesentlich ist. 

- 65 -





8.7.1 Das Struktogramm 

Hauptprogramm 

Fensterklasse registrieren und Fenster erzeugen 

Render-DLL laden 

Renderer registrieren und aktivieren 

RenderContext erzeugen 

Landschaft erstellen und dem RenderContext hinzufügen 

Himmel erstellen und dem RenderContext hinzufügen 

Kamera aktivieren und Position setzen 

V24 initialisieren 

Endlosschleife 

Windows-Nachricht empfangen 

J 

Schleife verlassen 

J 

V24 Bytes lesen 

für alle Bytes, die empfangen wurden 

2 oder 6 

vorwärts 

bewegen 

J 

Demo fortsetzen 

J 

Kollision verhindern 

Grafik rendern 

4 oder 8 

rückwärts 

bewegen 

1 oder 

5 

links 

drehen 

3 oder 

7 

rechts 

drehen 

9 

Quit-Message 

absetzen 

Nachricht = Quit? 

Nachricht an die Fensterprozedur weiterleiten 

18 

nach 

oben 

gucken 

Demomodus? 

Flug-/Demomodus? 

20 

nach 

unten 

gucken 

Position auf Bodenhöhe setzen 

Fernbedienungssteuerung aktiviert? 

25 

Demomodus 

starten/beenden 

aktuelles Byte 

26 

Umschalten 

Laufen/Fliegen 

N 

N 

N 

N 

- 66 -





8.7.2 Der Code 

// TestappDlg.cpp : Implementierungsdatei 

// 

#define RPC_NO_WINDOWS_H 

#define WIN32_LEAN_AND_MEAN 

#include "stdafx.h" 

#include "Testapp.h" 

#include "TestappDlg.h" 

#include 

#include "HermiteSpline.h" 

#ifdef _DEBUG 

#define new DEBUG_NEW 

#undef THIS_FILE 

static char THIS_FILE[] = __FILE__; 

#endif 

// Startposition des Betrachters (der Kamera) 

#define STARTX 128.0f 

#define STARTZ 128.0f 

// die Distanz, die der Betrachter mit einem Tastendruck zurücklegt 

#define MOVEMENTSPEED (1.0f) 

// der Winkel, um den sich der Betrachter mit einem Tastendruck dreht 

// (Bogenmaß) 

#define TURNINGSPEED (0.1f) 

// Höhe der Kamera über dem Boden 

#define CAMHEIGHT 7.0f 

// Nummer der Wegpunkte im Demo(Flyby)-Modus 

#define NUMWAYPOINTS 1000 

// maximale Flughöhe für den Demomodus 

#define MAXFLIGHTHEIGHT 120.0f 

// Geschwindigkeit im Demomodus 

#define FLYBYSPEED 0.15f 

// ungefähre Distanz zwischen 2 Wegpunkten 

#define WAYPOINTDISTANCE 50.0f 

// Multiplikator für die Splinenormalen 

#define NORMALMULTIPLIER 100.0f 

// Exponent für die Zufallswerte, die zur Winkelberechnung im Demomodus 

// berechnet werden 

#define ANGLEEXPONENT 3.0f 

// maximaler Höhenunterschied zwischen zwei Wegpunkten 

#define WAYPOINTHEIGHT (WAYPOINTDISTANCE / 1.7f) 

/* diese Distanz wird in der Kollisionsabfrage addiert um sie sicherer zu 

machen (weil die Collision()-Funktion nur auf Kollisionen auf der Geraden 

zwischen den Wegpunkten, nicht auf dem Spline prüft*/ 

#define SAFETYHEIGHT 10.0f 

MTCamera 

g_camera("cam"); // die Betrachterkamera 

MTLandscape * g_land; // Pointer auf die Landschaft 

bool g_flying; // Fliegen wir? 

bool g_flyby; // sind wir im Flyby-Demomodus? 

// unsere Wegpunkte für den Demomodus 

MTVector3D g_waypoints[NUMWAYPOINTS]; 

// Index des aktuellen Wegpunkts 

int 

g_currentwaypoint; 

- 67 -





// Pointer auf die aktuelle Splinekurve 

HermiteSpline * g_currentspline; 

// Interpolationswert für den Spline 

float g_flybyinterpolator = 0.0f; 

// Tastatursteuerung an? 

bool g_keyboard; 

/////////////////////////////////////////////////////////////////////////// 

Hier folgt von Visual C++ generierter Code, den wir ausgelassen haben, da 

er nichts zur Sache tut. 

/////////////////////////////////////////////////////////////////////////// 

BOOL CTestappDlg::OnInitDialog() 

{ 

CDialog::OnInitDialog(); 

// Symbol für dieses Dialogfeld festlegen. Wird automatisch erledigt 

// wenn das Hauptfenster der Anwendung kein Dialogfeld ist 

SetIcon(m_hIcon, TRUE); 

// Großes Symbol verwenden 

SetIcon(m_hIcon, FALSE); 

// Kleines Symbol verwenden 

// ZU ERLEDIGEN: Hier zusätzliche Initialisierung einfügen 

// Standard-Datei setzen 

m_heightfileedit.SetSel(0, m_heightfileedit.GetLimitText()); 

m_heightfileedit.ReplaceSel("height.bmp"); 

m_resolution.SetCurSel(0); 

m_keyboard.SetCheck(true); 

m_remote.SetCheck(true); 

GetCurrentDirectory(1023, m_directory); 

} 

return TRUE; 

/////////////////////////////////////////////////////////////////////////// 

Hier folgt von Visual C++ generierter Code, den wir ausgelassen haben, da 

er nichts zur Sache tut. 

/////////////////////////////////////////////////////////////////////////// 

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

** Diese Funktion bewegt die Betrachterkamera um MOVEMENTSPEED Einheiten.** 

** Im Flugmodus einfach in Richtung des Betrachtungsvektors, im Laufmodus** 

** an der Landschaft entlang. Das Flag forward gibt an, ob die Bewegung ** 

** vorwärts oder rückwärts erfolgen soll. ** 

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

void Move(bool forward) 

{ 

if(g_flying) 

{ 

/* im Flugmodus bewegen wir uns einfach in Richtung des 

Betrachtunsvektors der Kamera (bzw entgegengesetzt, je nach 

forward-Flag)*/ 

float direction = 1.0f; 

if(!forward) direction = -1.0f; 

g_camera.SetPosition(g_camera.GetPosition() + 

- 68 -





} 

else 

{ 

MTVector3D vec; 

float dist; 

float dx, dy, dz; 

direction * MOVEMENTSPEED * 

g_camera.GetLookAtVector()); 

} 

} 

// Positionsunterschied für Bewegung nach vorne berechnen 

dx = g_camera.GetLookAtVector().x; 

dz = g_camera.GetLookAtVector().z; 

dy = g_land->GetAltitude(g_camera.GetPosition().x+dx, 

g_camera.GetPosition().z+dz) – 

g_land->GetAltitude(g_camera.GetPosition().x, 

g_camera.GetPosition().z); 

// Richtung umkehren, wenn rückwärts 

if(!forward) 

{ 

dx *= -1; 

dy *= -1; 

dz *= -1; 

} 

// Positionsunterschied angleichen (auf die Länge von 

// MOVEMENTSPEED) 

dist = sqrt(dx*dx + dy*dy + dz*dz); 

dist /= MOVEMENTSPEED; 

dx /= dist; dy /= dist; dz /= dist; 

// Position berechnen und setzen 

float xpos = g_camera.GetPosition().x; 

float zpos = g_camera.GetPosition().z; 

xpos += dx; 

zpos += dz; 

g_camera.SetPosition(MTVector3D(xpos, g_land->GetAltitude(xpos, 

zpos) + CAMHEIGHT, zpos)); 

/////////////////////////////////////////////////////////////////////////// 

void RotateUp() 

{ 

// Um den Rechtsvektor (die lokale x-Achse der Kamera) rotieren 

g_camera.Rotate(g_camera.GetRightVector(), TURNINGSPEED); 

} 

/////////////////////////////////////////////////////////////////////////// 

void RotateDown() 

{ 

// Um den Rechtsvektor (die lokale x-Achse der Kamera) rotieren 

g_camera.Rotate(g_camera.GetRightVector(), -TURNINGSPEED); 

} 

/////////////////////////////////////////////////////////////////////////// 

void RotateLeft() 

- 69 -





{ 

} 

// um die y-Achse rotieren 

g_camera.Rotate(MTVector3D(0,1,0), TURNINGSPEED); 

/////////////////////////////////////////////////////////////////////////// 

void RotateRight() 

{ 

// um die y-Achse rotieren 

g_camera.Rotate(MTVector3D(0,1,0), -TURNINGSPEED); 

} 

/////////////////////////////////////////////////////////////////////////// 

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

** Diese Funktion prüft ob die Gerade von pos1 nach pos2 die Landschaft ** 

** (ungefähr) schneidet. ** 

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

bool Collision(MTVector3D pos1, MTVector3D pos2) 

{ 

// Entfernungsunterschied zwischen den beiden Positionen berechnen 

float dist = MTVec3Length(pos2-pos1); 

// Schrittweite berechnen (sollte ca 1 sein) 

MTVector3D step = (pos2-pos1) / dist; 

// die gesamte Distanz durchlaufen... 

for(int i = 0; i < (int)dist; i++) 

{ 

// ... und prüfen ob die Gerade unterhalb der Landschaft liegt. 

// Wenn ja, Kollision 

pos1 += step; 

if(pos1.y < g_land->GetAltitude(pos1.x, pos1.z) + 

CAMHEIGHT + SAFETYHEIGHT) 

return true; 

} 

} 

// keine Kollision 

return false; 

/////////////////////////////////////////////////////////////////////////// 

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

** Diese Funktion startet den Demomodus. Dazu berechnet sie alle ** 

** Wegpunkte und berechnet das erste Spline. ** 

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

void StartFlyBy() 

{ 

float height; 

float angle; 

// Winkel auf Zufallswert setzen 

float oldangle = ((float)rand() / (float)RAND_MAX) * 2 * MT_PI; 

float dangle; 

// Startposition zur Berechnung ist die Kameraposition 

float oldx = g_camera.GetPosition().x; 

float oldz = g_camera.GetPosition().z; 

float oldy = g_camera.GetPosition().y + SAFETYHEIGHT; 

float x, z; 

- 70 -





float turndirection; 

// Zufallswerte initialisieren 

srand(time(NULL)); 

// Flag setzen, damit der Flug später fortgesetzt wird. 

g_flyby = true; 

// alle Wegpunkte... 

for(int i = 0; i < NUMWAYPOINTS; i++) 

{ 

do 

{ 

do 

{ 

// Winkelunterschied im Bereich von 0 bis 180°. 

// Zufallswert wird potenziert, 

// um öfter kleinere Winkel zu erzeugen. 

dangle = pow(((float)rand() / (float)RAND_MAX), 

ANGLEEXPONENT) * MT_PI; 

// Drehrichtung bestimmen 

turndirection = floor(((float)rand() / 

(float)RAND_MAX) + 0.5f) * 2.0f -1.0f; 

dangle *= turndirection; 

angle = oldangle + dangle; 

// neue x/y-Position = alte Position + 

// WAYPOINTDISTANCE Einheiten in Winkelrichtung 

g_waypoints[i].x = oldx + sin(angle) * 

WAYPOINTDISTANCE; 

g_waypoints[i].z = oldz + cos(angle) * 

WAYPOINTDISTANCE; 

x = g_waypoints[i].x; 

z = g_waypoints[i].z; 

// so lange bis die Position nicht ausserhalb der Karte 

// liegt 

} while(x > (float)(g_land->GetWidth()) || x < 0 

|| z > (float)(g_land->GetHeight()) || z < 0); 

// Höhe im Bereich zwischen der Höhe der Landschaft und 

// der maximalen Flughöhe 

height = g_land->GetAltitude(x, z) + CAMHEIGHT; 

g_waypoints[i].y = ((float)rand() / (float)RAND_MAX) * 

(MAXFLIGHTHEIGHT - height) + height; 

// solange bis keine Kollision mit der Landschaft entsteht und 

// der Höhenunterschied zwischen der alten und der neuen 

// Position nicht größer als WAYPOINTHEIGHT ist 

} while(Collision(MTVector3D(oldx, oldy, oldz), 

MTVector3D(x, g_waypoints[i].y, z)) || 

fabs(g_waypoints[i].y - oldy)>WAYPOINTHEIGHT); 

} 

// alte Werte für den nächsten Durchlauf setzen 

oldx = x; 

oldy = g_waypoints[i].y; 

oldz = z; 

oldangle = angle; 

// Wegpunkt initialisieren 

- 71 -





g_currentwaypoint = 0; 

} 

// ersten Spline berechnen, die Normale (Lookat) in einem Punkt 

// ergibt sich aus dem normalisierten Vektor zwischen dem Wegpunkt 

// davor und dem danach, multipliziert mit NORMALMULTIPLIER 

MTVector3D lookat = g_waypoints[1] - g_waypoints[NUMWAYPOINTS-1]; 

MTVec3Normalize(lookat); 

lookat *= NORMALMULTIPLIER; 

MTVector3D lookat2 = g_waypoints[2] - g_waypoints[0]; 

MTVec3Normalize(lookat2); 

lookat2 *= NORMALMULTIPLIER; 

g_currentspline = new HermiteSpline(g_waypoints[0], 

lookat, g_waypoints[1], lookat2); 

/////////////////////////////////////////////////////////////////////////// 

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

** Diese Funktion setzt den Demomodus fort. Hierzu wird die nächste ** 

** Position auf dem aktuellen Spline berechnet. Wenn das Ende des ** 

** aktuellen Splines ereicht ist, wird der nächste Spline berechnet. ** 

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

void ContinueFlyBy() 

{ 

// Interpolator basierend auf vergangener Zeit und 

// Fluggeschwindigkeit erhöhen 

g_flybyinterpolator += FLYBYSPEED * g_rendermanager->GetFrameTime(); 

// ein Spline liegt immer zwischen 0 und 1, also bei 1 nächster 

// Spline 

while(g_flybyinterpolator > 1.0f) 

{ 

g_flybyinterpolator -= 1.0f; 

g_currentwaypoint++; 

// wenn wir den letzten Wegpunkt erreicht haben, landen wir 

// wieder beim ersten 

g_currentwaypoint %= NUMWAYPOINTS; 

// alten Spline löschen 

delete g_currentspline; 

} 

// neuen Spline wie oben berechnen 

MTVector3D lookat, lookat2; 

lookat = g_waypoints[(g_currentwaypoint+1)%NUMWAYPOINTS] – 

g_waypoints[(g_currentwaypoint-1)%NUMWAYPOINTS]; 

MTVec3Normalize(lookat); 

lookat *= NORMALMULTIPLIER; 

lookat2 = g_waypoints[(g_currentwaypoint+2)%NUMWAYPOINTS] – 

g_waypoints[(g_currentwaypoint)%NUMWAYPOINTS]; 

MTVec3Normalize(lookat2); 

lookat2 *= NORMALMULTIPLIER; 

g_currentspline = new 

HermiteSpline(g_waypoints[g_currentwaypoint], 

lookat, g_waypoints[(g_currentwaypoint+1)%NUMWAYPOINTS], 

lookat2); 

// Kameraposition basierend auf Interpolationswert des Splines setzen 

g_camera.SetPosition(g_currentspline->GetValue(g_flybyinterpolator)); 

- 72 -





// Lookat-Punkt (Ortsvektor) für die Kamera berechnen 

// = aktuelle Position + kleines Stück weiter auf dem Spline 

MTVector3D look; 

look = g_currentspline->GetValue(g_flybyinterpolator) – 

g_currentspline->GetValue(g_flybyinterpolator-0.001f); 

MTVec3Normalize(look); 

look += g_currentspline->GetValue(g_flybyinterpolator); 

// leicht nach unten gucken 

look.y -= 0.45f; 

} 

// Lookat für die Kamera setzen. 

g_camera.SetLookAt(look, MTVector3D(0,1,0)); 

/////////////////////////////////////////////////////////////////////////// 

LRESULT CALLBACK MTWindowProc(HWND hwnd, 

UINT msg, 

WPARAM wparam, 

LPARAM lparam) 

{ 

PAINTSTRUCT ps; 

HDC 

hdc; 

switch(msg) 

{ 

case WM_CREATE: 

{ 

return 0; 

} break; 

case WM_PAINT: 

{ 

hdc = BeginPaint(hwnd,&ps); 

EndPaint(hwnd,&ps); 

return 0; 

} break; 

case WM_DESTROY: 

{ 

PostQuitMessage(0); 

return 0; 

} break; 

case WM_KEYDOWN: 

{ 

if(g_keyboard) 

{ 

if(g_flyby) 

{ 

// im Flyby-Demomodus nur auf Escape und D 

// (Demomodus beenden) reagieren 

if(wparam == 'D') 

{ 

g_flyby = false; 


} 

- 73 -





} 

} break; 

} 

else 

{ 

} 

else if(wparam == VK_ESCAPE) 


switch(wparam) 

{ 

// vorwärts bewegen 

case 'W': 

Move(true); break; 

// rückwärts bewegen 

case 'S': 

Move(false); break; 

// Flugmodus verlassen 

case 'F': 

g_flying = !g_flying; break; 

// Demomodus starten 

case 'D': 

StartFlyBy(); break; 

// nach oben gucken 

case VK_UP: RotateUp(); break; 

// nach unten gucken 

case VK_DOWN: RotateDown(); break; 

// nach links drehen 

case VK_LEFT: RotateLeft(); break; 

// nach rechts drehen 

case VK_RIGHT: RotateRight(); break; 

// Programm verlassen 

case VK_ESCAPE: PostQuitMessage(0); break; 

} 

} 

default:break; 

} 

return (DefWindowProc(hwnd, msg, wparam, lparam)); 

/////////////////////////////////////////////////////////////////////////// 

//////// 

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

** In dieser Methode findet das Hauptprogramm statt. Es startet beim ** 

** Druck auf OK. Es erstellt ein neues Fenster, startet die 3D-Engine, ** 

** initialisiert V24 und Landschaft und läuft dann in einer ** 

** while-Schleife, wo Userinputs abgearbeitet werden und gerendert wird. ** 

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

void CTestappDlg::OnOK() 

{ 

WNDCLASS winclass; 

MSG 

msg; 

HINSTANCE hinstance = GetModuleHandle(NULL); 

HWND hwnd; 

// Fensterklassen-Struktur füllen 

winclass.style = CS_DBLCLKS | CS_OWNDC | 

CS_HREDRAW | CS_VREDRAW; 

winclass.lpfnWndProc = MTWindowProc; 

winclass.cbClsExtra = 0; 

winclass.cbWndExtra = 0; 

winclass.hInstance = hinstance; 

winclass.hIcon 

= LoadIcon(NULL, IDI_APPLICATION); 

- 74 -





winclass.hCursor = LoadCursor(NULL, IDC_ARROW); 

winclass.hbrBackground = (HBRUSH)GetStockObject(BLACK_BRUSH); 

winclass.lpszMenuName = NULL; 

winclass.lpszClassName = "ManiaTech Window"; 

// Fensterklasse registrieren 

if (!RegisterClass(&winclass)) 

{ 

exit(1); 

} 

// Tastatursteuerung? 

g_keyboard = m_keyboard.GetCheck(); 

// gewählte Auflösung der ComboBox auswerten 

switch(m_resolution.GetCurSel()) 

{ 

case 0: m_width = 640; m_height = 480; break; 



} 

// Fenster erzeugen 

if (!(hwnd = CreateWindow("ManiaTech Window", 

"ManiaTech Landscape Demo", 

WS_OVERLAPPEDWINDOW | WS_VISIBLE, 

0,0, 

m_width, 

m_height, 

NULL, 

NULL, 

hinstance, 

NULL))) 

{ 

} 

// DLLManager-Klasse. Lädt und verwaltet DLLs. 

MTDLLManager 

dllman; 

// Der Rendermanager ist das Rendering-Subsystem der Engine 

MTRenderManager 

renderman; 

// das Interface zum Rendern von Grafik 

MTRenderContext * 

context; 

// Pointer auf die Create-Funktion der DLL 

MTRenderManager::CreateRenderContextPtr 

createcontextptr; 

// Pointer auf die Render-DLL 

MTDLL * 

dx8dll; 

// Schleifenzähler 

int i; 

// aktuelles Verzeichnis setzen. (wird bei Initialisierung gesichert, 

// da der Windows-Öffnen-Dialog das Verzeichnis ändert) 

SetCurrentDirectory(m_directory); 

// Laden der Render-DLL 

dx8dll = dllman.LoadDLL("RendererDirect3D8.dll"); 

assert(dx8dll); 

// Create-Pointer aus der DLL-Laden. Die Funktion, auf die der 

// Pointer zeigt, ist für die Erstellung eines RenderContexts 

- 75 -





// zuständig. 

createcontextptr = (MTRenderManager::CreateRenderContextPtr) 

dx8dll->GetFunctionAddress("CreateContext"); 

assert(createcontextptr); 

// Renderer registrieren und auswählen 

renderman.SetRenderer(renderman.RegisterRenderer("DirectX8", 

createcontextptr)); 

// RenderContext erzeugen 

context = renderman.CreateRenderContext(&hwnd, 

m_fullscreenbutton.GetCheck(), m_width, 

m_height, 1, MTFMT_A8R8G8B8, MTFMT_D24X8, 

((int)m_aliasbutton.GetCheck())*2, 75, 

false, false); 

assert(context); 

// Dateinamen für die Heightmap aus dem Editfeld holen 

char heightfile[1024]; 

m_heightfileedit.GetLine(0, heightfile, 255); 

// Landschaft erzeugen ... 

MTLandscape landscape(context, string(heightfile), 7); 

// ... und dem RenderContext hinzufügen 

context->AddRenderable(&landscape); 

// globalen Pointer auf die Landschaft setzen 

g_land = &landscape; 

// Himmel erzeugen ... 

MTSkyBox skybox(context, 500, "camTOP.jpg", "camWE.jpg", "camNO.jpg", 

"camEA.jpg", "camSO.jpg", "camBOT.jpg"); 

// ... und dem RenderContext hinzufügen 

context->AddRenderable(&skybox); 

// Kamera setzen 

context->SetCamera(&g_camera); 

// Startposition des Betrachters setzen 

g_camera.SetPosition(MTVector3D(STARTX, landscape.GetAltitude(STARTX, 

STARTZ)+CAMHEIGHT, STARTZ)); 

// V24 initialisieren 

MTV24Windows v24; 

Byte bytes[256]; // Puffer für die Bytes von der V24 

DWord numbytes; 

if(m_remote.GetCheck()) 

{ 

v24.Init(1, 9600, 8, V24STOP_ONE, V24PARITY_NONE); 

} 

while(1) 

{ 

// Nachrichten abarbeiten 

if(PeekMessage(&msg,NULL,0,0,PM_REMOVE)) 

{ 

// Programm beenden, wenn wir eine WM_QUIT Message 

// bekommen 

if (msg.message == WM_QUIT) 

{ 

break; 

- 76 -





} 

TranslateMessage(&msg); 

} 

// Nachrichten an die Windowprozedur senden 

// (MTWindowProc) 

DispatchMessage(&msg); 

if(m_remote.GetCheck()) 

{ 

// Bytes von der V24 lesen... 

numbytes = v24.Read(bytes, 256); 

for(i = 0; i < numbytes; i++) 

{ 

// ... und interpretieren 

if(g_flyby) 

{ 

// im Flyby-Demomodus nur auf Quit und 

// Demomodus-Taste 

// (Demo beenden) reagieren 

if(bytes[i] == 25) 

{ 

g_flyby = false; 


} 

else if(bytes[i] == 9) 


} 

else 

{ 

switch(bytes[i]) 

{ 

// vorwärts bewegen 

case 1: case 5: Move(true); break; 

// rückwärts bewegen 

case 3: case 7: Move(false); break; 

// Flugmodus verlassen 

case 26: 

g_flying = !g_flying; break; 

// Demomodus starten 

case 25: 

StartFlyBy(); break; 

// nach oben gucken 

case 18: 

RotateUp(); break; 

// nach unten gucken 

case 20: 

RotateDown(); break; 

// nach links drehen 

case 2: case 6: RotateLeft(); break; 

// nach rechts drehen 

case 4: case 8: RotateRight(); break; 

// Programm verlassen 

case 9: PostQuitMessage(0); break; 

} 

} 

} 

} 

// Im Demomodus Flug fortsetzen 

if(g_flyby) 

ContinueFlyBy(); 

- 77 -





// Kollisionsverhinderung (Betrachter bleibt CAMHEIGHT 

// Einheiten über dem Boden) 

if(g_flying || g_flyby) 

{ 

float xpos = g_camera.GetPosition().x; 

float zpos = g_camera.GetPosition().z; 

} 

else 

{ 

} 

if(g_camera.GetPosition().y < 

landscape.GetAltitude(xpos, zpos) + CAMHEIGHT) 

g_camera.SetPosition(g_camera.GetPosition() + 

MTVector3D(0, landscape.GetAltitude(xpos, zpos) + 

CAMHEIGHT- g_camera.GetPosition().y, 0)); 

// im Laufmodus auf Bodenhöhe bleiben (ist normalerweise 

// schon der Fall, 

// aber nicht beim Wechsel von Flug- zu Laufmodus) 

float x = g_camera.GetPosition().x, z = 

g_camera.GetPosition().z; 

g_camera.SetPosition(MTVector3D(x, 

g_land->GetAltitude(x,z) + CAMHEIGHT,z)); 

} 

// Rendern (Zeichnen der Grafik) 

if(g_rendermanager->Render()) 

MessageBox("rendering error", "error", 0); 

} 

CDialog::OnOK(); 

/////////////////////////////////////////////////////////////////////////// 

//////// 

// Diese Methode wird bei Drücken des "Durchsuchen"-Buttons aufgerufen. 

// Sie zeigt einen Datei öffnen Dialog an, in dem man die Heightmap wählen 

kann. 

void CTestappDlg::OnButton1() 

{ 

OPENFILENAME openfile; 

char filename[1024] = ""; 

} 

memset(&openfile, 0, sizeof(OPENFILENAME)); 

openfile.lStructSize = sizeof(OPENFILENAME); 

openfile.lpstrFilter = "24-Bit Bitmap (*.BMP)\0*.BMP\0"; 

openfile.nFilterIndex = 1; 

openfile.lpstrFile = filename; 

openfile.nMaxFile = 1023; 

openfile.lpstrTitle = "Heightmap laden"; 

if(GetOpenFileName(&openfile)) 

{ m_heightfileedit.SetSel(0, m_heightfileedit.GetLimitText()); 

m_heightfileedit.ReplaceSel(openfile.lpstrFile); 

} 

- 78 -





9. Schlussbemerkung 

Ja, hier ist es nun, unser fertig dokumentiertes Projekt. Es kostete Geld, viel Zeit und Mühe 

und nicht zuletzt auch noch Nerven (diese Dokumentation wurde 2 Stunden vor dem 

Abgabetermin gedruckt und gebunden). 

Auf dem langen und beschwerlichen Weg von einer Projektidee bis zur Verwirklichung 

vergingen viele, viele Stunden vor Kopfschmerzen bereitendem Quellcode und vor den nicht 

immer korrekt konfigurierten Rechnern der EST, die es uns des Öfteren nicht gerade leicht 

machten. 

Doch zuletzt bleibt nur zu sagen, dass wir beide selbst erstaunt waren, wie viele Probleme wir 

im Stande waren, selbst anzugehen und zu lösen. Wir hatten definitiv viel Spaß und Freude an 

der Entwicklung dieses Vorhabens und wir sind uns sicher, dass dies auch nicht unser letztes 

Projekt in dieser Fachrichtung sein wird. 

Ganz besonderer Dank geht an dieser Stelle an Herrn Hambsch und Herrn Czok, unsere 

beiden Betreuer, welche uns bei Problemen wie „Darf man in einem Vorwort emotional 

werden?“ tatkräftig zur Seite standen; und natürlich auch bei echten Problemen. 

Kontakt mit den Erschaffern dieses Projektes erhalten Sie unter: 

Alexander Fuchs 

grunzgrunz@web.de 

David Zaadstra 

mythomania@gmx.de 

- 79 -





10. Anhang 

10.1 Literaturverweise 

[1] Additional Class Notes on Triangle Rasterization, 2000 

http://cs-people.bu.edu/jisidoro/cs480/additional/trirast5.doc 

[2] Tomas Möller und Eric Haines, Realtime Rendering, S. 23 ff, 1999, 

ISBN: 1-56881-101-2 

[3] Oliver Vornberger und Olaf Müller, 3D-Transformationen, Juli 2000 

h t t p : / / w w w -l e h r e . i n f o r m a t i k . u n i - 

o s n a b r u e c k . d e / ~ c g / 2 0 0 0 / s k r i p t / 1 3 _ 3 D _ T r a n s f o r m a t i o n e n . h t m l 

[4] Tomas Möller und Eric Haines, Realtime Rendering, ISBN: 1-56881-101-2 

[5] Mark Segal und Kurt Akeley, The OpenGL Graphics System: A Specification 

(Version 1.3), 2001 

h t t p : / / w w w . o p e n g l . o r g / d e v e l o p e r s / d o c u m e n t a t i o n / v e r s i o n 1 _ 3 / g l s p e c 1 3 . p d f 

[6] Appeal, Outcast 

h t t p : / / w w w . o u t c a s t -g a m e . c o m / g e r m a n / h t m l / i n d e x . h t m 

[7] The good old days – Comanche 

h t t p : / / w w w . g o o d d a y s . o r g / c o m a n c h e s c r e e n s 3 . s h t m l 

[8] Pat Hanrahan und G. Scott Owen, Hermite Splines, 1998-99 

h t t p : / / w w w . s i g g r a p h . o r g / e d u c a t i o n / m a t e r i a l s / H y p e r G r a p h / m o d e l i n g / s p l i n e s / h 

e r m i t e . h t m 

- 80 -

IR-Empfänger für Fernbedienungen 

IR-Receiver for Remote Control Systems 

SFH 5110 

SFH 5111 

Beschreibung 

SFH 5110 und SFH 5111 sind Infrarot-Empfänger 

für die Erkennung von Signalen aus Infrarot-Fernbedienungssystemen 

und bestehen aus Fotodiode, 

Vorverstärker, automatischer Verstärkungsregelung, 

Bandpaß-Filter und Demodulator. Das 

schwarz eingefärbte Gehäuse dient zur Unterdrückung 

des Tageslichteinflusses. 

Wesentliche Merkmale 

• IC mit monolithisch integrierter Fotodiode 

(Ein-Chip Lösung) 

• Speziell geeignet für Anwendungen von 

940 nm 

• Hohe Empfindlichkeit 

• Variable Bandpaß-Filterfrequenz 

• TTL und CMOS kompatibel 

• Ausgang: aktiv „Low“ 

• Keine externe Beschaltung nötig 

Anwendungen 

• Empfänger in Fernbedienungen für TV, 

Videorekorder, HiFi, Satellitenempfänger und 

CD-Spieler 

• Optischer Schalter 

Description 

SFH 5110 and SFH 5111 are IR receivers to detect 

light from infrared remote control systems. 

The IC includes photodiode, preamplifier, automatic 

gain control, bandpass and demodulator. 

The black-colored package is designed as daylight-cutoff 

filter. 

Features 

• IC with monolithic integrated photodiode (single 

chip solution) 

• Especially suitable for applications of 940 nm 

• High sensitivity 

• Various bandpass filter frequency 

• TTL and CMOS compatibility 

• Output: active Low 

• No external components necessary 

Applications 

• Remote control module for TV sets, VCRs, hi-fi 

audio receivers, SAT receivers and compact 

disk players 

• Optical Switch 

2001-02-22 1

SFH 5110, SFH 5111 

Typ 

Trägerfrequ. 

Bestellnr. 

Typ 

Trägerfrequ. 

Bestellnr. 

Type 

Carrier 

Frequency 

kHz 

Ordering Code 

Type 

Carrier 

Frequency 

kHz 

Ordering Code 

SFH 5110-30 30 Q62702-P5088 SFH 5111-30 30 Q62702-P5257 

SFH 5110-33 33 Q62702-P5089 SFH 5111-33 33 Q62702-P5258 

SFH 5110-36 36 Q62702-P5090 SFH 5111-36 36 Q62702-P5259 

SFH 5110-38 38 Q62702-P5091 SFH 5111-38 38 Q62702-P5260 

SFH 5110-40 40 Q62702-P5092 SFH 5111-40 40 Q62702-P5261 

Grenzwerte (T A = 25 °C) 

Maximum Ratings 

Bezeichnung 

Parameter 

Betriebs- und Lagertemperatur 

Operation and storage temperature range 

Betriebsspannung 

Supply voltage 

Betriebsstrom 

Supply current 

Ausgangsspannung 

Output voltage 

Ausgangsstrom 

Output current 

Verlustleistung 

Total power dissipation, T A ≤ 85 °C 

Symbol 

Symbol 

Wert 

Value 

T op 

T stg 

– 10 … + 75 

– 30 … + 100 

V CC 6.3 V 

Einheit 

Unit 

°C 

I CC 5 mA 

V OUT 

6.3 V 

I OUT 3 mA 

P tot 50 mW 

Empfohlener Arbeitsbereich 

Recommended Operating Conditions 

Bezeichnung 

Parameter 

Betriebstemperatur 

Operating temperature 

Betriebsspannung 

Supply Voltage 

Symbol 

Symbol 

Wert 

Value 

min. typ. max. 

T op – 10 – 75 °C 

V cc 4.5 5.0 5.5 V 

Einheit 

Unit 

2001-02-22 2

SFH 5110, SFH 5111 

Kennwerte (T A = 25 °C) 

Characteristics 

Bezeichnung 

Parameter 

Stromaufnahme, V CC = 5 V, E = 0 

Current consumption 

Wellenlänge der max. Fotoempfindlichkeit 

Wavelength of max. sensitivity 

Spektraler Bereich der Fotoempfindlichkeit 

Spectral range of sensitivity 

Ausgangsspannung 

Output voltage 

Output “High” - (I q = 10 µA) 

Output “Low” - (I q = 500 µA) 

Trägerfrequenz 

Carrier frequency 

Min. Bestrahlungsstärke (Testsignal, s. Fig. 3) 

Min. Threshold irradiance (test signal, see Fig. 3) 

f = f 0 , t p,I = 600 µs 

Min. Eingangspulsbreite „ON“ 

(Testsignal, s. Fig. 3) 1) 

Min. Input pulse width “ON” 

(test signal, see Fig. 3) 1) 

Ausgangspulsbreite „ON“ 

(Testsignal, s. Fig. 3) 

Output pulse width “ON” (test signal, see Fig. 3, 

E e = 1 mW/m 2 ) 

50%-Filterbandbreite, f = f O , E V = 0, V CC = 5 V 

50%-Filter bandwidth 

Symbol 

Symbol 

Wert 

Value 

min. typ. max. 

I CC – 1.3 – mA 

λ s max – 940 – nm 

λ 830 – 1100 nm 

V OUT high V S – 0.5 

V OUT low – 

– 

– 

f 0 – 30 

33 

36 

38 

40 

– 

0.5 

Einheit 

Unit 

V 

– kHz 

E e min – 0.35 0.5 mW/m 2 

t p,I 6/f O – – µs 

t p,O 

t p,I – t p,I µs 

– 6/f O + 6/f O 

∆f 50% 3 – 6 kHz 

1) 

1) 

Die volle Empfindlichkeit wird bei einer Burstlänge von mindestens 6 Pulsen erreicht. Die Reichweite bei 

Verwendung eines typischen Senders (SFH 4510/SFH 4515, I F = 500 mA) beträgt etwa 30 m. 

A minimum burst length of 6 pulses is necessary for full sensitivity. The transmission distance with a typical 

transmitter (SFH 4510/SFH 4515, I F = 500 mA) is about 30 m. 

2001-02-22 3

_< 

SFH 5110, SFH 5111 

Input 

Control 

Circuit 

23 kΩ 

V CC 

PIN 

AGC 

Bandpass 

Demodulator 

OUT 

GND 

OHF00404 

Figure 1 

Blockschaltbild 

Block Diagram 

SFH 5110-xx 

SFH 5111-xx 

3 

*) 

4.7 µF 

*) 

10 k Ω 

optional 

+5 V 

1 

µC 

2 

*) only necessary to suppress power supply disturbances 

GND 

OHF00430 

Figure 2 

Externe Beschaltung 

External Circuit 

2001-02-22 4

SFH 5110, SFH 5111 

t p, I t off, I t p, I 

Transmitter 

t 

= t p, o 

t 

± 6 / f o 

p, I 

Detector 

(Output Signal) 

t 

Burst wave: carrier frequency f o , Duty cycle = 0.5 

OHF00399 

Figure 3 

Optisches Testsignal 

Optical Test Signal 

2001-02-22 5

SFH 5110, SFH 5111 

Relative Luminous Sensitivity 

S rel = f (λ) 

100 

% 

90 

OHF00400 

Vertical Directivity ϕ y 

1 

0.9 

OHF00401 

Horizontal Directivity ϕ x 

OHF00402 

1 

0.9 

80 

0.8 

0.8 

70 

/E e 

0.7 

/E e 

0.7 

S rel 

10 

60 

E e, min 

0.6 

E e, min 

0.6 

50 

0.5 

0.5 

40 

0.4 

0.4 

30 

0.3 

0.3 

20 

0.2 

0.2 

0.1 

0.1 

0 

700 800 900 1000 nm 1100 

λ 

Relative Sensitivity E e /E e, min = f (f 0 ) 

OHF00403 

5 

0 

0 

30 60 [ ] 90 

ϕ 

0 

0 

30 60 [ ] 90 

ϕ 

4.5 

4 

E e /E e, min 

3.5 

3 

2.5 

2 

1.5 

1 

f o -4 fo-2 

f o fo+2 

kHz f o +4 

Center Frequency 

2001-02-22 6

SFH 5110, SFH 5111 

Maßzeichnung 

Package Outlines 

2.54 (0.100) 

0.6 (0.024) 

0.4 (0.016) 

2.54 (0.100) 

1 

2 

3 

24.4 (0.961) 

23.4 (0.921) 

32.0 (1.260) 

6.1 (0.240) 

5.9 (0.232) 

1.3 (0.051) 

1.1 (0.043) 

3.0 (0.118) 

2.8 (0.110) 

6.1 (0.240) 

5.9 (0.232) 

0.5 (0.020) 

0.3 (0.012) 

3.5 (0.138) 

3.3 (0.130) 

30.0 (1.181) 

5.1 (0.201) 

4.9 (0.193) 

Pinning SFH 5110 

1 OUT 

2 GND 

3 

V CC 

Pinning SFH 5111 

1 OUT 

2 V CC 

3 GND 

GEOY6985 

Maße werden wie folgt angegeben: mm (inch) / Dimensions are specified as follows: mm (inch). 

2001-02-22 7

SFH 5110, SFH 5111 

Published by OSRAM Opto Semiconductors GmbH & Co. OHG 

Wernerwerkstrasse 2, D-93049 Regensburg 

© All Rights Reserved. 

Attention please! 

The information describes the type of component and shall not be considered as assured characteristics. 

Terms of delivery and rights to change design reserved. Due to technical requirements components may contain 

dangerous substances. For information on the types in question please contact our Sales Organization. 

Packing 

Please use the recycling operators known to you. We can also help you – get in touch with your nearest sales office. 

By agreement we will take packing material back, if it is sorted. You must bear the costs of transport. For packing 

material that is returned to us unsorted or which we are not obliged to accept, we shall have to invoice you for any costs 

incurred. 

Components used in life-support devices or systems must be expressly authorized for such purpose! Critical 

components 1 , may only be used in life-support devices or systems 2 with the express written approval of OSRAM OS. 

1 A critical component is a component usedin a life-support device or system whose failure can reasonably be expected 

to cause the failure of that life-support device or system, or to affect its safety or effectiveness of that device or system. 

2 Life support devices or systems are intended (a) to be implanted in the human body, or (b) to support and/or maintain 

and sustain human life. If they fail, it is reasonable to assume that the health of the user may be endangered. 

2001-02-22 8

est Bewegung durch eine 3D-Landschaft mit ... - David Zaadstra

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?