gLCD Problem: Leerzeichen zeichnen oder anderen Fix

[dau45 (Gast)]

Guten Abend!

Ich bin gerade dabei einen Funkwecker zu realisieren. Basis ist ein 
Atmega32 welcher in C programmiert wird. DCF Dekodierung etc. steht 
schon und nun habe ich mein 16x2 Display durch ein 128x64 gLCD 
ausgetauscht welches ich mit der Libary von Andre 
(Beitrag "GLCD Routinen ( KS0108, HD61202 )") auch wunderbar 
ansteuern kann.

Nun habe ich ein Problem dessen Ursprung mir bekannt ist, für das mir 
aber keine Lösung einfällt:

Die Uhrzeit (siehe Anhang) wird als weiße Schrift (damit das möglich ist 
habe ich die Libary angepasst) auf schwarzem grund dargestellt. Wenn 
sich nun eine Zahl verändert wird die vorherige einfach "übergemalt", 
d.h. die Zahlen überlagern sich und die Ausgabe ist hin (wie im Anhang 
zu sehen).

Der Hintergrund mit den Grafiken etc. ist übrigens als BMP eingebunden 
und wird beim Start geladen.


Nun welche Lösungen habe ich mir schon überlegt?

1) Vor jeder Ausgabe LCD clearen und die Bitmap mit dem Hintergrund neu 
laden
=> Neuladen der BMP dauert so lange, dass die Ausgabe fürchterlich 
blinkt; Darstellungsprobgleme natürlich perfekt behoben aber Zustand 
nicht tragbar.


2) hmm vll den besagten schwarzen Streifen nicht als BMP laden sondern 
via drawFillrect immer neu zeichnen => zeichnen dauert noch länger als 
aus BMP, sieht noch schlimmer aus.



Kennt jmd eine Lösung für das Problem? Wäre für jede Hilfe sehr dankbar!

[Thomas R. (tinman)]

vllt einfach die aktuelle Uhrzeit beim "zeitwechsel" erst schwarz auf 
weiss ausgeben und dann die neue weiss auf schwarz ? Am besten nur den 
teil der sich geändert hat.

[Hannes L. (hannes)]

Wie wäre es damit?

Einen Bitmap-Ausschnitt mit einer eigenen Routine schreiben, deren 
Schleifen nur einen Teil des Bildbereiches (RAM-Adressen) abdecken und 
die Grafik byteweise ins RAM legt. Also nicht mit Pixel-Set/Clear, 
sondern durch Schreiben ins RAM auf ausgesuchte Bereiche. Das erfordert 
zwar bei jeder Pixelzeile erneutes Setzen des Adresspointers, ist aber 
schneller als Einzelpixelzugriff.

...

[dau45 (Gast)]

Danke für eure Antworten.

@Thomas: die Idee hatte ich verfolgt und es war garnicht soo schlecht, 
war aber auch mit einer großen Verzögerung verbunden... habe die gLCD 
Routine jetzt so angepasst, dass sie nicht nur die gesetzten Bits 
zeichnet sondern alle Bits eines Chars entweder weiß oder schwarz macht. 
Nun ist das Problem behoben.

@Hannes: Deinem Ansatz konnte ich leider nicht ganz folgen... Ist für 
mich wohl eine Nummer zu hoch -- das hier ist mein erstes "richtiges" 
Projekt mit dem AVR abseits von blinkenden LED's :-)



Ich habe leider nun ein neues Problem: Das zeichnen auf dem gLCD hält 
den Programmablauf immens auf! Ich habe vorher nicht genau drauf 
geachtet aber eine Sekunde dauerte ca. 1,5s... weil das schreiben auf 
dem LCD alles aufhiehlt.....
Habe das ganze dann soweit optimiert, dass immer nur die veränderte 
(Sekunden)Ziffer gezeichnet wird - das hat etwas geholfen aber das 
Problem keinesfalls behoben...

Ich habe die mylcd Lib schon nach Optimierungspotenzial durchsucht aber 
konnte keine waits o.ä. finden -- es denke er hängt so lange in der 
Schleife fest, welche die Bussy-Flag des LCD abfragt... Also sind die 
langen Verzögerungen hervorgerufen durch das LCD-Modul ansich?



Ich fürchte fast dass das außerhalb meiner Einflussnahme steht und als 
gegebene Eigenscahft des Bauteils hinzunehmen ist??


Freue mich auf Antworten -- ich bin gerade etwas Verzweifelt und 
befürchte, dass ich mein Projekt in der momentanen Form nicht 
realisieren kann -.-

[Karl H. (kbuchegg)]

dau45 schrieb:

> Ich habe leider nun ein neues Problem: Das zeichnen auf dem gLCD hält
> den Programmablauf immens auf! Ich habe vorher nicht genau drauf
> geachtet aber eine Sekunde dauerte ca. 1,5s... weil das schreiben auf
> dem LCD alles aufhiehlt.....
> Habe das ganze dann soweit optimiert, dass immer nur die veränderte
> (Sekunden)Ziffer gezeichnet wird - das hat etwas geholfen aber das
> Problem keinesfalls behoben...

Ich denke, das Problem wird darin bestehen, dass deine Buchstaben Pixel 
für Pixel gemalt werden. Das dauert nun mal. Das kann man nur dann 
optimieren, wenn man das etwas intelligenter angeht und sich zunächst im 
Speicher die darzustellenden Bytes zurechtlegt und diese rausschiebt. 
Das kann allerdings je nach Speicherorganisation der Anzeige aufwändig 
werden.

Aber ein paar Texte ausgeben, kann keine 1.5 Sekunden dauern :-)

Wie generierst du eigentlich deine Zeitinformation?
Wenn du jetzt delay sagst, dann hast du schon deinen Ansatzpunkt.

[Klaus (Gast)]

@dau45

Guck mal hier in der Libary von Andre kann man das Datenbyte 
Invertieren.
Also Invert setzen.
// ---------------------------------
// Set Data mode, and write data
// ---------------------------------
void lcd_write_data(uint8_t data ,uint8_t chip)
{
  if (invert!=0)  data = ~data;
  lcd_chip_select(chip);
  LCD_CMD_PORT |= (1<<CD);
  LCD_CMD_PORT &= ~(1<<RW);        // we're in data mode
  lcd_write(data,chip);
}

[dau45 (Gast)]

@Klaus: Danke, dass habe ich auch schon gefunden :-)


@Karl Heinz:
Das von dir beschriebene vorgehen wird in Andre's Routine "FastText" 
genannt (ich glaube zumindest, dass es das ist) - ich dachte es wäre 
aktiv. Dann habe die Libary gerade nochmal überflogen und habe gesehen, 
dass FastText nur arbeitet wenn die Startposition des Textes ein 
vielfaches von 8 ergibt.

Habe meine Position der Uhrzeit angepasst und siehe da: es läuft ohne 
Probleme!! Manchmal sieht man dan Walt vor lauter Bäumen nicht - ich 
sollte mal was Anderes machen....

Einen Delay nutze ich natürlich nicht sondern einen Timer der alle 10ms 
overflowed - da schaut er dann nach dem DCF Signal und zählt 
gleichzeitig für eine Softclock eine Variable um 1 hoch; ist die 
Variable bei 100 angekommen werden die Sekunden inkrementiert.
Die Abweichung konnte ich nur erkennen, weil der DCF-Empfänger atm nicht 
angeschlossen war.


Ich werd mal duschen gehen und ein wenig beobachten ob die Uhr nun 
wieder exakt läuft aber es sieht gut aus.