Entwicklung eines MMI und Host-PC-Interface

Transkript

1 Entwicklung eines MMI und Host-PC-Interface für einen HF/ZF-Transceiver Diplomarbeit von Martin Schönfeld an der Fachhochschule Konstanz, Fachbereich Nachrichten- und Informationstechnik Betreuung: Herr Prof. Dr. R. Reiß.

2 2 Inhalt 1 Inhalt 1.1 Kapitelübersicht 1 INHALT Kapitelübersicht Verzeichnis der Abbildungen Verzeichnis der Tabellen EINLEITUNG Gesamtkonzept Aufgabenstellung Funktionsanforderungen Spannungsversorgung Mikrokontroller als zentrale Steuereinheit DMA-Kontroller für Baseband-Audio Vorgaben für die Leiterplatte Schnittstellendefinitionen Host-PC-Schnittstellen Man Maschine Interface Andere Schnittstellen Vorgehensweise und Durchführung Arbeitsablauf und Zeitplan Schaltungsentwicklung Platinenentwurf / Layout Firmware- / Softwareentwicklung Mikrokontroller-Firmware FPGA-Firmware Hardwareaufbau und -test Dokumentation HARDWARE Hardwareumgebung und Hardwarekonzept... 18

3 Kapitelübersicht Schaltungsbeschreibung Spannungsversorgung Taktversorgung des Moduls Beschaltung des Mikrokontrollers Grundbeschaltung Serielle Schnittstellen In-System-Programmierung Quadratur Decoder Netzwerk-Kontroller Beschaltung des FPGA Beschaltung des Display-Kontrollers Platinen-Layout Revision A Revision B Hardware-Aufbau und -Test Widerstände, Kondensatoren und Induktivitäten Spannungsregler Reset-Schaltung und Serielle Schnittstelle A Oszillatoren Mikrokontroller, SRAM und Flash Quadraturdecoder / Inkrementale Drehgeber Ethernet-Controller USB-Kontroller SPDIF FPGA, Flash und JTAG-Programmierport SRAM, Display-Kontroller, Erzeugung der Display- Kontrastspannung SOFTWARE Mikrokontroller-Firmware Hauptprogramm Taktversorgung Serielle Schnittstellen Ethernet-Schnittstelle NetBIOS...36 Entwicklung eines MMI und Host-PC-Interface

4 4 Inhalt Telnet Command Parser Slaveport Quadratur-Decoder Display-Kontrastspannung FPGA-Firmware Masterport Timing-Generator Control-Logic Kommando-Bus Kommando-Struktur FPGA-interne Geräte (Destination Devices) und deren Register Bus-Arbitrierung Datenübertragung SRAM-/Display-Controller-Port Timing-Generator Control-Logic FPGA-Testsoftware Windows-Software MÖGLICHKEITEN DER WEITERENTWICKLUNG LITERATURVERZEICHNIS SOFTWARE-QUELLCODE Mikrokontroller-Firmware Hauptprogramm Taktgenerator-Treiber Slave-Port-Treiber Echtzeit-Uhr-Funktionsbibliothek Treiber für die serielle Schnittstelle A Netzwerk-Treiber Telnet-Funktionsbibliothek NetBIOS-Funktionsbibliothek Netzwerk-Konfiguration Kommando-Parser...68

5 Verzeichnis der Abbildungen Treiber für den LCD-Kontrastspannungs-DAC FPGA-Firmware Haupt-Entity der FPGA-Testsoftware Digital Clock Managers Display/SRAM-Port Control Logic Display/SRAM-Port Timing Generator Masterport Control Logic Masterport Timing Generator DIAGRAMME UND SCHEMATA Verzeichnis der Abbildungen Abbildung 1 Abbildung 2 Herstellungsfehler auf der Leiterplatte: verschobene innere Massefläche...14 Bottomlayer der fertig bestückten Platine...16 Abbildung 3 Toplayer der fertig bestückten Platine...16 Abbildung 4 Zentrale ICs der Schaltung auf der fertigen Platine...19 Abbildung 5 Konfiguration des Taktgenerator-PLL-ICs CY Abbildung 6 Abbildung 7 Abbildung 8 Abbildung 9 Abbildung 10 Abbildung 11 Schema der Zusatzplatine zur Unterbringung aller Stecker bei 19 -Rack-Einbau...27 Revision A - Top Layer der Command Unit...27 Revision A - Bottom Layer der Command Unit...28 Revision A - Ground- und Split-Power-Plane der Command Unit...28 Revision B - Layout des Command Unit Connector Boards28 Revision B - Top Layer der Command Unit...29 Abbildung 12 Revision B - Bottom Layer der Command Unit...29 Abbildung 13 Abbildung 14 Revision B - Ground- und Split-Power-Plane der Command Unit...30 Revision C - Layout des Command Unit Connector Boards30 Abbildung 15 Gegenseitige Abhängigkeiten der Mikrokontroller- Software-Module...34 Abbildung 16 Hardwareumgebung der Command Unit, Gesamtkonzept 95 Abbildung 17 Schema der "Command Unit" mit MMI und Host PC Interface Rev. B...96 Entwicklung eines MMI und Host-PC-Interface

6 6 Inhalt Abbildung 18 Abbildung 19 FPGA-Test-Firmware - Datenflussdiagramm...97 FPGA-Firmware - Datenflussdiagramm Verzeichnis der Tabellen Tabelle 1 Arbeitsplan: Aufgaben (Tasks) mit Zeitplan...12 Tabelle 2 Strombedarf des Moduls bei den vier internen Spannungen19 Tabelle 3 Erforderliche Taktfrequenzen und deren Einsatzort...20 Tabelle 4 SRAM- und Flash-Konfiguration...32 Tabelle 5 FPGA-interne Kommando-Struktur auf dem Kommando- Bus...39 Tabelle 6 FPGA-interne Geräte und deren Geräte-Nummern...40 Tabelle 7 Geräteinterne Register und deren Bedeutung/Funktion...41

7 Gesamtkonzept 7 2 Einleitung Dieses Kapitel gibt einen Überblick über die Thematik des Projekts und die genaue Aufgabenstellung dieser Arbeit. Im letzten Abschnitt wird die Vorgehensweise und die Durchführung der Arbeit näher erläutert. 2.1 Gesamtkonzept Das Projekt beinhaltet die Entwicklung eines modularen Sende-Empfängers (Transceivers, kurz TRX) bestehend aus Hard- und Software. Der Transceiver stellt eine Experimental-Plattform dar, mit der nicht nur die üblichen Funktionen eines Sende-Empfängers genutzt werden können. Es bestehen vielfältige Experimentier- und Entwicklungsmöglichkeiten in den Bereichen der digitalen Signalverarbeitung, der Softwareentwicklung für Mikrokontroller und Personal Computer (Treiber für Remote Control u.ä.) sowie der Übertragungstechnik. Der TRX besteht aus möglichst vielseitig nutzbaren Modulen, sodass er modulweise der technischen Entwicklung angepasst werden kann: Ein Empfängermodul arbeitet nach dem Prinzip des Software Radio bzw. genauer Software Defined Radio, d.h. alle Empfangsparameter (Filterung, Demodulation,...) werden durch Software festgelegt. Dazu wird das hochfrequente Original- bzw. Zwischenfrequenzsignal mit einem schnellen Analog/Digital-Wandler (ADC) digitalisiert. Ein sogenannter Receive Signal Processor (RSP) implementiert alle Funktionen eines Direktmischempfängers auf digitaler Ebene. Er mischt mehrere Kanäle aus dem breitbandigen Quellsignal in das Basisband und sorgt für die Dezimierung und Filterung. Für die Signal-Konditionierung (Pegelanpassung und Vorfilterung) vor dem Empfängermodul sorgen analoge Front-Ends, die zur Erweiterung des Eingangsfrequenzbereichs auch analoge Mischstufen beinhalten können. Das Sendemodul setzt das (die) Basisband-Sendesignal(e) in der digitalen Ebene auf eine höhere Frequenz um, wandelt das Summensignal in ein analoges Signal (DAC) und verstärkt es soweit, dass eine Endstufe oder ein Sendemischer nachgeschaltet werden kann. Endstufen- und Transverter-Module verstärken die Sendesignale und mischen sie ggf. zur Erweiterung des Ausgangsfrequenzbereichs. Entwicklung eines MMI und Host-PC-Interface

8 8 Einleitung Ein DSP-Modul übernimmt die weitere Verarbeitung der Basisbanddaten, wie Filterung, Demodulation usw. Die gesamte Steuerung des TRX sowie die Weiterleitung der Basisbanddaten an die verarbeitenden Module übernimmt die sogenannte Command Unit, welche im Rahmen dieser Arbeit entwickelt wurde. Sie beinhaltet die logischen Blöcke MMI (Man Maschine Interface, d.h. die Schnittstelle von Mensch zur Maschine) und Host PC Interface, welches verschiedenste Standardschnittstellen zu einem Personal Computer zur Verfügung stellt (siehe Abschnitt 2.2.2). Ein Frontpanel umfasst alle Bedienelemente für den Standalone- Betrieb des TRX. Dazu gehören insbesondere ein Display, Drehgeber und eine Tastatur. Insbesondere die Command Unit ist ein vielseitig einsetzbares Modul, dessen Einsatz keinesfalls auf dieses Projekt beschränkt ist. 2.2 Aufgabenstellung Im Rahmen dieser Arbeit wurde das in Abschnitt 2.1 erwähnte Modul Command Unit entwickelt. Die genauen Anforderungen an die Funktion und die Schnittstellen (Pflichtenheft) sind in den folgenden Unterabschnitten definiert Funktionsanforderungen Spannungsversorgung Alle modulinternen Spannungen sollen von einer einzigen positiven Versorgungsspannung im Bereich zwischen 7V und 15V abgeleitet werden Mikrokontroller als zentrale Steuereinheit Die zentrale Steuerung des gesamten MMI und Host PC Interfaces übernimmt ein In-System-Programmierbarer (ISP) Mikrokontroller. Er übernimmt insbesondere auch die Ansteuerung der MMI-Elemente wie Display und Tastatur bzw. Drehgeber, bereitet die Parameter der Empfänger- und Sendemodule grafisch auf und steuert diese Module DMA-Kontroller für Baseband-Audio Die Basisband-Signale sollen über einen eigenen DMA-Kontroller an die entsprechenden Schnittstellen weitergeleitet werden. Durch den Einsatz eines DMA-Kontrollers wird der Mikrokontroller nicht unnötig belastet und kann jederzeit auf Benutzereingaben reagieren Vorgaben für die Leiterplatte Die gesamte Schaltung soll auf einer Europakarte (Leiterplatte mit den Abmessungen mm) untergebracht werden. Alle Steckverbinder für den Anschluss von Projekt-externen Geräten (z.b. Host-PC) müssen an einer kurzen Seite des PCB (Printed Circuit Board) untergeracht werden, sodass die Platine zusammen mit anderen Modulen des Gesamt-Projekts in einem 19 -

9 Aufgabenstellung 9 Einschub-Gehäuse untergebracht werden kann. An den langen Seiten des PCB müssen für die entsprechenden Führungsschienen mindestens 2mm unbenutzte Leiterplatte vorhanden sein. Ferner dürfen keine Steckverbinder in Richtung der langen Platinen-Seiten ausgerichtet sein Schnittstellendefinitionen Host-PC-Schnittstellen Folgende Standard-Schnittstellen zum Anschluss eines Host-PCs sollen zur Verfügung stehen: Serielle Schnittstelle RS232C mit den üblichen Baudraten bis mindestens kbd. Serielle Schnittstelle nach IrDA-Standard 1.2 ( bis kbd), wobei der Optische IrDA-Transceiver nicht auf der Command-Unit sondern auf dem Front-Panel sitzt. Ethernet-Schnittstelle nach IEEE BaseTX und 10BaseT USB 1.1 und/oder USB 2.0 Fullspeed-Schnittstelle (12MBit/s) mit Connector Typ B für Hot-Plugging Digital Audio-Schnittstellen (Ein- und Ausgänge) nach IEC958 (auch bekannt als S/PDIF), optisch mit TOSLINK-Anschluss und elektrisch mit RCA-Steckverbinder (Chinch-Buchse) Man Maschine Interface Das Man Maschine Interface (MMI) sorgt für die Kommunikation zwischen Mensch und Maschine, indem es Schnittstellen für Ein- und Ausgabegeräte zur Verfügung stellt. Folgende Schnittstellen sollen hierfür zur Verfügung stehen: PS/2-Tastatur-Schnittstelle zum Anschluss einer handelsüblichen PC-Tastatur LC-Display-Schnittstelle (schwarz/weiss, Graustufen, Farbe), für passive und aktive Displays S-Video- und Composite-Video-Ausgang (4Pol Mini-DIN und RCA) zur Ansteuerung eines Fernseh-Gerätes Analoger Monitor-Anschluss (15Pol High Density D-SUB) zur Ansteuerung eines Farb-PC-Monitors mit einer Auflösung von mindestens 800x600 Pixel (SVGA) mit 16 oder mehr Farben Zwei Anschlüsse für Inkremental-Drehgeber mit jeweils zwei um 90 versetzten Puls-Ausgängen mit wahlweise TTL- oder LVCMOS-Pegel (+5V oder +3.3V für HIGH-Pegel, 0V für LOW- Pegel) Zwei Taster zum Zurücksetzen des Mikrokontrollers in den Normalmodus bzw. in den Programmiermodus zur In-System- Programmierung (ISP) Entwicklung eines MMI und Host-PC-Interface

10 10 Einleitung Andere Schnittstellen Zur Steuerung von anderen Modulen des Zielsystems sollen außerdem folgende Signale und Schnittstellen über geeignete Pin-Header verfügbar gemacht werden: Spannungsversorgung über einen 2-Pin-Header 8Bit-Address/Daten-Bus zum Anschluss der Empfänger- und Sender-Module und möglicher weiterer Module Eingang für den synchronen Systemtakt der Sende- und Empfangsmodule (SMB-Verbinder, männlich) Linkport zum Anschluss eines DSP-Moduls, kompatibel zum Linkport des SHARC Fliesskomma-DSPs ADSP21160M der Firma Analog Devices Inc. (siehe [1]). IIC-Schnittstelle (siehe [2]) zur Steuerung verschiedenster Module, z.b. Vorselektion und Vorverstärker SPI-Schnittstelle mit Chip-Select-Signalen zur schnellen Ansteuerung anderer Module und Bausteine (z.b. EEPROM) Reset-Eingang zum Zurücksetzen des Mikrokontrollers im Normalund Programmiermodus mit Hilfe von Open-Drain-Active-Low- Treibern. Ggf. unbenutzte serielle Schnittstellen des Mikrokontrollers JTAG-Port zur In-System-Programmierung des FPGA- Configuration-PROM und zum Debuggen der FPGA-Firmware (DMA-Kontroller) 2.3 Vorgehensweise und Durchführung In den folgenden Abschnitten werden die Systematik des Arbeitsablaufs sowie die bei der Durchführung der einzelnen Schritte aufgetretenen Probleme und deren Lösungen aufgezeigt Arbeitsablauf und Zeitplan Die meisten Schritte bei der Durchführung dieser Arbeit waren vom Abschluss anderer Schritte abhängig, sodass die Reihenfolge der Schritte gegeben ist. Um die Arbeit möglichst zielgerichtet durchführen zu können wurde der folgende Arbeitsplan erstellt: Task-Name Project Plan Hardware Concept Hardware Preparations Setup Hardware Development Environment Dauer 2 Tage 5 Tage 5 Std.

11 Vorgehensweise und Durchführung 11 Hardware Development Schematic Entry MCU incl. SRAM, Flash and POR/Backup ISP-Circuitry and RS232-Interface Ethernet-Controller Incremental Encoders and Serial Ports FPGA Spartan 3 FPGA Configuration Memory with JTAG TAP Display Controller DSP Link Port USB Controller incl. EEPROM Generic AD-Port for RX/TX modules Keyboard PS/2 Port SPDIF Output SPDIF Input FPGA FIFO and Userdata SRAM Clocking Circuit Power Supply Nonvolatile Memory for the Rabbit3000 MCU Schematic Review Visible Errors Check Logic Check Electrical Roule Check (ERC) Schematic Documentation Layout PCB Specify Footprints in Schematic Generate Netlist Place Components Layout Power Supply Layout USB Circuitry Layout Ethernet-Controller Layout Display-Controller Layout MCU Layout Connectors attached to FPGA Layout Component-Group connections Layout Review Layout Documentation PCB assembly Hardware Testing Hardware Testing Documention Administration Bill of Materials BOM Order or Request BOM Components Manufacture PCB Sofware Concept 3 Tage 1 Tag 12 Std. 4 Std. 3 Tage 3 Std. 12 Std. 1 Std. 4 Std. 1 Std. 30 mins 5 Std. 5 Std. 6 Std. 1 Tag 1 Tag 2 Tage 6 Std. 1 Tag 1 Tag 4 Tage 2 Tage 5 Std. 3 Tage 1 Tag 6 Std. 2 Tage 2 Tage 1 Tag 1 Tag 3 Tage 2 Tage 3 Tage 5 Tage 5 Tage 3 Tage 1 Tag 10,45 Tage 15 Tage 5 Tage Entwicklung eines MMI und Host-PC-Interface

12 12 Einleitung Software Preperations Setup Software Development Environment Software Development Firmware Development MCU Firmware Test MCU In System Programmability Get MCU OS running PLL-Circuitry driver Serial Port A driver Command Parser module Real Time Clock function library LCD Contrast DAC funtion library Ethernet driver with configuration file NetBIOS driver Telnet driver Slave port driver Firmware debugging Firmware Documentation FPGA Firmware main entity with pin association Master Port logic Display/SRAM Logic FPGA Firmware debugging Firmware Documentation Write/Finish Documentation Tabelle 1 Arbeitsplan: Aufgaben (Tasks) mit Zeitplan 1 Tag 5 Std. 3 Std. 4 Std. 1 Tag 2 Tage 4 Std. 2 Std. 1 Tag 2 Tage 2 Tage 3 Tage 7 Tage 3 Tage 2 Tage 3 Tage 3 Tage 7 Tage 3 Tage 20 Tage Die Reihenfolge der Tasks in Tabelle 1 gibt auch weitgehend den zeitlichen Ablauf der Projektdurchführung wieder. Ausnahmen sind die Aufgaben der Gruppe Administration. Die Stückliste der benötigten Komponenten (BOM, bill of materials ) kann nach Abschluss der Schaltungsentwicklung erstellt werden. Liegt der BOM vor, so können die Komponenten natürlich schon bestellt werden. Demgegenüber kann die Herstellung der Platine natürlich erst nach dem Abschluss der Layout-Arbeiten erfolgen. Eine weitere Ausnahme stellte der Test der Hardware dar, welcher erst nach Vorliegen der Firmware möglich war. Mit diesem Zeitplan war noch etwas Zeit-Reserve zu erwarten. Bis zum Abschluss des Layout-Reviews konnte der Zeitplan mit etwa ±1Tag eingehalten werden. Auf Grund der in den folgenden Abschnitten erläuterten Probleme traten dann Verzögerungen auf, so dass der Zeitplan nicht mehr eingehalten werden konnte Schaltungsentwicklung Um die Lieferzeit der benötigten Bauteile so klein wie möglich zu halten, wurde bereits beim Schaltungsentwurf darauf geachtet, möglichst nur gut verfügbare Bauteile zu verwenden. Aus Kostengründen sollten ausserdem für

13 Vorgehensweise und Durchführung 13 die Prototypen möglichst kostenlose Muster zur Verfügung stehen. Dies bieten glücklicherweise viele Chip-Hersteller mittlerweile an (teilweise direkt per online-bestellung im Internet, teilweise bei Anfrage z.b. per ). Nicht immer konnten Standardbauteile verwendet werden: Insbesondere beim Ethernet-Stecker (RJ-45 mit integrierten Breitbandübertragern) musste aus Platzgründen eine reine SMD-Version gefunden werden, welche ausserdem auch die Link- und Activity-LEDs eingebaut haben sollte. Nur damit konnte der Netzwerkstecker ebenfalls platzsparend an der kurzen Leiterplattenseite untergebracht werden (USB-Stecker, ebenfalls reine SMD-Version auf der anderen Platinenseite), wie in Abschnitt 2.2 gefordert. Die Wahl viel bei den zentralen integrierten Bausteinen auf einen Rabbit3000 Mikrokontroller (siehe [3]) und einen Xilinx-FPGA der neusten Generation Spartan-3 (siehe [7]). Der Mikrokontroller R3000 bietet einen grossen Umfang an integrierter Peripherie, insbesondere gehören Quadraturdecoder und mehrere asynchrone Schnittstellen (durch geeignetes Setup auch IrDA-kompatibel) zum Funktionsumfang. Desweiteren ist für diesen Kontroller eine Software- Entwicklungsumgebung für eine Variante der Hochsprache C erhältlich, die sowohl kooperatives Multitasking unterstützt als auch den kompletten TCP/IP-Stack mit Netzwerkkartentreibern im Quellcode enthält. Diese Entwicklungsumgebung kannte ich bereits aus dem 2. Praxissemester (Einsatz des Mikrokontrollers Rabbit2000), sodass sich die Einarbeitung auf das Kennenlernen der neuen Funktionen und der Änderungen auf Grund des Versionswechsels beschränken konnte. Wie gefordert kann dieser Mikrokontroller im Zielsystem programmiert werden, und das mitgelieferte BIOS enthält ein kleines Monitorprogramm, mit dem der Mikrokontroller im System debugged werden kann (incl. Single-Stepping im C- und Assembler-Quellcode). Der FPGA XC3S50 war erste Wahl, da er ein gutes Preis/Leistungsverhältnis bietet und ausserdem einer der wenigen FPGA ist, der trotz grosser Anzahl an Logikzellen mit relativ geringer Pinzahl (unter 200) im TQFP-Gehäuse (Thin Quad Flat Pack) erhältlich ist. Die meisten ähnlich komplexen FPGA haben mehr als 200 Anschlüsse und sind meist nur im BGA-Gehäuse (Ball Grid Array) lieferbar, dessen Bestückung eine umfangreiche Ausrüstung erfordert. Ausserdem sollte für die Ableitung des SPDIF-Taktes vom zu den Empfangsmodulen synchronen Takt ein neues Feature des XC3S50 genutzt werden: die sogenannten DCM (Digital Clock Manager). Zu guter Letzt ist der XC3S50 pinkompatibel zu zwei weiteren Typen der Spartan-3-Familie, sodass eine Aufrüstung bei unverändertem Platinenlayout möglich ist Platinenentwurf / Layout Sehr zeitaufwändig war das geschickte Platzieren der Komponenten auf der Platine, da relativ viele Vorgaben zu erfüllen waren und der Platz auf der Eurokarte nicht gerade üppig war. Der Autorouter war nicht zu gebrauchen - er ging nach kurzer Zeit in eine Endlosschlaufe über, was sich auch durch das Umplatzieren der Bauteile, das Einfügen von Layoutdirektiven oder das teilweise manuelle Routen nicht verhindern liess. So wurde die Platine manuell geroutet. Nur wenige quasistatische Signale führen über drei oder vier Vias. Entwicklung eines MMI und Host-PC-Interface

14 14 Einleitung Ansonsten konnten mehrfache Durchkontaktierungen weitgehend vermieden oder reduziert (meist nur ein Via pro Net) werden. Leider schlich sich in der ersten Revision des Layouts ein Fehler im Footprint des FPGA ein, sodass die Platine teilweise neu geroutet werden musste. Ausserdem war die Qualität der Leiterplatte nicht sehr gut, sodass sich einzelne Pads insbesondere beim Footprint des Mikrokontrollers trotz kurzer Lötdauer bei niedrigstmöglicher Temperatur ablösten. Dies erschwerte die Arbeit deutlich. Die neue Leiterplatte der überarbeiteten Revision B war dann gar völlig unbrauchbar: Ein Kurzschluss zwischen den Signalen +3.3V und GND sorgte dafür, dass nur noch die +5V-Spannungsversorgung funktionierte. Ich versuchte, den Kurzschluss mit Hilfe der Impulsreflektrometrie zu orten, doch die Distanz zum nächsten Kurzschluss betrug an nahezu jeder Stelle der Platine nur wenige Millimeter bis maximal 2cm. Der Versuch, die Kurzschlussstelle durch einen grossen Stromfluss zu erwärmen und so zu lokalisieren, schlug ebenfalls fehl die Platine erwärmte sich erst bei Strömen jenseits von 10A an wenigen Stellen. Damit war klar: es handelte sich um einen sehr grossflächigen Kurzschluss. In starkem Gegenlicht zeigte sich der genaue Grund für den Fehler: die innere Massefläche war verschoben (siehe Abbildung 1). Dieser Fehler kostete leider viel Zeit nicht nur zum Suchen des Fehlers, sondern auch, weil eine neue Leiterplatte hergestellt werden musste. In der Zwischenzeit wurde an der Software weitergearbeitet. Die Garantieplatine war dann fehlerfrei, sodass mit dem Bestücken und Testen fortgefahren werden konnte. Abbildung 1 Herstellungsfehler auf der Leiterplatte: verschobene innere Massefläche Firmware- / Softwareentwicklung Mikrokontroller-Firmware Die Mikrokontroller-Software konnte relativ schnell fertiggestellt werden. Da die Garantie-Leiterplatte und damit das Zielsystem noch nicht verfügbar war, wurde die Software - soweit möglich - auf einem RCM2100-

15 Vorgehensweise und Durchführung 15 Mikrokontrollerboard (von Rabbit Semiconductors) auf Basis des Rabbit2000-Mikrokontrollers getestet (dieses stand mir noch von früheren privaten Projekten zur Verfügung). Die Fernsteuerung über die serielle Schnittstelle und über Telnet funktionierte einwandfrei und auch die NetBIOS-Funktion konnte verifiziert werden. Nur die Programmierung des PLL-Bausteins (siehe [14]) sowie die Funktion der Quadratur-Dekoder und des LCD-Spannungs- DACs konnten zu diesem Zeitpunkt noch nicht getestet werden. Nach dem Aufbau der Hardware zeigten sich Probleme mit der Treiberbibliothek für den Asix-Netzwerkchip (Bestandteil von [32]), sodass die Netzwerkfunktion noch nicht gegeben ist. Da dies jedoch nachweislich nicht an den von mir programmierten Bibliotheken/Treibern lag (Funktion auf RCM2100 getestet), wurde die Fehlersuche im Rahmen dieser Arbeit aus Zeitgründen abgebrochen FPGA-Firmware Zur Entwicklung der FPGA-Firmware wurde die von Xilinx kostenlos verfügbare Entwicklungsumgebung ISE WebPACK 6.1i (siehe [33]) verwendet. Diese beinhaltet auch ein Synthesetool, sodass die Firmware komplett als Verhaltensmodell in VHDL geschrieben werden konnte. Da ich vorher noch keinen Kontakt mit der Hardware-Beschreibungssprache VHDL hatte, war die Einarbeitung hier entsprechend aufwändiger als für die Mikrokontrollersoftware. Das Erlernen der Sprache VHDL erfolgte mit Hilfe des Buches [37] bereits parallel zum Platinenentwurf. Das Debuggen mit Hilfe des mit [33] mitgelieferten Simulators verlief weitgehend problemlos. Erst beim Testen der Hardware zeigte sich eine weitere kleine Hürde: Die Angabe des Herstellers der Entwicklungsumgebung Xilinx auf seiner Webseite, die Version 6.1i würde alle Bausteine der Spartan-3-FPGA- Familie unterstützen, trifft leider nicht zu. Nach weiteren Recherchen fand ich heraus, dass die von mir verwendeten Engineering Samples des Modells XC3S50J C ES nur in der Version 5.2SP3 unterstützt werden. Die FPGA- Software wurde daher im Rahmen dieser Arbeit nicht in der Hardware getestet Hardwareaufbau und -test Der Hardwareaufbau erfolgte stufenweise wie in Abschnitt 3.4 beschrieben. Jede Aufbaustufe wurde so weit wie möglich getestet, bevor die nächste Stufe in Angriff genommen wurde. Der Aufbau und die Tests erfolgten - abgesehen von einigen Verzögerungen wegen schlechter Lötpaste und ähnlichem reibungslos. Das Löten der vielbeinigen ICs war mit guter Lötpaste, einer feinen Pinzette und Heissluft relativ problemlos (unter Berücksichtigung der Beinfreiheit von etwa 0.2mm beim Mikrokontroller, Pitch = Beinchenabstand = 0.4mm). In einigen Details musste die Schaltung ergänzt oder verbessert werden. Diese Änderungen sind in Abbildung 17 daran zu erkennen, dass die hinzugefügten Bausteine einen Designator, d.h. eine Bezeichnung ohne Nummer ha- Entwicklung eines MMI und Host-PC-Interface

16 16 Einleitung ben (z.b. IC?). Diese Änderungen sollten in einer nächsten Revision berücksichtigt werden. FPGA und Display-Kontroller wurden auf Grund der in Abschnitt beschriebenen Umstände nur elektrisch, d.h. durch Messen der an den Pins anliegenden Signale getestet. Wegen der Treiberprobleme wurde auch der Netzwerkkontroller (siehe [6]) nur auf diese Weise getestet. Damit ist sichergestellt, dass die entworfene Schaltung korrekt/funktionsfähig ist, auch ohne die Softwareprobleme gelöst zu haben. Abbildung 2 und Abbildung 3 zeigen die fertig bestückte Platine mit aufgesetztem Connector-Board (siehe Abschnitt 3.3 und Abbildung 14). Abbildung 2 Bottomlayer der fertig bestückten Platine Abbildung 3 Toplayer der fertig bestückten Platine

17 Vorgehensweise und Durchführung Dokumentation Die Dokumentation in Form dieses Berichtes wurde so weit wie möglich parallel zur eigentlichen Arbeitsdurchführung erledigt, um alle wichtigen Punkte zu berücksichtigen. Mit etwas zeitlichem Abstand fällt außerdem die Ü- berarbeitung nach Beendigung der Entwicklungs- und Testarbeiten deutlich leichter. Auch bei der Dokumentation wurde wie bei der gesamten Arbeit die sog. Top-Down-Methode angewandt, d.h. es wurde zuerst eine Einteilung in logische Funktionsgruppen (beim Schaltungsentwurf) bzw. die Gliederung (der Dokumentation) vorgenommen und diese erst danach mit Inhalt gefüllt. Im Gegensatz dazu würden bei Anwendung der Bottom-Up-Methode zuerst die Details implementiert und diese danach zu einem Gesamtwerk (Schaltung oder Dokumentation,...) zusammengefügt. Entwicklung eines MMI und Host-PC-Interface

18 18 Hardware 3 Hardware Die folgenden Abschnitte beschreiben die Hardwarelösung des MMI und Host-PC-Interfaces im Detail. 3.1 Hardwareumgebung und Hardwarekonzept Ein Blockschaltbild des Gesamtsystems und damit die Hardwareumgebung der Command Unit ist in Abbildung 16 (Kapitel 8) zu sehen. Es spiegelt im wesentlichen die Schnittstellendefinitionen vom Abschnitt wider, wobei hier auch die Verbindungen mit den anderen Modulen des Zielsystems ersichtlich sind. 3.2 Schaltungsbeschreibung Die beiden zentralen Bausteine der Schaltung sind der Mikrokontroller des Typs Rabbit 3000 (siehe [1]) von Rabbit Semiconductor (siehe B6 bis C7, Abbildung 17) sowie der FPGA des Typs XC3S50 (bzw. dessen pinkompatible größere Brüder XC3S200 und XC3S400, siehe [4]) aus der Reihe der Spartan-3-FPGA der Firma Xilinx (siehe C9 bis D10, Abbildung 17). Abbildung 4 zeigt diese zusammen mit dem Flash-Speicher und dem Display-Kontroller auf der fertig bestückten Platine. Beim Mikrokontroller R3000 handelt es sich um ein sehr schnelles Z80- Derivat, das sich mit der Entwicklungsumgebung DynamicC (siehe [32]) des Herstellers relativ komfortabel in C programmieren lässt. Die Kommunikation des Mikrokontrollers und des DMA-Kontrollers (implementiert im Xilinx FPGA, siehe [7]) erfolgt über einen 8Bit breiten Parallel-Port, den sog. Slave-Port des Mikrokontrollers. Der Mikrokontroller kann auf diesen Port über drei interne Register zugreifen. Wird vom Master (FPGA) das Register 0 beschrieben, löst dies einen internen Interrupt im Mikrokontroller aus. Schreibt der Mikrokontroller seinerseits Daten in das Register 0, wird von der Slave-Port-Peripherie eine externe Interruptleitung (/SLAVEATTN) aktiviert, um dem Master mitzuteilen, dass neue Daten vorliegen. Dies erlaubt eine ereignisorientierte Kommunikation der beiden zentralen Einheiten MCU und FPGA. Findet kein Datenaustausch statt, kann somit der Mikrokontroller in einen stromsparenden Schlafmodus versetzt werden oder ohne Verlust von Rechenleistung durch Abfrageroutinen anderen Aufgaben wie der Netzwerkkommunikation und der Aufbereitung des Betriebszustands für dessen Anzeige nachkommen.

19 Schaltungsbeschreibung 19 Abbildung 4 Zentrale ICs der Schaltung auf der fertigen Platine Spannungsversorgung Die Schaltung benötigt vier geregelte Spannungen. Tabelle 2 zeigt den Strombedarf der Schaltung bei den verschiedenen internen Spannungen. Spannung Maximaler Strombedarf der Schaltung excl. der I/O-Ströme zum Treiben von externen Modulen +5V 87 ma +3.3V +2.5V +1.2V Tabelle ma 7 ma 10 ma Strombedarf des Moduls bei den vier internen Spannungen Der Forderung nach der Möglichkeit einer Spannungsversorgung mit nur einer positiven Spannung zwischen +7V und +15V wurde mit Hilfe von Low- Drop-Out Spannungsreglern nachgekommen. Die Speisespannung und die Ausgangsspannungen werden, wo erforderlich, mit Tantal-Kondensatoren gestützt bzw. gesiebt (diese sorgen ausserdem für die Stabilität der Regel- Entwicklung eines MMI und Host-PC-Interface

20 20 Hardware schleifen). +5V und +3.3V werden mit Hilfe der Spannungsregler LM (siehe [8]) und LM (siehe [11]) direkt aus der Versorgungsspannung gewonnen. Die niedrigeren Spannungen (+2.5V und +1.2V) werden jeweils aus der nächst höheren geregelten Spannung abgeleitet, um den Spannungsabfall an den LDO-Spannungsreglern (siehe [12] und [13]) möglichst gering zu halten (Minimierung der Verlustleistung). Dies ist hier ohne weiteres möglich, da der Strombedarf der Schaltung bei den Spannungen von 2.5V und 1.2V nur gering ist (siehe Tabelle 2). Eine stabile Spannungsregelung ist bereits ab einer Versorgungsspannung von 5.6V gewährleistet (siehe [10] und [11]); Bei höheren Spannungen wird jedoch prinzipbedingt die Verlustleistung in den LDO-Spannungsreglern relativ groß, sodass Kühlkörper erforderlich werden. Zu bevorzugen ist in solchen Fällen daher eine Lösung mit externen DC/DC-Wandlern, welche die Eingangsspannung mit hohem Wirkungsgrad auf 5.6V bringen Taktversorgung des Moduls Da auf dem Modul für das Host PC Interface viele Standard-Schnittstellen realisiert werden sollten, welche alle unterschiedliche, quarzgenaue Taktfrequenzen benötigen, wurde eine Möglichkeit gesucht, nicht für jeden Schnittstellenbaustein einen eigenen Quarz einsetzen zu müssen. Tabelle 3 zeigt die erforderlichen Taktfrequenzen des Moduls. Frequenz Einsatzort MHz Haupttakt für R3000 MCU (siehe [1]), Serielle Schnittstellen mit Standard-Baudraten bis 115.2kBaud MHz USB-Schnittstellenbaustein FT245BM (siehe [9]) MHz Ethernet-Schnittstellenbaustein AX88796 (siehe [6]) MHz Maximaler Bustakt für internen Bildspeicher des Display-Treibers S1D13806 (siehe [8]) MHz PAL-kompatibler Compositevideo- und S-Video- Ausgang des Display-Treibers S1D13806 (siehe [8]) Ca. 35 MHz bis 65 MHz MHz oder MHz LCD-Takt für Display-Treiber S1D13806 (siehe [8]) SPDIF-Schnittstelle, FPGA-intern abgeleitet vom synchronen Systemtakt 80 MHz Synchroner Systemtakt (extern eingespeist) Tabelle 3 Erforderliche Taktfrequenzen und deren Einsatzort

21 Schaltungsbeschreibung 21 Der zu den Sende- und Empfangsmodulen synchrone Systemtakt wird von einer externen Quelle über einen Koaxial-Eingang eingespeist. Er gelangt an den FPGA, der alle synchronen Aufgaben erledigt. Dank der sogenannten DCM des FPGA (Digital Clock Manager, siehe [4]) können die Taktfrequenzen für die SPDIF-Schnittstelle vom synchronen Systemtakt FPGA-intern abgeleitet werden. Alle anderen Frequenzen müssen on board erzeugt werden. Eine Takterzeugung auf Basis von PLLs bot sich an. Der Baustein CY22393 (siehe [14]) beinhaltet einen Quarz-Oszillator und drei PLLs, die sechs Ausgänge mit unabhängigen Teilern treiben können. Damit können alle erforderlichen Frequenzen von einem MHz-Quarz abgeleitet werden. Außerdem bietet diese Lösung die Möglichkeit, die Frequenzen während des Betriebs über die IIC-Schnittstelle des PLL-Bausteins zu ändern (z.b. LCD-Taktanpassung für eine andere Auflösung am externen Monitor). Abbildung 5 zeigt die mit Hilfe des kostenlosen Programms CyberClocks (siehe [35]) erstellte Konfiguration. Wie in Abbildung 5 zu sehen ist, treten beim MCU-Takt und beim PAL-TV-Takt systematische Fehler auf. Die systematischen Fehler liegen mit -5.6ppm deutlich unter der Genauigkeit des Quarzes und können daher vernachlässigt werden. Die PLL3 steht damit frei programmierbar zur Generierung des LCD-Takts zur Verfügung. Abbildung 5 Konfiguration des Taktgenerator-PLL-ICs CY22393 Das Programm erzeugt an Hand der eingegebenen Daten eine JEDEC- Konfigurations-Datei, deren Inhalt von Hand ausgelesen und in Form von Entwicklung eines MMI und Host-PC-Interface