Hallo, ich habe bei Digikey das TFT NHD-7.0-800480CTXI#-T von Newhaven bestellt. Es hat eine Auflösung von 800*480 Pixeln und einen Touchscreen (resistive). Dazu gibt es zwei Datenblätter, einmal für das ganze Display und eines für den dort verwendeten Controller SSO1963. Der Controller hängt über einen 8-Bit Bus mit CS#, D/C#, RD# und WR# am Prozessor, außerden gibt es noch einen Resetanschluß RST# (alle low active). Im Datenblatt für das ganze Display ist auch ein Codebeispiel für die Initialisierung angegeben. Dieses habe ich übernommen, mußte nur den Code etwas umschreiben, da ich als Prozessor den NXP1769 verwende, da werden die Ports anders angesprochen. Mit dem Oszilloskop konnte ich nachvollziehen, daß die Buszugriffe hardwaremäßig korrekt ablaufen, Commands und Daten (werden mit D/C# unterschieden) werden auch richtig adressiert. Aber leider rührt sich das Display überhaupt nicht. Ich kann keinerlei Pixel setzen, das Display zeigt nicht die geringste Reaktion. Nur das Backlight geht, aber das hat mit dem Display selber ja nichts zu tun, der Touchscreen ist ebenfalls vollkommen davon getrennt und wird bis jetzt noch nicht benutzt. Auch ein langsamer Zugriff im Debugger und mit zusätzlichen Delays hat nichts verändert. Hat jemand schon zufällig so ein Display mal in Betrieb genommen, zumindest ein TFT von Newhaven? Ein funktionierender Code von der Init-Routine würde mich interessieren, der bei Newhaven tut es offensichtlich nicht. Ach, ja, nach dem Init habe ich das DIsplay mit Commando 0x29 auch eingeschaltet, aber ohne Erfolg. Die Suchfunktion hat leider erst einmal nichts passendes gefunden. Gruß Andy_W
Huhu Ich hatte einen ähnlichen Effekt (aber auf einem völlig anderen Display). Da hatte ich ein par Delays während der Initialisierung nicht eingehalten. Hast Du sowas gecheckt ? Viel Erfolg Andreas
Hallo, ich habe die Delays alle probeweise verlängert, selbst beim Bustiming zwischen jeden Schritt, bei dem sich ein Steuerpin ändert war ein Delay drin. Aber leider zeigte auch das keine Wirkung. Es ist schon blöde, wenn noch gar nichts funktioniert, man hat keinerlei Hinweise, was da falsch sein könnte. Die Datenblätter und der Beispielcode widersprechen sich auch zum Teil, PLL wird eingeschaltet, bevor die Teilerfaktoren gesetzt werden (laut Datenblatt muß das anders herum gemacht werden), es wird ein Kommando verwendet, das im Datenblatt nur "reserved" ist und die Frequenz für den Pixelclock (!= PLL Frequenz) paßt auch nicht zu den verwendeten Parametern. Der Pixelclock kommt auch gar nicht hardwaremäßig vom Displaycontroller zum eigentlichen Display, es sollten ca. 31MHz sein (oder 21.25MHz nach meiner Rechnung), mit dem Skope ist aber nichts zu messen. Ich hatte auch schon zwei leicht unterschiedliche Beispielprogramme gefunden, ich habe inzwischen alle Möglichkeiten durchprobiert (z.B. auch die Teilereinstellung für die PLL vor dem Einschalten der PLL), immer noch ohne jeden Erfolg, das Display zeigt keinerlei Reaktion. Gruß Andy_W
Andreas W. schrieb: > Es ist schon blöde, wenn noch gar nichts funktioniert, man hat keinerlei > Hinweise, was da falsch sein könnte. Ohne mir Display/Controller angesehen zu haben: die 1. Kontrolle besteht im Zurücklesen der zuvor beschriebenen Register. Damit kannst Du den 'sauberen' Buszugriff überprüfen.
m.n. schrieb: > Ohne mir Display/Controller angesehen zu haben: die 1. Kontrolle besteht > im Zurücklesen der zuvor beschriebenen Register. Damit kannst Du den > 'sauberen' Buszugriff überprüfen. Guter Hinweis. Ich bin (ganz naiv) davon ausgegangen, dass der TE das getan hat. @TE Hast Du das mal gecheckt ? Viele Grüße Andreas
Hallo, so, endlich kann ich wieder an der Schaltung messen. Ein Zurücklesen habe ich jetzt auch implementiert, es funktionierte aber auch nicht. Per Debugger halte ich genau an der Stelle an, bei der CS# = 0 (Chip select), D/C# = 1 (select data register), RD# = 0 und WR# = 1 ist. Und dann stellte ich fest, daß CS# an einem anderen, unbenutzten Port angelötet war als ich dachte und der war immer high... Wohlweislich habe ich die Prozessorplatine erst einmal als Fädelplatine realisiert, weil ich schon ahnte, daß die Schaltung noch nicht gleich richtig sein wird. Nun zeigt sich immerhin schon was auf dem Display, wenn auch nicht so, wie ich es erwarte. Aber nun kann man schon etwas mehr machen und muß wohl auch an den Init-Parametern spielen, mal sehen, wann ich weiteres herausbekommen habe. Gruß Andy_W
Andreas W. schrieb: > Und > dann stellte ich fest, daß CS# an einem anderen, unbenutzten Port > angelötet war als ich dachte und der war immer high... Und ich dachte, sowas passiert nur mir ;-) Aber wenn das Display erst mal zuckt, ist das ja schon ein Schritt in die richtige Richtung :-) Grüße Andreas
Hallo, so etwas weiter herumprobiert. Schreiben und zurücklesen der Controllerregister funktioniert einwandfrei, die Buszugriffe funktioniren jetzt offensichtlich. Aber leider funktioniert das Display noch immer nicht so, wie es sollte. Schreibe ich den ganzen Framespeicher abwechselnd mit einer einheitlihen Farbe voll (z.B. Rot/Blau abwechselnd), müßte eigentlich der Bildschirm von oben nach unten mit der jeweils neuen Farbe gefüllt werden, da das Vollschreiben des Framespeichers relativ lange dauert (knapp 1s). Stattdessen blendet aber die Farbe im ganzen Bildschirm allmählich von der alten zur neuen über. Schreibe ich Testbilder, haben alle Zeilen den gleichen Inhalt und zwar etwa den Mittelwert aller geschriebenen Zeilen, man sieht imme nur senkrechte Streifen. Außerdem wird nur der linke Bereich von ca. 600*480 Pixeln angesprochen, die restlichen ca. 200 Pixel rechts bleiben komplett weiß. Das Display selbst hat 800*480 Pixel Auflösung. Egal, was ich an der Initialisierungsroutine auch ändere und variiere, die Funktion ändert sich nur marginal. Vor allem gelingt es mit nicht, unterschiedliche Zeilen darzustellen. Kennt jemand so ein Phänomen bei TFT-Displays und hat herausbekommen, was die Ursache dafür ist? So langsam befürchte ich, daß ich ein defektes Display geliefert bekommen habe. Die Verbindung vom Controller zum eigentlichen Display enthält außer den Pixeldaten nur noch einen Pixelclock und ein EN-Signal, das bei sichtbaren Pixeln high und sonst low ist. Das EN-Signal sieht korrekt aus, jede Zeile ca. 35µs lang, davon ca. 28µs high, ca. alle 17ms eine längere low-Phase für den VSYNC. Die Zeiten sind nur schnell geschätzt, das Signal sieht aber erst einmal korrekt aus. Das Supportforum von Newhaven hilft nicht wirklich weiter, ca. 80-90& aller Anfragen bleiben unbeantwortet und die anderen sind oft knapp und allgemein gehalten, gehen kaum auf das jeweilige Proble ein. Inzwischen habe ich im Datenblatt eine Emailadresse gefunden, die sich zumindest etwas nach technischem Support anhört, ob ich aber dort auf meine Anfrage eine Antwort erhalte, weiß ich nicht... Gruß Andy_W
Andreas W. schrieb: > Stattdessen blendet > aber die Farbe im ganzen Bildschirm allmählich von der alten zur neuen > über. Schreibe ich Testbilder, haben alle Zeilen den gleichen Inhalt und > zwar etwa den Mittelwert aller geschriebenen Zeilen, man sieht imme nur > senkrechte Streifen. Die Bits/Pixel sind korrekt im Controller eingestellt ? Andreas W. schrieb: > Außerdem wird nur der linke Bereich von ca. 600*480 Pixeln angesprochen, > die restlichen ca. 200 Pixel rechts bleiben komplett weiß. Über ALLE Zeilen ? Check mal die Front-Porch Einstellungen (falls der Controller sowas hat. Ich kenn das ding leider nicht). Grüße Andreas
Andreas W. schrieb: > Die Verbindung vom Controller zum eigentlichen Display enthält außer den > Pixeldaten nur noch einen Pixelclock und ein EN-Signal Wieviele 'Pixelclocks' werden im EN-aktiv Zustand ausgegeben? Etwa nur 640?
Sag mal, NORMAL_MODE (also NICHT PARTIAL_MODE) hast Du aber eingestellt ? Grüße Andreas
Hallo, Frontporch, Backporch und Synclänge habe ich für horizontal und vertikal diverse Einstellungen ausprobiert, von knapp (ca. 850*500 Pixel Brutto) bis großzügig (ca. 1200*600 Pixel Brutto). Mit Brutto meine ich Pixel pro Zeile incl. der Porches und des Syncs, analog für alle Zeilen. Das hat aber nur geringfügigen Einfluß gehabt, prinzipiell blieben die Fehler. Der Pixelclock hat gemessene knapp 30MHz, d.h. in den 28µs sichtaren Teil der Zeile sind wohl tatsächlich 800 Takte, nicht ca. 600. Wie gesagt, die Zeiten sind nur grob mit dem Analogskop gemessen, es sind aber definitiv mehr als ca. 600 Takte. Den Normal-Mode habe ich testweise auch noch explizit eingeschaltet, obwohl der als Defaultwert nach dem Reset sowieso vorhanden ist, das hat erwartungsgemäß nichts geändert, war schon im Normalmode. Ich werde heute Abend dann mal abwechselnd weiße und schwarze Zeilen schreiben und mit dem Skop die Datenleitungen zum Display ansehen, die müßten ja abwechselnd high und low sein, wenn sie richtig aus dem Controller kommen. Sind die Daten richtig, läuft der Controller korrekt und das Display hat eine Macke, ansonsten heißt es weiter suchen... Ich werde auch mal die kurze Flachbandleitungsverbindung zwischen Controller und Display durchklingeln, das ist so eine dünne biegsame, die lediglich in den Steckern eingeklemmt wird, wer weiß, wie zuverlässig die Kontakte sind oder ob das Kabel richtig montiert wurde. Gruß Andy_W
Hallo, letzte Tests haben ergeben: die RGB-Daten, die ich in einen rechteckigen Bildbereich schreibe, lese ich auch exakt wieder zurück (nur 6Bit, die 2 LSB bleiben bei meinen Funktionen beim Schreiben unberücksichtigt und beim Lesen werden die auf 0 gesetzt). Und wenn ich die Zeilen abwechselnd schwarz und weiß beschreibe, kann ich mit dem Skop sehen, daß die Daten auch so an das Display gehen. Der Controller funktioniert also offensichtlich. Nur das Display nicht... Ich befürchte, das ist defekt. Ich hoffe, das passiert nicht, wenn es längere Zeit Power hat und der Controller noch nicht initialisiert ist, was ja beim Flashen des Prozessors ja der Fall ist. Jetzt kann ich nur noch Kontakte durchklingeln, ansonsten bleibt die Frage, ob ich noch ein Display kaufen soll, die Reklamation wird bestimmt stressig bei Digikey werden, da ich das Display schon ziemlich lange bei mir herumliegen hatte, ich mußte ja erst einmal eine mechanische Halterung bauen, die Frontplatte dafür bearbeiten, eine Adapterplatine für die drei Displayanschlüsse (Controller, LDE Hintergrundbeleuchtung und Touchscreen) auf einen Flachbandkabelanschluß (konventionell mit 2-reihigen Steckern im 2.54mm-Raster) löten und schließlich habe ich auch noch die Versuchsplatine für den Prozessor mit Fädeldraht gelötet. Das dauert eben seine Zeit... Andererseits ist das Gesamtprojekt, ein digitaler Surroundvorverstärker in professioneller Qualität so teuer, daß so ein Display nicht mehr sooo sehr ins Gewicht fällt... Wenn das Projekt fertig ist (vielleicht in einem Jahr oder so...) stelle ich das hier sicher auch mal vor, wenn auch nicht in sämtlichen Details für Schaltpläne, Sourcen und VHDL-Files für die FPGAs. Aber Teile davon durchaus, auf jeden Fall auch z.B. den Treiber für das Display, wenn er denn endlich mal läuft ;-) Gruß Andy_W
Thread beobachten
Seitenaufteilung abschaltenBitte 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.