Hi, ich habe einen 240x64 GLCD mit einem T6963C an einem mega32 zu hängen. Ich benutze die lib aus diesem Beitrag: Beitrag ""Bessere" T6963c Library" von Simon K. bzw. die aktuelle Version von seiner Seite. Es funktioniert alles so weit. Grafik und Text werden richtig angezeigt. Wenn ich jetzt aber eine Ausgabe in der while(1) Schleife habe, wird es zwar angezeigt, jedoch „wandert“ die Ausgabe ganz schnell mehrere Pixel vor und wieder zurück. Also eine art sehr schnelles Zittern (siehe Bild). Mit Grafik verhält es sich genauso. Ich habe schon alles Mögliche ausprobiert. An den Wartezeiten liegt es nicht. Statusabfrage funktioniert auch. Mit einer anderen lib habe ich das Verhalten nicht. Jedoch arbeitet diese nicht mit Autowrite. Hatte jemand bereits ähnliche Probleme? Danke für Eure Hilfe, MXM
Vielleicht stresst die permanente Ausgabe das Display intern (abgesehen davon dass es unsinnig ist). Probier mal folgendes: 1. Gib den Text aus und geh dann in eine leere while-Schleife 2. Gib den Text in der while-Schleife aus, aber setz ein Delay davor/dahinter > An den Wartezeiten liegt es nicht. Statusabfrage funktioniert auch. Wie geprüft? > Jedoch arbeitet diese nicht mit Autowrite. Hm... Autowrite inkrementiert den Adresszähler automatisch. Wenn die Funktion erneut aufgerufen wird, wird dann auch der Adresszähler wieder korrekt gesetzt? Ralf
Hilf alles nichts. Da immer das Statusbyte ausgewertet wird, kann man davon ausgehen, dass das LCD für die nächste Aktion bereit ist. -> Zeiten werden eingehalten. Auch wenn ich einen delay von 1 sek setze zittert das Bild ca. 300-500 ms. Danach ist es für den Rest der Sekunde stabil und auch richtig. Danach geht alles von vorne los. Kann jemand, der die Lib im Einsatz hat das Folgende in der while(1) Schleife ausprobieren:
1 | for(n=0;n<64;n++){ |
2 | for(i=0;i<240;i+=2){ |
3 | T6963cSetPixelXY(i, n); |
4 | }
|
5 | }
|
Es müssten senkrechte Linien zu sehen sein. Und eigentlich ohne das Rumgezittere. Danke, MXM
>Auch wenn ich einen delay von 1 sek setze zittert das Bild ca. 300-500 >ms. Änderst du einen Portpin von einem Port wo das LCD angeschlossen ist irgendwo in einem Interrupt?
>nein.. es läuft nur der Code fürs LCD.
Und wie sieht der aus?
1 | #include "T6963c.h" |
2 | #include <util/delay.h> |
3 | |
4 | int main() |
5 | {
|
6 | uint8_t n, i; |
7 | |
8 | //Initialize
|
9 | //XOR mode, internal CG, Text and Graphic, Blinking Cursor
|
10 | T6963cInit( T6963C_MODE_XOR | T6963C_CG_INTERNALROM, T6963C_TEXT_GRAPHIC); |
11 | T6963cClear(); |
12 | |
13 | while(1){ |
14 | for(n=0;n<64;n++){ |
15 | for(i=0;i<240;i+=2){ |
16 | T6963cSetPixelXY(i, n); |
17 | }
|
18 | }
|
19 | }
|
20 | |
21 | return 0; |
22 | }
|
und halt die lib.. mit Textausgabe verhält es sich genauso. MXM
>und halt die lib.. mit Textausgabe verhält es sich genauso. >Beitrag ""Bessere" T6963c Library" von Simon K. bzw. die >aktuelle Version von seiner Seite. Poste dein gottverschissenes ganzes Projekt. Oder glaubst du ich such mir das alles selber zusammen?
Funktioniert ohne Probleme auf ATega128 und Winstar WG24064A. Musste noch ein paar Portpins anpassen, aber geht. Da bewegt sich gar nichts. Schöne stabile senkrechte Linien.
Danke für deinen Test.. habe es grad mit einem mega16 ausprobiert. gleiches bild. Ich check nochmal die Leitungen. Hmm.. Könnte es auch ein LCD Bug sein? Gruß, MXM
@Holger: Ruhig bleiben :) Ton wahren :| @MXM & Holger: Könntet ihr mal vergleichen, wie die Power-Versorgung eurer Displays aussieht? Ansonsten fällt mir ausser Display defekt bzw. falsch initialisiert grad nix ein. Ralf
>@Holger: >Ruhig bleiben :) Ton wahren :| Manchmal muss man halt grob werden:( >@MXM & Holger: >Könntet ihr mal vergleichen, wie die Power-Versorgung eurer Displays >aussieht? Meine ist perfekt. 7805 mit dem üblichen Geraffel drum rum. Ich kenn mich da ganz gut aus;) Mein Display hat aber keine Hintergrundbeleuchtung. Vieleicht zappelt sein Display ja weil der Spannungsregler am abkochen ist oder die Kondis zu klein sind?
Erstmal danke für Eure Hilfe... ich habe das Problem gefunden. Der "FS" Pin (Pin19) des LCD war bei mir am PortD. In der ersten lib, die ich verwenden habe wurde er benutzt. in dieser nicht. Anscheinent muss er auf GND liegen. "Nur am Port auf logisch 0" reicht nicht. komisch.. Nun läufts.. Danke nochmal... Gruß, Maxim
> In der ersten lib, die ich verwenden habe wurde er benutzt. in dieser > nicht. > Anscheinent muss er auf GND liegen. "Nur am Port auf logisch 0" reicht > nicht. komisch.. Passt irgendwie nicht zusammen. Auf welchen Level hat die erste den Pin gelegt? Auch Null? Wenn er in der ersten verwendet wurde, und in der zweiten nicht, und du setzt ihn ausserhalb der Lib auf Null, ist das ja das gleiche. Es sei denn, du hast das in der zweiten ignoriert, was bedeutet, dass der Pin nach einem Reset auf High liegt... Ralf
@ Ralf ich habe den Pin nicht zusätzlich auf low gelegt. Da er nicht benutzt wird, muss er default nach einem Reset auf low liegen.. Scope zeigte auch 0V. In der ersten Lib wurde er folgend (nur in Init()) benutzt:
1 | if (glcd_FONT_SELECT) // = narrow (small) font |
2 | glcd_fs_high() // FS HIGH |
3 | else
|
4 | glcd_fs_low(); // FS LOW |
Gruß, MXM
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.