Wie bereits erwähnt, wird die Platine von Thomas Kindler als eigentlicher Player verwendet. Diese enthält den IPC@CHIP, den MP3-Decoder (VS1001 von VLSI) mit Audio-Ausgang und das IDE-Interface für die Festplatte. Weiter ist auf der Platine ein Infrarot-Empfänger zur Fernsteuerung vorgesehen. Diesen habe ich allerdings nicht eingebaut, da man den Player (oder zumindest den Empfänger) sonst sichtbar montieren müsste, was ich nicht wollte.
Es hat sich weiter herausgestellt, dass die serielle Schnittstelle ohne DMA viele Empfangsfehler produziert. Die beiden DMA-Kanäle des @CHIP werden aber bereits für den mp3-Dekoder und den IR-Empfänger verwendet. Da ich aber den Infrarot-Port nicht verwende, konnte ich den DMA-Kanal des VS1001 umlegen, sodass nun der Empfang über DMA für die EXT-Schnittstelle möglich ist. Dazu habe ich auf der Platine die Leitung von Beck-Pin 31 zu Lattice-Pin 8 (RC_DMARQ) aufgetrennt und die Beck-Pins 31 und 30 verbunden. Besser wäre es aber gewesen, den Lattice-Baustein umzuprogrammieren.
Die zweite Platine enthält einen Spannungsregler (5V-Schaltregler) zur Versorgung der Hauptplatine und der Festplatte, einen MAX232 zur Pegelwandlung für die serielle Schnittstelle und einen Microcontroller (Microchip PIC16F628), welcher das Protokoll zum Autoradio hin abwickelt und den eigentlichen Player per Relais ein- und ausschalten kann (vom Radio gesteuert).
Dieser Schaltungsteil basiert auf dem GNUnilink-Projekt von Simon Wood. Ich habe einige Änderungen vorgenommen, damit der Chip mit meinem Becker Mexico Pro zurechtkommt (GNUnilink wurde für Sony-Radios entwickelt). Der Player wird vom Autoradio als MD-Wechsler angesprochen, d.h. es können Disk-Namen angezeigt werden.
Die Kommunikation zum IPC@CHIP erfolgt per serieller Schnittstelle, allerdings ist das Protokoll gegenüber GNUnilink komplett geändert. Dies war nötig, da am @CHIP keine serielle Schnittstelle verfügbar war: die erste wird nach außen geführt, die Pins der zweiten Schnittstelle sind leider bereits auf der Hauptplatine mit anderen Funktionen belegt. Daher habe ich für den @CHIP Routinen entworfen, die eine serielle Schnittstelle per Software emulieren. Die Übertragung ist allerdings etwas fehleranfälliger als mit einem "echten" (Hardware-) UART, sodass sie ohne Fehlererkennung nicht anzuwenden war. Besser wäre sicher, einen der Hardware-UARTs des @CHIP zu nutzen, dazu müsste man aber entweder auf die externe Schnittstelle verzichten oder die Platine neu entwerfen (falls die Pins überhaupt anders belegt werden können, ich habe das nicht näher untersucht). Eine weitere Möglichkeit wäre der Einsatz eines PIC mit I2C-Slave-Schnittstelle; der @CHIP kann an beliebigen Pins als I2C-Master agieren (zwar auch nur in Software, das I2C-Protokoll ist aber im Gegensatz zum asynchronen seriellen Protokoll gut in Software abzubilden). Beispielsweise der PIC16F818, der aber kaum in Einzelstücken zu bekommen ist. Die Software-Schnittstelle kann aber durchaus eingesetzt werden, mit der Fehlererkennung arbeitet sie ausreichend stabil.
→ Cleggy's Unilink pages - Weitere Informationen zum Unilink-Protokoll (inoffiziell)
Das Gehäuse habe ich bei der Firma Schaeffer Apparatebau KG fertigen lassen. Es besteht neben den Seitenprofilen aus vier Alu-Platten: Vorder- und Rückseite mit den Durchbrüchen und Beschriftungen sowie der Deckel- und Bodenplatte. An der Bodenplatte sind Gewindehülsen (M3 / 4mm) angebracht, um die Platinen befestigen zu können. Die Festplatte habe ich mit Abstandshülsen (15 mm) und Alu-Winkeln direkt oberhalb der Hauptplatine montiert.
