|
|
|
proSTU - oder meine derzeitige Bastelei ;-)
 |
Als ich vor einiger Zeit meinen alten analogen Satelliten-Receiver - ein Philips STU560 - mal wieder in Betrieb nehmen wollte, musste ich feststellen, dass dieser sich im wahrsten Sinne des Wortes totgestanden hatte. Also griff ich zum Schraubendreher und öffnete den Receiver, um ihn zu reparieren, was sich letztendlich auch als recht einfach erwiess. Ein Elko im Netzteil war taub.
|
 |
Nun stand dieser Receiver so offen vor mir und diverse recht interessante Hardware schrie förmlich danach, neu programmiert werden zu wollen. Fuer einen analogen Receiver befindet sich eine Menge Hardware im Geraet, was wohl auch den recht hohen Preis erklaert (um die 250,- Euro), den ich beim Kauf im Jahre 1995 bezahlen mußte. Welche Hardware ist das nun im einzelnen ? Die Steuerung uebernimmt ein mit 12MHz getakteter 8 bit Controller vom Typ i8032 aus dem Hause Intel. Diese MCU kann auf externe 64KB* ROM, 2KB RAM und 8KB EEPROM zugreifen. Fuer etwas Komfort sorgt eine Echtzeituhr vom Typ PCF8573 aus dem Hause Philips. Die Kommunikation mit dem Anwender wird durch einen OSD-Generator vom Typ STV5730 (ST Microsystems), einem zehnstelligen VF-Diplay mit diversen zusaetzlichen Symbolen und einer auf RC5 basierenden Fernbedienung realisiert. Ein per I2C-Bus programierbarer Synthesizer-Tuner basierend auf einer TSA5055 sorgt fuer die ZF-Aufbereitung und -Abstimmung im Frequezbereich von 920 bis 2050 MHz. Das vom Tuner gelieferte Basisbandsignal wird einem TDA8012 (Video) und einem MSP3400B von Micronas (Audio) zu Demodulation zugefuehrt. Desweiteren finden sich in diesem Receiver noch eine freikonfigurierbare Video-Kreuzmatrix, eine RGB-Matrix und ein 5 Band Euqalizer.
* In Wirklichkeit steckt ein 128KB EPROM (27C1001) im Receiver, allerdings kann die MCU nur 64KB direkt addressieren. Es kann zwar per Software zwischen 2 Speicherbaenken umgeschaltet werden, allerdings funktioniert das auch nur bedingt, da die MCU dem Programmcode direkt aus dem EPROM abarbeitet.
|
 |
Aufgrund der "unkritischen" Hardware war es nicht schwer, die einzelnen Datenblaetter zu bekommen. Lediglich fuer den bisher noch unerwaehnten synthesizerbasierenden UHF-Modulator konnte ich bisher kein Datenblatt auftreiben. Um die ganze Hardware aber zu programmieren, waere es nicht schlecht, den Schaltplan des Receivers griffbereit zu haben. Auch dieses Problem war schnell geloest. Ein Anruf beim Schaltungsdienst Lange genuegte, um 2 Tage spaeter das komplette Service Manual in den Haenden zu halten. Nun konnte es also losgehen mit der Programmierung - voellig planlos natuerlich *g* Und schon entstand das naechte Problem. Ich musste mir die Frage stellen, wie ich denn programmieren will. Ein kurzer Blick in das Internet verraet sehr schnell, dass es für die MCU eine Unmenge an Programmierumgebungen gibt. Vom klassischen Assembler bis hin zu Hochsprachen wie C und Pascal ist alles als Freeware, Shareware und komerzielles Produkt erhaeltlich. Also musste ich die Ueberlegung etwas anders fuehren... In welcher Programmiersprache macht es ueberhaupt Sinn ? Schnell stand der Entschluss fest, dass es Assembler sein muß. Hochsprachen sind zwar komfortabler als Assembler, produzieren aber eine Menge unnötigen Overheads im compilierten Programm. Auf der Suche nach einem geeigneten Assembler bin ich dann auf "ASEM-51" gestossen. Genau das hab ich gesucht. Also dann, auf an's Werk. Nur sollte man dann auch Assembler beherrschen. Ich entschied mich fuer den Weg "Learning by doing" und mittlerweile komm ich auch ohne Literatur mit dem Befehlssatz und den Eigenheiten der MCU klar.
|
 |
Nun, wo faengt man mit der Programmierung eines Betriebsystems fuer einen Satelliten-Receiver an ? Die MCU bietet keinerlei Debug-Moeglichkeiten. Einen BDM-Anschluss sucht man vergebens. Also muß erstmal ein minimalistisches Userinterface geschaffen werden. Dazu bietet sich die Fernbedienung und das VF-Display foermlich an. Die Ansteuerung des Displays gestaltet sich recht einfach ueber eine synchrone serielle Schnittstelle. Nur die Tatsache das der Displaycontroller (NEC uPD16311) keinen eigenen Zeichengenerator besitzt, erschwert die Textausgabe etwas, da die Software erst jeden Buchstaben und jede Ziffer aus einem eigenen Zeichensatz generieren muß.
|
 |
Im naechsten Schritt waere es nicht falsch, das Userinterface zu erweitern. Warum nicht die Hardware nutzen, die vorhanden ist ? Also auf an's Werk und den OSD-Generator in Betrieb nehmen. Vorher aber nicht vergessen die Video- und die RGB-Matrix richtig zu initialisieren. So sieht das OSD also aus, wenn man den Generator gemaeß Datenblatt initialisiert. Nur das die 308 Byte Video-RAM dabei nicht in einen definierten Zustand gebracht werden, das steht nirgendwo im Datenblatt. Nungut, also noch eine zusaetzliche Schleife programmieren, die den Video-RAM initialisiert. Der OSD-Controller beschert uns uebrigens fuer heutige Verhaeltnisse laecherliche 11 Textzeilen mit 28 Zeichen je Zeile. Immerhin enthaelt der OSD-Controller einen Zeichengenerator mit einem Vorat von 128 Zeichen. Die farbliche Gestaltung laesst auch zu wuenschen uebrig, da der Controller nur 8 Farben kennt. Die Hardwareentwickler des Receivers waren dann auch noch so "intelligent", die Anzahl der Textfarben auf drei zu begrenzen (schwarz, weiß und blau).
|
 |
Et voila. Ich hab ein brauchbares Interface zum debuggen. Den Rechtschreibfehler uebersehen wir einfach mal *g* OK, der OSD-Generator läuft nun so, wie ich es will, nur die Fernbedienung will noch nicht so ganz. Bis dato habe ich hier auf eine fertige Routine aus dem Internet zuruekgegriffen. Diese funktioniert mit den meißten Tasten ja auch, nur so elementare Tasten wie die Cursor-Tasten und die OK-Taste kann diese Routine nicht auswerten. Modifikationen an der Routine brachten nicht den gewuenschten Erfolg. Irgendeine Taste war immer nicht auswertbar. Also blieb mir nichts anderes uebrig, auch hier alles neu zu machen. Herausgekommen ist dabei eine Routine, die nicht nur den anfaenglichen Wunsch nach Auswertung aller Tasten erfuellt, sondern gleich noch eine Bitfehlerueberpruefung durchfuehrt, was Fehlreaktionen der Software eliminiert.
|
 |
Es wurde Zeit, sich mit dem Tuner zu beschaeftigen. Neben den ueblichen Moeglichkeiten zum setzen der ZF-Frequenz, der 14/18V Steuerung (Polarisation) und der 22KHz Steurung (Lo-/Hiband Umschaltung) werden auch die Extras des Tuners genutzt. So hat dieser zwei ZF-Eingaenge, zwischen denen umgeschaltet werden kann und auch die ZF-Bandbreite kann zwischen 27MHz (ASTRA) und 32MHz (Eutelsat u.a.) eingestellt werden. Als besonderes Schmankerl - und daraf bin ich besonders Stolz, weil es die Original-Software nicht kann - funktioniert auch DiSEqC. Das beschraenkt sich zwar auf DiSEqC 1.0 (committed switches mit 4 Eingaengen) und Mini-DiSEqC (2 Eingaenge), aber somit lassen sich schonmal 8 LNB's direkt schalten.
|
 |
Der MSP3400 Audio-Demodulator/-Prozessor. Dies war einer der Hauptgruende, warum ich mich jetzt mit dem Receiver beschaeftige. Dieser Signalprozessor hat ein I2S-Interface, was es erlaubt, weitere Signalprozessoren anzuschließen. Dazu passend gibt es fuer run 35,- Euro einen ADR-Dekoderchip (ADR = Astra DigitalRadio), der ueber dieses I2S-Interface angeschlossen werden kann. Leider ist es so, dass im Receiver die B-Revision des MSP3400 verbaut wurde. Glaubt man den Datenblaettern, funktioniert ADR erst zusammen mit der neueren C-Revision des Chips. Dennoch werde ich das demnaechst mal ausprobieren. Wie heisst es so schoen ? Versuch macht klug. Was kann dieser Chip aber nun von Haus aus ? Erstmal demoduliert er ein bzw. 2 voneinander unabhaengige Tontraeger. Einer der beiden Tontraeger darf dabei, wenn auch fuer Satellitenempfang eher unüblich, ein amplitudenmodulierter Traeger sein. Der Chip erlaubt fuer jeden der beiden Tontraeger frei programmierbare Bandbreiten und beherrscht alle gaengigen Enzerrungen (50us, 75us, J17 und Wegener Panda 1). Der Chip ist auch fuer die Lautstaerkeregelung zustaendig und enthaelt die komplette Audio-Matrix. Die Lautstaerke laeßt sich fuer jeden Ausgang getrennt regeln, so dass z.B. die VCR-SCART-Buchse eine andere Lautstaerke haben kann als die TV-SCART-Buchse. Das gleiche gilt fuer die Balance. Uebrigens, die beiden Balken rechts im Bild sind eine kleine Spielerei. Sie stellen ein funktionsfaehiges Stereo-Levelmeter dar. Es stellt generell erstmal einen Leistungstest fuer die Hardware dar. Die 8 bit MCU muss hier 16 bit Werte umrechnen und diese als ASCII-Grafik aufbereitet ständig an den OSD-Controller senden.
|
 |
Und so sieht es nun aus, das derzeitige Haupmenue. Wie zu erkennen ist, arbeitet das Menue genauso wie in der Originalsoftware mit einem Scrollbalken. Auf eine Steuerung mit Zifferntasten hab ich bewusst verzichtet, da die dann anzuzeigenden Ziffern kostbaren Platz auf der verfuegbaren OSD-Flaeche benoetigen. Hinter den Menue-Eintraegen selbst verbirgt sich noch nicht sonderlich viel. Lediglich unter dem Punkt "Applications" verbirgt sich ein RC5-Dekoder, also ein Anwendung, welche die Befehle einer jeden auf RC5 basierenden Fernbedienung anzeigt (alle Geraete von Philips, diverse Geraete von Loewe und anderen Herstellern). Das ganze Menuesystem ist zweisprachig realisiert. Man kann also per Fernbedienung zwischen einer Primaer- und einer Sekundaersprache waelen.
|
Nun kann man sich die Frage stellen, warum ich das mache, warum ich fuer solch alte Hardware ein eigenes Betriebsystem programmiere. Nun, wie ich schon erwaehnte, hat es mir insbesondere der MSP3400 angetan. Wenn ich den ADR-Dekoderchip daran zum laufen bekomme, bin ich fuer's erste gluecklich, denn fuer den pris des Chips bekommt man keinen ADR-Receiver zu kaufen. Das ist natuerlich nicht alles. Die Hardware stellt eine gute Grundlage, um in die Assembler- und embedded system Programmierung einzusteigen. Geplant habe ich, den Receiver noch mit einer seriellen Schnittstelle auszurüsten. Der Hardwareaufwand beschränkt sich dabei auf eine klassische pegelwandlung mit den allseits bekannten MAX232. Über diese Schnittstelle liessen sich dann die Settings am PC bearbeiten und - was mich viel mehr reizt - liesse sich ein recht flinker Spectrumanalyser realisieren.
letzte Änderung: 12. Januar 2002
|
