| |
DF6JB > DSP 27.03.96 16:05l 297 Lines 18482 Bytes #-10769 (0) @ DL
BID : R36DB0CL01E
Read: DH1FBK DJ0RA DK8RW DG8SGC DL1EFA LX2GT DG8RAD DK8CB DJ2TK DL1EEC OE2DWL
Read: OM1ATO 9A2AZ DC2MRR DL8SER DG5YMS DK5RAS GUEST DF2EL
Subj: EasyDSP
Path: DB0AAB<DB0MWS<DB0RBS<DB0SEL<DB0ZDF<DB0SRS<DB0FP<DB0ERF<DB0SAW<DB0HRO<
DB0DJ<DB0VER<DB0CL
Sent: 960327/1054z @:DB0CL.#HB.DEU.EU [Bremen,JO43GF,DD4BN] $:R36DB0CL01E
de DF6JB @ DB0CL.#HB.DEU.EU (Ulli)
to DSP @ DL
E a s y D S P
- Eine Bekanntmachung -
Eine bekannte Hollywoodkommödie (ich glaube sie heißt "Ein Pyjama für zwei)
mit Doris Day und Rock Hudson in den Hauptrollen bezieht ihren Reiz aus der
Tatsache, daß dort in Funk und Fernsehen ein Produkt beworben wird, welches
gar nicht existiert. Alle Welt rätselt nun herum, um was es sich wohl handeln
mag...
...In so einer ähnlichen Situation befinde ich mich auch im Moment, nein,
nicht ganz, weil: EasyDSP, worüber ich hier ein wenig erzählen will, liegt
von seiner Entwicklung her in den allerletzten Zügen. Geben tut's das aller-
dings wirklich noch nicht, alles noch ein wenig DSP-Fiction !
Wie kam es zu der Idee ein "EasyDSP" zu entwickeln? Bereits vor einigen zig
Jahren wurde ich auf die "DSP CARD 4" der finnischen ALEFNUL Gruppe aufmerk-
sam gemacht. Ich las zwar die Dokumentation mit großem Interesse, hatte aber
-ehrlich gesagt- wenig Ahnung, wovon da die Rede war. Vor etwa zwei Jahren
machte mich Hartmut, DL1YDD, darauf aufmerksam, daß von der Firma TEXAS
INSTRUMENTS ein billiges Evaluationboard für den TMS320C25/6 und später für
den C50 auf dem Markt war. Hartmut kaufte ein solches Board und ich lieh es
mir von ihm aus. Nachdem ich damit nur einige wenige Anfangserfolge erzielen
konnte, gab ich es ihm wieder zurück und war der Ansicht, daß DSP wohl weiter-
hin nichts für mich sei. Damit war DSP vorläufig für mich gestorben.
Da ich mit "EasyFax" vor einigen Jahren einen überaus erfolgreichen Konverter
für die Anwendung mit JVFAX entworfen aber seitdem in Sachen Hardware
wenig gemacht hatte, traf ich mich vor zwei Jahren auf der Interradio in
Hannover mit Django, DL5YCC, (ja ja, dem HAMCOM Django), um mit ihm darüber
zu diskutieren, ob ich nicht eine für sein HAMCOM optimierte Konverter-
schaltung entwerfen solle. Nicht so wie der "Simpelkonverter" sondern
vornehmer: mit Vorfiltern, welche durch HAMCOM in ihrer Durchlasskurve
einstellbar sein sollten. Django gefiel die Idee an sich, war aber anderer-
seits der Ansicht, wenn man wirklich universell sein wolle, so ließe sich
dies eigentlich nur mit einem DSP erzielen (er selber hatte auch schon mit
einem C25 board experimentiert). Dadurch wieder in Richtung DSP gedrängt,
kaufte ich mir selber ein C50 board und experimentierte intensiver damit
herum. Wieder wurde ich nicht wirklich glücklich damit. Einerseits war ich
von der Hardware nicht besonders begeistert (schon Django hatte angemerkt,
daß man für ernsthafte Modemanwendungen besser einen richtigen UART hätte,
als den per Software emulierten). Aber auch der TEXAS Assembler war nur
schwierig mit meiner Denkungsart in Einklang zu bringen, obwohl ich nun
wirklich schon zig unterschiedliche Prozessoren in Maschinensprache
programmiert hatte.
Dann passierte etwas einschneidendes: In ELRAD (in Sachen DSP sehr engagiert)
erschien die Ankündigung eines Evaluationboards für den DSP56002. Das
besorgte ich mir umgehend, und siehe da: Daaaas also ist DSP. Ich will hier
die Firmenphilosophieen von TEXAS und MOTOROLA gar nicht weiter auseinander-
diskutieren (TEXAS ist immerhin der Marktführer...), klar war aber: Wenn ich
was mit einem DSP mache, dann mit einem von MOTOROLA. Hier kam ich auch über
die Anfangserfolge schnell heraus und Filter sowie einige Modems für JVFAX
waren relativ schnell programmiert.
Ich begann, meine ersten Schaltzeichnungen zu machen. Als ich damit schon
etwas weiter fortgeschritten war, kam die Kunde von KC7WW nach Deutschland.
KC7WW, Johan Forrer, ist in den USA so etwas wie ein DSP-Guru und hatte im
Sommer '95 in der amerikanischen QEX einen Grundsatzartikel über die
Anwendung des DSP56002EVM im Amateurfunkshack veröffentlicht, nebst einer
hübschen Sammlung von Software, die er von der DSP CARD 4 auf das EVM
portiert hatte. Ich dachte: Das ist ein Mann, der sich auskennt. Den müßte
man mal ansprechen. Ich schrieb ihm einen Brief "Hey Johan, ich will ein
DSP-Modem bauen. Wie soll es deiner Meinung nach aussehen?" Seine Antwort
war, er würde gerne mit mir darüber diskutieren, aber erst mal solle ich mir
eine E-Mail Adresse beschaffen. Zwei Stunden später war ich COMPUSERVE Kunde
und bin seither unter 101530,1426@COMPUSERVE.COM erreichbar. Mit Johan folgte
eine ausgesprochen fruchtbare Diskussion darüber, wie ein DSP Modem für
Amateurfunkanwendungen aussehen müsse. Diese umfasste Fragen der Speicher-
größe, der Zahl der Transceiver-Anschlüsse, die Verpackung des ganzen (wegen
Störstrahlung und so), die Beschaffenheit der Schnittstellen zum PC und so
weiter und so fort. Ich denke, wir haben so ziemlich jeden Aspekt diskutiert.
Es taten sich drei Schwierigkeiten auf: Die von der DSP CARD 4 auf das EVM
portierte Software (die selbstverständlich auch auf meinem Kasten laufen
sollte) erwartete eine bestimmte Belegung der RS232 Schnittstelle. Ich hatte
mich aber aus ganz bestimmten Gründen (Kompatibilität zu einigen sehr
bekannten Programmen aus Europa) auf eine andere Art der Ansteuerung fest-
gelegt. Zum anderen läuft die portierte Software dann besonders gut (es geht
auch anders, aber umständlicher), wenn sie bestimmte Programmteile im sog.
Boot-Eprom des Systems vorfindet. Ich hatte mir allerdings auch schon
überlegt, was ich im Eprom drinhaben wollte. Die dritte Schwierigkeit war
mehr rechtlicher Natur. Die Copyrights auf die ursprüngliche DSP CARD 4
Software lagen natürlich bei der ALEFNUL Gruppe und wer weiß, ob die damit
einverstanden waren, wenn ihnen jemand auf ihrem eigenen Feld Konkurrenz
macht. Also kontaktierte ich Jarkko Vuori, OH2LNS, den Softwaremann der
Gruppe und fragte ihn danach. Weil ihm mein Design gut gefiel, gab er mir
spontan die Erlaubnis dazu, die von ihm entwickelte Monitorsoftware kosten-
frei in meinem Design benutzen zu dürfen. Nochmals Danke dafür an Jarkko.
Auch mit ihm entspann sich eine fruchtbare Diskussion und er hatte noch
etliche Tips auf Lager. Nachdem die rechtliche Seite geklärt war, blieb die
Frage, wie man die Probleme der unterschiedlichen Designansätze in den Griff
bekommt. Ursprünglich hatte ich an Drehschalter mit 'zig Ebenen gedacht, aber
die bessere Lösung war sicher die Benutzung von großen PLDs. Mit denen hatte
ich aber noch nie gearbeitet und deshalb mußte ich zunächst einmal einen
Crash-Kurs in PLD-Programmierung machen. Hat sich aber gelohnt.
Nun die große Frage: Was ist bei der ganzen Diskussion und Überlegung denn
nun rausgekommen ?? Wie selbst unser Bundeskanzler weiß, ist es sehr wichtig,
was hinten herauskommt.
Hier einige Eigenschaften des Designs:
- CPU: 24 Bit DSP56002 CPU, 40 Mhz, schnellere Taktraten in Zukunft möglich
- Speicher: 32 K Worte X-Speicher, 32 K Worte Y-Speicher, 32 K Worte
P-Speicher, zusammen also 288 K Byte von nichtüberlappendem 15 nS 0-Waitstate
Ram. 2 X 32 K Byte Flash EEPROM AT29C256, 2 X 1 K Byte EEPROM AT93C46
- Adressdekodierung: GAL 16V8 mit Tpd = 7 nS, später Tpd = 5 nS
- Codec: CS4215KL (wie EVM). Wer sich schon damit beschäftigt hat: Der
24.576 MHz Quarz ist an der "richtigen" Stelle und es werden die Line-In und
Line-Out Pins benutzt. 16 Bit Auflösung, 2 Kanäle, also Stereo. Sowohl die
DSP CARD 4 als auch die von KC7WW beschriebene Erweiterung des EVM boards
gehen von der Idee aus, damit (nebst einigen digitalen Signalen wie PTT) zwei
Transceiver zu bedienen. Meine Vorstellungen dazu sahen anders aus, nämlich
wie folgt:
- Transceiveranschlüsse: 4 Stück. Ein einzelner Transceiveranschluß besitzt
folgende Signale: NF-In, NF-Out, PTT, UP, DOWN, CAT-OUT, CAT-IN, GND. UP und
DOWN sind für die Ansteuerung entsprechender Frequenz-Up/Down Eingänge am
Transceiver. CAT-OUT und CAT-IN dienen der seriellen Steuerung, wenn diese
vom Transceiver unterstützt wird. Alle digitalen Signale führen zu einem
digitalen Multiplexer, welcher jeweils einen Transceiveranschluß mit der CPU
verbindet. Das gleiche gilt für die analogen Signale, wobei diese über Relais
gemultiplext werden. Hinsichtlich der digitalen Signale ist die Belegung des
CPU Ports B so wie bei der DSP CARD 4, so daß die Portierung von Software
einfach ist. Auf der Transceiverseite sind die Signale auf 8-polige
DIN-Buchsen aufgelegt (TNC-kompatibel). Die analogen Signale werden durch
den Multiplexer prinzipiell mit dem linken I/O Kanal des Codec's verbunden.
Das analoge I/O des rechten Kanals führt zu zwei Chinch-Buchsen auf der Rück-
seite. Der Multiplexer wird durch einen ATMEL AT89C2051 Microcontroller
gesteuert, welcher einen Radio-UP/DOWN Taster auf der Frontplatte überwacht.
Dieser Controller hat sein eigenes EEPROM 93C46, in dem er den gerade
gewählten Transceiver abspeichert. Nach einem Aus- und Einschalten ist der
letzte gewählte Transceiver automatisch wieder der aktive. Der aktive
Transceiver kann vom 56002 sowohl gelesen als auch eingestellt werden. Wird
von Hand der Transceiver gewechselt, so erzeugt der 89C2051 ein Interrupt-
signal für die CPU. Dieser Anordnung liegt folgende Überlegung zugrunde:
Alle Filteranwendungen werden für den rechten Codec-Kanal programmiert und
sind dann über die Chinch-Buchsen einfach mit der Außenwelt zu verbinden.
Alle Modemanwendungen werden für den linken Codec-Kanal programmiert (und
über den Multiplexer an die DIN-Buchsen verteilt). Ein Modemprogramm liest
den gewählten Transceiver aus und sucht sich in einem eigenen EEPROM die dazu
passenden Eingangs- und Ausgangsempfindlichkeiten und stellt diese am Codec
ein. Dieses EEPROM wird einmalig, oder wann immer man es zu verändern wünscht,
mittels eines Setup-Programmes programmiert. Soweit es technisch also
überhaupt möglich ist, sorgt diese Anordnung dafür, daß jedes Modemprogramm
unmittelbar mit jedem Transceiver arbeitet, ohne daß dazu irgendwelche
analogen Einstellungen an Potis oder Trimmern vorgenommen werden müßten. Das
Interruptsignal dient dazu, die CPU darauf hinzuweisen: Achtung, neuer
Transceiver wurde gewählt, bitte die richtigen Parameter am Codec ein-
stellen! Alle digitalen Ausgänge werden über insgesamt drei ULN2803
angesteuert, alle digitalen Eingänge weisen einen Überspannungsschutz bis zu
mehreren hundert V auf.
- Analoges Frontend: 1/2 LT1013 pro Kanal, Eingangsimpedanz 220 K Ohm
Nennempfindlichkeit 2.8 Vpp für Vollaussteuerung, Über einen im Codec
befindlichen Vorvertärker in 1.5 dB Schritten bis auf 280 mVpp einstellbar.
- Analoges Outend: 1/2 LT1013 pro Kanal, Ausgangsimpedanz < 10 Ohm
Maximaler Ausgangshub > 6 Vpp. Über einen im Codec befindlichen Abschwächer
um mehr als 94 dB abschwächbar.
- OnCE port: Vollständig realisiert wie beim EVM, alle hierfür benutzte
Software kann unverändert hiermit benutzt werden. Hierfür war einige Mühe
notwendig. Mein Universal(?)-Programmierer kommt mit dem auf dem EVM
benutzten MC68C705K1 nicht zurecht! Daraufhin wurde der gesamte OnCE code
dieses MOTOROLA-Prozessors in Pascal (Sie lesen richtig) für 80C51 um-
geschrieben. Als OnCE Controller werkelt in EasyDSP ein Atmel AT89C2051.
(Danke nochmals, Hartmut, daß du mich auf diesen Baustein aufmerksam gemacht
hast!) Zusätzlich zu der vom EVM bekannten Led für den Debug mode gibt's noch
eine zweite Led "Once Activity", welche anzeigt, wenn ein Programm mit voller
Geschwindigkeit aber trotzdem unter Kontrolle des OnCE ports abläuft. Die
9-polige SubminD Buchse des OnCe-Ports sitzt übrigens auf der Frontplatte, so
daß man EasyDSP mit allen rückseitigen Kabeln verbunden an seinem üblichen
Platz stehen lassen kann und für Debugzwecke bequem von vorne einen Stecker
einsteckt. Nebenbei: Da der OnCE code jetzt in PASCAL vorliegt, ist er
wirklich einfach zu überschauen und abzuändern, wenn das mal notwendig sein
sollte. Das kann man vom Original nicht behaupten. Der Autor des Originals
schreibt über sein Programm: "By the way, I'll mention that this code will
probably a nightmare to maintain and extend. Good luck :-)". Da der 89C2051
über einen richtigen UART verfügt und ihn nicht per Software nachbilden muß,
sind für den OnCE-Port auch höhere Baudraten bis zu 57600 Bd denkbar, wenn
die PC-Debugsoftware dies zuläßt.
- Modes: Es gibt zwei prinzipiell unterschiedliche Betriebsmodes von EasyDSP,
welche über einen Schalter auf der Frontplatte ausgewählt werden: Den DF6JB-
Mode und den KC7WW-Mode. Einzelheiten dazu weiter unten. Hier sei nur darauf
hingewiesen, daß der AT89C2051, welcher den OnCE port überwacht, sich auch
noch um diesen Schalter kümmert. Wenn nämlich der Mode gewechselt wird, so
ist i.A. ein Neubooten der CPU aus dem "richtigen" EEPROM notwendig. Der
89C2051 erzeugt das dafür notwendige Reset-Signal, außer, wenn wir gerade in
einer Debugsitzung sind, wo das gerade nicht erwünscht wäre.
- RS232: Datenleitungen sowie a l l e Handshakeleitungen werden angesteuert
über einen MAX237. Die TTL-Leitungen diese Bausteins sind nicht unmittelbar
an die CPU geführt sondern an ein dickes Gal (AMD Mach210), welches auf dem
schnellen CPU-Bus aufsetzt. Dieses Gal sorgt dafür, daß nicht nur prinzipiell
alle Hanshakeleitungen angesteuert werden, sondern daß auch das bei vielen
Programmen beliebte "Multiplexen" möglich ist. Über RTS und DTR als
Multiplexsignal können solche Programme hintereinander 4 X 4 Bit parallel
einlesen. Dies bezieht sich auf den DF6JB Mode. Im KC7WW mode sorgt das Gal
hingegen dafür daß die Schnittstellenbelegung mit PC3 und PB12 der Empfehlung
ALEFNUL Gruppe folgt und DSP CARD 4 kompatibel ist. Was mir an der DSP CARD 4
überhaupt nicht gefiel: Wenn vom PC über die normale RS232-Verbindung (also
nicht über den OnCE-Port) ein Reset des 56002 ausgelöst werden soll, so ist
es notwendig, einen bestimmten Befehl zu schicken. Dieser Befehl muß von dem
gerade aktiven Programm erkannt werden und die CPU in einen "Sleep" Modus
versetzen, so daß nun der externe Watchdog anspricht und den Hardwarereset
erzeugt. Ich denke: Wenn ich den DSP resetten will, dann möglicherweise doch
gerade deswegen, weil das gegenwärtige Programm Unsinn macht und daher den
entsprechenden Befehl gar nicht dekodieren kann! Also habe ich mir eine
andere Möglichkeit ausgedacht: Serielle Sendeleitung PC->EasyDSP in den
"Break"-Zustand versetzen und während der Break aktiv ist, acht mal die
DTR Leitung toggeln. Diese Konstellation kommt normalerweise nie ungewollt
vor und ist deshalb ein geeignetes Merkmal zum Auslösen eines Reset. Die
Detektion dieser Konstellation findet in einem der Gals statt.
- Gehäuse: Lansing Inc., USA, Werbespruch: "If i hadn't a circuit to put in
i would design one... Sieht wirklich gut aus, kostet aber leider auch etliche
US $. "Dicht" im Sinne der CE Kennzeichnung oder erst recht unter den viel
größeren Anforderungen in einem Amateurfunkshack ist dieses Gehäuse nicht.
Da ich "Dichtigkeit" mittlerweile für sehr wesentlich halte, befinden sich
innerhalb des "äußeren" Gehäuses noch zwei vollkommen dichte Abschirmgehäuse,
eines für den Analogteil, das zweite für den Digitalteil. Da HF-Müll fast
immer auch von den Kabeln abgestrahlt wird, die mit schneller Elektronik
verbunden sind, ist jede einzelne Leitung, welche eine Verbindung nach außen
darstellt (und das sind einige!) mit einem MURATA L-C-L T-Filter verblockt.
- Platine: Abmessungen 7" X 9", minimal 4 Layer, möglicherweise aber auch 6.
Das muß ich so formulieren, weil die Platine noch nicht fertig ist.
- Anzeigen/Bedienelemente: 1 X LED "Debug Mode", 1 X LED "OnCE Activity",
1 X LED "PLL-Lock", 4 X LED "Radio 1-4", 1 X Taster "Radio Up/Down",
1 X LED "PTT", 1 X LED "CMD", 1 X LED "Heartbeat" (die beiden letzten aus
Gründen der Kompatibilität zur DSP CARD 4), 1 X Umschalter "Mode".
- Gegenwärtiger Entwicklungsstand Hardware: Die Schaltung an sich steht. Wenn
sich auf den ersten Musterplatinen nicht ernsthafte Probleme ergeben sollten,
so wird die Schaltung in dieser Form bestehen bleiben. Die Schaltungs-
unterlagen befinden sich derzeit bei einem Profi-Layouter, von dem ich
irgendwann im April '95 die fertigen Layouts zurückbekomme. Musterplatinen
dauern auch noch etwas, also würde ich sagen: Zum Jahresende hin könnte es
mit den ersten Geräten etwas werden.
- Gegenwärtiger Entwicklungsstand Software: Für den DF6JB Mode gibt es
derzeitig einen seriellen Urlader (im EEPROM), welcher nach einem Reset aktiv
wird. Der Download benötigt Files im .LOD Format und funktioniert mit
115.2 K Bd (etwa 10-15 mal so schnell wie über OnCE). Typische Ladezeiten,
z.B. ein SSTV Modem für JVFAX, liegen bei ca. 2 Sekunden. Für FIR Filter-
anwendungen existiert ein Programm-Grundgerüst, welches hinsichtlich der Zahl
der benutzten Taps individuell konfiguriert und neu assembliert werden muß.
Die notwendigen Filterkoeffizienten werden von einem von mir geschriebenen
Windows-Programm berechnet (sehr einfach in der Bedienung). Bei Modems habe
ich mich ein wenig auf solche für JVFAX konzentriert. AM- FM-FAX sowie SSTV
sind empfangsseitig realisiert. Sendeseitig liegt derzeit noch nichts vor.
Insbesonders fehlt auch noch die automatische Anpassung an die Transceiver-
eigenschaften nach der weiter oben beschriebenen Methode. Für den KC7WW Mode
müssen noch Anpassungsarbeiten am Monitorprogramm durchgeführt werden. Sind
diese abgeschlossen, so sollte folgende Software unmittelbar ablauffähig
sein: Hf-RTTY/AMTOR/PACTOR, 1200 Bd KISS TNC, 9600 Bd G3RUH KISS TNC, einige
Denoiser-Programme sowie ein korrelationsbasiertes CW-Filter. Bitte beachten:
Auch diese Software "kennt" die Transceiverauswahl noch nicht und muß in
dieser Hinsicht überarbeitet werden. Es kommt also noch viele Arbeit auf die
Software-Entwickler zu. (Ich kenn da zwar auch ein wenig von, betrachte mich
aber im Gegensatz zu den "Softies" eher als "Hardy-Boy")
- Firmware-Updates: Da die Firmware in zwei Flash EEPROMS abgelegt ist,
wird für einen Update kein Austausch oder "Brennen" eines Bauteiles auf
einem externen Programmiergerät notwendig sein. Man wird einen Update
"in situ" seriell vom PC aus durchführen können.
Jarkko hat das ganze "ein massives Design" genannt, und ich denke, er hat
recht! Johan meinte "That's a winner", aber das muß sich wohl erst noch
herausstellen!
Wer sich für das Teil interessiert oder, was noch interessanter ist, selber
Software für diesen Kasten entwickeln will, dem schicke ich gegen Einsendung
eines mit DM 3.00 freigemachten SASE im Format DIN C5 gerne die Schaltungs-
unterlagen zu (10 Blätter DIN A 4).
Des Autors Daten:
Ulrich Bangert, DF6JB @ DB0CL
Ortholzer Weg 1
D-27243 Gross Ippener
Tel & Fax 04224-431
E-Mail:101530,1426@COMPUSERVE.COM
73's an alle DSP'ler wünscht Ulli, DF6JB
Read previous mail | Read next mail
| |
