Diplomarbeit Elektrotechnik

Diplomarbeit - Parallelprozessorsystem mit DSP56002

“Entwicklung eines Signalprozessorsystems mit zwei Prozessoren und integrierter Entwicklungsumgebung”

Eine Zusammenarbeit von
Marcus Bäckmann und Andreas Börcsök

Fachhochschule Darmstadt,
Fachbereich Elektrotechnik/Automatisierungstechnik,
Schwerpunkt Datentechnik.

Betreuer: Prof. Dr. Münter, Prof. Wycisk

Bearbeitungszeit: August 1995 bis Februar 1996

DSP 56002 Duoboard

Wer sich für den Volltext interessiert, kann diesen als Buch erwerben: "Ein Signalprozessorsystem mit zwei Prozessoren und integrierter Entwicklungsumgebung", Marcus Bäckmann & Andreas Börcsök, 140 S., Berlin, Logos-Verlag, 1997, ISBN 3-931216-44-6

Zum Inhaltsverzeichnis

Kurzreferat:

Im Rahmen dieser Arbeit wurde ein Entwicklungssystem für den Parallelbetrieb zweier digitaler Signalprozessoren DSP56002 von Motorola entwickelt. Das Entwicklungssystem wird mit Hilfe einer seriellen Schnittstelle mit einem PC verbunden. Die Software zur Programmentwicklung auf dem PC wurde unter dem Betriebssystem Windows implementiert.

Die Entwicklungsumgebung kommuniziert über die serielle Schnittstelle mit einem Mikrocontroller, der das eigentliche Monitorprogramm enthält. Die Verwendung des integrierten Hardwaredebuggers der Signalprozessoren ermöglichte ein Konzept, das ohne Leistungseinbußen hinsichtlich Geschwindigkeit und Speicherplatz auskommt.

Inhaltsverzeichnis:

Vorwort

Die Diplomarbeit wurde im Zeitraum Oktober 1995 bis Ende Februar 1996 an der Fachhochschule Darmstadt durchgeführt. Das gesamte Werk umfaßt nach Abschluß der Arbeit eine etwa 140 Seiten starke Ausarbeitung, einen Anhang im Umfang von etwa 600 Seiten, sowie eine CD mit allen Sourcecodes (ca. 50MByte). Die Programme auf PC-Ebene umfassen etwa 60.000 Zeilen Quellcode (C++), das Monitorprogramm auf einem MC68HC11 hat etwa 18.000 Zeilen Code (ANSI-C).

Daher mußten wir bei der Erstellung dieser Webpages etwas kürzen, wir haben uns daher entschlossen, nicht etwa die gesamte Arbeit, sondern nur eine Kurzfassung eines Fachartikels ins Web zu stellen.

Für weiterführendes Interesse an dem System sind wir jederzeit dankbar. Die Arbeit war übrigens kein Selbstläufer - es gab noch eine Nachfolgearbeit, die sich mit der Entwicklung von AD-/DA-Umsetzern für das System beschäftigte, so daß das System im Laborbetrieb einsetzbar wurde.

Aufgabenstellung

Aufgabe dieser Diplomarbeit war es, eine Entwicklungsumgebung für einen digitalen Signalprozessor zu erstellen. Verwendung findet dabei ein DSP56002 von Motorola mit 40MHz Taktfrequenz (20 MIPS), das Entwicklungssystem wird mit Hilfe einer RS232-Schnittstelle mit einem PC verbunden. Die Software auf dem PC wurde unter dem Betriebssystem Windows implementiert.

Das Einsatzgebiet des Systems liegt vor allem in der Lehre, es soll die Möglichkeit bieten, mit möglichst wenig Schritten einfache Programme für einen DSP zu erstellen. Um allerdings auch für komplexere Anwendungen genug Möglichkeiten anzubieten, wird großer Wert auf die flexiblen Erweiterungsmöglichkeiten gelegt.

In der einfachsten Ausbaustufe wird ein DSP56002 im Single-Chip-Betrieb (also ohne externen Speicher) unterstützt, in der Maximalausbaustufe eine Erweiterung auf 192Kx24 Bit-Worte statisches RAM und Unterstützung eines zweiten DSP56002, der als echter Parallelprozessor arbeiten kann. Die Aufrüstung orientiert sich am Stand der sogenannten Plug&Play-Technik - d.h. die Erweiterungen werden eingesetzt und automatisch erkannt.

Die Ausbaustufe mit einem Signalprozessor sollte nahtlos in den Betrieb mit einem zweiten DSP übergehen, d.h. die Software bietet für beide DSPs adäquate Debugging- und Entwicklungsmöglichkeiten.

Funktionsumfang

Die DSPs sollen mit der vollen Arbeitsgeschwindigkeit von 40MHz arbeiten, als externer Basistakt wird ein 1MHz-Takt eingesetzt, der durch die interne PLL multipliziert wird. Dadurch ist eine Systemerweiterung auf den DSP56002 mit 66MHz prinzipiell denkbar. Der Speicherzugriff soll mit voller Geschwindigkeit - also 0 Waitstates - erfolgen.

Der Speicher steht beiden Signalprozessoren gleichermaßen zur Verfügung, eine Busüberwachung verteilt den globalen Bus auf die DSPs. Die Kommunikation und Synchronisation der beiden Parallel-DSPs kann über den gemeinsamen Speicher (Semaphoren) oder über Interruptsignale erfolgen.

Um dem DSP-System eine Anbindung an die Außenwelt zu ermöglichen, wird ein flexibler Port zum Anschluß von AD-/DA-Umsetzern bereitgestellt, sowie eine zusätzliche serielle RS232- Schnittstelle für den DSP#1.

Der Port zum Anschluß von Analog-Einheiten bietet eine volle 24-Bit-Busanbindung, unterstützt ADUs und DAUs - auch in Mehrkanalausführung -, ist für beide DSPs nutzbar und die maximale Abtastfrequenz wird nur durch den Systemtakt der DSPs begrenzt (theoretisch 10MHz).

Durch die zusätzliche serielle Schnittstelle für DSP#1 wird die Verwendung als Stand-Alone- System unterstützt, da eine eigene Kommunikationsverbindung zu einem anderen System (z.B. Prozeßrechner, SPS) möglich ist.

Der Monitor zur Steuerung der Signalprozessoren wird nicht im Sichtbarkeitsbereich der DSPs realisiert, sondern in einem externen Mikrocontroller abgelegt. Der Mikrocontroller steuert über die integrierten Hardwaredebugger der DSPs (OnCE-Port) alle Funktionen von außen, dadurch wird keinerlei DSP-Speicher und keine DSP-Rechenleistung für den Monitor benötigt.

Für den DSP-Programmierer hat dies zur Folge, daß sich das System ihm gegenüber immer als Stand-Alone-System zeigt, der Programmier muß den Monitor bei der Programmierung eigener Applikationen nicht berücksichtigen (z.B. ist kein Linken eines Debug-Monitors bei DSP- Programmen notwendig).

Um die flexible Erweiterung so einfach wie möglich zu gestalten, sind in den Monitor Funktionen zur Erkennung der DSPs und des Speichers bereits integriert.

Die serielle Verbindung zwischen Monitor und PC stellt den Flaschenhals des Systems dar, daher muß die Anzahl der übertragenen Daten möglichst gering gehalten werden. Dies wird durch die Schaffung fest definierter Datenprotokolle gewährleistet. Direkte Hardwareeingriffe werden daher ausschließlich vom Monitor durchgeführt, während die Kommunikation via serieller Schnittstellte über Makrobefehle stattfindet.

Damit besitzt der Monitor einen festen Befehlssatz, der durch Makrobefehle über die serielle Schnittstelle abgerufen werden kann. Dies hat mehrere Vorteile: die Sicherheit gegen fehlerhafte Bedienung wächst, es ist eine gute Erweiterbarkeit für neue Makrobefehle gegeben, da neue Protokolle sehr leicht in die bestehenden Programme einfügbar sind, und die Entwicklungsoberfläche auf dem PC arbeitet hardwareunabhängig, da sie sich nicht um die eigentliche Interpretation kümmern muß.

Die Entwicklungsumgebung auf dem PC wird als MDI-Windows-Applikation implementiert, d.h. sie kann mehrere Assemblerquelltexte gleichzeitig verwalten. Für die Quelltexte werden alle üblichen Editiermöglichkeiten angeboten, desweiteren ist der Assembler voll in die Oberfläche integriert.

Um auch größere Programme entwickeln zu können, wird eine einfache Projektverwaltung angeboten, die das Zusammenfassen von mehreren Modulen zu einem größeren Programm ermöglicht.

Die Oberfläche unterstützt beide DSPs gleichermaßen, es werden sowohl Systeme mit einem als auch mit zwei DSPs unterstützt, für beide Prozessoren sind die gleichen Funktionen verfügbar. Die Oberfläche stellt sich über die automatische Konfigurationserkennung des Monitors jederzeit auf die vorhandene Ausstattung ein, es sind daher keine unterschiedlichen Programmversionen für verschiedene Ausbaustufen notwendig.

Da die Oberfläche die Konfiguration des Systems und die Zustände der DSPs über Makrobefehle vom Monitor abfragen kann, verhindert die Oberfläche Fehlbedienungen, indem nur solche Befehle abrufbar sind, die in diesem Betriebszustand keine Fehlfunktion hervorrufen können. Dies schränkt zwar die Möglichkeiten des Bedieners etwas ein, wird aber im Lehreinsatz zu einem schnelleren Lernerfolg führen, da die Häufigkeit von Bedienfehlern mangels exakter Systemkenntnisse abnimmt.

Um den Lernerfolg zu verbessern, werden umfangreiche Hilfefunktionen bereitgestellt. Zum einen werden die Programmfunktionen vollständig erklärt, zum anderen sind zahlreiche Hilfeseiten zur Assemblerprogrammierung enthalten. Eine vollständige Auflistung der Assemblerdirektiven und - fehlermeldungen rundet das Hilfeprogramm ab. Dies soll gerade im Lehreinsatz verhindern, daß wegen fehlender Informationen bestimmte Funktionen falsch oder überhaupt nicht genutzt werden. Da sämtliche Hilfetexte über Hyperlinks ("Querverweise") verfügen, sind Informationen schnell abrufbar, das eigenständige Arbeiten ohne lange Einarbeitungszeit wird somit ermöglicht.

Ein Entwicklungssystem mit einem oder zwei DSP56002 und integrierter Entwicklungsumgebung unter Windows.

Im Rahmen dieser Arbeit wurde ein Entwicklungssystem für den Parallelbetrieb zweier digitaler Signalprozessoren DSP56002 von Motorola entwickelt. Das Entwicklungssystem wird mit Hilfe einer seriellen Schnittstelle mit einem PC verbunden. Die Software zur Programmentwicklung auf dem PC wurde unter der grafischen Benutzeroberfläche Windows implementiert.

Die Entwicklungsumgebung kommuniziert über die serielle Schnittstelle mit einem Mikrocontroller, der das eigentliche Monitorprogramm enthält. Die Verwendung des integrierten Hardwaredebuggers der Signalprozessoren ermöglichte ein Konzept, das ohne Leistungseinbußen hinsichtlich Geschwindigkeit und Speicherplatz auskommt.

DSP-System Platine

Abbildung 1: Das Gesamtsystem mit 2 Prozessoren DSP56002 aufgerüstet

Als Signalprozessor werden zwei 24-Bit-Festkomma-Signalprozessoren DSP56002 von Motorola eingesetzt. Für die Kontrolle der Kommunikation zwischen DSPs und PC wird ein Mikrocontroller 68HC11, ebenfalls Motorola, verwendet.

Der DSP56002 bietet eine besondere Schnittstelle, den sogenannten OnCE-Port (On-Chip Emulator). Hierbei handelt es sich um eine serielle Schnittstelle, über die von außen der Zugriff auf alle internen DSP- Register erfolgen kann. Außerdem ist über diesen Port das Starten und Stoppen von Programmen und das Aktivieren von Trace- oder Breakpointmodus möglich. Dies hat den großen Vorteil, daß der DSP über einen externen Monitor betrieben oder debuggt werden kann. Ein Monitor im Speicherraum des DSP wird nicht benötigt.

Das 8 Bit breite bidirektionale Host-Interface des DSPs ermöglicht einen parallelen Datenaustausch zu Mikrocontrollersystemen.

Ausbaustufen des Systems

Die offene Architektur des DSP-Systems ermöglicht eine Vielzahl von unterschiedlich teuren Ausbaumöglichkeiten.

Alle erwähnten Varianten sind frei kombinierbar, wenn auch nicht alle gleich sinnvoll sind. Etwas überraschend ist vielleicht, daß der Speicher für das X- bzw. Y-RAM statt 24 Bit auch 8 oder 16 Bit breit sein kann. Dies hat einen einfachen Grund: wird X- oder Y-RAM nur als Zwischenspeicher für Samples o.ä. benutzt, so ist es nicht notwendig, 24-Bit-Daten abzuspeichern, da die Samples ohnehin nur eine Auflösung von 12 Bit (oder weniger) besitzen. In diesen Anwendungen werden die Speichersockel, die das niederwertigste (und evtl. auch das mittelwertige) Byte speichern, nicht bestückt. Benötigt man für Zwischenrechnungen die volle Datenbreite von 24 Bit, so können die Berechnungen bequem im internen RAM mit voller Auflösung abgespeichert werden. Die dadurch mögliche Ersparnis ist relativ groß: müßten sonst für ein 128K-Sample für 24 Bit-Speicher insgesamt 12 statische RAMS 32Kx8 eingesetzt werden, so sind es bei 8 Bit-Auflösung nur 4, bei 16 Bit-Auflösung immerhin nur 8 Bausteine.

Der variable Speicherausbau bezüglich der Wortbreite ist natürlich nur bei den Datenspeichern X- und Y- RAM möglich, nicht dagegen beim P-RAM. Ein Opcode ist immer 24Bit breit, benötigt also immer die volle Wortbreite.

Der DSP56002 wird im vorliegenden Fall in der 40MHz-Version eingesetzt, der 40MHz-Takt wird mittels der internen PLL aus einem externen 1MHz-Takt hochmultipliziert.

Struktur der Schaltung

Blockschaltbild

Abbildung 2: Blockschaltbild des 2#DSP56-Boards

Das 2#DSP56002-Board ist ein Multiprozessorboard, auf dem bis zu zwei DSP56002 parallel arbeiten können. Die erforderliche Busarbitration befindet sich in einem Logikbaustein GAL16V8. Dieser ist im obigen Blockschaltbild im Block Arbitration enthalten. Die Kontrolle über die beiden Signalprozessoren hat ein 68HC11-System, das den Host-Port und den OnCE-Port kontrolliert. Hieraus ergeben sich vielfältige Kontroll- und Debugmöglichkeiten. Die Schnittstelle zur Software-Entwicklungsumgebung auf dem Personal Computer ist die serielle Schnittstelle COMx:. Über diese werden alle relevanten Daten zum Entwicklungsboard gesendet bzw. empfangen. Es besteht auch noch die Möglichkeit einer weiteren Kommunikation zum PC, die direkt vom DSP aus geführt werden kann. Des weiteren wurde eine Schnittstelle geschaffen, um eine flexible Verbindung zu ADU/DAU-Bausteinen zu ermöglichen. Das DSP-System ist ebenfalls mit externem Speicher erweiterbar, um auch Probleme, die größere Speicherkapazitäten benötigen, nicht auszuschließen (jeder DSP besitzt insgesamt von Haus aus 1024 x 24Bit internen Speicher).

Die Platine wurde als Vierfach-Layer mit einem flächigen Masse- und einem flächigen Versorgungslayer ausgeführt.

Externe Speicherzugriffe

Bei dem DSP56002 gibt es die Möglichkeit, durch Software Wartezyklen einzufügen. Dies bietet die Möglichkeit, Speicherbausteine an den digitalen Signalprozessor anzuschließen, die sich in ihren Zugriffszeiten stark unterscheiden (z.B. SRAM und EPROM). Im Signalprozessor können für jeden Speicherbereich getrennt Wartezyklen definiert werden. Für jeden dieser Bereiche (Externer-X-Speicher, Externer-Y-Speicher, Externer-P-Speicher, Externer-IO-Speicher) können bis zu 15 Wartezyklen eingefügt werden.

Um das System nicht künstlich zu verlangsamen, wurden durchgängig statische RAMs mit 15ns Zugriffszeit eingesetzt, dadurch kann das System mit 0 Waitstates betrieben werden.

Gemeinsamer Speicherzugriff der DSPs

Der DSP56002 stellt für die gemeinsame Benutzung von Speicher mit einem zweiten DSP verschieden Bussignale bereits zur Verfügung, die nur noch von einer Logik ausgewertet werden müssen.

Das folgende Blockschaltbild verdeutlicht das Zusammenspiel von Speicher, DSP und Arbitration-Logik.

Speicheraufteilung

Abbildung 3: Blockschaltbild der Bus-Arbitration-Logik

Entwurf der Arbitration-Logik

Bei vielen Anwendungen, bei denen beide DSPs eingesetzt werden, wird häufig ein DSP zur Dateneingabe und ein DSP zur Datenausgabe benutzt.

Greift ein DSP auf den Bus zu und benötigt ihn nicht länger, so erhält der Arbiter den Bus und wartet auf die nächste Anforderung eines DSPs.

Falls beide DSPs einmal den Bus gleichzeitig anfordern und der Arbiter besitzt den Bus, so wird der Bus nicht immer an den gleichen DSP abgegeben, da sonst der andere DSP stillgelegt würde. Stattdessen wird der Bus immer abwechselnd auf beide DSPs aufgeteilt, der Bus wird also paritätisch auf beide DSPs verteilt, falls gleichzeitige Anforderungen auftreten.

Durch den verfügbaren lokalen Speicher können Programme im internen RAM des DSPs abgearbeitet werden, ohne daß externe Opcode-Fetch-Zyklen benötigt werden. Externe RAM-Zugriffe fallen dann vornehmlich für den globalen Datentransfer an.

Anbindung HC11 - DSP

Das SPI des HC11 und der OnCE-Port des DSP sind datenformatkompatibel, allerdings besitzt der HC11 nur eine SPI. Somit ist eine Umschaltung zwischen den beiden OnCE-Ports notwendig. Eine externe Logik übernimmt die Umschaltung der seriellen Verbindung und speichert asynchrone Ereignisse (z.B. Breakpointauslösung) zwischen, bis sie durch Interruptserviceroutinen verarbeitet werden. Die Logik wird über die IO-Pins des MC68HC11 angesteuert.

Die Host-Interfaces der beiden DSPs werden so verknüpft, daß sie im Adressraum des HC11-Systems liegen (memory-mapped). Mit Hilfe eines einfachen Protokolls werden bidirektionale parallele Datentransfers zwischen 68HC11 und DSP56002 ermöglicht.

AD-Port Beschreibung

An einer Steckerleiste ist eine Umsetzerkarte (ADU/DAU) anschließbar, dazu stehen digitale und analoge Versorgungsspannungen zur Verfügung.

Als Steuerleitungen sind Chipselectleitungen für maximal 6 Bausteine auf dem Port vorhanden. Über einen programmierbaren Timerausgang kann die Umsetzungsgeschwindigkeit gesteuert werden, die Reaktion auf die Umsetzung erfolgt über globale Interruptleitungen.

Der globale Datenbus ist in voller Breite (24-Bit) am Stecker vorhanden, um die volle Auflösung des Festkommaformats nutzen zu können. Der Datenbus wurde über Treiberbausteine abgekoppelt, so daß kein digitales Datenbusrauschen (digital feed through) auf dem Analogteil stört.

Datenflußmodell

Das verwendete Datenflußmodell lehnt sich an das OSI-Schichtenmodell an. Auf der PC-Seite übernehmen die oberen Layer die Umsetzung der DSP-Informationen in grafische Strukturen der Oberfläche. Die gleichen Layer (Application Layer, Presentation Layer) wandeln Benutzereingaben in standardisierte Datenpakete um, die von den unteren Layern (Transport Layer - Physical Layer) via RS232 an den Mikrocontoller 68HC11 gesendet werden.

Auch auf der 68HC11-Hostseite existiert das Schichtenmodell, realisiert im Monitorteil des HC11- Systems. Die Anwendungsschicht (Application Layer) kommuniziert dann über die zuvor beschriebene Hardwareschnittstelle mit den integrierten Hardwaredebuggern der DSPs.

Datenaustausch PC und HC11

Die Kommunikation zwischen PC und und der Monitorsoftware auf dem Board findet durch den Austausch von Datenpaketen statt. Da es den beiden Hostseiten nicht direkt möglich ist, den Zustand der Gegenstelle zu erkennen, werden bei entscheidenden Aktionen (Reset, Programmende, Programmstart, Unterbrechung) Kommandos geschickt, so daß sich Sender und Empfänger wieder an einem bestimmten Punkt synchronisieren können.

Die Reihenfolge der Pakete ist nicht frei kombinierbar, sondern hängt vom Zustand des DSP-Systems ab. Dadurch werden Fehlbedienungen (z.B. Programmstart vor Download des Programms) schon auf Protokollebene abgefangen.

Konfigurationserkennung durch "Plug&Play"

Da die vorliegende Entwicklungsumgebung in sehr vielen verschiedenen Ausbaustufen existieren kann, wurde eine automatische Konfigurationserkennung implementiert.

Einen RAM-Baustein erkennt man daran, daß beim Schreiben eines Wertes an eine bestimmte Adresse dieser Wert beim Lesen wieder erscheint. Weichen die beiden Werte ab, so befindet sich an dieser Adresse kein Speicher. Um die Sicherheit der Erkennung zu erhöhen, wird das obige Verfahren mehrfach mit Komplementärwerten wiederholt.

Zur DSP-Erkennung versucht der Monitor den Debugmodus anzufordern. Bleibt das Acknowledge-Signal aus, so wird dies als Abwesenheit des DSPs interpretiert.

Funktionsweise des Monitors

Das Programm arbeitet im wesentlichen als Endloschleife, die auf durch Interrupts angezeigte Ereignisse reagiert. Der Monitor enthält auf der HC11-Hostseite sämtliche Layer des OSI-Schichtenmodells. Dadurch wird der DSP mit der Datenübertragung von Monitordaten nicht belastet, seine Resourcen stehen vollständig für Anwendungen zur Verfügung.

Da die Bitübertragungsschicht auf asynchrone Ereignisse reagieren muß, wurde sie in Form von Interruptserviceroutinen implementiert. Die darüberliegenden Schichten übernehmen die Umsetzung (Transportschicht) und Interpretation (Anwendungsschicht) der Daten in Einzelanweisungen für den Hardwaredebugger (OnCE-Port) vor. Je nach Zustand des Systems und Art der Anweisung werden Daten in den DSP geschrieben oder daraus gelesen. Mögliche Anweisungen wären das Lesen und Schreiben von Registern oder Speicherbereichen, sowie das Anhalten und Starten von Programmen. Zusätzlich erkennt diese Schicht das Auftreten von Breakpoints und Trace-Ereignissen.

Über das Host-Interface kann ein DSP einen Speicherbereich als Datensatz für eine grafische Darstellung übertragen. Dieser Datensatz wird vom Monitor mit hoher Priorität an die grafische Oberfläche gesendet, wo er grafisch dargestellt werden kann. Dies ist hilfreich für die Visualisierung von Samplingdaten oder FFT-Ergebnissen.

Implementation und Test

Das wesentliche Problem bei der Monitorsoftware ist, daß die Software quasi blind ablaufen muß, d.h. ein Fehler an einer beliebigen Stelle innerhalb der Software macht sich von außen, also aus Sicht des PCs, nur durch eine Nichtfunktion oder fehlerhafte Funktion des gesamten Systems bemerkbar. Folglich ist eine Zuordnung einzelner Fehlerquellen kaum mehr möglich, auch gezieltes Testen wird dadurch erschwert. Um diesem Problem von Anfang an entgegenzutreten, wurde ein sehr ausführliches Entwurfs- und Testverfahren gewählt, das von modernen Software-Engineering-Konzepten abgeleitet wurde. Zusätzlich wurde die Software (ANSI-C) vor dem Einsatz im Mikrocontrollersystem auf einem PC übersetzt, Hardwarezugriffe wurden dabei auf PC-Ebene emuliert. Dadurch war es möglich, innerhalb sehr kurzer Zeit den Monitor betriebsfähig zu machen.

Systemprogrammierung

Bestimmte wichtige Konfigurationsregister (Taktfrequenz, Waitstates, Host-Interface) werden bei der Verbindungsaufnahme zwischen grafischer Oberfläche und DSP-System bereits mit Werten belegt. Dies hat zwei Vorteile: zum einen können wichtige Hardwareeinstellungen auf der Ebene der Benutzeroberfläche verändert werden, zum anderen wird der Programmierer von der Initialisierung nach einem Reset entlastet.

Über das zuvor beschriebene Host-Interface ist es dem DSP-Programmierer jederzeit möglich, gezielt Datenpakete an die grafische Benutzeroberfläche zu senden, um sie dort darstellen zu lassen.

Parallelbetrieb aus Sicht des Programmierers

Eine Kommunikation zwischen den Prozessoren ist nur über einen gemeinsamen Speicherplatz möglich, daraus ergibt sich als zwingende Konsequenz, daß bei Multiprozessor-Betrieb mindestens eine RAM-Bank (P/X/Y) bestückt sein muß. Ein Datenaustausch findet in der Form statt, daß DSP A einen Wert an eine festgelegte Adresse schreibt und DSP B diese Adresse ausliest (Semaphoren).

Der interne Speicher ist lokal, d.h. die internen Adressräume im X-/Y- und P-RAM sind nur für den eigenen DSP sichtbar, insbesondere sind die Programme im internen P-RAM für jeden DSP voneinander getrennt.

Für die Synchronisation der beiden DSPs gibt es folgende Möglichkeiten:

  1. Polling

    Beim Polling existiert eine festgelegte Adresse im gemeinsamen Speicherraum, die von DSP A zu einem bestimmten Zeitpunkt mit einem Wert beschrieben wird, während der andere DSP B diese Adresse liest und weiß, daß bei einem verändertem Wert ein bestimmtes Ereignis eingetreten ist. Diese Methode hat den Nachteil, daß Rechenzeit für das Warten verloren geht.

  2. Lokale Interrupt-Aufrufe

    Bei den beiden DSPs sind die Interrupt-Eingänge des NMI (Non-Maskable Interrupt) über Kreuz mit Bitausgängen verbunden, d.h. durch Setzen und Löschen eines Ausgabe-Pins kann beim anderen DSP ein Interrupt ausgelöst werden.

  3. Globale Interrupt-Signale als Zeitbezug

    Zusätzlich zur lokalen Interrupt-Verbindung sind auch die Interrupts INTA und INTB, die durch die AD-/DA-Umsetzer ausgelöst werden, auf beide DSPs geführt, d.h. die Interruptauslösung erfolgt (falls die Interruptquellen vom Programmierer zugelassen werden) gleichzeitig.

Debuggingmöglichkeiten

Vor allem für die Programmentwicklung ist es nützlich, das Programm an bestimmten Stellen anhalten zu können, und sich dort bestimmte Register anzusehen. Von der grafischen Oberfläche werden der Tracemodus und der Breakpointmodus angeboten, um ein Programm zu debuggen. Hierbei handelt es sich um externe Debuggingmöglichkeiten, d.h. diese Möglichkeiten sind unabhängig vom eigentlichen Programm, und werden erst zur Laufzeit festgelegt. Gerade die Breakpoint-Möglichkeiten der Oberfläche sind sehr ausgefeilt, da auch Datenspeicherbereiche oder I/O-Speicherbereiche überwacht werden können.

Der Programmierer kann Breakpointe auf 2 Arten herbeiführen: der Programmierer kann Haltepunkte für bestimmte Ereignisse setzen und Ausdrücke überwachen, d.h. bei bestimmten Werten von Ausdrücken kann ein Breakpoint ausgelöst werden.

Grafische Oberfläche

Die grafische Oberfläche bietet folgende Features:

Tabelle: Darstellungsgeschwindigkeit der Oszilloskop-Funktion
Werteanzahl 256 reell 256 komplex 512 reell 512 komplex
Bilder / sec 3,5 2 2 0,9

Systemanforderungen

Folgende Systemvoraussetzungen sollte der PC erfüllen:

Bedienungsanleitung

Die Bedienungsanleitung für die Systemsoftware wurde nicht für den schriftlichen Gebrauch entworfen, sondern als Windows-Hilfe-Datei. Dies hat den Vorteil, daß jederzeit Hilfe verfügbar ist. Die Hilfedatei gliedert sich in folgende Abschnitte:

Zusammenfassung

Das vorliegende System ermöglicht Stand-Alone-Betrieb, bietet flexible Erweiterbarkeit und universelle Anbindung an die Umgebung (AD-Port, Serielle Schnittstelle).

Der Programmierer muß sich nicht in das System einarbeiten, sondern nur in den DSP, er wird nicht mit systemspezifischen Details belastet. Der Programmierer benötigt kaum Systemkenntnisse, um die ersten Programme zu schreiben und zu testen, vor allem, da umfangreiche Makrobibliotheken zur Verfügung gestellt werden. Das Ziel "mit 10 Mausklicks zum ersten Programm" wurde verwirklicht.

Die integrierte Entwicklungsumgebung ist in sich abgeschlossen, d.h. ein Programm für alles, Entwurf, Implementation und Test sind innerhalb eines einzigen Programms durchführbar. Gerade der Test (Debugging) ist ohne aufwendige Einarbeitungszeit des Programmierers mögich, da alle Optionen übersichtlich visualisiert wurden.

Es handelt sich um ein sehr komplexes System, dennoch ist der Übergang von einem Singleprozessorsystem zu einem Doppelprozessorsystem fließend. Es sind keine Änderungen an Hard- und Software nötig, um Programme für die beiden Konfigurationen zu entwickeln. Ist nur ein Prozessor vorhanden, so sperrt die Oberfläche automatisch alle Befehle, die sich mit dem zweiten DSP befassen.

Dies hat auch den Vorteil, daß das System preislich flexibel ist, da man nach dem Prinzip "so schnell wie nötig, aber nicht teurer als möglich" vorgehen kann - gerade bei der heutigen finanziellen Situation ein wichtiges Argument.

Das beschriebene System wurde von den beiden Autoren an der Fachhochschule Darmstadt im Zeitraum Oktober 95 bis Februar 96 im Rahmen einer Diplomarbeit entworfen, entwickelt und in Betrieb genommen.

Literaturhinweise

Bildnachweis:

Alle Abbildungen Bäckmann, Börcsök, Februar 1996

Fragen, Fehlermeldungen, Tipps und Hinweise per Mail an Marcus Bäckmann, danke. Aktualisierung am 19.02.2017

© Marcus Bäckmann, www.baeckmann.de/diplomarbeit_elektrotechnik.php, Version vom 19.02.2017

Valid XHTML 1.0 Strict