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
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
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)
@ 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
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
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
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 !!
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
