Atmega8 + LCD mit externem Takt

[Steffen (Gast)]

Hallo!

# Zuerst:
Mein LCD am Atmega8 funktioniert wundervoll mit dem internen 
Standard-Takt von 1 MHz. Für eine RS232-Schnittstelle bräuchte ich aber 
nen externen Quarz.

# Nun also mein Problem:
Wenn ich per fuse-bits den 16MHz-Quarz einschalte, der auf meinem Board 
eingebaut ist, gibt das Display nur wirre Zeichen aus.

# Ich benutze folgendes Display: "DataVision DG-16080-11" von Pollin
http://www.pollin.de/shop/shop.php?cf=detail.php&pg=OA==&a=MzU2OTc4OTk=&w=OTg4OTk4&ts=0

mit dem Treiber von vsergeev, der zufällig mal das gleiche LCD auf ebay 
gefunden hat: http://www.frozeneskimo.com/samsunglcd/
Den Code hab' ich soweit wie nötig angepasst, mit dem internen Takt 
läuft das Teil.
Den veränderten Takt hab' ich dem Programm dann mittels

#define F_CPU 16000000

 mitgeteilt.

# Außerdem: Ich muss den uC natürlich nicht mit 16MHz betreiben, mir 
reicht auch weniger. Nur ist der 16MHz-Quarz eben gerade verbaut. Ich 
werd' mir schonmal n paar kleinere bei Reichelt bestellen.

Hat jemand eine Idee, was ich dabei übersehe?

Viele Grüße, Steffen.
Schöne Ostern noch!

[Otto (Gast)]

Ohne jetzt nachgesehen zu haben, würde ich behaupten, dass die Delays 
nicht mehr passen.

Otto

[Steffen (Gast)]

Jawoll, das war's. Der Programmierer des Treibers hat die notwendigen 
delays mithilfe von jeweils vier asm-nops realisiert. Bei 8 MHz scheint 
das noch zu reichen, bei 16 ist dann wohl Schluss. ;-)
Ich hab' das jetzt erst mal so gelöst:

 for (i=0;i<100;i++) __asm("nop;");

Das ist aber auch nur Zeitverschwendung, gibts bestimmt was 
sinnvolleres...

Danke Otto für den Tipp, das war das Entscheidende.

[gast (Gast)]

sinnvoll ist es das LCD auszulesen was aber wenige libs tun

wenn man den status des LCD ausließt weiß man was es fertig ist und das 
timing stellt sich automatisch ein

[Peter D. (peda)]

gast wrote:
> sinnvoll ist es das LCD auszulesen was aber wenige libs tun

Weil es unötig ist.

Wenn man überlegt programmiert, d.h. daß der User auch Zeit zum Ablesen 
hat und nicht nur Flimmern sieht, dann ist die CPU-Belastung durch das 
LCD mit Delays unerheblich.


Peter

[Peter D. (peda)]

Steffen wrote:
>

 for (i=0;i<100;i++) __asm("nop;");

Solche Pi*Daumen Programme fallen Dir irgendwas auf die Füße, laß das 
daher  besser sein.


> Das ist aber auch nur Zeitverschwendung, gibts bestimmt was
> sinnvolleres...

Ja, nutze die "delay.h", da sind funktionierende Delayfunktionen drin 
bis 6s.

Wie oben schon gesagt, ob etwas Zeitverschwendung ist, läßt sich nur 
anhand der CPU-Auslastung ermitteln.

Wenn Du aber unbedingt die Ausgaben viel schneller machen willst, als 
sie ablesbar sind, dann nimm besser die Interruptmethode:
Alle Ausgaben schreiben in den SRAM (Bildspeicher) und ein Interrupt 
gibt z.B. alle 1ms ein Zeichen aus. Damit wird die Mainloop nicht mehr 
behindert.


Peter

[hans (Gast)]

Das lesen des Displays wäre bei der Initialisierung interesant, aber da
geht es noch nicht und man braucht die Delays.
Danach könnte es nur noch in sehr gestörter Umgebung helfen,
ein hängendes Display zu erkennen. Dann dürfte aber auch der µC
so seine Probleme haben.
Wenn man die Delays an die Datenblattangaben anpasst (Zeiten
mit geringer Zugabe für die Befehle getrennt) geht auch fast keine
Zeit verloren.

gruß hans

[spess53 (Gast)]

Hi

@Peter: Für Text-LCDs kann ich deine Anmerkungen noch nachvollziehen, 
aber bei Grafik-Displays möchte ich nicht unbedingt zusehen können, wie 
sich das Bild aufbaut. Abgesehen von dem zusätzlichen RAM-Bedarf.

MfG Spess

[Hannes Lux (Gast)]

Hier geht es um ein Grafik-LCD mit 160x80 Pixeln.
Die Dreifach-NOPs dienen zum Generieren der Enable-Impulsbreite.
Das Byte-Timing wird per Busywait realisiert.

...

[Peter D. (peda)]

spess53 wrote:
> @Peter: Für Text-LCDs kann ich deine Anmerkungen noch nachvollziehen,

Richtig, meine Ausführungen bezogen sich auf ein Text-LCD.

GLCD-Libs enthalten üblicher Weise nen Busy-Test, Text-LCD-Libs üblicher 
Weise nicht. Deshalb habe ich nach Gasts Beitrag angenommen, es geht um 
ein Text-LCD.


Peter

[Frank (Gast)]

Hallo Steffen,

ich bin auf der Suche nach einem Code für das DG16080 mit Atmega8 nach 
dem Muster von vsergeev da meine Kenntnisse noch am Anfang sind wollte 
ich fragen ob Du oder jemand anderes mir den Code vielleicht zur 
Verfügung stellen könnte.

Gruß und Dank Frank