Analog TFT Controller?!

tja, dann füttere doch mal unsere Krisatallkugeln mit den Aausgangsdaten 
oder sind die geheim?

Es scheint einen RGB Eingang zu haben. Wenn du die Pixel da schnell 
genug hineinbringst... Ich wuerd mir erst mal Sogen ueber den Speicher 
machen.
Du wirst das ganze Bild abspeichern muessen und repetitiv reinladen. die 
4k des Mega32 reichen da nicht aus. Je nach Format des TFT musste ein 
paar MByte bringen. 3 Byte pro pixel. Mal die Anzahl der Pixel. 
Moeglicherweise ist 4 byte pro pixel einfach zum ansteuern.

Und erst mal das ganze Datenblatt konsultieren. Ein Bild ausgeben ist 
eher eine Sache fuer einen FPGA, wie fuer einen Mega32

> Es schein einen RGB Eingang zu haben. Wenn du die Pixel das schnell
> genug hineinbringst...

Du mußt das analoge Signal im Wechsel der Taktsignale auch noch 
invertieren. Pixeltakt bitte mal ausrechnen und sich wundern ... das 
Bild muß ständig neu geschrieben werden.

Einen Ansatz einer Lösung gibt es im Sonderheft der c't, 
Hardwarehacks(?). Dort werden mit einem "Vielzeller" (FPGA wars nach 
meiner Erinnerung) die Taktsignale abgelauscht und zu denen passend mit 
einem R2R-DA-Wandler die analogen Signale eingespeist. Ein Riesenaufwand 
und sicher nicht mit einem ATMega zu lösen.

tja sieht aus wie ein RGB Monitor mit ein paar Extras

achja ist nur pseudo anaolog (diskrete luminanz pegel am RGB signal) 
aber was ist sonst noch in dem Bilderrahmen verbaut?

Da muss noch etwas zwischen Videospeicher und Display sein, das sollte 
ein prozessor/interface sein welcher den Speicher ausliest und das 
Timing  sowie die 3 DAC abwickelt.

[ot]
beim 8 bit ATARi waren das mal 2 Chips ANTIC und GTIA
[/ot]

Nach der Lektüre der c't Hacks habe ich überlegt, ob man mit dem 10Mhz 
Pixeltakt nicht direkt den AVR takten könnte. Dann hätte man das Timing 
und müsste mit dem AVR 'nur' die Sync Signale und ein einfaches RGB 
erzeugen ( z.b. mit modifizierter AVGA library) . Wenn mir son Dings mal 
in die Hände fälltprobier ichs jedenfalls mal aus. Die FPGA Lösung der 
c't fällt hier flach, da keine Tools.

10MHz Pixeltakt ist am unteren Ende, dazu spaeter. Das bedeutet 3 byte 
ausm Speicher holen und in die 3 DACs schieben. Dann die Adresse 
erhoehen und allenfalls den Zeilen, oder Seitenumbruch. Eine Vielzahl an 
Operationen.

10MHz Pixeltakt ... nehmen wir einen kleinen TFT von 640x480. Das waeren 
dann 370kPixel. Der Gesammtrefresh waere dann mit ca 30Hz. Macht der TFT 
das ?

Hab mir jetzt den Artikel nochmal rausgesucht. Also, der Hi1018 
generiert ca. 10Mhz Pixeltakt, ein VCOM-Display AC signal, sowie HSTART 
mit ca 14.7 kHz und VSTART mit ca. 30Hz. Die Signale gehen an das c't 
FPGA.

Das verwendete Display bei denen ist ein Typhoon 7" mit 480*234 Punkten. 
Wenn ich mir AVR Mario dagegen angucke ( RGB Spiel für den ATMega 88/168 
) sollte es eigentlich möglich sein, einen Mega statt des FPGA zunehmen. 
Ok, die Signale könnten um die 0.2 uSec jittern wegen der INT 
Reaktionzeit bei 10 Mhz. Wird sich zeigen, ob man das sieht.

Also die Mega88168 haben kein externes RAM Interface. Nimm einem mit 
externem RAM Interface und die ADC sind auch Adress extern 
Adress-gemapt.

Dann musst du pro pixel 3 byte lesen, 3 byte schreiben, die Adresse 
erhoehen, schauen, ob die Zeile voll ist, und falls, ob die seite voll 
ist. Dann kommste vielleicht auf Clock div 10. Bedeutet, fuer 10MHz 
Pixelclock braucht man 100MHz Clock.

Ich bin auch mit einem Graphikdisplay beschaeftigt, probier's aber gar 
nicht erst mit was Kleinerem wie einem AVR32UC3. Der kann 66MHz und 
schaufelt gleich 32 bit auf's Mal.