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
ist denn keiner hier, der sich das mal angucken könnte ? wollte eigentlich über die feiertage damit ein projekt fertigstellen :)
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
hab nach mehreren stunden versuchen immernoch kein ergebnis erreicht....so langsam wird das debuggen stressig...
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
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.