Hallo !
Ich würde gerne wissen ob es möglich ist einen Mikrocontroller
(ATMEGA128 z.B.) direkt mit einem TFT (QVGA) Farbdisplay zu verbinden?
Spricht da etwas gegen?
Die Voraussetzung ist natürlich das beide ein SPI Interface besitzen!
Geht so etwas oder muss die SPI des Mikrocontrollers mit einem
Grafikcontroller verbunden werden und die Daten dann weiter zum TFT
geleitet werden..
Wäre allerdings auch komisch, denn das Display das ich mir von Hitachi
ausgesucht habe hat direkt ein SPI Interface!
Eigentlich musste doch eine direkte Kombination gehen,oder?
Was meint Ihr denn ? Muss ich da noch irgendwas beachten ?
Gruss der Lutz
Lutz wrote:
> Die Voraussetzung ist natürlich das beide ein SPI Interface besitzen!
Richtig !
> Geht so etwas oder muss die SPI des Mikrocontrollers mit einem> Grafikcontroller verbunden werden und die Daten dann weiter zum TFT> geleitet werden..
Ja, ein LCD/TFT Controller ist auf jedenfall notwendig. Ein AVR alleine
ist ziemlich an der Grenze, bzw schon etwas überfordert wenn er einen
TFT ansteuern soll.
> Wäre allerdings auch komisch, denn das Display das ich mir von Hitachi> ausgesucht habe hat direkt ein SPI Interface!
Dann poste doch mal das Datenblatt...
Hallo !
Ich muss noch etwas dabei sagen, was ich eben nicht erwähnt habe!
Für eine endgültige Steuerung mit einer unterschiedlichen
Bilddarstellung des Displays werde ich einen Grafikcontroller verwenden.
Für Testzwecke will ich ausschließlich ein Bild aufbauen um ein paar
Pixel etc. zu setzen mehr nicht ! Ich will wissen ob der Kontrast, der
Blickwinkel für meine Anwendung in Ordnung ist!?!
Anbei das Datenblatt...
Später kommt auch ein ARM7 an den Grafikcontroller...
Gruss der Lutz...
Das von Dir erwähnte Display hat keinen Controller und auch keine
SPI-Schnittstelle.
Das kannst Du weder mit einem AVR noch einem ARM direkt ansteuern. Auch
nicht zu Testzwecken.
Hä ? Dann habe ich wohl etwas falsch verstanden!
Im Datenblatt sind doch das SPI Interface Mode 8-2/11 beschreiben. Auch
das Pinning auf Seite 8-1/11 deutet doch auf etwas hin.
Kann mir jemand erklären, warum es dann erwähnt wird ? Wofür soll dies
dann sein?
Grss der Lutz !
Über diese SPI-Schnittstelle kann man allenfalls ein OSD oder ähnliches
implementieren, das Display selbst wird über die RGB-Schnittstelle mit
zyklischem Auffrischen des Bildinhaltes angesteuert.
Würde mich wundern, wenn das anders sein sollte.
Hallo !
Danke für die Info´s! Ich habe selber so ein TFT schon einmal in Betrieb
genommen (RGB 18bit - Steuerung mit Grafikcontroller). Deswegen habe ich
mich auch über die SPI Schnittstelle gewundert..
Fragt sich nur warum das SPI bei den Display´s auftaucht? Hat jemand ne
logische Erklärung?
Gruss der Lutz
Im Datenblatt gibts den Modi SPI und RGB, per SPI steuerst Du nur einen
OSD von 240xRGBx96 was rund 69kB an informationen ist, das ist auch
schon für einen Mega128 ganz schön heftig,..
Die RGB Daten werden Paralell eingegeben, über eine anliegende Clock mit
105ns müssten die Daten binnen ~52.5ns geladen und auf die Ports gegeben
werden, und das heißt lade Zeite plus 3 Ports ~4ns Cycle Instruction
Time also einen Rund 250 Mhz Single Cycle schneller µC ist erforderlich
wenn das laufen sollte, es gibt doch ARM9 Prozessesoren die das
machen,...
(Hoffentlich habe ich mich net verrechnet)
grüüüße
Hallo Zeusi..
das rechne ich noch mal nach :-)
Zitat:
per SPI steuerst Du nur einen
OSD von 240xRGBx96 was rund 69kB an informationen ist, das ist auch
schon für einen Mega128 ganz schön heftig,..
Wo steht das im Datenblatt, dass ich nur das OSD mit SPI ansteuern kann?
Ich habe mir die Seiten jetzt zweimal angeschaut aber wie kann ich
sicher sein das Eure Angaben stimmen ? Also ich vertrau Euch wohl. Aber
beim nächsten Mal muss ich dann n. mehr nachfragen !
Auf Seite 3 unter Punkt (15) ist SPI als System Interface also als
steuerung und zugehöriges OSD definiert
Auf seite 10 unter punkt 8.2.1 ist geschildert das die SPI daten direkt
in den RAM gehen,
auf seite 11 unter Punkt 8.3 ist der PArtial RAM aufgelistet (OSD) ,..
grüüüße
Hallo !
Jetzt muss ich doch noch mal etwas nachhaken.
Bis jetzt habe ich nur ein Display mit einem integrierten Timing
Controller gehabt. Da laufen die sämtliche Leitungen über den
Grafikcontroller.
1)
Jetzt ist dieses Display aber ohne Timing Controller, deswegen auch die
SPI Schnittstelle, Richtig? ? ?
2)
Wie bekomme ich denn jetzt das Timing des Display richtig hin?
Vermutlich muss ich dieses direkt von meinem µC aus machen, Richtig??
3)
Das 18Bit RGB Interface vom Display wird über einen Grafikcontroller
ausgesteuert. Der Grafikcontroller wird hingegen mit dem Daten - und
Adressbus vom µC angesteuert, Richtig?
Wäre cool, wenn ich dazu noch ein Feedback bekommen könnte damit ich mir
sicher sein kann, dass ich technisch auf dem richtigen Wege bin!!
Gruss der Lutz
Lutz wrote:
> 1)> Jetzt ist dieses Display aber ohne Timing Controller, deswegen auch die> SPI Schnittstelle, Richtig? ? ?
Nein, SPI hat damit erstmal rein garnichts zu tun.
SPI ist nur ein Zusatzfeature, das nur sehr wenige TFTs haben. Die
normalen TFTs haben nur RGB + Sync.
2)
> Wie bekomme ich denn jetzt das Timing des Display richtig hin?> Vermutlich muss ich dieses direkt von meinem µC aus machen, Richtig??
Nein. Das kann ein µC nicht, außer es ist ein >100MHz RISC Controller.
Besorg dir einen TFT Controller (z.B. von Epson: S1D3513), oder bau
einen mit einem FPGA selbst.
> 3)> Das 18Bit RGB Interface vom Display wird über einen Grafikcontroller> ausgesteuert. Der Grafikcontroller wird hingegen mit dem Daten - und> Adressbus vom µC angesteuert, Richtig?
Ja.
Gut...dann habe ich noch ein Frage zur SPI...
Die Funktion bzw. das Vorhandensein habe ich noch nicht so richtig
verstanden.
Wozu ist die SPI dann gut, wenn ich diese für die Darstellung meiner
240x320 Pixel eh nicht gebrauchen kann?
Was bring mir dieses Interface?
Kann ich das irgendwo für nutzen?
Gruss der Lutz
Ich muss ehrlich sein, so genau verstehe ich die Funktionsweise auch
nicht, aber einigen Stellen im Datenblatt nach, besitzt das TFT für
einen bestimmten Bildbereich einen internen RAM. Mit diesem lässt sich
eine Bild in Bild Funktion erziehlen:
Über das RGB Interface wird das TFT ganz normal angesteuert, zusätzlich
lässt sich aber ein kleines OSD Bild über das andere Bild einblenden.
Die Auflösung liegt bei 96x240 wenn ich das richtig verstanden habe.
Genau so habe ich mir das auch gedacht (Recherche Google)!
Demnach müsste es doch möglich sein, nur die 240x96 Pixel über die SPI
Schnittstelle zu programmieren bzw. damit Bilder darzustellen! Ich will
ja auch nur ein Bild zum testen haben.
Den µC einfach an die SPI Schnittstelle und schon müsste das System doch
funktionieren, oder?
Was meint Ihr..?
Gruss der Lutz
Genau - Es dauert auch kaum länger als wenn ich hier mal Frage ob dies
überhaupt möglich ist..!
Fragen gibt es - naja egal!
Ich bin gerne bereit dieses auszuprobieren, meine Resultate
(Probleme/Erfolge) würde ich hier bekannt geben.
Aber vielleicht hat jemand so etwas schon mal ausprobiert und sagt von
vorne rein das es definitiv nicht geht !
Gruss der Lutz
Lutz wrote:
> Genau so habe ich mir das auch gedacht (Recherche Google)!>> Demnach müsste es doch möglich sein, nur die 240x96 Pixel über die SPI> Schnittstelle zu programmieren bzw. damit Bilder darzustellen! Ich will> ja auch nur ein Bild zum testen haben.>> Den µC einfach an die SPI Schnittstelle und schon müsste das System doch> funktionieren, oder?
Nein, das TFT muss zusätzlich angesteuert werden. Es reicht wenn RGB auf
GND liegt, aber HSync und Vsync müssen vorhanden sein.
Hallo ! Ich noch mal...
Laut Datenblatt (3Eintrag von oben) muss ich drei verschiedene
Frequenzen haben um das Display ohne Grafikcontroller aber mit SPI
anzusteuern!
VSync = 90kHz
HSync = 90Mhz
DotClk = 62,5MHz
Also die DotClk mit 62,5Mhz ist verständlich, warum ich aber dann noch
zwei weiter unterschiedliche Frequenzen für die H/V Sync haben muss ist
doch etwas merkwürdig oder?
Vielleicht kann jemand man von Euch noch mal nen Blick auf das
Datenblatt machen, ob er ebenfalls der Meinung ist das ich 3Frequenzen
brauche.
Ich habe die Daten von Seite 8-4/11. Tabelle ( 8.4.2. Angaben in µ/n
Sek)
Gruss der Lutz
@ Lutz (Gast)
>Laut Datenblatt (3Eintrag von oben) muss ich drei verschiedene>Frequenzen haben um das Display ohne Grafikcontroller aber mit SPI>anzusteuern!
hat mit SPI rein gar nichts zu tun.
>VSync = 90kHz>HSync = 90Mhz
Das glaube ich kaum.
Hsync sind vielleicht 90 kHz, das ist die Zeilenfreqeunz. Vsync liegt
irgendwo zwischen 50..150 Hz, bei LCDs eher bei 50..70 Hz.
>DotClk = 62,5MHz>Also die DotClk mit 62,5Mhz ist verständlich, warum ich aber dann noch>zwei weiter unterschiedliche Frequenzen für die H/V Sync haben muss ist>doch etwas merkwürdig oder?
Das ist vollkommen normal. Damit wird die Bildgeometrie sowie
Bildwiederholfrequenz definiert.
Dotclk / Hsync = 62,5 MHz / 90 kHz ~ 690 Pixel/Zeile
Dotclock Vsync Pixel pro Zeile = 62,5 MHz 90 690 = 1006 Zeilen
pro Bild, wobei da nicht alle sichtbar sind.
MFG
Falk
Je genauer ich das Datenblatt lese, desto merkwürdiger wird es:
Auf Seite 5-1/1 unter Frame Frequency gibt es "Internal Clock Mode".
Das TFT scheint also einen halben Controller integriert zu haben. Leider
ist alles nicht besonders aussagekräftig, aber es könnte sein, dass das
TFT sogar von alleine läuft.
Anscheinend kann man also wahlweise beide Modi verwenden.
Die SPI Frequenz muss zwischen 52kHz und 9MHz liegen. Probiers einfach
mal aus.
@ Lutz (Gast)
>Na gut..trotzdem benötige ich drei unterschiedliche Frequenzen für einen>provisorischen Aufbau meiner Schaltung,oder ?
Jain. Du musst per Zähler/CPLD/FPGA aus EINEM Takt (Quarzoszillator)
alle drei ableiten.
MFG
Falk
Aha..ansonsten verwende ich meinen Grafikcontroller für die
unterschiedlichen Frequenzen, Richtig ?
Die meisten sowie der Epson S1D13706 haben ja einen V/H Sync - und einen
DotClk Ausgang !
Was würde denn passieren, wenn ich die H/V Sync synchron für mein
Testbild laufen lasse. Eigentlich kann man das doch wohl riskieren.
Gruss der Lutz
