TFT Display ansteuern

Tilo Lutz schrieb:
> Hallo
>
> Ich habe hier von einem defekten Notebook ein TFT-Display liegen,
> welches ich mit einem Cyclone II ansteuern will. Das Display ist ein
> B121EW01, zu welchem ich auch ein paar Infos im Netz gefunden habe. Grob
> ist das ganze unter http://tinyurl.com/mogbjg beschrieben. In dem
> Datenblatt wird auf einen Controller von TI verwiesen, dessen Datenblatt
> ausführlicher ist (SN75LVDS86).

Das ist kein Controller, sondern ein LVDS-Receiver und der sollte im 
Panel schon drin sein. Such mal nach dem Gegenstück (LVDS-Treiber) wie 
z.B. 
http://www.nalanda.nitc.ac.in/industry/datasheets/Texas_analog/SLLS258A.pdf

> Das Display wird mit 4 Differenziellen Signalen (LVDS) angesteuert,
> wobei eines der Signal die Clock ist. Der Cyclone II soll LVDS ausgeben
> können. Das Display wird mit 3,3V versorgt. Kann ich das Display direkt
> an den Cylcone II anschließen? Ist die Busspannung dann +/- 3,3V?

Nein, LVDS hat einen Ruhepegel von ca. 1,2V und einen Hub von 
250...400mV.

> Auf den drei Datenleitungen werden immer 6Bits zusammen übertragen, was
> der Farbauflösung des Displays entspricht.

Nein, die werden hintereinander im Zeitmultiplex übertragen (siehe z.B. 
obiges Datenblatt - Seite 3).

>  Werden die Farben jeweils über einen eigenen Kanal übertragen?

Nein, Multiplex.

> Weiß jemand, wo ich Informationen bekommen kann, wie die Daten kodiert sind?

Siehe Datenblatt eines LVDS Treibers von TI oder National, oder 
Fairchild, oder ..., oder ..., oder...

> Dazu habe ich leider nichts finden können.

Wo hast Du gesucht?? ;-)

> Ich will erst einmal nur ein Testbild ausgeben. Alles andere soll dann
> nach und nach kommen...

...dann bau Dir einfach zwei Zählerketten für horizontal (getaktet mit 
Pixelclock) und vertikal (Zeilenclock) und gib jeweils die oberen 6 Bits 
des Pixelzählers auf die RGB-Daten, so dass Du einen Graukeil erhältst. 
Das dürfte der einfachste und schnellste Weg zu einem Testbild sein.
Den Sync-Rahmen drumrum bekommst Du noch hin - oder?

Tilo Lutz schrieb:

> Bei der Clock-Leitung ist mir eine Kleinigkeit noch unklar. Laut
> Handbuch  hat der Ausgangstakt für LVDS die selbe Frequenz wie der
> Eingangstakt. Auf dem von dir genannten Datenblatt ist auf Seite9 ein
> Timingdiagramm abgebildet. Demnach hat das Clocksignal eine steigende
> Flanke bei dem ersten zu übertragende Bit und eine fallende Flanke bei
> dem wechsel vom 4. auf das 5.Bit. Gewinnt der LVDS-Empfänger daraus
> mittels PLL o.ä. den 7-fachen Takt, mit dem die einzelnen Bits
> ausgelesen werden?

Ja.
Wenn man den Bittakt übertragen würde, bräuchte man noch ein Sync Signal 
das den Beginn jedes 7. Bits anzeigen müsste.

> Sync-Rahmen ... ;)
> Da muss ich mich noch einlesen. Ich kenne nur die klassische analoge
> Variente, dass über zwei Sync-Leitungen VSync und HSync übertragen
> werden. Wie und wo das in den Datenstrom eingebaut wird, muss ich noch
> herausfinden.

Hier geht das genauso. Es gibt eben 2 Bits für die Sync Signale.

Ich würde erstmal mit einem fertigen LVDS Encoder arbeiten. Dann musst 
du dir um das ganze LVDS Zeug keine Gedanken machen und es reicht RGB + 
Pixeltakt (=DTCLK) + Sync + DataEnable (DSPTMG, was dem bei der 
Bilderzeugung nur intern verwendeten Blank\ Signal entspricht) zu 
erzeugen.
Keine Ahnung wie schnell der Cyclone2 ist, aber z.B. die Spartan3 sind 
zu langsam für LVDS für TFTs.

Tilo Lutz schrieb:

> Es gibt für den Cyclone II einen fertigen IP-Core zur
> Displayansteuerung. Die LVDS-Ausgänge sollen bis zu 622MBps schaffen. Ob
> ich das hinbekomme, ist ein anderes Thema.

Ok, 622MBit/s sollten reichen, das Display braucht irgendwas um die 
490MBit/s (bei den Spartan3 ist irgendwo um die 300MBit/s Schluss, sind 
aber auch eher Low Cost).

> Es reicht, wenn ich die 4 LVDS-Leitungen sowie Versorgungsspannung
> anschließe oder wird noch mehr benötigt?

Die 4 LVDS Paar + 3,3V reichen.
Möglichst die 3,3V nicht lange anlegen wenn die Timingsignale fehlen, 
das mag das Display nicht.

> Zum dem Display gehört noch ein Inverter. Dieer hat 2Ausgangspins für
> die Beleuchtung und 4 Eingangspins. Weiß jemand auf die schnelle, wie
> der Inverter angesteuert wird?

Vermutlich Betriebsspannung, On/Off, Dimmen.
Die Betriebsspannung liegt meist bei um die 12V, Onoff und Dimmen meist 
bei Logikpegeln.
Die Spannung und GND sollte man über die Breite der Leiterbahnen bzw. 
einen Elko erkennen können, bei den anderen beiden hilft nur 
ausprobieren (über einen Widerstand als Schutz mal 0V/5V anlegen, 
schauen ob sich was tut).

> Ich
> denke ich werde am Anfang ein Testbild mit Zählern realisieren und mit
> langsamen Takt auf einem Oszi beobachten.

Ja, mache ich auch immer. Ob das Bild passt, kann man nicht erkennen, 
aber die Frequenzen der Sync Signale und vom Displaytakt kann man grob 
nachprüfen ob die wie erwartet aussehen. Erst wenn das passt wird das 
Display angeschlossen.

Das ist genau das, was ich auch machen wollte. Habe 2 14,1" Laptop 
Displays
QD141X1LH03
Bei meinen Displays wurde ein DS90C363 als Transmitter benutzt. Den habe 
ich auch schon, aber leider noch keine Zeit gehabt.

Xapp486 von Xilinx für Spartan 3E hab ich schon mal gefunden als LVDS 
Transmitter.

Wollte auch als erstes das Timing machen und den DS90C363 benutzen und 
wenn das läuft mich an das LVDS machen.

Benedikt K. schrieb:
> Tilo Lutz schrieb:
>
>> Es gibt für den Cyclone II einen fertigen IP-Core zur
>> Displayansteuerung. Die LVDS-Ausgänge sollen bis zu 622MBps schaffen. Ob
>> ich das hinbekomme, ist ein anderes Thema.
>
> Ok, 622MBit/s sollten reichen, das Display braucht irgendwas um die
> 490MBit/s (bei den Spartan3 ist irgendwo um die 300MBit/s Schluss, sind
> aber auch eher Low Cost).

...auch bei den "edleren" Teilen ist die im Datenblatt angegebene 
Maximaldatenrate kaum in der Relaität zu erreichen. Was geht weiss man 
leider immer erst wenn man das erste P&R durch hat und die Timingreports 
durchforstet.


>> Es reicht, wenn ich die 4 LVDS-Leitungen sowie Versorgungsspannung
>> anschließe oder wird noch mehr benötigt?
>
> Die 4 LVDS Paar + 3,3V reichen.
> Möglichst die 3,3V nicht lange anlegen wenn die Timingsignale fehlen,
> das mag das Display nicht.

Das wichtigste sind der LVDS-Takt (für die LVDS-PLL und der Pixelclock, 
den das Display für alle internen Timings verwendet. Die Daten sind erst 
mal nicht so wichtig (ausser für den Kerl vor dem Display :-) ). Ältere 
Panels waren noch etwas pingelig was das Sync-Timing anging (speziell 
die von LG), aber heutzutage scheinen die Syncs wirklich nur noch zum 
Rücksetzen der internen Zählerketten zu dienen. Da geht das mit den 
Porches z.B. nicht mehr so genau.

>> Zum dem Display gehört noch ein Inverter. Dieer hat 2Ausgangspins für
>> die Beleuchtung und 4 Eingangspins. Weiß jemand auf die schnelle, wie
>> der Inverter angesteuert wird?
>
> Vermutlich Betriebsspannung, On/Off, Dimmen.
> Die Betriebsspannung liegt meist bei um die 12V, Onoff und Dimmen meist
> bei Logikpegeln.
> Die Spannung und GND sollte man über die Breite der Leiterbahnen bzw.
> einen Elko erkennen können, bei den anderen beiden hilft nur
> ausprobieren (über einen Widerstand als Schutz mal 0V/5V anlegen,
> schauen ob sich was tut).

Vorsicht!
es gibt einige Inverter, die habe 12V Betriebsspannung, vertragen 0-5V 
am Enable-Eingang, sterben aber der Heldentod bei mehr als 3,3V am 
Dimmeingang. Also beim Probieren nicht zu niederohmig rangehen, wenn 
möglich lieber das Datenblatt des Herstellers zu Rate ziehen (oder die 
Eingangsschaltung vom Inverter bis zum Steuer-IC abnehmen. So viel 
Technik ist da meist nicht im Spiel).

@  Tilo Lutz (katagia)

>Ich glaube ihr habt mich überzeugt. Ich werde mit dem FPGA ein
>TTL-Signal erzeugen, dass dann zu LVDS umgesetzt wird. Dadruch
>verringert sich der benötigte Taktrate des FPGA um Faktor 7.

Bei der Leistung der heutigen FPGAs nicht nötig und sinnvoll. Man kann 
die Datengenerierugn mit dem langsamen Takt im FPGA betreiben, die 
Parallel-Seriell-Wandlung dann im FPGA mit dem 7fachen Takt, welcher von 
einer PLL/DCM erzeugt wird. Keine Notwendigkeit nach einem externen 
LVDS/TTL Wandler.

MFG
Falk

Ich sags mal so: LVDS ist halb so schlimm wie man denkt, Ich hatte 
selbst schon ein paar Meter normales Flachbandkabel zwischen LVDS 
Transmitter und TFT, und es lief. Ich behaupt jetzt einfach mal, das 
parallele RGB Interface mit TTL Signalen ist kritischer als das ganze 
über LVDS. Zumindest ist das meine Erfahrung.
Ein paar cm Längenunterschied ist da auch nicht weiter schlimm, grob 
kann man das ja ausrechnen: Bei etwa 300000km/s und 500MBit, und einer 
maximalen Verschieben von max 1/2 Bit sollten die Unterschiede weniger 
als 1ns*300000km/s=30cm liegen.

...im Prinzip ja, aber... ;-)

Die LVDS-Schnitte arbeitet mit sehr geringem Spannungshub und recht 
niederohmigem Abschluß (100 Ohm) und kann daher einiges ab. Für 
Prototypen geht's da nicht so genau: ich habe manchmal 2m (allerdings 
paarweise verdrillte) Leitungen zwischen Ausgang und Panel, wenn ich die 
'Tronik in der Klimakammer 'foltere'.

Aber für kommerzielle Produkte heist's aufpassen: wegen der doch recht 
hohen Frequenzen (speziell bei größeren Panels) erweist sich das 
LVDS-Kabel immer wieder als hartnäckige EMV-Quelle (Spread-Spektrum 
hilft aber die Pegel einzuhalten).

Mich hat es nun auch gepackt.

@ Tilo Lutz
Hoffe es stört dich nicht das ich deinen Thread missbrauche.

Seh ich das Richtig, das in dem von mir hier
Beitrag "Re: TFT Display ansteuern"
gepostetem Datenblatt auf Seite 9

Das Enable Signal nur bei den aktiven Pixeln an ist.

Das heißt bei Typischer Ansteuerung
von Zeile 35 bis 803 und in den Zeilen vom Tackt 296 bis 1320?

Finde das etwas komisch beschrieben.

John-eric K. schrieb:

> Das Enable Signal nur bei den aktiven Pixeln an ist.

Ja.


> Das heißt bei Typischer Ansteuerung
> von Zeile 35 bis 803 und in den Zeilen vom Tackt 296 bis 1320?

Ja, ergibt genau 1024x768 Pixel.

Danke,
dann hab ich das richtig in VHDL umgesetzt. War mir bloß mit dem Enable 
Signal nicht sicher. Hab es erst einmal nach Typisch Programmiert, wenn 
das Läuft kann man die Zeiten ja immer noch auf Minimum verkürzen.

Vielen Dank
John-Eric

Tilo Lutz schrieb:
> 8 Vollständig leere Zeilen, also Enable=0, beide Syncs auf 1, da
> invertiert.

Zwischen den Zeilen sendest du aber schon HSync, oder?

> Danach werden 800 Zeilen mit Inhalt geschickt.
> Der Inhalt besteht aus: 64 deaktivierten Pixel, 1280 aktive Pixel, 32
> deaktivierte Pixel und 32 deaktivierte Pixel, bei denen VSync auf 0
> gesetzt ist, also invertiert ist.

Du verwechselst HSync und VSync.

> Zum Anschluss werden 6 leere Zeilen und danach 2 Zeilen lang HSync=0 für
> den Seitenwechsel gesendet.

VSync nicht HSync. Und währenddessen HSync ganz normal weiter laufen 
lassen.

> Im Meinem Datenblatt steht leider nicht drin, wann HSync und VSync
> gesendet werden und wie lange die Signale anliegen müssen.

Stimmt. Wenn man zwischen den Zeilen liest, könnte man auf die Idee 
kommen, dass DSPTMG/DE alleine ausreicht. Zumindest gibt es Displays die 
das können. Allerdings scheint das Datenblatt auch nicht eindeutig zu 
sein, also ausprobieren.

...hier mal ein Auszug aus einem Scaler-Datenblatt. Ist etwas 
kompliziert zu lesen (horizontal und vertikale Zeitachsen), aber wenn 
man's begriffen hat ist's ganz anschaulich.


(Anmerkung zum Bildchen: Im Normalfall ist "verschenkt" man keine Pixel 
an ein "Display Background Window", das dient hier nur der Beschreibung 
einiger Register des Bausteins aus dessen Datenblatt ich das Bildchen 
habe)

Tilo Lutz schrieb:
> OK, kann gut sein, dass ich VSync und HSync verwechsele

Ja, tust Du :-)

> An jedem aktiven Zeilenende, also wenn Pixel "Enabled" sind, sende ich
> auch das entsprechende VSync. Muss auch am ende eine nichtaktiven Zeile
> ein Vsync gesendet werden?

Ja, am Ende JEDER Zeile kommen H-Frontporch, HSYNC und H-Backporch.

Am Ende eines Bildes (neudeutsch: Frame) kommen einige Zeilen nur mit 
HSync (V-Frontporch), einige Zeilen während derer VSync aktiv ist (die 
ganze Zeit), und dann wieder einige Zeilen nur mit Hsync (V-Backporch).

Also meins sieht so aus.

Geht bis Zeile 37(vcount)

Zeile 36 ist die erste mit richtigen Daten, weshalb auch das Enable mit 
angeht.

Vergrößerung des Frames 37


Das musst du dann an dein Display anpassen.

Kann meins leider nicht testen, da ich 1500Km weit weg von zu hause bin 
und erst Anfang Juni an die Hardware komme.

@Tilo Lutz
Hast mich aber animiert was zu machen gg

Mal so eine Frage.
LVDS ist immer ein Pinpaar!

ich weiß nicht wie Altera das macht, aber bei Xilinx muss man glaube ich 
für LVDS extra noch eine Komponente einbinden.

Also du hast auch ein Pinpaar(+ und -) definiert und angeschlossen für 
den jeweiligen Ausgang?

Ich finde den Code, naja leicht grässlich(Nicht böse gemeint), aber 
warum nimmst du nicht die richtigen Namen für die Ausgänge?
Es kommt ja keiner hinterher was was ist. Das ist schlecht für 
Außenstehende zu erkennen und nachzuvollziehen.

Würde aber sagen das die Widerstände mit dran Schuld sind.
weil LVDS geht hin über +, erster 470Ohm, im Display sind 100Ohm und 
zurück zweiter 470Ohm zu -

Im Anhang ist mal was zu LVDS als Erklärung.

Mein Quellcode sieht zurzeit so aus.

In deinem PDF zu deinem Display, steht das er den sn75lvds86 als 
Empfänger verwendet(Seite 11). Als gegenstück wird zum übertragen der 
sn75lvds84 in dem PDF des Empfängers als Sender genannt.

http://pdf1.alldatasheet.com/datasheet-pdf/view/28672/TI/SN75LVDS84.html

siehe link

Auf Seite 3 hast du z.B. ein Bild wie das Signal spiel aussehen sollte.
Und auf Seite 8 ein paar Sachen zu den Timings ein sowie Ausgang.

Ich wollte erst mit einem externen Transmitter testen, da ich diesen mir 
mal gekauft habe.

Was zum Transmitter interessant wäre, ist das:
http://www.xilinx.com/support/documentation/application_notes/xapp486.pdf
Ist eine Xilinx Apnote zum Thema.
Muss ich mich mal mit beschäftigen.

Die nutzen am Ausgang einen DDR-FF, weiß aber noch nicht so recht wie 
ich mir das vorstellen muss. Suche dazu noch was.
Ich kann zurzeit eh nicht testen, weil ich mein Praktikum gerade in 
England mache und die Hardware nicht da habe.

Ich wollte erst mit einem externen Transmitter testen, da ich diesen mir 
mal gekauft habe.

Was zum Transmitter interessant wäre, ist das:
http://www.xilinx.com/support/documentation/application_notes/xapp486.pdf
Ist eine Xilinx Apnote zum Thema.
Vielleicht hat Altera sowas ja auch?
Muss ich mich mal mit beschäftigen.

Die nutzen am Ausgang einen DDR-FF, weiß aber noch nicht so recht wie 
ich mir das vorstellen muss. Mein Virtex2 sollte welche drinne habe, 
denke ich. Suche dazu noch was.
Ich kann zurzeit eh nicht testen, weil ich mein Praktikum gerade in 
England mache und die Hardware nicht da habe.

Gruß John-Eric

Vielleicht weil du bei der parallel-> seriell Wandlung was vertauscht 
hast?

Hast du das nun hinbekommen?

Ich hab meinen Transmitter denke ich auch fertig.
Habe es etwas anders gemacht, weil ich keine PLL gefunden habe und die 
DCM "nur" bis 320MHz geht. 420MHz wären ja für den 7-fachen Takt bei 
60MHz Eingang notwendig.
Ich habe mir per DCM einen 3,5x schnelleren Takt gemacht (normal und 
negiert), dass ergibt im Endeffekt auch den 7-fachen Takt. Und als 
Ausgangsstufen werden DDR-Flipflops verwendet

Ähnlich wie im Datenblatt
Beitrag "Re: TFT Display ansteuern"
beschrieben. Das hat mich darauf gebracht.

Nur hab ich nicht verstanden was die da zwischendurch gemacht haben, 
deshalb hab ich mir den Rest dazwischen selber ausgedacht.

Laut Simulation sieht das Ganz ganz gut aus.
Ich speichere 2 Datensätze zwischen, weil durch den nur 3,5fachen Takt 
hätte ich sonst eine Verdrehung der zweiten Daten drinnen, welche ich so 
einfacher kompensieren kann. Eingangsdaten sind im Bild einfach nur pro 
Kanal von Bit 6 nach 0 geschoben. Die roten Striche bilden jeweils einen 
Schiebevorgang.

AHA.
Na wie oben geschrieben
"Eingangsdaten sind im Bild einfach nur bei jedem normalen Takt pro 
Kanal von Bit 6 nach 0 geschoben." Also kein bestimmtes Signal!

Wo ich einen Fehler erdenken würde, ist die Übergabe zwischen deinen 
beiden Takten in die Schieberegister! Das du da, weil die Signale nicht 
synchron sind, auch mal dann abfragst, wenn die Daten noch nicht stabil 
anliegen und du dadurch misst sendest.

Bei mir ist es das gleichen Datenformat:
L0:      GRRRRRR
L1:      BBGGGGG
L2:      EVHBBBB
CLK:     HHLLLHH

Ich hab mir ein Reset von der DCM so gebastelt, dass ich ca in der Mitte 
des ersten der beiden Takte die Daten in die Schieberegister lade. Da 
meine Tackte zueinander synchron durch die DCM sind, hoffe ich das es 
dadurch keine Probleme gibt. Sozusagen kommen auf 2x60MHz Takte, 
7x210MHz Takte. Und wenn die Erkennung gut läuft, sollte er dann in der 
Mitte des ersten Taktes ungefähr übernehmen.

Kann das aber frühestens in 1,5 Wochen Testen.

Das mit dem nicht symmetrischen Tackt glaube ich nicht, weil die 
Receiver dafür ja ausgelegt sein sollten und das Datenformat ja 
vorgeben.

Gruß John

Ich habe nun mal alles zusammengetan und versucht zu erstellen.
Das Funktioniert soweit auch, nur erhalte ich 4 Warnungen beim Mappen, 
die ich nicht zuordnen kann! Pins sind auch schon zugeordnet und CLK mit 
60MHz angegeben.

Die Warnungen lauten:
WARNING:Par:275 - The signal TxCLK has no driver
WARNING:Par:275 - The signal TxOUT<2> has no driver
WARNING:Par:275 - The signal TxOUT<1> has no driver
WARNING:Par:275 - The signal TxOUT<0> has no driver

Diese Signale sind zwischen dem DDR-FF und dem LVDS-Wandler.
Die "Behavioral"- und "Post and Place"-Simulation funktionieren ohne 
Probleme. Auf den Leitungen ist ein Signal spiel zusehen, wonach ich 
sagen würde, dass die Leitungen benutzt werden. (Siehe angehängte Bilder 
weiter oben)

Es sind noch ein paar mehr Warnungen drinnen, der meiste Teil kommt aber 
von der DCM, weil Eingänge nicht benutzt werden. (Von Xilinx so 
erstellt)
Er optimiert auch die rot/grün/blau-Signale(DataIn) zusammen, da die 
zurzeit das Gleiche ausgeben.

Die vorletzte Warnung verstehe ich auch nicht:
WARNING:Route:447 - CLK Net:CLK may have excessive skew because
   3 NON-CLK pins failed to route using a CLK template.

Na OK, diese bezieht sich wohl auf die oberen Warnungen würde ich sagen.
WARNING:Par:284 - There are 4 sourceless or loadless signals in this 
design.

Die LVDS-Transmitter sehen so aus,

1

   library UNISIM;

2

   use UNISIM.vcomponents.all;

3

   .

4

   .

5

   OBUFDS_TxCLK : OBUFDS

6

   generic map (

7

      IOSTANDARD => "LVDS_33")

8

   port map (

9

      O  => TxCLK_p,    -- Diff_p output

10

      OB => TxCLK_n,    -- Diff_n output

11

      I  => TxCLK       -- Buffer input 

12

   );

Vielleicht könnte ja mal einer von den VHDL-Spezis drüber schauen.

Wenn andere Sachen noch gewünscht sind, gebt bescheid.
Gruß John

Vergessen, ist ISE 8.1
Die anderen waren mir zugroß, hier ist nur eine kleine Internetleitung.

Also ohne den LVDS-Transmitter geht es ohne Probleme.
Jetzt ist die Frage warum?

Ich habe vergessen die Komponente zu deklarieren.
Das habe ich behoben, aber er zeigt immer noch die gleichen Warnungen 
und beim erstellen der Programmierdatei spuckt er Fehler aus.
Laut http://www.xilinx.com/support/answers/19539.htm
und der Datei im 2ten Link, sieht meins gleich aus.
Aber warum optimiert(löscht) er die trotzdem weg?

Anbei noch die VHDL-Datei wo das erstellt wird.
Wieso muss das so schwer sein.
Die Pins sind auch auf den Richtigen p und n zugewiesen in der 
UCF-Datei.

Oder liegt das daran, dass ich die 8.1.3 verwende?

Nacht.
John

Habe mal für das LVDS Problem einen neuen Post aufgemacht um das hier 
nicht damit zu belasten.
Beitrag "LVDS, DDR-FF Problem Xilinx"

Hm, mir fällt da auch nix ein, außer halt die Übernahme zwischen den 
beiden verschiedenen Tackten.

Vielleicht versuchst du einfach mal den Takt zu Minimieren auf zB. 25MHz 
und 175MHz, es ändert sich ja dann nur die Bildwiederholfrequenz, was 
dir aber erstmal egal sein kann. Aber vielleicht ist durch den Aufbau 
(deine Überbrückten Widerstände) das besser, da nicht so schnell und 
Zeitkritisch.

Vielleicht Meldet sich ja mal einer der Spezies, zB. Falk, Benedikt
Oder die haben auch keine Ahnung warum.

Mein blöder Fehler war mir auch nicht bewusst, weil ich die Dinger noch 
nie benutzt habe.

Gruß John-Eric

Was mir grad noch auffiel!

1

  SIGNAL    RowCounter    : INTEGER RANGE 0 TO 1408 := 0;

2

  SIGNAL    LineCounter    : INTEGER RANGE 0 TO 816 := 0;

du machst 1409 Punkte und 817 Zeilen!
damit hast du immer 1Pixel/Zeile zufiel oder nicht?

und

1

      IF LineCounter>11 AND LineCounter<812 AND

2

        RowCounter>63 AND RowCounter<1344 THEN

erste Zeile von 12 bis 811 an = 799 Zeilen
zweite      von 64 bis 1343 = 1279 Pixel

könnte da das Problem liegen oder sehe ich das falsch?

John-eric K. schrieb:

> Vielleicht versuchst du einfach mal den Takt zu Minimieren auf zB. 25MHz
> und 175MHz, es ändert sich ja dann nur die Bildwiederholfrequenz, was
> dir aber erstmal egal sein kann.

Würde ich auch empfehlen, auch wenns außerhalb der Specs des TFTs ist.
Am besten so niedrig, dass man die Ausgänge mit einem Oszilloskop 
anschauen kann. Falls ein DSO vorhanden ist, dann würde ich parallel die 
Syncsignale ausgeben und auf diese triggern, und dann schauen ob in dem 
LVDS Datenstrom die Bits entsprechend gesetzt sind.
Oder alternativ, falls du an den LVDS Decoder auf dem Display ran 
kommst, an dessen Ausgänge mal messen.

> Vielleicht Meldet sich ja mal einer der Spezies, zB. Falk, Benedikt

Zum Thema Display jederzeit, aber bei VHDL bin ich eher im Bereich der 
Anfänger.

Ich mach das so:

1

  signal lvdsdatabuff : std_logic_vector(20 downto 0); -- DE, VS, HS, B(5..0), G(5..0), R(5..0)

2

  alias de    : std_logic is lvdsdatabuff(20); 

3

  alias vs    : std_logic is lvdsdatabuff(19); 

4

  alias hs    : std_logic is lvdsdatabuff(18); 

5

  alias blau  : std_logic_vector(5 downto 0) is lvdsdatabuff(17 downto 12); 

6

  alias gruen : std_logic_vector(5 downto 0) is lvdsdatabuff(11 downto 6); 

7

  alias rot   : std_logic_vector(5 downto 0) is lvdsdatabuff(5 downto 0); 

8

   :

9

10

   -- Ausgabe

11

   process begin

12

      wait until rising_edge(CLK); -- 7*Pixeltakt

13

      if (lvds_cycle < 6) then  lvds_cycle <= lvds_cycle+1;

14

      else                      lvds_cycle <= 0;

15

      end if;

16

      lvdsoutsr0 <= lvdsoutsr0(5 downto 0) & '0'; 

17

      lvdsoutsr1 <= lvdsoutsr1(5 downto 0) & '0'; 

18

      lvdsoutsr2 <= lvdsoutsr2(5 downto 0) & '0'; 

19

      if (lvds_cycle = 2) then --  Daten übernehmen

20

         lvdsoutsr0 <= lvdsdatabuff( 6 downto  0);

21

         lvdsoutsr1 <= lvdsdatabuff(13 downto  7);

22

         lvdsoutsr2 <= lvdsdatabuff(20 downto 14);

23

      end if;

24

      if   (lvds_cycle = 1) then lvdsclkout <= '1'; -- LVDS-Takt 

25

      elsif(lvds_cycle = 5) then lvdsclkout <= '0';  

26

      end if;

27

      lvdsout0 <= lvdsoutsr0(6);

28

      lvdsout1 <= lvdsoutsr1(6);

29

      lvdsout2 <= lvdsoutsr2(6);

30

   end process;

> Im Timingdiagramm sieht alles richtig aus :(
Hast du das gemessen?

@Benedikt
Ich hab von deiner vorherigen Antwort auf ein bisschen Erfahrung 
geschlossen. Fand das nur komisch das erst ein paar Antworten kahmen und 
dann keine mehr.

@Lothar
Im Endeffekt sieht das genauso wie Tilos aus,
nur das er sein Schieberegister als Zähler sozusagen verwendet.
Ich denke er meinte Simuliert.


Was sagt ihr zu meiner Behauptung mit den Zählern für die aktive Fläche?
Ich glaube nicht, dass das Display das so mag, dass in jeder Zeile ein 
Pixel zu wenig und die letzte Zeile ganz weg ist. Oder ich habe mich 
verrechnet.

@Tilo
mach dir mal einen Zähler in die aktive Fläche und simuliere bis 
Zeilenende durch, daran kannst du doch genau sehen ob du deine 1280 
Pixel pro Zeile einhälst.
Das gleiche mit den Zeilen.

Ich habe Einen kompletten Bildaufbau bei mir Simuliert, um zu schauen ob 
die Pixel und Zeilen Anzahl stimmt mit so einem Zähler da drinnen. Auch 
wenn das ISE-Simulationprogramm massig abgestürzt ist bei der Laufzeit. 
Aber irgendwann hat er es doch einmal gemacht.

Gruß John

> Im Endeffekt sieht das genauso wie Tilos aus
Das schon, aber meins funktioniert  ;-)

>>> Im Timingdiagramm sieht alles richtig aus :(
>> Hast du das gemessen?
> Ich denke er meinte Simuliert.
Ja, aber wir sind jetzt an einem Punkt, wo Simulieren offenbar nicht 
mehr weiterhilft.

John-eric K. schrieb:

> Was sagt ihr zu meiner Behauptung mit den Zählern für die aktive Fläche?
> Ich glaube nicht, dass das Display das so mag, dass in jeder Zeile ein
> Pixel zu wenig und die letzte Zeile ganz weg ist. Oder ich habe mich
> verrechnet.

Ja, das Display bekommt einen Pixel zu wenig, aber das stört die 
Displays meist nicht weiter.
Von daher tippe ich eher auf ein falsches LVDS Signal, so dass das 
Display falsche Sync Signale bekommt.

> Ja, das Display bekommt einen Pixel zu wenig, aber das stört die
> Displays meist nicht weiter.
In den Displays ist nämlich auch keine höhere "Intelligenz", die das 
Protokoll überwacht, sondern nur ein Zähler, der mit dem Sync auf 0 
gesetzt wird und dann loslegt. Ich betreibe ein paaar tausend alte 
DSTN-Displays seit Jahren weltweit knapp ausserhalb der (Snyc-)Specs (zu 
langsam), und es tut ganz problemlos. In Wahrheit kann man das Ding fast 
um die Hälfte unter- und gut 30% übertakten, bevor die Anzeige 
schlappmacht.

> Macht es einen Unterschied, ob man "IF rising_edge"
> oder "wait until rising_edge" verwendet?
Nein. Es schreibt sich nur schöner, man spart eine Einrück-Ebene, und 
die Sensitiv-Liste ist garantiert korrekt (weil leer).

BTW:
> Die vorletzte Warnung verstehe ich auch nicht:
> WARNING:Route:447 - CLK Net:CLK may have excessive skew because
>    3 NON-CLK pins failed to route using a CLK template.
Was ist eigentlich daraus geworden?

Also geht dein Display nun Tilo?
Bin gerade wieder bei meinem bei.
meins will aber noch nicht so wirklich.
Es zeigt nur Müll an.

Hallöle
Also mein TFT geht mit dem Originalem CHip nun auch.
Was bei mir nur ist, wenn ich alle Bits auf 1 machen bei der Farbe
ergibt das aber kein wirkliches weiß! das geht mehr ins blaugrüne würde 
ich sagen. Hat da einer eine Idee.
Ich werde die Fraben mal durch Taster veränderlich machen als Test.

So hab das mit dem LVDS per FPGA nun auch hinbekommen.
Läuft supi.
Das mit dem weiß stimmt nun auch.