Probleme 128*64 Grafik LCD TG12864B (Controller KS0108)

Hallo!

Ich kämpfe gerade mit einem TG12864B 128x64 Pixel Dotmatrix LCD (Controller KS0108, wie's sie u. a. bei Pollin gibt). Habe die Dinger schon vielfach verwendet, immer ohne Problme. Heute hakt es aber gewaltig und ich habe keinen blassen Schimmer wo das Problem ist :-( Vielleicht seh ich den Wald vor Bäumen nicht ...

Hier zunächst ein runtergekochtes Stück Bascom Code, bei dem das Problem auftritt:

Code:

---

$regfile = "m8def.dat"
$crystal = 8000000
$framesize = 64
$swstack = 64
$hwstack = 64
$baud = 9600
$lib "glcdKS108.lib"

Config Graphlcd = 128 * 64sed , Dataport = Portb , Controlport = Portd , Ce = 1 , Ce2 = 0 , Cd = 7 , Rd = 6 , Reset = 4 , Enable = 5
Setfont Font8x8


Dim I As Byte

Cls
Showpic 0 , 0 , M22
Wait 3


Do
  Cls
  Lcd "i= " ; I
  Incr I
  Waitms 500
Loop

End


M22:
$bgf "pics\m22.bgf"

$include "font8x8.font"

---

Das Problem ist, dass die Darstellung auf dem LCD auf seltsame Wiese "corrupted" ist. Wenn ich den o.g. Code ausführe, bekomme ich folgendes zu sehen:

http://youtu.be/VBZLlThzQUE


Oder nochmal in Beispielbildern:

Anhang 25898 Anhang 25899Anhang 25900 Anhang 25901

Das erste Bild auf dem Display hat die daneben gezeigte Vorlage (als "m22.bgf" eingebunden). Irgendwie doppelt sich also die Darstellung der zweiten Displayhälfte. Text (mittels Befehl LCD(String)) wird nach dem ersten CLS in der untersten Zeile ausgegeben, danach wandert die Darstellung nach oben. Das LCD ist defintiv so angeschlossen, wie im Code behauptet, ich habe das mittlerweile fünf mal nachgemessen. Außerdem habe ich das ganze auf einem anderen LCD exakt so reproduzieren können, das LCD ist also in Ordnung. Auch den Controller habe ich gewechselt, probiert habe ich mit einem mega8 und zwei mega168, immer mit dem gleichen Resultat. Ich weiß dass es hin und wieder Timing Probleme mit diesem LCD Kontroller gibt, allerdings eigentlich erst >8MHz, außerdem sehen die anders aus. Trotzdem habe ich das ganze auch nochmal mit 1 MHz Prozessortakt probiert, ebenfalls mit dem gleichen Ergebnis. Also ich glaube ja fast dass ich etwas extrem dämliches übersehe, aber ich finde das Problem einfach nicht. Hat jemand einen Tipp für mich? Würde mich sehr freuen!

Danke!
Malte

Du verwendest Control-PortD, PD0..1 ist das UART, welches Du mit $baud = 9600 einschaltest.

Hm, ich dachte $baud setzt nur die entsprechenden Register (UBRRnH und UBRRnL). Passiert dadurch auch irgendwas mit den TXD und RXD Pins? Zumindest hat es keinen Einfluß auf das Problem wenn ich "$baud = 9600" auskommentiere, das kann also leider nicht der Grund sein.

Zitat:

---

Zitat von malthy

Hm, ich dachte $baud setzt nur die entsprechenden Register (UBRRnH und UBRRnL). Passiert dadurch auch irgendwas mit den TXD und RXD Pins?

---

Das, sowie jedes "Print", schaltet das UART ein, womit die normale Funktion der Pins außer Kraft gesetzt wird.

Okay, die Idee ist vermutlich auch gut. Aber das bloße weglassen der Baud-Definition hilft definitv nichts. Könnte ich den UART komplett und explizit ausschalten?

Zitat:

---

Zitat von malthy

Okay, die Idee ist vermutlich auch gut. Aber das bloße weglassen der Baud-Definition hilft definitv nichts. Könnte ich den UART komplett und explizit ausschalten?

---

Klar, aber der ist ohne Print und Baud erst gar nicht eingeschaltet.

Mit ist noch etwas eingefallen: könnte es sein, dass bei Weglassen der $baud Angabe im Code trotzdem die Angabe aus den "Compiler Options" in das Compilat übernommen werden? - mit den von dir beschriebenen Konsequenzen ... Kann ich das irgendwie verhindern?

Programmer zum Betrieb abgezogen?

- - - Aktualisiert - - -

Zitat:

---

Zitat von malthy

Mit ist noch etwas eingefallen: könnte es sein, dass bei Weglassen der $baud Angabe im Code trotzdem die Angabe aus den "Compiler Options" in das Compilat übernommen werden? - mit den von dir beschriebenen Konsequenzen ... Kann ich das irgendwie verhindern?

---

Meines Wissens hat nur das Baud & Print im Code diese Auswirkung. Zum Abschalten des UART: UCSRB = 0
Mach' danach ein InitLCD.

Zitat:

---

Programmer zum Betrieb abgezogen?

---

Mit und ohne probiert, macht keinen Unterschied.

Hast du eine Idee zu dem o.g. Punkt? Ich glaube nämlich schon dass du Recht hast, denn wenn ich jetzt darüber nachdenke, ist der einzigen Unterschied zu meiner Verwendung dieses LCDs in vorigen Projekten, dass es jetzt u.a. an den UART Pins (Port D) hängt.

- - - Aktualisiert - - -

sorry, warst schneller

- - - Aktualisiert - - -

Ich bin ein Stück weiter! Bilder (mit "$bgf" eingebunden und mit "Showpic" angezeigt) funktionieren jetzt fehlerfrei. Seltsamerweise läuft die Textausgabe immer noch nicht, die springt immer noch wie im o.g. Video, allerdings ist die Verdoppelung weg. Das ist jetzt hier nicht so wichtig, etwas seltsam finde ich es aber dennoch. Ich muss da nochmal dran bleiben. Auf jeden Fall schonmal vielen Dank für deine Hilfe, MagicWhiteSmoke, das hat schonmal sehr weitergeholfen.

Ok.
Hier:

Zitat:

---

Zitat von malthy

Trotzdem habe ich das ganze auch nochmal mit 1 MHz Prozessortakt probiert, ebenfalls mit dem gleichen Ergebnis.

---

wäre noch die Frage, ob Du nur den Takt per Fuse runtergestellt hast, dabei aber $crystal = 8000000 beibehalten hast. Nur so werden die Delays für's LCD länger.
Hast Du hingegen $crystal auch auf 1 MHz gesetzt, dann hat sich gar nichts geändert, da besagte LCD-Delays aus dieser Angabe berechnet werden.

Auch wenn's etwas peinlich ist, ich muss mich nochmal korrigieren: allein das Entfernen von $baud löst das Grafikproblem (nicht aber das Textproblem). Beim Rumprobieren im Code hatte ich dann doch Ce und Ce2 noch vertauscht, daher wurde die Grafik immernoch leicht vermüllt angezeigt. Sorry für den Umweg.

Zitat:

---

wäre noch die Frage, ob Du nur den Takt per Fuse runtergestellt hast

---

Auch wenn ich nur den tatsächlichen Takt (über Fuses) runterstelle und die $crystal Angabe lasse, habe ich den Darstellungsfehler bei Text (Befehl "LCD").

Wie sieht's bei der Verwendung von LCDAT aus?

"LCDAT" funktioniert tadellos. Etwas irritierend, dass "LCD" nicht geht, aber damit ist das Problem zumindest erstmal praktisch gelöst. Wobei ich auch nochmal in älteren Programmen von mir geguckt habe, ich habe bisher immer "LCDAT" verwendet, es war also eher ein zufälliger "Flüchtigkeitsfehler" hier "LCD" zu probieren... Naja, wie auch immer, auf jeden Fall vielen Dank nochmal!

Gruß
Malte

Die Bascom Hilfe ist da nicht ganz eindeutig bezüglich LCD, ich würd's so lesen, dass LCD sowohl auf Text-, als auf Grafik-Displays verwendbar ist. Andererseits wird in den Beispielen zum Grafik-Display ausschließlich LCDAT verwendet, was ein Hinweis sein könnte. Du könntest ein zusätzliches Locate vor LCD reinsetzen und schauen was passiert.

Bitte ;-)

Zitat:

---

Du könntest ein zusätzliches Locate vor LCD reinsetzen und schauen was passiert.

---

Das hatte ich probiert, der Effekt bleibt der gleiche, der Text erscheint trotz locate "irgendwo". Wobei "irgendwo" auch nicht ganz richtig ist, denn es gibt eine mehr oder weniger regelmäßige Verschiebung. Ich war allerdings zu faul die "Regel" zu ergründen. Hatte auch nochmal in der Bascom Hilfe gelesen, ja, das ist dort nicht so wirklich eindeutig dargestellt. Aber die Hilfe ist ja ohnehin nicht immer so dolle :-).

Nach Untersuchung der KS108 Lib ist des Rätsels Lösung folgende:
Bei Verwendung von LCD werden die internen Variablen ___LCDROW & ___LCDCOL nicht initialisiert, auch das CLS setzt die nicht zurück. Allerdings macht LCD da weiter, wo LCDAT aufgehört hat, eben weil LCDAT diese Variablen setzt.
Ein:

Code:

---

LCDAT 1 , 1 , "i= "
LCD I

---

dürfte also funktionieren. Es könnte einen gewissen Nutzen haben, den Rest der Zeile mit LCD, ohne Angabe der weiteren Position schreiben zu können.
Allerdings wird die Zeile nicht laufend umgebrochen, d.h. ___LCDCOL wird auch über die möglichen 128 hinaus hochgezählt, jede Zeile muss also durch ein LCDAT begonnen werden.

Danke für die Mühe das low-level abzuklären! Ich kann deine Vorhersage bestätigen, der o. g. Code führt zum beschrieben Resultat. Einen ganz konkreten Nutzen sehe ich noch nicht, aber ich werde mal versuchen mir das zu merken, vielleicht kann man es doch mal gebrauchen :-). Ansonsten fährt man mit LCDAT soweit ganz gut.

Gruß
Malte