mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega8 + LCD mit externem Takt


Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&p...

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!

Autor: Otto (Gast)
Datum:

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

Otto

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.