GLCD mit T6963C an AVR merkwürdiges verhalten

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.

MXM

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

Projekt anbei..

MXM

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