Ansteuerung LCD-Display mit t6369c-Chip und 16Mhz Taktfrequenz

Chesterfield93 schrieb:
> und hat eine "delay"-Funktion, die eine Verzögerung abhängig der
> Taktfrequenz verursacht.

Die wird wohl das Problem sein.

1

void delay(void)

2

{

3

  volatile unsigned char i;

4

  for(i = 0; i < (F_CPU/1000000); i++)

5

  {

6

    asm("nop");

7

  }

8

}

Ändere die probeweise, indem Du sie langsamer machst. Also entweder den 
Teiler (1000000) verkleinern oder ein zweites nop in die Schleife 
einfügen.

void GLCD_WriteData(unsigned char data)
{
  while(!(GLCD_ChceckStatus()&0x03));
  GLCD_DATA_PORT = data;
  GLCD_CTRL_PORT &= ~((1 << GLCD_WR) | (1 << GLCD_CE) | (1 << GLCD_CD));
  delay();
  GLCD_CTRL_PORT |= ((1 << GLCD_WR) | (1 << GLCD_CD)); // | (1 << 
GLCD_CE));
}

Du kannst auch mal probieren nach der letzten Zeile auch noch ein 
delay() einzufügen.

Hallo,

Danke für die schnellen Antworten!

Ich habe alles schon versucht.
Ich hab' die Delay-Funktion in der Schleife auch schon bis zu 
verschiedenen festen Wert zählen lassen, anstatt einen Teiler für F_CPU 
zu nehmen, habe den Teiler zwischen 10.000 und 32.000.000 variiert - 
also echt so ziemlich jede denkbar mögliche Zeit abgedeckt - hat alles 
nichts gebracht.
Seltsamerweise funktioniert das ganze mit interner Taktfrequenz tadellos 
- dann bauen sich zwar die Grafiken einfach leeehr langsam auf oder es 
haut bei dem 32.000er Teiler (das ist immerhin der 32-fache Wert des 
originalen) ein paar Pixelfehler rein, aber wirklich kaum...

Auch die Idee mit der delay()-Funktion an anderen Stellen hatte ich 
schon. Leider ebenfalls kein Ergebnis, egal wo ich sie mit ran hänge

Bist du sicher, dass der Compiler dein delay() nicht weg optimiert? 
Verwende doch probehalber mal das gcc _delay_us().

Alte Soft durchwühlt und fündig geworden. Bei mir lief ein solches 
Display mit 16MHz und (fast) der gleichen Lib. Einziger Unterschied, den 
ich auf die schnelle sehe:

void delay(void) {
    uint8_t i;
    for(i = 0; i < (F_CPU/1000000L); i++) {
        asm volatile ("nop\n\t"::);
        }
    }


Kabellänge übrigens etwa 15cm, normales Flachkabel.

Habe es gerade ausprobiert und bekomme keine Änderung.
Unter 8MHz immernoch alles tip top, unter 16MHz nur Müll.

Es gab ja auch unter 8 MHz mit der originalen Funktion keine Probleme 
mit der Funktion, und durch Veränderung des Teilers in der Schleife 
wurde der Aufbau des Bildes auch schneller oder langsamer. Ich zweifle 
inzwischen daran dass es an der delay()-Funktion liegt.

Es scheint so als ob der Controller das Bild im Fehlerfall mehrfach 
versucht aufzubauen und immer wieder abstürzt und von vorne anfängt - 
manchmal braucht er weit mehr als 10 Anläufe bis sich der "Home-Screen" 
aufbaut, und dann auch nur mit dem Fehler den ihr ja oben im Bild schon 
seht.

Kabellänge: ca. 40cm, Flachband.

@spess: Danke, habe es mir mal notiert, das wäre natürlich noch ne 
Möglichkeit der Optimierung. Allerdings muss ich das Display ja erstmal 
überhaupt zum laufen bringen...

Einen Watchdog habe ich nicht am laufen. Soweit ich das verstanden habe 
ist das ein Auto-Reset, den ich regelmässig nullen muss, der den Zweck 
hat ungewollte endlosschleifen zu verhindern?

Quentin schrieb:
> Offenbar müssen da irgendow 80 ns eingehalten werden. Bei 16 MHz sollten
> zwei NOP reichen.

Die NOP-Schleife wird pro 10MHz CPU-Frequenz einmal durchlaufen. Dazu 
kommt die Zeit für Call-Return. Und da es bei mir mit 16MHz gepasst hat, 
muss der Fehler bei dir an anderer Stelle liegen. Nimm doch einfach mal 
ein Scope und sieh dir die Signale an. Messen heißt Wissen.

Hallo,

vielen Dank für die vielen Ideen und Ratschläge,

Im Endeffekt hat es schinbar an einem der Daten-Pins des 
Microcontrollers gelegen.. ich habe auf Verdacht nochmal alle nach 
gelötet und jetzt passt es. Das Beinchen hatte wohl einfach einen 
minimalen Wackelkontakt.

Zur Info: mit 'nem Teiler von 2.000.000 in der delay-Funktion passt die 
Ansteuerung, wenn ich sie noch schneller mache fängt er an hier und da 
ein paar Pixel zu verhauen.