Probleme 128*64 Grafik LCD TG12864B (Controller KS0108)

[malthy]

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:

$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:




Oder nochmal in Beispielbildern:



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

[MagicWSmoke]

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

[malthy]

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.

[MagicWSmoke]

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.

[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?

[MagicWSmoke]

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.

[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?

[MagicWSmoke]

Programmer zum Betrieb abgezogen?

- - - Aktualisiert - - -

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.

[malthy]

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.

[MagicWSmoke]

Ok.
Hier:

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.