Hallo, ich versuche nun schon seit Tagen ein Display mit SSD1289 Displaycontroller anzusteuern. Leider gibt es dabei ständig Glitches und Darstellungsfehler. Heute hatte ich endlich die Möglichkeit mir das Problem mit einem Oszilloskop anzuschauen und habe dabei Störungen auf den CS, RD und RESET Leitungen festgestellt, die jeweils immer dann auftreten wenn der WR Pin umgeschaltet wird um den nächsten Pixel zu übertragen. Die Störung sieht nach einer gedämpften Schwingung aus und hat etwa 500mV Amplitude. Das Display wird von einem STM32F4Discovery Board angesteuert und ist mit ca. 15cm langen Jumper Kabeln damit verbunden. Ich habe nun 100nF Kondensatoren zwischen RESET und GND, RD und GND, CS und VCC direkt am Display angeschlossen und nun funktioniert alles. Trotzdem bin ich mit der Lösung nicht wirklich zufrieden und die Ursache der Störungen ist mir auch nicht klar. Gibt es eine bessere Möglichkeit die Leitungen zu entstören oder sind 15cm Kabel bereits zu lang?
Sebastian V. O. schrieb: > oder sind 15cm Kabel bereits zu lang? Je nach Aufbau/Verlegung, Masseverhältnissen, STützkondensatoren, Reflexionen usw. könnte da schon einiges möglich sein.
Sebastian V. O. schrieb: > Ich habe nun 100nF Kondensatoren zwischen RESET und GND, RD > und GND, CS und VCC direkt am Display angeschlossen Und wo ist der Kondensator zwischen Vcc und GND? Das ist der wichtigste überhaupt. Sebastian V. O. schrieb: > die Ursache der Störungen ist mir auch nicht klar Kurzzeitiger Zusammenbruch der Spannung beim Schalten. Dafür ist oben genannter Kondensator. Nennt sich Stützkondensator. Sebastian V. O. schrieb: > oder sind 15cm Kabel bereits zu lang? Nein. mfg.
Thomas Eckmann schrieb: > Und wo ist der Kondensator zwischen Vcc und GND? Das ist der wichtigste > überhaupt. Den habe ich natürlich als erstes probiert, ändert aber genau gar nichts an den Störungen auf den anderen Leitungen. Auf der Platine mit dem Display und auf dem STM32F4Discovery sind ja hoffentlich Stützkondensatoren an den µCs.
Sebastian V. O. schrieb: > Ich habe nun 100nF Kondensatoren zwischen RESET und GND, RD > und GND, CS und VCC direkt am Display angeschlossen und nun funktioniert > alles. Du hast jetzt nicht wirklich 100nF an RD und CS hängen, oder?
Wolfgang A. schrieb: > Du hast jetzt nicht wirklich 100nF an RD und CS hängen, oder? Doch. RD und CS brauch ich sowieso nie und RD ist ganze Zeit High und CS ganze Zeit Low. Wenn du ne bessere Idee hast wie ich CS davon abhalte auf 500mV zu steigen und RD um 500mV zu fallen dann her damit. Edit: Oder gehts dir um die Größe des Kondensators? Vermutlich reicht auch ein Kleinerer aber ich bin gerade froh, dass es überhaupt das erste mal vernünftig läuft.
:
Bearbeitet durch User
Klingt für mich nach Ground-Bounce. Spendiere doch einfach mal mehr Masseleitungen um die Induktivität zu verringern, mit der die Massen verbunden sind.
Schlumpf schrieb: > Spendiere doch einfach mal mehr Masseleitungen um die Induktivität zu > verringern, mit der die Massen verbunden sind. Und das soll ich wie genau tun? Das Display Board hat nur zwei GND Pins. Selbst wenn ich beide mit dem STM32F4Discovery verbinde ändert es nichts.
Das mit dem Ground-Bounce ist natürlich nur eine Vermutung. Du könntest an einen Pin mehrere Leitungen parallel anschließen. Hast du die Masse des Oszis am Display angeklemmt oder an deinem Discovery Board? Hast du den Massepin jeder Probe angeklemmt?
Schlumpf schrieb: > Hast du die Masse des Oszis am Display angeklemmt oder an deinem > Discovery Board? > Hast du den Massepin jeder Probe angeklemmt? Ja ich habe beide Massen angeschlossen und immer möglichst dicht dort wo ich messen möchte. Ich werde aber Morgen wohl nochmal ein wenig messen. Kann man Ground-Bounce messen wenn man sich die Differenz der beiden Gound-Planes anschaut?
Ich vermute mal, das Display ist ein TFT-China Modul, das Du parallel ansteuerst. Zunächst mal einen blöde Vorbemerkung: Wer mißt, mißt Mist. Muß hier nicht sein, wäre aber denkbar, obwohl das Dein Problem nicht löst. Möglich wäre auch ein Timing-Problem, wenn z.B. WR zu früh kommt. Hängt das Display bei Dir direkt am Bus odet an Ports? (Ich sehe gerade, der STM hat Ports und keinen herausgeführetn Bus, richtig?) In diesem Fall wäre es ggdf. eine Lösung, zunächst die Datenbits zu setzen, und danach die Steuersignale. Ich habe selber so ein TFT-Displaychen an einem Arduino-Mega getestet und dazu die Signalleitungen mittels Widerständen auf 3,3 V heruntergeteilt. Das soll (??) wichtig sein, da der SSD mit 3,3 V läuft. Probleme hatte ich keine. Good Luck, Yogy
Das Einfachste ist, einfach mal die Flankensteilheit der Ausgänge am STM32 per Software herunterzusetzen.
Hanns-Jürgen M. schrieb: > Ich vermute mal, das Display ist ein TFT-China Modul, das Du parallel > ansteuerst. Genau es ist ein billiges TFT-Modul aus China. Angesteuert wird es "manuell" über die Ports vom STM32. Ich hatte das gleiche Display auch schon an einem ATxmega benutzt und hatte dort keine Probleme. Die STM32 und ATxmega µCs werden ja schon mit 3,3V betrieben also ist kein Spannungsteiler mehr notwendig. Simon K. schrieb: > Das Einfachste ist, einfach mal die Flankensteilheit der Ausgänge am > STM32 per Software herunterzusetzen. Das hilft tatsächlich allerdings funktioniert ohne die Kondensatoren nur der Low Speed 2MHz Modus. Der nächst schnellere Modus sind direkt 50MHz und da gibts schon Probleme. Da ich gerne bei 160x144 Pixel eine Bildwiederholrate von 60Hz erreichen möchte werden die 2MHz schon knapp.
Sebastian V. O. schrieb: > Das hilft tatsächlich allerdings funktioniert ohne die Kondensatoren nur > der Low Speed 2MHz Modus. Der nächst schnellere Modus sind direkt 50MHz > und da gibts schon Probleme. Da ich gerne bei 160x144 Pixel eine > Bildwiederholrate von 60Hz erreichen möchte werden die 2MHz schon knapp. Kann man da nicht einfach die Slew-Rate einstellen? Das muss doch unabhängig von irgendwelchen Takten gehen. Da treibt der Treiber einfach mit weniger steilen Flanken. Dadurch sind die Frequenzanteile in den Flanken nicht so hochfrequent und die Ausgleichstöme kommen besser durch die Induktivitäten der Leitungen. Egal, was die Ursache für dein Problem ist, es ist immer kein Fehler, die Flanken nur so steil zu machen, wie sie sein müssen. Zu deiner Frage zum Messen des Ground Bounces: Ja, den kann man auch zwischen den Masselagen messen. Allerdings muss man schon ein bisschen den Messaufbau im Auge haben, um nicht was zu sehen, was gar nicht da ist
Angehängte Dateien:
-
ds.png
80 KB -
IMG_20141014_231308.jpg
200 KB
Schlumpf schrieb: > Kann man da nicht einfach die Slew-Rate einstellen? Das muss doch > unabhängig von irgendwelchen Takten gehen. Also was man einstellt hat ja schon mit der Flankensteilheit zu tun aber das Datenblatt gibt dazu keine Angaben in Zeiten sondern nur in Frequenzen (siehe angehänger Ausschnitt aus dem Datenblatt). Und der Low-Speed Modus bringts einfach nicht so und alles andere läuft nicht stabil. Edit: Und noch ein Foto vom Aufbau angehängt auch wenn man da eigentlich nicht zu sagen muss: Ist eben nur das STM32F4Discovery Board verbunden mit dem Display.
:
Bearbeitet durch User
Angehängte Dateien:
-
GND_2MHz.png
3,3 KB -
GND_100MHz.png
3,3 KB -
GND_VCC.png
3,2 KB
Ich habe vorhin mal versucht die Differenz zwischen den Ground Planes am Display und Discovery Board zu messen. Auf Kanal 1 ist dabei der WR Pin, gemessen am Discovery Board, und Kanal 2 die Differenz der Massen. Das Ganze habe ich bei zwei verschiedenen Flankensteilheiten gemessen. Wie man sieht ist dort ganz schon was los. Interessanterweise ändert sich die Steilheit der Flanke vom WR Pin aber kaum. Außerdem habe ich noch die Versorgungsspannung am Display gemessen (GND_VCC.png).
Meiner Meinung nach ein klarer Fall von Ground-Bounce, verursacht durch die Induktivität der Verbindungsleitungen. Beim Eintreffen des WR-Signals zieht das Display einen kurzen Strompuls, der zu einer hochfrequenten geämpften Schwingung führt. Ausführliche Beschreibung hier: http://www.analog.com/library/analogdialogue/archives/41-06/ground_bounce.pdf Ich würde mal versuchen, zu jeder Signalleitung eine Masseleitung mitzuführen, idealerweise die beiden Drähte verdrillen. Ebenso Vcc und GND zum Display dicht nebeneinander und verdrillen. Alternativ Flachbandkabel, wo jeder zweite Draht ein Massedraht ist.
Vor Allem die Verorgungsleitungen verstärken und am Display gut blocken. In den WR 10-100 OHM in Serie sollten den Spike begrenzen, zur not per RC-Tiefpassglied die Flankensteiheit reduzieren.
:
Bearbeitet durch User
Sehe ich das richtig, dass bei deiner Messung 1 Grid= 100ns sind?? Das würde ja bedeuten, dass die Flanke vom WR schön gemächlich in > 50ns daherkommt? Das ist aber extrem langsam und völlig untypisch. Bei einem einigermaßen modernen Bauteil hätte ich erwartet, dass die Flanke in kleiner 5ns durch ist. Da stimmt meiner Meingung nach noch an ganz anderer Stelle etwas nicht. Kannst du mal bitte aufzeigen, welchen Weg der WR-Pin vom Prozessor bis zu deinem Tastkopf nimmt? Also welche Bauteile/Stecker/Kabel sind da "beteiligt"?
Ach ja.. und was "kann" dein Oszi und dein Tastkopf? Nicht, dass wir uns hier über Bilder unterhalten, die mit nem 20MHz-Oszi aufgenommen wurden ;-)
Mike schrieb: > Ich würde mal versuchen, zu jeder Signalleitung eine Masseleitung > mitzuführen, idealerweise die beiden Drähte verdrillen. Leichter gesagt als getan für so einen Prototypenaufbau. Ich werde aber nacher mal versuchen mehrere/dickere Leitungen für die Versorgungsspannung zu nehmen. Schlumpf schrieb: > Kannst du mal bitte aufzeigen, welchen Weg der WR-Pin vom Prozessor bis > zu deinem Tastkopf nimmt? Also welche Bauteile/Stecker/Kabel sind da > "beteiligt"? Den Tastkopf habe ich direkt an den Pinheadern (PE11 Pin) vom Discovery Board angeschlossen. Die Klemme für Ground ca. 2cm neben dem Pin. Ich kann dir leider nicht mehr sagen was für ein Tastkopf es genau war aber irgendwas von Tektronix mit 200MHz Bandbreite. Vom Tastkopf dann direkt zum Oszi (Tektronix TDS2012C mit 100MHz Bandbreite). Ich meine ich hätte gestern noch die Rise Time von irgendeinem anderen Pin, ohne das sonst etwas am Discovery Board angeschlossen war, mit der Measure-Funktion vom Oszi gemessen und dort kamen ~41ns raus. Ich weiß aber leider nicht mehr was als Flankensteilheit eingestellt war.
:
Bearbeitet durch User
Sebastian V. O. schrieb: > Den Tastkopf habe ich direkt an den Pinheadern (PE11 Pin) vom Discovery > Board angeschlossen. Dich interessiert doch aber, wie das Signal am Display aussieht, oder? Also der WR-Impuls wird doch vom Discovery-Board erzeugt und soll dann beim Display die Übernahme der Daten bewirken. Oder habe ich das falsch verstanden? Dann wäre es doch sinnvoll, dort zu messen, wo es drauf ankommt. Also am Display gegen die Masse am Display. Nur dann weisst, du, ob das Signal, welches das Display "sieht" noch gut genug ist. 100MHz-Oszi? Bissle schlapp, um solche Flanken zu messen, aber noch kein Grund, der erklären würde, dass die Flanke 50ns braucht. Klemme doch mal einfach das Display komplett ab und wiederhole dann die Messung von gestern (also WR-Pin am Ausgang des Discovery-Boards gegen Masse des Discovery-Boards)
Und bitte krame mal den Schaltplan vom Discovery Board raus und sage uns, was zwischen µC-Pin und Messstelle alles ist.
Hab ihn mir gerade selber aus dem Netz gezogen. So wie es aussieht, gehen die Pins direkt auf den Stecker. Meines Erachtens darf die Flanke dann nicht so flach sein. Sicher, dass du am Oszi nicht so ne Bandbegrenzung von 20MHz aktiviert hast? Außerdem fällt mir auf, dass die 3,3V über einen LDO erzeugt werden. Der kann 150mA. Nur für den Fall, dass du das Display damit betreibst..
Schlumpf schrieb: > Dich interessiert doch aber, wie das Signal am Display aussieht, oder? > Also der WR-Impuls wird doch vom Discovery-Board erzeugt und soll dann > beim Display die Übernahme der Daten bewirken. Oder habe ich das falsch > verstanden? Ne das ist schon richtig, allerdings war das WR-Signal auch eher dazu gedacht um zu zeigen, dass die Störungen und Wechsel des WR-Signals zeitgleich stattfinden. Vermutlich ist auch nicht das WR-Signal alleine Schuld, da ich auch fast zeitlich die neuen Pixeldaten ausgebe. Es scheint auch einen Zusammenhang zwischen dem anzuzeigenden Bild und den Störungen zu geben. Wenn ich z.B. die unteren (oder auch oberen) 8 Bit der 16 Bit Pixeldaten konstant halte läuft es auch ohne Glitches. Schlumpf schrieb: > Klemme doch mal einfach das Display komplett ab und wiederhole dann die > Messung von gestern (also WR-Pin am Ausgang des Discovery-Boards gegen > Masse des Discovery-Boards) Mal sehen wann ich das schaffe. Ich hab selbst kein Oszi und die Messung habe ich der Uni durchgeführt. Ich werde aber wohl nacher nochmal hinfahren und dann ein Oszi für ein paar Tage leihen. Eventuell kriege ich dann auch eins mit mehr Bandbreite.
Schlumpf schrieb: > Sicher, dass du am Oszi nicht so ne Bandbegrenzung von 20MHz aktiviert > hast? Ja ziemlich sicher. Schlumpf schrieb: > Außerdem fällt mir auf, dass die 3,3V über einen LDO erzeugt werden. Der > kann 150mA. Nur für den Fall, dass du das Display damit betreibst.. Display wird über das Discovery Board mit Strom versorgt, allerdings braucht das Display weniger als 20mA. Das sollte noch drin sein (Der gesamte über USB gezogene Strom beträgt ~120mA). Zur Sicherheit habe ich es gerade noch über andere Stromversorgung angeschlossen und das ändert auch nichts.
:
Bearbeitet durch User
Sebastian V. O. schrieb: > Vermutlich ist auch nicht das WR-Signal alleine > Schuld, Das WR-Signal an sich ist sicher nicht schuld, wenn es nicht gerade einen Kurzschluss macht, aber so sieht es ja nicht aus. Aber das WR löst im Display-Modul vermutlich einen Vorgang aus, der Strom zieht. Das Businterface ist 16 Bit breit? Und wenn du davon ein Byte konstant hältst, sind die Glitches weg? Also z.B. Schreiben 0xFFFF Schreiben 0xFF00 --> OK Schreiben 0xFFFF --> OK Schreiben 0x00FF --> OK Schreiben 0xFFFF --> OK Schreiben 0x0000 --> Problem! Werden die 16 Bit gleichzeitig geschrieben, oder zweimal 8 Bit hintereinander? Kannst du mal erklären, welche Signale es an dem Interface des Display gibt und wie sie angesteuert werden?
Also das Display hat ein typisches paralleles Interface. Es gibt 16 Datenleitungen und diverse Steuerleitungen RD, WR, CS, RESET und RS (Befehle schreiben). Davon wird CS ganze Zeit auf Low gehalten (ist alles active Low) und RD auf High. RESET wird nur zu Beginn einmal für 100ms auf Low gezogen und ist sonst auch kontinuierlich High. Zum Schreiben von Registern wird RS auf Low gezogen, die Addresse des gewünschten Registers an die Datenleitungen gelegt, WR einmal kurz auf Low gezogen und dann RS wieder auf High. Das Schreiben von Pixeln ist damit identisch nur das RS High bleibt, also Daten anlegen und WR kurz auf Low. Das Display ließt die Daten bei steigender WR Flanke. Das Businterface ist 16 Bit breit und alle 16 Bits werden aufeinmal geschrieben. Mit konstant halten von Pixeln meine ich, dass ich die von anderer Quelle gelieferten Pixeldaten mit (data & 0xFF00) oder (data | 0x00FF) maskiere. Es müssen auch nicht Bits aus dem gleichen Byte sein sondern (data & 0xF00F) funktioniert auch. Generell scheint es eine Abhängigkeit von der Art und Stärke der Gliches und den anzuzeigenden Daten zu geben.
Ok, danke für die Erklärung, wie´s funktioniert. Es scheint also eine Abhängigkeit zu geben, wieviele Datenbits eines Pixels geändert werden und wie stark die Störung ist. Da es offensichtlich egal ist, welche Bits man ändert, ist ein Kurzschluss auf einem der Bits eher unwahrscheinlich. Ist dieser Effekt nur zu beobachten, wenn du immer das identische Pixel neu beschreibst, oder auch, wenn du unterschiedliche Pixel beschreibst. Also tritt der Effekt nur auf, wenn du IN einem Pixel viele Bits änderst? Fassen wir mal zusammen: Den schwächlichen LDO schließen wir aus, da du zum einen sagst, dass das Display nur 20mA benötigt und du auch durch Messung geprüft hast, dass die gesamte Anordung nur 120mA "zieht". Weiterhin hast du das Display auch separat versorgt und hoffentlich dabei auch die Massen von Board und Display verbunden ;-) Mir erscheint es aber etwas außergewöhnlich, dass das Display 20mA und der Prozessor 100mA benötigen. Aber wenn du das gemessen hast, wird das so sein. Du sagst, dass es im "Low-Speed-Modus" funktioniert. Also scheint das Display richtig angeschlossen zu sein und die Software zu funktionieren. Du hast Messungen im Low und Fast-Speed Mode gemacht. Die Flanke vom WR-Signal ist aber immer gleich langsam --> Das gibt mir zu denken Auf dem STM-Board sind keine Filter in den Leitungen, die erklären würden, dass die Umschaltung der Schaltgeschwindigkeit keine Auswirkung auf die Flanke hat. (Die Flanke ist für meinem Geschmack eh viel zu langsam) Einen bidirektionalen Port scheint es auf dem Display nicht zu geben, so dass ausgeschlossen werden kann, dass du aufgrund von Timing-Problemen einen Kurzschluss erzeugst. Ist es ein Ground Bounce und kommt von den internen Schaltvorgängen im Display, dann sollte es unabhängig davon sein, wie schnell du das Display ansteuerst. Entscheidend ist bei sowas nur die Flankensteilheit. Die ist aber offensichtlich immer mehr oder weniger identisch. Irgendwie ergibt sich für mich noch kein Bild, was letztendlich die Störungen verursacht, oder in welcher Richtung man nach der Ursache schauen muss. ich würde, wenn du wieder ein Oszi hast, auf jeden Fall mal die Flanken aufzeichnen, wenn KEIN Display angeschlossen ist.
Angehängte Dateien:
-
2MHz.png
2,6 KB -
100MHz.png
2,7 KB
Schlumpf schrieb: > Ist dieser Effekt nur zu beobachten, wenn du immer das identische Pixel > neu beschreibst, oder auch, wenn du unterschiedliche Pixel beschreibst. > > Also tritt der Effekt nur auf, wenn du IN einem Pixel viele Bits > änderst? Die Frage verstehe ich nicht ganz. Ich schreibe momentan ca. 30mal pro Sekunde (Ziel sind 60 fps) ein Fenster von 160x144 Pixeln auf dem Display voll. Dabei schreibe ich zeilenweise und setze zu Anfang jeder Zeile den Write Pointer auf die richtige Addresse und der Display Treiber erhöht dann beim Schreiben der Pixel automatisch den Write Pointer, sodass ich 160 Pixel direkt hintereinander ausgeben kann. Das Bild ist dabei momentan noch überwiegend konstant, also ich schreibe immer wieder das gleiche Bild. Komischerweise habe ich auch keine Glitches wenn ich einfache Testbilder generiere, wie etwa ein Karomuster aus schwarzen und weißen Pixeln oder eine Farbpalette. Schlumpf schrieb: > ich würde, wenn du wieder ein Oszi hast, auf jeden Fall mal die Flanken > aufzeichnen, wenn KEIN Display angeschlossen ist. Ich komme gerade aus der Uni und habe die Messung wiederholt. Dabei ist mir auch mein Fehler aufgefallen: Der Tastkopf hat die 200MHz Bandbreite nur bei 10x Dämpfung und nur 6MHz bei keiner Dämpfung. Die Flanken sind nun deutlich steiler (siehe Bilder). Im High-Speed 100MHz Modus sind schon wieder irgendwelche Überschwinger drin aber das schiebe ich auf den Messaufbau. Ich muss zugeben, dass ich bisher noch keine solche Messungen im MHz-Bereich gemacht habe. Die Tastköpfe hat vor mir auch scheinbar noch niemand benutzt, da die noch originalverpackt im Schrank lagen. Leider hatte ich das Display nicht mitgenommen, sodass ich die Messungen mit Display nicht nochmal wiederholen konnte. Eigentlich wollte ich mir ja ein Oszi ausleihen aber außer mir war niemand da. Ich werde also frühestens Montag wieder Messungen durchführen können.
Sebastian V. O. schrieb: > Ich kann dir leider nicht mehr sagen was für ein Tastkopf es genau war > aber irgendwas von Tektronix mit 200MHz Bandbreite. Und stand der auch auf 1:10 oder hast du da gar 1:1 drangehangen?
Wolfgang schrieb: > Und stand der auch auf 1:10 oder hast du da gar 1:1 drangehangen? Ne der stand auf 1:1, dass war ja mein Fehler.
Sebastian V. O. schrieb: > und der Display > Treiber erhöht dann beim Schreiben der Pixel automatisch den Write > Pointer Ah okay, das wusste ich nicht. Ich habe noch nie mit so nem Display gearbeitet und dachte, dass man jedes Pixel direkt adressieren kann. Daher auch meine Frage, ob das immer nur auftritt, wenn du immer auf das gleiche Pixel schreibst. Aber das ist ja hinfällig. Sebastian V. O. schrieb: > Dabei ist > mir auch mein Fehler aufgefallen: Sowas passiert ;-) Und jetzt sehen die Flanken auch schon eher so aus, wie ich sie erwartet hätte. Und vorallem sieht man einen Unterschied zwischen 2MHz und 100MHz. Bei 2MHz tut es, hast du ja gesagt, und bei 100MHz tut es nicht. Nun, wenn man der Messung trauen kann und die Überschwinger tatsächlich auf dem Signal vorhanden sind, dann wäre es jetzt auf jeden Fall angesagt, dass Signal mit angeschlossenem Display AM DISPLAY zu messen. Wenn die Schwinger dann stärker werden und so groß, dass sie die L-H und H-L Schwelle des WR-Eingangs überschreiten, dann würden vom Display zwei WR-Pulse erkannt und der Pixelcounter öfter inkrementiert, als du denkst ;-) Das solltest du auf jeden Fall nachprüfen. Abhilfe könnt ein Längswiderstand in der WR-Leitung schaffen. Ich würde mal mit 47 Ohm anfangen (auf der STM32-Seite) und dann nochmal am Display messen.
Schlumpf schrieb: > Abhilfe könnt ein Längswiderstand in der WR-Leitung schaffen. Ich würde > mal mit 47 Ohm anfangen Beitrag "Re: Störungen auf Steuerleitungen beseitigen" also der Tip war schon ;)
Ja, war er. Pauschal geraten. Denn du hast dich auf einen Spike bezogen, der bis dahin nicht sichtbar war. Auf den Bildern, die zu dem Zeitpunkt zu sehen waren, war das WR-Signal glatt, wie ein Babyarsch ;-) Nur die Massen gegeneinander haben sich verschoben. Und dagegen hilft ein R in der WR-Leitung erstmal gar nichts. Einen logischen Zusammenhang zwischen den damals gezeigten Bildern und deinem Vorschlag, einen R in die WR-Leitung zu hängen, gab es zu dem Zeitpunkt jedenfalls nicht. Aber stimmt schon. Man kann auch einfach mal in die Trickkiste greifen und alle Tricks rausholen, die man kennt und wenn es dann tut, ist es ja gut. Ich bin eher ein Freund davon, die URSACHE zu finden und diese zu bekämpfen :-) Aber hast recht, du hast vor mir den Vorschlag gemacht.
Schlumpf schrieb: > Ich bin eher ein Freund davon, die URSACHE zu finden und diese zu > bekämpfen :-) Ich auch, aber das Foto deds Fliegenden Aufbaus und die Aussagen das vom TO beobachtete Timing betreffend, sprachen für überschwingen aus steilen Flanken genau des Signals auf der WR Leitung Deshalb riet zu ich zu einem Längs "R" (notfalls TP) um die Flanke künstlich abzuflachen was zu einer Dämpfung des Überschwingens führen sollte. Ja schon ohne die alten oder neuen Oszilogramme gesehen zu haben. Eben rein von der Theorie her , aber nicht ins Blaue geschossen. ;) Namaste
Na ja, aber ein Längs-R in einer Steuerleitung verhindert keinen Ground-Bounce. Denn der wird immer durch eine große Stromaufnahme hervorgerufen. Diese große Stromaufnahme kann synchron mit dem WR-Impuls auftreten, da z.B. intern im Chip mit dem WR-Impuls etwas angestoßen wird, was ordentlich Strom zieht. Aber eine steile Flanke an einem hochohmigen Eingang erzeugt keinen Ground-Bounce. Und die internen Schaltvorgänge sind unabhängig von der Flankensteilheit eines Eingangs. Ich würde sogar soweit gehen, zu behaupten, dass eine flache Flanke zu einer großeren mittleren Stromaufnahme am Pin führt, als eine steile. Ich bin davon ausgegangen, dass du dir die Oszillogramme angeschaut hast. Denn wenn man die anschaut, würde man nicht dazu raten, die Flanken abzuflachen :-) Und, hast noch eine Idee, woran es liegen könnte? Der Bounce zwischen den Masselagen könnte sich auch als eine Fehlmessung herausstellen. Und da das WR-Signal jetzt bei einer richtig durchgeführten Messung gar nicht mehr so schön aussieht, wie auf den erten Bildern, würde ich auch zuerst in dieser Richtung weitermachen. Wenn man die beiden Bilder anschaut, dann ist es auch plausibel, dass es in der langsamen Einstellung funktioniert und in der schnellen nicht. Wofür ich aber immer noch keine Erklärung habe ist, dass die Störungen weg oder geringer sind, wenn man in einem Pixel weniger Bits ändert. Das leuchtet mir noch gar nicht ein, wo da der Zusammenhang sein soll. Mit der unruhigen WR-Leitung kann das meines Erachtens nichts zu tun haben. Echt rätselhaft.
Ich habe in zwei Richtungen gedacht. 1.Schwache Versorgung mit Anhebeung des Ground aufgrund erhöhter Stromspitzen, Gegenmaßnahme: Leitungsverstärkung (verringerung der Leitungs/ Übergangwiderstände)und auffangen der Stromspitzen durch bessere Blockung. 2. Überschwingen auf der WR, Gegenmaßnahme: Dämpfung Aber du hast Recht. Das Oszilogramm gab das nicht her. Die Bilder bedienten nur nur Punkt 1) Das fiel mir später auch auf. Aaber mir war das mit dem Überschwingen nicht zu unplausibel als dass ich auch hier schon den Vorschlag brachte. Nun die Strategien sind Standard. Namaste
:
Bearbeitet durch User
Schlumpf schrieb: > Mit der unruhigen WR-Leitung kann das meines Erachtens nichts zu tun > haben. nö, hat es nicht. Das ist eine typische Laständerungsfolge wobei sich allerdings auch die Bezugspegel verschieben .... > Echt rätselhaft. eher nicht Man muss die Kausalkette nicht zu Ende suchen. Es reicht die Ursache zu beheben. Das ist wie in der Medizin. Wirksamkeit ist Beweis genug, ein mathematischer Beweis durch vollständige Induktion ist zwar nett, aber nicht zwingend notwendig. Klar ist es blöd einen Fehler durch einen Anderen zu kompensieren, aber die ideale Schaltung ist ein Scholarentraum vor dem ersten Statistikseminar. Danach ist sie sie schlichte Ignoranz der Realität. Aber es soll ja auch leute geben, welche die Teilnahme an der Realität, auch nur als Gast, verweigern.
:
Bearbeitet durch User
Ich habe gerade mal einen 68 Ohm Widerstand (von dem was ich da habe am nächsten an 47 Ohm) in die WR-Leitung gepackt. Das macht die Störungen auf dem Display zwar etwas besser aber noch lange nicht fehlerfrei. Messen mit Oszi kann ich leider erst wieder ab Montag. Ich habe auch ein wenig mit verschiedenen Geschwindigkeiten rumgespielt. Wenn ich die Geschwindigkeit von den Steuerleitungen auf Low-Speed lasse und die vom Datenport auf die nächst höhere Stufe (also 25MHz nach dem Schema in den Headern von ST) ändere, dann gibt es auch schon Probleme. Es kann also nicht am WR-Signal alleine liegen. Anders herum (also Steuersignale High-Speed und Datenleitungen langsamer) scheint es generell besser zu funktionieren. Hier kann ich auch wieder wie bei den Pixeldaten fast alle Pins vom Datenport auf High-Speed stellen und es läuft. Nur alle Pins gleichzeitig High-Speed geht wieder nicht. Alles sehr merkwürdig.
Winfried J. schrieb: > Danach ist sie sie schlichte Ignoranz der Realität. Sehr schön gesagt.. das muss ich mir merken ;-) Winfried J. schrieb: > Aber es soll ja auch leute geben, welche die Teilnahme an der Realität, > auch nur als Gast, verweigern. Zu denen würde ich mich nicht zählen.. auch wenn ich am Ende immer ein besseres Gefühl habe, wenn ich alle meine Messungen und Maßnahmen wenigstens in einen kausalen Zusammenhang bringen kann. Nicht, dass ich alles verstanden haben muss, aber es ist zumindest beruhigend, wenn man keine Messung mehr auf dem Tisch liegen hat, die einem beweist, dass die Maßnahmen, die man getroffen hat und die wirksam waren, eigentlich gar keine Wirkung haben dürften ;-) Ich bin gespannt, was hier rauskommt. Aber ich tippe auch darauf, dass es eine Mischung aus starkem Überschwinger auf der WR-Leitung ist, der dann in Kombination mit dem offensichtlich entstehendem Groundbounce ausreicht, dem Display zwei WR-Impulse zu verpassen, und es somit aus dem Tritt zu bringen. Ich würde daher zuerst das WR-Signal bedämpfen, da dies einfacher zu bewerkstelligen ist. Wenn das ausreicht, ist alles gut (bei einem Aufbau für die Uni). Bei einem Aufbau für die Serie würde ich mich aber auf jeden Fall auch noch um den Groundbounce kümmern. Bessere Leitung verwenden, das Display anständig abblocken, indem man mit vielen verschiedenen Kerkos dafür sorgt, dass über ein breites Spektrum immer ein C in Resonanz ist, etc.
Sebastian, hast du mal deinen Code genauer unter die Lupe genommen? Kann es sein, dass du da noch irgendwo ne Schlamperei drin hast? Wenn du in deinem Code nicht sicherstellst, dass die Daten stabil anliegen, wenn du den WR-Impuls erzeugst, dann wäre es denkbar, dass es eine Kombination gibt bei der du mit unterschiedlichen Geschwindigkeiten auf Daten und Steuersignalen das Timing so hinrückst, dass es gerade noch so passt und im anderen Fall eben gerade nicht mehr passt.
Schlumpf schrieb: > Sebastian, hast du mal deinen Code genauer unter die Lupe genommen? > Kann es sein, dass du da noch irgendwo ne Schlamperei drin hast? Einen Softwarefehler will ich nicht ganz ausschließen aber halte ich für unwahrscheinlich. Den Displaytreiber habe ich von einem ATxmega Projekt portiert und der Code dahinter läuft auf dem PC und bei einem Kollegen mit anderem Display auch auf dem Discovery Board problemlos. Vielleicht erstelle ich aber nochmal ein einfacheres Programm, welches nur ein einziges Bild aus dem Flash anzeigt. Ich habe vorhin mal ein Video von den Glitches aufgenommen. Hilft vermutlich nicht bei der Fehlersuche ist aber schön anzuschauen: https://www.youtube.com/watch?v=29lPA7u-0oQ
Habe mir das Video gerade angeschaut. Nochmal zum Verständnis: Das Display funktioniert so, dass du in ein Register die Zeilennummer einträgst und dann wird eine Zeile, Pixel für Pixel durch Anlegen von Daten und WR-Puls durchgetickert. Und die Pixelposition wird automatisch vom Displaycontroller inkrementiert. Habe ich das richtig verstanden? Wenn das so ist und die Ursache für deine Probleme die Tatsache wäre, dass ungewollt zusätzliche WR-Impulse entstehen, dann müsste sich ja der Pixelcounter im Display "verzählen". richtig? Dann erstaunt es mich, dass vertikale Kanten aber akkurat abgebildet werden. Da würde ich dann erwarten, dass diese auch irgendwie verschoben wären.
Du gibst doch das Bild kontinuierlich immer wieder neu aus. Auch wenn sich der Inhalt nicht ändert. Also ein Standbild wird ja nicht im Display "eingefroren" sondern immer wieder neu geschrieben, oder? Wenn es Störungen auf der Leitung wären, dann wäre es doch ein sehr großer Zufall, wenn dann die Artefakte immer an der gleichen Stelle aufreten. Ich hätte jetzt eigentlich eher ein wildes Flackern erwartet, als ein eigentlich stabiles Bild mit feststehenden Artefakten.
Die gewünschte hohe Übertragungsgeschwindigkeit und die unbestimmte Impedanz des Drahtverhaus passen ganz schlecht zusammen. Ich würde hier kleine Adapter für Flachbandkabel bauen, damit alle digitalen Signale zwischen diesen beiden Modulen mit bestimmter Impedanz verbunden sind. Beispiel 3V3-D0-GND-D1-GND-...D15-GND-WR-GND-RD-GND-RE-GND-RESET └──║──┘ Alle digitalen Signale dieser Verbindung können dann gleichmäßig mit Widerständen im Signalweg bedämpft werden. Erfahrungsgemäß wird ein Wert irgendwo zwischen 33Ω und 120Ω ein guter Kompromiß zwischen Dämpfung der Überschwinger und Geschwindigkeit werden.
Genau, hast du richtig verstanden. Tatsächlich sind die vertikalen Kanten im Video erhalten aber ich habe auch schon andere Glitches gesehen, bei dem eindeutig Pixel zu häufig ausgegeben wurden. Ich kann das jetzt gerade aber nicht reproduzieren. Die Fehler sehen teilweise sehr unterschiedlich aus. Es gibt auch eine Abhängigkeit von der Position der Kabel. Wenn man ein wenig an den Kabeln wackelt werden die Störungen mehr oder wenn man sie zusammen drückt, sodass sie dicht nebeneinander verlaufen wirds etwas besser. Was ich auch absolut nicht verstehe ist, dass auf dem gesamten Bildschirm manchmal merkwürdige Farbverläufe angezeigt werden. Das Display ist so konfiguriert, dass man eigentlich nur in einen 160x144 großen Bereich in der Mitte schreiben kann. Dazu müsste man das Display umkonfigurieren aber da kurz später wieder nur der Bereich in der Mitte zu sehen ist muss dann die Konfiguration wieder stimmen. Und ich kann mir kaum vorstellen, dass sich das Display dann zufällig wieder genau richtig konfiguriert. Edit: Schlumpf schrieb: > Ich hätte jetzt eigentlich eher ein wildes Flackern erwartet, als ein > eigentlich stabiles Bild mit feststehenden Artefakten. Naja es erscheinen ja schon eher zufällig mal einzelne Zeilen die vorher nicht zu sehen waren. Wildes Flackern und geringes Flackern habe ich aber auch schon gesehen. Helge A. schrieb: > Ich würde hier kleine Adapter für Flachbandkabel bauen Wie baut man sich sowas am besten? Wohl nicht auf Lochraster und selbst ätzen tue ich nicht. Demnächst gibts sowieso eine eigene Platine für das Projekt bei dem man das Display direkt aufstecken kann. Wäre nur schön wenn man bis dahin noch etwas weiter programmieren kann.
:
Bearbeitet durch User
Sebastian V. O. schrieb: > Wenn man ein wenig an den Kabeln wackelt werden die > Störungen mehr oder wenn man sie zusammen drückt, sodass sie dicht > nebeneinander verlaufen wirds etwas besser. Dann würde ich erstmal dieses Problem angehen. Schaue, dass du die Verbindung wirklich sauber hinbekommst. Helges Vorschlag halte ich für sehr gut. Jedes Signal hat einen sauberen Bezug und somit eine definierte Impedanz. Eine schneller Versuch wäre auch, die Kabel ordentlich nebeneinander zu legen, wie wenn es ein Flachbandkabel wäre und dann so zu fixieren (Klebeband). Das ganze dann in Alufolie wickeln und diese beidseitig an Masse klemmen (kurze Leitung) Vielleicht habt ihr ja an der Uni sogar selbstklebende Kupferfolie. Die kannst du sogar löten. Allerdings riskierst du dann ggf ein Übersprechen zwischen den Leitungen. Daher wäre ein direkter Umbau auf Helges Vorschlag vielleicht am sinnvollsten. Und wenn du dann schon am Basteln bist, könntest du darüber nachdenken, zumindest die Steuersignale am Display über Schmitt-Trigger wieder "sauber" zu machen. Wenn der WR-Impuls zeitlich weit genug von Schaltzeitpunkt der Datenleitungen weg ist, dann ist ein R in den Datenleitungen nicht unbedingt erforderlich. Auf das Umschaltsignal zwischen Pixelspeicher und Zeilenregister (RS) würde ich auch ein Auge werfen. Ebenso drauf achten, dass das Reset-Signal sauber ist. Für das Hin- und Herschalten zwischen den Anzeigegrößen habe ich allerdings auch keine Erklärung.
Sebastian V. O. schrieb: > Wohl nicht auf Lochraster Warum nicht? Schlechter als dein Drahtverhau wird das sicher nicht :-)
Wenn eh eine kleine Verbindungsplatine mit kurzen Signalwegen kommt, ist das Phänomen wahrscheinlich nicht mehr sichtbar. Nach dem Glaubenssatz[*] Leiterinduktivität=1nH/mm hättest du grob 150nH. Jeder Impuls koppelt auf die Nachbarleiter und stößt eine gedämpfte Oszillation an aus dem Schwingkreis Leiterinduktivität + IC-Eingangskapazität. Widerstände im Signalweg können diese Oszillation ausreichend abschwächen. [*] "Glaubenssatz", weil die geometrische Anordnung Leiter + Rückleiter sowie Leiterquerschnitt unberücksichtigt sind. Es können auch 20% oder 300% dieses Schätzwertes sein.
Helge A. schrieb: > Wenn eh eine kleine Verbindungsplatine mit kurzen Signalwegen kommt, ist > das Phänomen wahrscheinlich nicht mehr sichtbar. Nein keine Verbindungsplatine sondern eine eigene Platine komplett mit STM32 Mikrocontroller usw. drauf. Das Discovery Board ist nur für erste Gehversuche um überhaupt die Machbarkeit und benötigte CPU Leistung abzuschätzen. Ich will mir darum nicht zuviel Arbeit machen. Die allgemeine Meinung scheint ja nun zu sein, dass meine Verkabelung das Problem ist und nicht für mehr als Low-Speed ausreicht. Ich werde aber noch versuchen mir auf Lochraster irgendwas mit Flachbandkabeln zu bauen und ab Montag nochmal ein paar Oszi-Messungen durchführen.
Dann sieh zu das du zwischen je zwei Signalleitung einen Massesteg bringst. Und sieh profilaktisch im neuen/zwischenboard je Signalleitung einen Dämpungswiderstand mit Möglichkeit einer Lötbrücke vor. ;) Der Drahtverhau ist jedenfalls eine Zumutung für einen kontinuierlichen Datenstrom. Und die Versorgung des Displays steht auch auf sehr wackliegen Füßen soweit ich das überblicke.
:
Bearbeitet durch User
Sebastian V. O. schrieb: > Ich habe vorhin mal ein Video von den Glitches aufgenommen. Hilft > vermutlich nicht bei der Fehlersuche ist aber schön anzuschauen: > Youtube-Video "LCD Glitches" Also, auf dem Video ist eindeutig zu sehen, dass das Display seine Taktsynchronisation verliert, quasi abstürzt. Die wenigen Displays die ich so kenne, synchonisieren sich mit einer PLL o.ä. mit irgendwelchen Signalen vom Datenbus. Wenn da zu viel Jitter ist oder die Timings nicht strikt eingehalten werden, dann passiert genau das was auf dem Video zu sehen ist: Die Logik des Displays bleibt stehen, und das Display wird nicht mehr refresht. Dann sorgen Leckströme oder das kurz davor dargestellte Bild im LCD dafür, dass die Zeilen in irgendwelchen farbliche Richtungen kippen. Das ganze ist übrigens nicht so gut für das Display, weil während der Streifen die Flüssigkristalle Gleichstrom ausgesetzt sind und sich zersetzen (können). Manche Displays vertragen nur einige Minuten, andere einige Stunden. Auf jeden Fall leidet die Lebensdauer.
So ich bin jetzt endlich nochmal dazu gekommen mich mit dem Display weiter zu beschäftigen. Seit Montag habe ich leihweise ein Oszi hier aber die korrekte Messungen mit 10x Dämpfung sahen nicht wesentlich anders aus, daher habe ich nicht nochmal hier geschrieben. Ich habe mir dann in mehreren Stunden Arbeit auf Lochraster einen Adapter gebaut um Flachbandkabel zu benutzen und jede zweite Ader auf Ground zu legen. Der Adapter sieht zwar auch ziemlich chaotisch aus, da die Pinouts vom µc und Discovery Board ziemlich verstreut liegen. Allerdings funktioniert das Display nun mit diesem Adapter und allen einstellbaren Flankensteilheiten. Ich habe dann nochmal ein paar Messungen mit dem Oszi gemacht und Signale mit dem alten Aufbau verglichen. In den angehängten Bildern ist oben jeweils der neue Adapter und unten der alte Aufbau mit Jumper Kabeln. Zuerst habe ich nochmal die Differenz zwischen Ground am Display und am Discovery Board gemessen (GND.png). Außerdem noch verschiedene Signale am Display (RESET.png, CS.png und WR.png). Hier fällt mir auf, dass die Störungen mit dem neuen Adapter zwar generell kleiner sind allerdings ist immer noch ganz schön viel los.
Der Rest an Schwingungen bzw. Überschwingern ergibt sich aus der (kleiner gewordenen) Leiterinduktivität und der Kapazität der IO-Pins. Ich vermute, du hast noch keine Widerstände in die Signalleitungen eingebaut? Immerhin funktionierts ja so schon mal :)
Ja genau das ist noch ohne Widerstände in den Leitungen. Hätte ich eventuell dazu sagen sollen. Ich bin jetzt zwar auch froh, dass es erstmal läuft aber ich glaube fast irgendwas anderes ist immer noch faul. Ich hatte mit dem Oszi auch nochmal meinen alten Aufbau mit dem ATxmega Board untersucht und auch dort viele Störungen gemessen, obwohl der Aufbau ziemlich sauber ist. Flachbandkabel (zwar ohne Ground zwischen jeder Ader) zwischen Display und Platine und am Display eine gefertige Adapterplatine. Ich habe mir jetzt auch das gleiche Display, das mein Kollege besitzt, bestellt.
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.