Problem mit G-LCD-Ansteuerung

[Marc S. (Gast)]

Hallo,

Ich habe ein Problem mit der Ansteuerung eines GLCDs mit 
T6963C-Controller an einem Atmel Mega32.

Problem ist folgendes: Die Routinen funktionieren einwandfrei, wenn ich 
ein sehr großes Delay einfüge (etwa Faktor 10 dessen was im Anhang zu 
finden ist ist). Anhand des Datenblattes des T6963C sollte das Delay in 
der angegebenen .c aber eigentlcih ausreichend sein (Seite 30). Der 
Mega32 Läuft bei 16 MHZ ( ~62,5 nS/Takt).

Ich liefer im nächsten Post noch ein Bild nach, welches den Datenmüll 
des GLCDs bei obigem Delay zeigt. Wie erwähnt funktionieren die Routinen 
bei großem Delay fehlerfrei, dann entstehen mehr und mehr einzelne 
Pixelfehler (z.T. sind die fehler als Struktur erkennbar)....aber Bilder 
sagen ja mehr als tausend worte^^


Wäre Klasse wenn jemand mir sagen könnte wo der fehler liegen könnte und 
wie ich dieses nervige Problem ausmerzen kann :)


Mit freundlichen Grüßen,

Marc

[Marc S. (Gast)]

Hier noch wie versprochen das Bild vom dem, was das GLCD anzeigt.

[Marc S. (Gast)]

ist denn keiner hier, der sich das mal angucken könnte ?

wollte eigentlich über die feiertage damit ein projekt fertigstellen :)

[Ralf (Gast)]

grins Dir is schon klar, dass man auf deinem Bild nur hauptsächlich ne 
schöne Frisur und ne modern wirkende Kamera sieht? kaputtlach

Okay, ernsthaft. Ich kann leider den Code grad nicht durchgehen, 
vielleicht komm ich morgen dazu. Aber das Wort "Delay" lässt mich 
vermuten, dass du das Statusbyte des Displays ignorierst, richtig? Prüfe 
den Status, ist besser so.
Oder meinst du mit Delay die Länge der Schreib-/Lese-Signale?

Du hast auf alle Fälle n Timing Problem. Wenn sich das Delay auf die 
Länge der Schreib-/Lese-Signale bezieht, dann musst du natürlich noch 
das Delay anpassen, mit dem du einzelne Bytes an den T6963C sendest, das 
ist nämlich auch nicht ohne! Kannst du mal den Schaltplan posten?

Ich hab n T6963C mit 240x128 Pixeln an nem 8052 mit 22,1184MHz pappen, 
funktioniert wunderbar. Ich prüfe allerdings immer das Statuswort des 
T6963C, also nix mit Delay.
Wie gesagt, ich guck mal bei Gelegenheit in deinen Code (hoffentlich ist 
da ALLES drin), vielleicht find ich was...

Ralf

[Benedikt K. (benedikt)]

Ich vermute der Fehler liegt in dieser Zeile:
icht_abbruch = !(PINB || 0b11111100);
0b11111100 ist immer true, also ist abbruch immer false, daher läuft 
deine while Schleife immer nur 1x durch.

Du meinst warscheinlich
nichtabbruch=(PINB&3)!=3)

[Marc S. (Gast)]

@ Ralf

Verdammt, ich hätte mir die Haare noch machen sollen....

Im Anhang findest du den Schaltplan.

Ich prüfe den Status des LCDs.
Das Delay ist dafür da, um die Timings des T6963C einzuhalten, da sonnst 
bei 16 MIPS eventuell Probleme entstehen könnten.
Der Code den ich hier reingestellt habe ist zwar nicht der des ganzen 
µC-Projektes (da kommt noch eine Befehlsverarbeitungsstruktur drüber), 
aber er ist alles, was die LCD-Ansteuerung betrifft, insofern also 
vollständig ;)

@ Benedikt

Stimmt. Ich will ja im Prinzip nur abfragen, ob die Statusbits gesetzt 
sind oder nicht. Da habe ich mir wohl nen kleinen Denkfehler einfallen 
lassen ^^

Jo, du hast recht, genau das meine ich ^^ will wissen, ob die letzten 
beiden bits gesetzt sind (also STAA und STAB des LCDs)
....das kommt dabei raus wenn die Uni der Meinung ist 
E-TEchnik-Studenten nur ein semester lang Informatik beibringen zu 
wollen, und dann noch die bitweisen operationen in ner halben h 
abhandeln um zu C++ -Mist (Exceptions, Templates, etc...) zu kommen ^^

Hab das Programm nu mit der anderne abfragerourine ausgestattet, aber 
irgendwie zeigt es nu nur noch vollmist an....sehr merkwürdige sache

[Marc S. (Gast)]

hab nach mehreren stunden versuchen immernoch kein ergebnis 
erreicht....so langsam wird das debuggen stressig...

[Sascha F. (sascha_focus)]

Hier mal mein Source. Vielleicht hilft er dir.

Gruß Sascha

[Marc S. (Gast)]

Hi, Sascha,

danke für den Source! Habe ihn mal vergleichen und soweit eigentlich 
keine prinzipiellen Unterscheide zu meinem festgestelltt.

Mir sind aber zwei Fragen aufgekommen:

1. Mit wieviel MHZ läuft der µC auf dem diese Soft läuft ?

2. weist du, inwiefern die Funktionsaufrufe (und da machst ja häufig von 
Gebrauch) die Geschwindigkeit des Programmes verlangsamen ?

Netten Gruß, Marc

[Sascha F. (sascha_focus)]

Hi,

mein ATmega644 läüft mit 20MHz, vorher waren auch nop's drin, aber 
funktioniert auch ohne. Was spricht gegen die Funktionsaufrufe, soll man 
etwa für die eigentlich gleiche Funktion immer neuen Code schreiben. Der 
Call wird wohl nicht so lange dauern, zeitlich habe ich bis jetzt nie 
Probleme gehabt. Das längste wird wohl die Abfrage des Status dauern, 
das Display ist langsamer wie der ATmega.

Gruß Sascha

[Marc S. (Gast)]

nö, ich bin der meinung, das die Funktionsaufrufe den Quellcode sehr 
angenehm übersichtlich machen!
Ich hab meine Funktionen ja auch mit STRG+C/V da reingehaun ;)

nur bin ich mir halt auch bewusst, das das ganze etwas mehr Code 
verursacht, zum einen die calls, zum anderen werden ja auch Register 
gesichert, soweit ich weis. Und das alles macht ja der Compiler, sodass 
man keine direkte Übersicht hat, was genau alles geschieht.

Ich habe nun eine kleine Änderung an der Statusausleseeinheit getätigt 
(das ganze wie im codebeispiel oben mit einer Glob. Variable gelöst) und 
das Ganze funktioniert. Ohne jegliche NOPs oder ähnlichen Mist. :) Wo 
der Fehler lag weis nich nu zwar immernoch nicht, aber für die Suche 
habe ich nun keine zeit...

Hab das ganze Projekt (eine Art Grafikkarte) zwar nu nicht über die 
Feiertage fertigstellen können, aber zumindest funzt die Ansteuerung nun 
perfekt und mit maximaler Geschwindigkeit :)



!! Danke an alle die mir geholfen haben !!

[Marc S. (Gast)]

Ich habe noch einen Nachtrag:

Ich habe Messungen bezüglich der Füllrate des Displays gemacht. Zwar nur 
per Hand mit Stoppuhr, aber doch aussagekräftig. Im Prinzip haue ich 
einfach nur hunderttausende Pixel aufs Display. Natürlich in beiden 
Messungen genau gleich viele. Dabei bin habe ich durch simples einfügen 
von 3 NOP's in die Statusroutine einen solchen Zeitunterschied 
festgestellt:

Variante A:  18,6 S
Variante B:  15,7 S

===> ~20% !

Sämmtliche Messungen habe ich mehrmals widerholt, ihr seht den 
durchschnittswert (die Messungen waren alle fast identisch, Abweichungen 
<0,3 S).
Nun das interessante:

Die 3 NOPs wurden erst in Variante B hinzugefügt.
Also wird das ganze schneller, obwohl mehr Code ausgeführt wird !

Begründet ist das ganze wohl darin, das das LCD eine gewisse Zeitspanne 
braucht um die Daten auf den Port zu legen, und ansonnsten ab und an mal 
gelesen wird, bevor die Daten überhaupt auf dem Port liegen (!!das kann 
auch zu fehlerhaftem Einlesen des Status führen, welches sich in (wenn 
auch nur sehr seltenen) Fehlern bei der Textausgabe bei mir bemerkbar 
gemacht hat!! PinB hat ja auch unvorhersehbar Programmierte Pullups je 
nachdem was man vorher auf den port gelagt hat).

Alles in allem ergibt 18,6 / 15,7 auch einen nicht zu verachtenden 
Geschwindigkeitsunterschied von fast 20% !

Auch der obige Code von Sascha sollte (v.a. in Anbetracht der Tatsache, 
das sein Controller auch noch 25% schneller läuft als meiner) dadurch 
einen kräftigen Geschwindigkeitsschub bekommen !

Netten Gruß, Marc