Hallo, ich muss euch (mal wieder) in meiner Verwirrung um Rat fragen (während das andere Problem noch offen ist, aber da es hier einen anderen thematischen Schwerpungt gibt einen neuen Thread). Also, ich habe erfolgreich das 64128A von Displaytech (128x64 gLCD) mit der Libary von ape [1] genutzt. Vor wenigen Tagen habe ich es leider durch unachsamkeit getötet (verpolt...) und sogleich ein neues bestellt. Heute habe ich das Neue eingelötet, welches komischerweise nicht reichtig funktioniert: die rechte Displayhälfte ist vertikal nach unten verschoben. Hier einige genauere Infos: -Grad der Verschiebung schwankt (0px, 1px, mehrere px) -manchmal erste Verschiebung ~5s nach Start, manchmal erst über eine Minute nach Start (alle 1s erfolgt eine neue Ausgabe) => Timingproblem? -gleiche Schaltung, auch an der Software nichts seitdem geändert -Wenn ich CS1 und CS2 tausche tritt der Fehler auf der anderen Displayhälfte auf => Controller ansich scheint nicht defekt zu sein -Verdrahtung durchgemessen und auch sicherheitshalber nochmal nachgelötet; scheint einwandfrei Was ich probiert habe: -alle delays um den Faktor 10 erhöht => keine Änderung -Taktrate von 8MHz auf 4 und auch 1 gesetzt => es scheint so, als sei das Problem bei geringerem Takt ausgeprägter Hat jmd Rat? Da der Fehler bei getauschten Controllern auf der anderen DIsplayhälfte auftritt, scheint das Display von der Hardware doch intakt? Aber an meiner Versuchsanordnung wurde rein garnichts verändert (weder Hadware noch Software). Ich bin etwas ratlos mit meinem Laienwissen.... [1] Beitrag "KS0108 GLCD Routinen"
>-manchmal erste Verschiebung ~5s nach Start Da könnte das in der Init helfen: WriteDisplay(0xC0); //Befehl Display Start Line 0 für jeden Controller senden >, manchmal erst über eine >Minute nach Start (alle 1s erfolgt eine neue Ausgabe) => Timingproblem? Da wird das oben kaum helfen. Du sendest irgendwas falsches zum Controller oder er erkennt irgendein Kommando nicht. Und das könnte durchaus am Timing liegen.
>Da könnte das in der Init helfen: > > WriteDisplay(0xC0); Vergiss es, das macht ape ja schon.
holger schrieb: > Da wird das oben kaum helfen. Du sendest irgendwas falsches zum > Controller oder er erkennt irgendein Kommando nicht. Und das könnte > durchaus am Timing liegen. Was mich nur wundert: a) Ich habe alle waits schon testweise um den Faktor 10 vergrößert und das brachte keine Besserung b) Warum funktionierte es bei dem Alten und bei dem Neuen nicht mehr (absolut identisches Display) Neue Erkenntnis: Der Fehler tritt auch auf der anderen Displayhälfte auf, wenn ich dort was ausgebe. Die momentane Hauptausgabe, welche alle 1s erfolgt, war auf der rechten Hälfte. Links waren mehr oder weniger statische Ausgaben. Packe ich nun die sich aktuallisierende Ausgabe auf die linke Hälfte ist der Fehler dort.
Ursache anscheinend gefunden... Die Fehler treten auf, wenn ein Interrupt während der Ausgabe ausgelöst wird. Interrupts werden in meinem Programm alle 10ms ausgelöst. Da vorher kein Interrupt gestört hat, war die Ausgabe vorher also noch spätestens 10ms beendet. Nun funkt ein Interrupt rein => Ausgabe dauert länger als 10ms. Da die waits etc. (wieder) wie vorher sind, hält die wait_while_chip_is_busy() Routine nun länger auf als beim alten LCD. D.h. das Neue braucht länger, bis es ready ist als das Alte - kann das sein?? Bzw. besser gesagt: wie kann das sein? Gleiches LCD vom gleichen Distributor hat unterschiedliche Eigenschaften?
>wait_while_chip_is_busy() Routine nun länger auf als beim alten LCD.
Vergiss den Busy Check beim KS0108. Den habe ich nie hinbekommen.
Auch fremde Sources mit Busy Check habe ich ausprobiert. Hat nie
funktioniert. Nimm feste Delays.
Die KS0108 Displays laufen scheinbar mit ziemlich unterschiedlichen
Taktraten. Wohl um den Stromverbrauch zu beeinflussen;)
Zwei Displays wo ich mal nachgemessen habe:
Pollin Display TG12864B 596kHz FCLK
Displaytech 64240A 395kHz FCLK.
Entsprechend muss man dann auch die Delays anpassen.
Kauf dir mal nen Display mit T6963, dann klappts auch mit
dem Busy Check. Und schneller sind die auch;)
holger schrieb:
> Nimm feste Delays.
Genau das habe ich gerade getan - bin bis auf eine µs runter und es
scheint perfekt zu funktionieren... muss noch ein wenig testen aber
sieht gut aus erstmal... Der Bildaufbau ist (erwartungsgemäß) nun auch
etwas flotter.
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.