Der Verwandlungskünstler - DSP-Programmierung auf dem Falcon

Ein neuer Prozessor mit neuem Befehlssatz verlangt auch nach neuen Entwicklungswerkzeugen. Mangels anderer Angebote kommt bisher nur das Falcon030-Entwickler-Kit von ATARI in Frage.

Das derzeit einzige Entwicklungspaket zur DSP-Programmierung kommt von ATARI und kann auch nur dort bezogen werden. Dementsprechend bescheiden ist der Bedienungskomfort.

Sowohl Assembler wie Linker werden nur in einer Kommandozeilenversion angeboten. Doch handelt es sich nicht um eine ATARI-Eigenentwicklung, sondern um eine Portierung des original Motorola-Assemblers, der seine Praxistauglichkeit schon auf dem NeXT-Rechner unter Beweis stellen mußte. Daß Motorola bei dem Assembler hauptsächlich auf Zuverlässigkeit, Portierbarkeit und gründlicher Fehlerüberprüfung Wert legte, davon zeugt die Programmgröße (über 200 Kilobytes) und noch deutlicher die behäbige Ausführungsgeschwindigkeit. Ähnlich verhält es sich beim Linker. Aus welchen Gründen auch immer, verlangt die gelinkte Binärdatei nach einem weiteren Konvertierprogramm, das dann die für den Falcon ladbare LOD-Datei (jetzt im ASCII-Format) erstellt. Wie schon in (2) beschrieben, werden die LOD-Dateien zur Laufzeit von der Applikation geladen, nochmals konvertiert (dieses Mal vom XBIOS) und gelangen schließlich zum DSP.

Hier noch einmal zur Übersicht:

Datei *.ASM
    &darr;  <- Assembler
Datei *.CLN
    &darr; <- Linker
Datei *.CLD
    &darr; <- CLD-to-LOD-Konvertierer
Datei *.LOD
    &darr;<- XBIOS-Funktion Dsp_LodToBinary()
Hauptspeicher
    &darr; <- XBIOS-Funktion Dsp_ExecProg() 
DSP56001 -Speicher und Ausführung

Die knapp 500 Seiten englische Dokumentation beschäftigen sich hauptsächlich mit der Assembler-Syntax und mit den im Falcon hinzugekommenen XBI-OS-Funktionen.

DSP-Entlausung

Weitaus zeitgerechter ist der im Paket enthaltene DSP-Debugger von der französischen Software-Schmiede Brainstorm. Als Vorbild dieses komplett in GEM eingebundenen fensterorientierten Debuggers diente mit Sicherheit der Pure Debugger. Angefangen bei den verschiedenen Fenstertypen über die Menüeinträge bis hin zum Hypertext-Hilfesystem stand der Pure Debugger Pate. So fühlen sich dann auch die Pure-Anwender sofort zu Hause. Zusätzlich einstellbare optische Verschleierungen, wie zum Beispiel das Einfärben der Assembler-Befehle im Quelltextfenster, bezahlt man mit einem allgemein langsamen Bildschirmaufbau. Das Debuggen der relativ kleinen DSP-Programme läßt aber den gemächlichen Programmlauf verschmerzen.

Programmier-Tools des DSP 56001 (Assembler, Linker, Debugger)

Übersicht DSP-Programmierkurs

Teil 1: Register und Befehlssatz des DSP 56001

Teil 2: I/O-Schnittstellen und I/O-Programmierung des DSP 56001 und des MC68030

Teil 4: Tips und Tricks mit Programmbeispiel

Wie bei allen Fenstersystemen macht sich auch hier eine große Bildschirmauflösung bezahlt, denn die aktuellen Registerwerte, die nächten paar Quelltextzeilen und einen Speichermitschnitt benötigt man praktisch immer, wenn es um die Fehlersuche geht.

Doch eignet sich der Debugger nicht nur zur Fehlerbereinigung. Die einfache und bequeme Bedienung des Debuggers verführt geradezu, bei den ersten Gehversuchen mit dem DSP mangelnde Kenntnisse über den Befehlssatz durch Ausprobieren zu komplettieren. Erst wenn diese Methode nicht mehr weiterhilft, greift man auf die Dokumentation zurück.

Da der Assembler keine spezielle Symboltabelle für den Debugger erzeugen kann, muß sich der Entwanzer mit den Informationen aus der LOD-Datei zufriedengeben. Damit lassen sich zwar Adressen über Label (aus dem Quelltext) ansprechen, eine direkte Programmausführung des Quelltextes ist aber nicht möglich. Deshalb findet die Programmausführung in einem Disassembler-Fenster statt. Um dennoch nicht auf Kommentare aus dem Quelltext verzichten zu müssen, läßt sich dieser noch optional anzeigen. Allerdings fehlen dann die Programmzählermarkierung wie auch die Funktionen „Step over“, „Trace into“ oder „Run“.

Gewöhnungsbedürftig ist die Funktion „Goto“. Diese disassembliert lediglich ab der gewünschten Stelle, führt das Programm aber nicht bis zu jener Stelle aus. Solches erreicht man nur über den Umweg: „Set Breakpoint“/“Run“.

Um die Echtzeitanwendungen des DSP unter die Lupe nehmen zu können, sind die angebotenen bedingten „Breakpoints“ (ein Ausdruck muß erfüllt sein, und/oder der Schleifenzähler ist abgelaufen) unerläßlich. Für den Durchblick sorgt ein Fenster, das alle Breakpoints auflistet.

Leider handelt es sich nicht um „echte“ Breakpoints. Normalerweise ersetzt ein Debugger den Opcode der gewünschten Bruchstellen durch einen ILLEGAL-Befehl und fängt dann den entsprechenden Interrupt ab. Im Falle des Brainstorm-Entwanzers wird aber nach jedem ausgeführten Befehl überprüft, ob sich an dieser Stelle ein Breakpoint befindet - wenn nicht, geht’s mit dem nächsten weiter. Diesen Aspekt mag man im ersten Moment für unbedeutend halten, berücksichtitg man jedoch das in (2) beschriebene Pipelining des DSP, bekommt dieser feine Unterschied eine ganz andere Qualität. Was beim „Single Step“ nicht anders zu erwarten ist (hier wird der DSP immer angehalten), ist im Falle von „Run“ lästig und absolut unnötig. Dazu betrachte man folgende DSP-Befehle:

MOVE #2,R0
NOP
MOVE #3,R0
MOVE R0,X0

Das Register X0 erhält bei einem kontinuierlichen Programmablauf den Wert „2“, denn der „MOVE“ in ein Adreßregister (hier R0) ist erst im übernächsten Befehl abgeschlossen. Das Register „R0“ erhält also erst nach Ablauf aller hier aufgeführten Befehle den neuen Wert „3“. Weil der Debugger aber nach jedem Befehl noch eigene private Befehle ausführt, bekommt die Pipeline genügend Zeit, um bis zum nächsten offiziellen Befehl das Adreßregister mit dem neuen Wert „3“ geladen zu haben. So lange dieser Fehler im Debugger (Version 1.0) nicht behoben ist, sollte man Konstruktionen obiger Art vermeiden.

Weitere Funktionen wie das Suchen und Ersetzen im Speicher, das Speicherfüllen oder der Memory-Dump fehlen ebensowenig wie ein Taschenrechner, der außer mit Dezimal- und Hexadezimalwerten auch mit den 24-Bit-Festkommazahlen umzugehen weiß.

Da ja „nur“ die DSP-Routinen unter der Obhut des Debuggers liegen und nicht die ganze Applikation, benötigt der Debugger weitere Funktionen für den Datenaustausch zwischen DSP und Host. Dazu stehen Bedienelemente ähnlich denen eines Kassettenrekorders (Play, Stop, Record, Rewind ...) bereit, mit denen sich über das Host-Interface Daten einer beliebigen Datei vom/ zum DSP empfangen/senden lassen. Die Debugger-Dokumentation beschreibt des weiteren eine Schnittstelle (via evnt_mesag()), womit sich der Host-Transfer von einem selbstgeschriebenen Accessory (oder ein anderes Programm unter MultiTOS) steuern läßt. Dennoch wäre ein direkter Empfang und das direkte Senden einzelner Werte, ohne eine Ein-/Ausgabedatei bemühen zu müssen, wünschenswert.

Ganz unter den Tisch gefallen ist die SSI-Schnittstellenansteuerung beziehungsweise die Soundsystemsteuerung aus dem Debugger heraus. Immerhin bietet ATARI ein Accessory (mit Quelltext) an, über das sich wenigstens die Verbindungsmatrix des CODEC setzen läßt. In diesem Programm ließen sich die fehlenden Funktionen DMA-Play und DMA-Record noch implementieren.

Bei aller Kritik muß man dem Debugger zugute halten, daß er für eine Version 1.0 sehr stabil läuft und daß er sauber strukturiert und nicht zuletzt deswegen noch ausbaubar ist.

Wenn selbst der Debugger nicht mehr weiterhilft, bietet sich noch ein informierender Blick in die mitgelieferten 1.3 MByte DSP-Quelltext an. Hierin dürfte man für praktisch jedes Problem funktionierende und lauffähige Beispielquellen finden. Nebenbei verdeutlichen die Beispiele, wie leistungsfähig der DSP ist und wie flexibel er sich einsetzen läßt. Zur Anregung und Nachahmung finden Sie in dem obenstehenden Kasten eine kleine Auswahl der DSP-Quellen auf. Diese findet man übrigens auch in der Motorola-Mailbox.

Bezugsquelle:

ATARI Falcon030 Toolkit:
ATARI (Benelux) B.V.
Attn: W. F. Kilwinger P.O. Box 70 NL-4130 EB Vianen

Lieferumfang:

Außerdem befinden sich sämtliche Quelltexte von Motorola in der hauseigenen Mailbox

Preis: 133,92 DM (Vorauskasse)

Literatur:

[1] Der Verwandlungskünstler, Teil 1, ST Computer, 10/93, MAXON Computer

[2] Der Verwandlungskünstler, Teil 2, ST Computer, 11/93, MAXON Computer

[3] DSP56000/DSP56001 Digital Signal Processor User’s Manual, Motorola, 1990

[4] Das Buch zum ATARI Falcon030, Dietmar Hendricks, Alexander Herzlinger, Martin Pittelkow, Data Becker, 1. Auflage 1992

Alle Rezepturen für das tödliche Wanzengift auf einen Blick

Name Dateigröße [KB] Beschreibung
ADPCM.ARC 71 ADPCM (G.721)
CC.JED 3 Monitorversion für den Commandconverter (PAL-Jedec-File)
CHORUS.ARC 6 Programm zur Erzeugung eines Stereo-Chorus
COSINE.ASM 2 Cosinus-Generator
DSPBUG.ARC 165 Debug-Monitor zum Betrieb über Terminal via SCI/Host
DTMF.ARC 29 DTMF-Decoder (Bandfilteransatz/Goertzel-Decoder)
DURBIN.ARC 4 berechnet LPC-Koeffizienten in Fließkomma (benötigt FLOAT.ARC)
DURBINF.ARC 5 Berechnung von LPC-Koeffizienten in Festkomma
EQUALIZ.ARC 7 Stereo-Equalizer
EQUATES.ARC 7 I/O-Equates
FFTS.ARC 59 Fast-Fourier-Transformationen inkl. Hilfsroutinen/-makros
RFFT56.ARC 6 „REAL“-FFT
FILTER.ARC 22 IIR- und FIR-Filterroutinen sowie LMS SW
FLANGER.ARC 2 Stereo-Flanger
LATTICE.ARC 21 Lattice-Filter-Routinen
LEROUX.ARC 5 Leroux-Gueguen-Berechnung von LPC
LINLOG.ARC 9 linear/logarithmische Umwandlungsroutinen
FLOAT.ARC 35 Fließkommabibliothek
MATRIX.ARC 5 Matrixmultiplikationen
FUNCTIMA.ARC 88 EXP-, LOG-, RND- und SQRT-Funktionen
SQRT56.ARC 2 Quadratwurzel
SDM.ASM 1 Single * Double-Multiplikation
REVERB.ARC 15 zwei Assemblerquellen zur Hallerzeugung
STREVERB.ARC 4 Stereo-Hallerzeugung
SLOADER.ARC 8 Bootloader via SCI
SORT.ARC 6 Sortieralgorithmen
SPEKTRUM.ARC 37 Spektrum-Analyzer
STEREO.ARC 4 AM-Stereo-Decoder (nach Motorola C-QUAM AM Stereo)
VITERBI.ARC 7 Viterbi-Encoder/-Decoder (z.B. für V.32-Modems)

Hier ein paar Leckereien aus dem Entwicklerpaket bzw. aus der Motorola-Mailbox


Jürgen Lietzow
Aus: ST-Computer 12 / 1993, Seite 116
Links
Copyright-Bestimmungen: siehe Über diese Seite