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
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?
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.
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.
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.
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).
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 ....
@ 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
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?
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
@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 .....
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.
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?
Angehängte Dateien:
-
SyncFrame.gif
41 KB
...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).
Angehängte Dateien:
-
Display.png
4,1 KB
Also meins sieht so aus. Geht bis Zeile 37(vcount) Zeile 36 ist die erste mit richtigen Daten, weshalb auch das Enable mit angeht.
Angehängte Dateien:
-
Display2.png
3,3 KB
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
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.
Code Schieberegister2 .... Offensichtliche Fehler hab ich keine mehr gefunden. Hat jemand einen Tip für mich? Viele Grüsse, Tilo
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.
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.
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
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
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:
1 | GREEN <= "000010"; |
2 | RED <= "000000"; |
3 | BLUE <= "000000"; |
4 | IF RowCounter=100 THEN |
5 | RED <= "111111"; |
6 | GREEN <= "000010"; |
7 | BLUE <= "000000"; |
8 | END IF; |
9 | IF LineCounter=100 THEN |
10 | GREEN <= "000010"; |
11 | RED <= "000000"; |
12 | BLUE <= "111111"; |
13 | 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.
Vielleicht weil du bei der parallel-> seriell Wandlung was vertauscht hast?
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.
Angehängte Dateien:
-
Transmitter.png
6,5 KB
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.
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
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"
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.
Der Multiplexer mischt die Signale so, wie sie über LVDS gesendet werden sollen.
Mittels des Schieberegister werden die Daten gesendet. Wo könnte das Problem liegen?
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.
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.
> 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?
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.
@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
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.