Und noch ein Erweiterungsboard

Da es scheinbar noch nicht genügend verschiedene Erweiterungsboards für den VDR gibt , habe ich auch mal einen Prototypen gebaut.

Die Features:

• LCD-Anzeige von Uhrzeit und Datum (batteriegepuffert) bei ausgeschaltetem VDR, Graphlcd-Anzeige bei eingeschaltetem Zustand
• LCD-Hintergrundbeleuchtung wird der Umgebungshelligkeit angepasst
• Bedienung des VDR sowohl durch Fernbedienung als auch durch Drucktasten am Gerät möglich
• Einschalten des VDR durch Fernbedienung, Gerätetaster oder Real-Time-Clock (Timergesteuerte Aufnahme)
• SCART-Anschluss von J2
• Audio-Ausgänge von J2 (analog, digital optisch, digital coaxial)
• Aufspielen neuer Firmware im Betrieb
• Anschluss der Erweiterungsplatine über ein einziges USB-Kabel
• Alle Schematics, Layouts und Software werden frei verfügbar sein (je nach Nachfrage)

Nährere Informationen und Bilder gibt es hier:
Infos zum VDR-Erweiterungsboard

Dankeschön. Geätzte Platinen sind eigentlich kein Problem, habe ja auch einfach die Eagle-Files zu nem PCB-Hersteller geschickt und die fertigen lassen.
Vom Preis her war mein Prototyp plus LCD-Display plus Frontplatte natürlich etwas teurer als andere Erweiterungsboards, habe aber gemerkt, dass ich einige Bauteile überhaupt nicht brauche (z.B. EEPROM, Serielle Schnittstelle, Reset-Relays,...) und jemand natürlich auf solche Spässe wie Tastenmatrix verzichten kann.
Dadurch und durch größere Stückzahlen bei der Fertigung kann der Preis natürlich sehr gedrückt werden (ich behaupte mal einfach so zwischen 70 und 100€).

Unregistered: Nicht beruflich, mache das nur, weil es beim Doktorarbeitschreiben so viel anderes wichtigeres zu tun gibt Hatte als Assi bei nem Lehrstuhl für Informatik in Praktika mal öfters mit so Sachen zu tun und wollte nun selber mal etwas bauen.

Bin gerade noch dabei, die Software (Daemon) etwas zu überarbeiten, da scheint es noch ein paar Bugs zu geben.

Ja, ist einiges drauf auf der Platine, was eigentlich unnötig ist. Dachte aber, dass ich zu Debug- und Erweiterungszwecken z.B. eine Serielle Schnittstelle und nen SPI-Connector mit drauf baue. Auch das Reset-Relais ist für die Hühner (bei mir überhaupt nicht angeschlossen). Das EEPROM für den USB-Transceiver braucht man auch nicht.
Die RTC hätte man sich zwar auch sparen und den ATMega128 die Zeitrechnung übernehmen lassen können, ich wollte aber das Datum mit Monaten und Schaltjahren nicht selber ausrechnen und ausserdem wird durch das SuperCap-Backup auch bei Stromverlust die RTC mit Spannung versorgt (hält mindestens 3 Wochen ohne Stromanschluss, länger habe ich es noch nicht ausprobiert) und zählt so schön ihre Zeit / Datum weiter.
Mit der Alarm-Funktion der RTC kann man unabhängig vom Motherboard bzw. Bios und dessen NVRAM-Unterstützung das Hochfahren des Rechners für Aufnahmen garantieren.
Das war z.B. bei meinem Motherboard immer ein Problem (Neustart erforderlich usw.)...

s.lipkow: Die Idee hinter den Tasten war eigentlich, dass ich das ganze als CD/MP3-Player Ersatz auf Parties mitschleifen kann und wie gewohnt CDs und die MP3-Sammlung damit ohne Fernbedienung abspielen kann.

Ja, zur Zeit wird ausschließlich der T6963C unterstützt.
Für andere Displays müsste man sowohl den Microcontroller-Code als auch den GraphLCD-Library-Code anpassen, was mir aber nicht möglich ist, da ich eben nur dieses eine T6963C-Display besitze. Ich denke aber, dass einfach ein paar kleine Funktionen abgeändert werden müssten, also nicht weiter tragisch.

Bezüglich Timing (ich verstehe jetzt unter Timing mal die USB-Kommunikation, der Rest ist eh unkritisch):
Die paar Tasten/Fernbedienungsevents über USB fallen nicht weiter auf. Problematischer sind die GLCD-Daten vom VDR, da der meistens ein Fullscreen-Refresh fährt (5KB, die durch das Daemon-Frontend Protokoll noch auf ca 10KB aufgebläht werden. Datenabhängig sind es noch mehr, da bestimmte Zeichen escaped werden müssen, um nicht als Befehl interpretiert zu werden). Da USB-Fullspeed jedoch bis zu 1,5MB/s an Datenrate bietet, ist das bei einem Display-Refresh von ca. 5 mal pro Sekunde auch kein Problem.
Dann kommen noch ein paar Datenpakete vom Rechner zum Frontend (z.B. Switch To Standby, Set Alarm,...), welche aber auch nicht nennenswert sind.

Sicher würde das gehen. Allerdings ist es wahrscheinlich so, dass jeder gerne eine etwas andere Konfiguration hätte:
- mit/ohne IR-Einschalter bzw. Fernbedienungserkennung
- mit/ohne Helligkeitsregelung
- mit/ohne Audioausgänge
- mit/ohne SCART
- mit/ohne Tastenfeld
Leider läßt sich das Design nicht für jede dieser Konfigurationen einfach so anpassen bzw. es gäbe für bestimmte Konfigurationen viel einfachere und bessere Lösungen.

Beispielsweise wäre es für eine reine Standby-Display-Geschichte besser, direkt den Parallel-Port des Rechners an den ATMega128 zu hängen bzw. mit einem Multiplexer zwischen dem Parallel-Port und dem ATMega128 einfach umzuschalten. Dann bräuchte man auch keine Änderung des GraphLCD-Treibers. Die Kommunikation mit dem Rechner würde ich dann per serieller Schnittstelle machen. In meiner Konfiguration ist es aber so, dass ich aufgrund des USB-Chips und den Tastern nicht genügend freie IO-Pins am ATMega128 mehr habe, um den Parallelport des Rechners auch noch dran zu hängen.

Wie gesagt: Falls Interesse besteht, kann ich die Schematics, Layouts und die Software (Quellcode) zum Download anbieten und jeder kann sich daraus basteln, was er genau benötigt. Für Fragen dazu stehe ich selbstverständlich zur Verfügung.
Wenn von vielen Leuten eine bestimmte Konfiguration favorisiert wird, werde ich diese gerne bauen, aber ich habe weder Lust noch Zeit, für jeden Wunsch ein individuelles Design zu basteln. Dafür ist es ja frei verfügbar...

Schon klar, deswegen hatte ich es auch mit draufgebaut.
Die Linux-Treiber funktionieren aber auch ohne die Personalisierung per EEPROM und da ich im Normalbetrieb die Bootmessages nicht mitlese, brauche ich auch keine personalisierte Plugin-Message
Bei Windows weiß ich nicht, wie es mit der Erkennung aussieht.
Da ich den VDR und die Erweiterung ausschliesslich unter Linux betreibe (wie wahrscheinlich die meisten hier), ist es einfach so, daß ich das EEPROM nicht benötige und es bei einem kommenden Design einfach weglassen würde...

Der 2560 sieht gut aus, da könnte man dann direkt den Parallelport an den Microcontroller hängen.
Vorteil:
- Keine Änderung der Graphlcd-Lib notwendig, Unabhängigkeit vom verwendeten LCD (solange es über den Parallelport angesteuert wird)
Nachteil:
- Zusätzliches Kabel vom Parallelport zum Erweiterungsboard notwendig, welches man entweder über einen Schlitz im Gehäuse wieder nach innen führen müsste oder man baut noch nen Connector ins Gehäuse ein. Auf dem Board selbst ist auf der Anschlussseite kein Platz mehr, da die SCART-Buchse fast die gesamte Boardbreite benötigt. Ich fand halt die Lösung über ein einziges USB-Kabel (evtl. sogar intern) relativ sauber.

TQFP100 zu löten ist mit Lötstopplack kein Problem (IMHO auch für Anfänger):
Einfach etwas Lötleitpaste auf die Pads, leicht vorverzinnen, IC draufdrücken und mit nem dicken fetten Lötkolben kurz mal quer über alle Pins fahren. Eventuelle Brücken einfach mit Entlötlitze absaugen. Klingt brutal, funktioniert aber prima.

Aufgrund mehrerer anderer Projekte habe ich leider keine Zeit, die µC-Code auf dein Display anzupassen.
Ist aber keine Magie: Einfach mal mit dem LCD-Datenblatt hinsetzen und schauen, welcher Pin für was gut ist bzw. welche Befehle es versteht. IMHO funktionieren die meisten Display-Controller relativ ähnlich, d.h. es geht nur um ein paar kleine Anpassungen im Code (z.B. Befehlsopcodes, Initialisierung, Breite/Höhe,...).
Im Oktober habe ich wieder etwas mehr Luft, dann könntest Du mich nochmal anhauen...

Gruß,
Pert