www.mikrocontroller.net

Forum: FPGA, VHDL & Co. TFT Display ansteuern


Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 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?

Auf den drei Datenleitungen werden immer 6Bits zusammen übertragen, was 
der Farbauflösung des Displays entspricht. Werden die Farben jeweils 
über einen eigenen Kanal übertragen? Weiß jemand, wo ich Informationen 
bekommen kann, wie die Daten kodiert sind? Dazu habe ich leider nichts 
finden können.

Ich will erst einmal nur ein Testbild ausgeben. Alles andere soll dann 
nach und nach kommen. Der FPGA sitzt auf einem DE1 Evaluationboard.

Viele Grüsse, Tilo

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

> 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?

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Vielen Dank für deine Hinweise.
Bei meiner Suche nach LVDS habe ich nur Informationen zu der 
Punkt-zu-Punktverbindung selbst gefunden. LVDS wird ja nicht nur für 
Displayansteuerungen verwendet. Google hat mich mit Ergebnissen 
erschlagen, mit welchen ich nichts anfangen konnte.

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?

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.
/EDIT:
In dem Datenblatt ist auf Seite12 abgebildet, wie das Signal 
zusammengesetzt wird. Dort finde ich auch HSync und VSync. Im Datenblatt 
zu meinem Display habe ich gefunden, wie die Daten kodiert sind. Der 
Vollständigkeit halber:
VSync ist nach einem Zeilenende "high" und HSync nach einem Seitenende 
"high"?
Was es mit DTCLK und DSPTMG auf sich hat, muss ich noch herausfinden.

Schon mal vielen Dank für deine Hilfe, jetzt kann ich erst einmal weiter 
suchen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Benedikt

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.

Den LVDS-Trasmitter müsste ich mir besorgen, den FPGA habe ich da und 
wartet, eine Aufgabe zu bekommen. Die Informationen, die ich jetzt habe, 
sollten reichen, einen Testbildgenerator zu realisieren.

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

Wenn ich hier gerade die Displayprofis habe:
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?

Nochmals Danke für die Hilfe, ich denke da ganze ist realisierbar. Ich 
denke ich werde am Anfang ein Testbild mit Zählern realisieren und mit 
langsamen Takt auf einem Oszi beobachten.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Mal, schaun, ob ich die von TI noch als Sample bekomme. Als Student war 
das für meine Diplomarbeit kein Thema. Jetzt als Privatperson muss ich 
mal schauen ....

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, danke für den Hinweis.

Mir ist noch folgendes aufgefallen: Der Cyclone II kann direkt LVDS 
ausgeben. Dabei werden zwei benachbarte Pins, A2,B2  A3,B3 usw. 
verwendet. Leider haben die Designer des DE1-Board Zeile A und Zeile B 
jeweils auf einen Pfostenstecker gelegt. Die LVDS-Leitungen sollten aber 
so nah wie möglich zusammen sein oder?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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).

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tilo Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@John-eric K. (mockup):
Passt schon, gut zu wissen, dass man sich mit anderen austauschen kann.

Zum Framing ist mir auch noch eine Kleinigkeit unklar. Wo genau wird 
HSync und VSync gesendet?

Bei mit im Datenblatt steht: Vertical: Active_Lines 800, Blanking 16
Horizontal: Active_Lines 1280, Blanking 128


Ich sende im Moment folgendes:

8 Vollständig leere Zeilen, also Enable=0, beide Syncs auf 1, da 
invertiert.
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.
Zum Anschluss werden 6 leere Zeilen und danach 2 Zeilen lang HSync=0 für 
den Seitenwechsel gesendet.

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

Ich denke den Rest ich soweit hinbekommen, morgen wird das Display 
angeschlossen. Im Moment verwende ich einen Pixeltakt von 50MHz. Die für 
LVDS notwendigen 350MHz bekomme ich mit dem FPGA gerade noch so hin. Mal 
schaun, was raus kommt .....

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, kann gut sein, dass ich VSync und HSync verwechsele

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?

Autor: Stefan Wimmer (wswbln)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...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)

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also meins sieht so aus.

Geht bis Zeile 37(vcount)

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

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tilo Lutz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab einen Testgenerator programmiert und angeschlossen. 
Natürlich hat nichts funktioniert. Die Hintergrundbeleuchtung und das 
Display gehen an, allerdings bleibt es schwarz.

Ich habe die drei Datenleitungspaare und Das Clock Paar angeschlossen. 
Neben der Stromversorgung ist sonst nichts angeschlossen. Ich habe hier 
leider nichts, um bei 50 bzw. 350MHz noch etwas messen zu können. Mein 
Multimeter zeigt auf allen 8Leitungen Pegel zwischen 1,38V und 1,6V an. 
Der FPGA scheint also etwas auszugeben. Auf dem DE1-Board befinden sich 
zwischen FPGA und Buchse Serienwiederstände mit 470Ohm in den 
Signalleitungen. Reicht das schon, damit kein Signal mehr ankommt?

Ich würde ungern auf dem Board rumlöten :(

Laut Simulator in Quartus scheint der Code OK zu sein. Das 
Ausgangssignal sieht so aus, wie es sein sollte (Ist leider ein wenig 
groß zum anhängen). Vielleicht hat der Code aber trotzdem etwas? In VHDL 
bin ich noch nicht so fit. Das Programm Multiplexer2 erzeugt die Daten 
für das Display. Eingangstakt sind 50MHz. Die Ausgänge sind mit den 
Eingängen von Schieberegister2 verbunden. Als Eingangstakt wird ein PLL 
(50MHzx7=350MHz) verwendet. Die Ausgangspins sind im Pin Planer als 
"LVDS" eingestellt.

Autor: Tilo Lutz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Code Schieberegister2 ....

Offensichtliche Fehler hab ich keine mehr gefunden. Hat jemand einen Tip 
für mich?


Viele Grüsse, Tilo

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mein Quellcode sieht zurzeit so aus.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/28...

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.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein extra Tool habe ich bei Altera nicht gesehen.
So bald im Pin Planer die Logic auf LVDS eingestellt wird, wird 
automatisch ein 2. Pin OutputX(n) erzeugt, über welchen das invertierte 
Signal ausgegeben wird. Die Paare sind immer fest definiert. Bei 2-3MHz 
Takt sieht das Ausgangssignal auf dem Oszi noch gut aus. Bei richtigen 
Takt sehe ich mit meinem Oszi nur noch Gleichspannung.

Jo, am Code muss ich onch ein wenig arbeiten. Ich mache im Moment quasi 
alles von hinten nach vorne durch die Brust und dann ins Auge. Ich denke 
das wird noch ;)

Ich bin mir noch ein wenig unsicher, wie das Taktsignal aussehen soll. 7 
lässt sich schlecht durch 2 Teilen, um einen symmetrischen Takt zu 
erzeugen. Wenn ich die Datenblätter richtig lese, liegt die fallende 
Flanke vorm 3. Bit und die steigende Flanke beim 6. Bit. Ich schiebe 
daher als Takt "1100011". Kann das schon das Problem sein?


Danke für deinen Code. Ich werde ihn mit meinem Vergleichen. Das ist 
aber nur der Code, mit dem du das Bild erzeugst oder? Benutzt du einen 
externen LVDS Transmitter?

Dann werde ich heute Abend noch ein paar Widerständer überbrücken ...

Viele Grüsse, Tilo

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/applic...
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.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/applic...
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

Autor: Tilo Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich habe am Ausgang des FPGA wie im DAtenblatt angegeben, entsprechende 
Widerstände angebracht. Jetzt funktioniert das Display.

Mir ist dabei eine Sache aufgefallen:
        GREEN <= "000010";
        RED <= "000000";
        BLUE <= "000000";
        IF RowCounter=100 THEN
          RED <= "111111";
          GREEN <= "000010";
          BLUE <= "000000";
        END IF;
        IF LineCounter=100 THEN
          GREEN <= "000010";
          RED <= "000000";
          BLUE <= "111111";
        END IF;

Dies ist ein Teil meines Codes ohne den Syncrahmen drum rum. Damit wird 
links eine rote senkrechte Linie und oben eine blaue waagerechte Linie 
erzeugt. Der Rest des Display ist schwarz. Was ich daran nicht verstehe: 
Warum muss das 2. Bit von Grün gesetzt sein, damit nicht ausgegeben 
wird? Wenn das 2. Bit eine Null ist, ist das ganze TFT grün.

Ich weiß, dass bei einigen Übertragungen das Sync-Signal mit Grün 
kombiniert ist, allerdings wüsste ich nicht wie.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht weil du bei der parallel-> seriell Wandlung was vertauscht 
hast?

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Selbst wenn ich etwas vertauscht hätte. Wenn alle 18 Farbbits auf "0" 
liegen, ist das TFT immer noch grün. Die Syncsignale liegen richtig an, 
sonst wären die Linien nicht an der richtigen Stelle.

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider nicht so wirklich.

Die Daten werden in folgender Reihenfolge gesendet:
L0:      GRRRRRR
L1:      BBGGGGG
L2:      EVHBBBB
CLK:   HHLLLHH
t ->

Mit: R: Rot, G: Grün, B: Blau, E: Enable; H: HSync bzw. High, V: VSync, 
L: Low

In der Simulation sieht alles gut aus und entspricht auch dem, was ich 
in den Datenblättern gesehen habe. Die 350MHz bekomme ich gerde noch 
ohne DDIOs hin.

Das Problem ist, dass sich das Display nicht so verhält wie es will. Zum 
einen stimmen die Farben nicht. Zum andern flimmern grüne Streifen an 
manchen stellen im Bild, was bei statischer Ausgabe nicht sein sollte. 
Mit den Sync-Signalen scheint auch etwas nicht zu stimmen, da auf dem 
Display auch bei fehlenden Sync-Signalen Linien an der richtigen 
Position dargestellt werden.

Wo das genaue Problem liegt habe ich noch nicht herausgefunden. Ich 
vermute, das nicht symmetrische Clock Signal bringt den PLL des Receiver 
durcheinander, wodurch Jitter entsteht.

Ich hab mir dein Timingdiagram angesehen. Was gibst du aus? Enable=off, 
HSync=High=off und VSync=low=on?

Wenn ich wieder am richtigen PC sitzte, poste ich meinen Code.

Viele Grüsse, Tilo

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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,
   library UNISIM;
   use UNISIM.vcomponents.all;
   .
   .
   OBUFDS_TxCLK : OBUFDS
   generic map (
      IOSTANDARD => "LVDS_33")
   port map (
      O  => TxCLK_p,    -- Diff_p output
      OB => TxCLK_n,    -- Diff_n output
      I  => TxCLK       -- Buffer input 
   );

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.

Autor: John-eric K. (mockup)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: John-eric K. (mockup)
Datum:

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

Autor: Tilo Lutz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sodele, ich bin leider nicht weiter gekommen. Das Display bleibt grün, 
sprich ich konnte das Problem nicht in den Griff bekommen.
Im Timingdiagramm sieht alles richtig aus :(

Hat jemand noch eine Idee?

Das Programm besteht aus den drei VHDL-Komponenten. CLK beträgt 50MHz. 
CLK_PLL wird mittels eines PLL erzeugt (50x7=350MHz)

Testbild.vhd erzeugt das Bild.

Autor: Tilo Lutz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Multiplexer mischt die Signale so, wie sie über LVDS gesendet werden 
sollen.

Autor: Tilo Lutz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mittels des Schieberegister werden die Daten gesendet.

Wo könnte das Problem liegen?

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!
  SIGNAL    RowCounter    : INTEGER RANGE 0 TO 1408 := 0;
  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
      IF LineCounter>11 AND LineCounter<812 AND
        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?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mach das so:

  signal lvdsdatabuff : std_logic_vector(20 downto 0); -- DE, VS, HS, B(5..0), G(5..0), R(5..0)
  alias de    : std_logic is lvdsdatabuff(20); 
  alias vs    : std_logic is lvdsdatabuff(19); 
  alias hs    : std_logic is lvdsdatabuff(18); 
  alias blau  : std_logic_vector(5 downto 0) is lvdsdatabuff(17 downto 12); 
  alias gruen : std_logic_vector(5 downto 0) is lvdsdatabuff(11 downto 6); 
  alias rot   : std_logic_vector(5 downto 0) is lvdsdatabuff(5 downto 0); 
   :

   -- Ausgabe
   process begin
      wait until rising_edge(CLK); -- 7*Pixeltakt
      if (lvds_cycle < 6) then  lvds_cycle <= lvds_cycle+1;
      else                      lvds_cycle <= 0;
      end if;
      lvdsoutsr0 <= lvdsoutsr0(5 downto 0) & '0'; 
      lvdsoutsr1 <= lvdsoutsr1(5 downto 0) & '0'; 
      lvdsoutsr2 <= lvdsoutsr2(5 downto 0) & '0'; 
      if (lvds_cycle = 2) then --  Daten übernehmen
         lvdsoutsr0 <= lvdsdatabuff( 6 downto  0);
         lvdsoutsr1 <= lvdsdatabuff(13 downto  7);
         lvdsoutsr2 <= lvdsdatabuff(20 downto 14);
      end if;
      if   (lvds_cycle = 1) then lvdsclkout <= '1'; -- LVDS-Takt 
      elsif(lvds_cycle = 5) then lvdsclkout <= '0';  
      end if;
      lvdsout0 <= lvdsoutsr0(6);
      lvdsout1 <= lvdsoutsr1(6);
      lvdsout2 <= lvdsoutsr2(6);
   end process;

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

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Tilo L. (katagia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Takte für eure Tips.

Ich hab das Timing nur simuliert. Mein altes Hameg geht nur bis 20MHz, 
von den Oszikabeln mal ganz abgesehen.

Danke für deinen Code Lothar. Prinzipiell sollte er das selbe wie meiner 
machen. Macht es einen Unterschied, ob man "IF rising_edge" oder "wait 
until rising_edge" verwendet?

Das mit dem niedrigeren Takt könnt ich ausprobieren. HSync bzw VSync 
kann ich als externen Trigger verwenden, dann sollte ich auch etwas 
sehen.

Eventuell kann ich auch "SignalTap" verwenden.

Ich melde mich wieder, so bald es etwas neues gibt.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Tilo Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich habs gefunden.

Die Ausgänge des FPGA auf dem DE1 Board sind mit 470 Ohm 
Serienwiederständen geschützt. Ich habe diese gegen 220 Ohm getauscht, 
damit die Pegel für LVDS stimmen. Ich habe zwar die Lötstellen 
nachgemessen aber dabei vermutlich immer leicht auf das Widerstandsarray 
gedrückt, wodurch Kontakt entsteht. Dann ist es auch nicht weiter 
verwunderlich, dass das Display bei kapazitiver Übertragung nur Blödsinn 
anzeigt ;)

Der Minimale LVDS-Takt liegt bei meinem Display bei ca. 80MHz, also 
einem Pixeltakt von 11,5MHz. Laut Spezifikation liegt das Minimum bei 
20MHz.

Nächste Baustelle ist nun das SD-Ram als Bildspeicher.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tilo:

Das ist das blöde beim FPGA: Der Fehler kann überall stecken:

- in der Hardware
- in der Hardwarebeschreibung (VHDL)
- in der Software des Softcores

Da kann man manchmal ganz schön lange an der falschen Stelle suchen.

Duke

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John-eric K. (mockup)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: John-eric K. (mockup)
Datum:

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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.