Atmega32 mit extern Quarz und LCD

[Peter (Gast)]

Hallo,
habe versucht einen LCD-Display an einen Atmega32 anzubinden. Habe 
leider das Problem das der LCD nicht mehr funktioniert wenn ich den 
Atmega auf dem externen Quarz laufen lasse. Bin vorgegangen wie im 
AVR-GCC-Tutorial/LCD-Ansteuerung beschrieben. Beispiel Programme laufen 
-- > Fuse bits setzen
-- > Programme laufen nicht mehr bzw. LCD zeigt nichts mehr an.

Ich habe im AVR-Studio das "Fuse-Bit-Fenster" geöffnet und habe folgende 
Einstellungen für einen 16MHz externen Quarz vornehmen:

SUT_CKSEL auf "Ext. Cristal/Resonator High Freq. Startuptime 16K CK + 
64ms"
und an CKOPT ein Häkchen.
Weis da jemand was?

[Mitlesa (Gast)]

Peter schrieb:
> Weis da jemand was?

- Schwingt der Atmega32 mit dem externen Quarz (-->messen)?

- Sourcen neu compiliert mit F_CPU=<Quarzfrequenz> ?

[Peter (Gast)]

beides Ja

[Karl M. (Gast)]

Peter,

ich frage mich immer warum man nicht auch die zugehörigen Datenblätter 
und Application Notes von Atmel liest.

Ich hatte noch nie Problem mit den Atmel AVR.

[M. K. (sylaina)]

Auch CPU-Clock richtig angegeben? Clockteiler berücksichtigt, nicht dass 
da noch ein Teiler von 8 mit drin ist.

[Peter (Gast)]

Ein Atmega32 hat soweit ich weiß keinen Clockteiler. Ich benutze das 
erste Mal einen LCD. Begreife aber nicht warum er nicht läuft wenn ich 
einen externen Quarz benutze.

[Mitlesa (Gast)]

Mitlesa schrieb:
> - Schwingt der Atmega32 mit dem externen Quarz (-->messen)?
>
> - Sourcen neu compiliert mit F_CPU=<Quarzfrequenz> ?

Peter schrieb:
> beides Ja

... und den neuen Code auch (erfolgreich) in den Controller geflasht?

[Mitlesa (Gast)]

Mitlesa schrieb:
> - Sourcen neu compiliert mit F_CPU=<Quarzfrequenz> ?

Man muss womöglich - um ganz sicher zu gehen - die *.o
Dateien löschen (am besten alles im default Verzeichnis)
damit auch sichergestellt ist dass der veränderte F_CPU
Wert in allen Sourcen (-->delay) korrekt berücksichtig wird.

[M. K. (sylaina)]

Peter schrieb:
> Ein Atmega32 hat soweit ich weiß keinen Clockteiler

Natürlich hat der einen Clockteiler. Er hat vielleicht kein Fusebit 
sodass er auf 8 voreinstellbar ist aber einen Clockteiler hat auch ein 
Atmega32.

[Elcid (Gast)]

Michael K. schrieb:
> Natürlich hat der einen Clockteiler. Er hat vielleicht kein Fusebit
> sodass er auf 8 voreinstellbar ist aber einen Clockteiler hat auch ein
> Atmega32.

Nennt sich DIVCLK8 oder so ähnlich und steht bei den Fuse Bits. Einfach 
das Häkchen dahinter entfernen und Fusebits auf den Controller 
schreiben.

War mir als Anfänger auch mal passiert und hatte ein Weilchen gedauert, 
bis der Groschen gefallen war.

[Amateur (Gast)]

Ich selber habe noch kein LCD-Display programmiert, aber soweit mir 
bekannt, ist das Timing, mit delay, nicht ganz ohne.
Also würde ich mal eine 08/15-Schleife (mit Port:an delay; Port:aus; 
delay) programmieren und laden. Dann schauen, ob (vielleicht ist ja eine 
LED in der Nähe) die Zeiten stimmen.
Das würde auch die Kontrolle des Quarzes erschlagen.

[M. K. (sylaina)]

Elcid schrieb:
> Nennt sich DIVCLK8 oder so ähnlich und steht bei den Fuse Bits. Einfach
> das Häkchen dahinter entfernen und Fusebits auf den Controller
> schreiben.

Es heißt CKDIV8 und der Atmega32, der hier zum Einsatz kommt, hat dieses 
Fusebit gar nicht. Blick ins Datenblatt hilft. ;)

[Karl H. (kbuchegg)]

Michael K. schrieb:
> Elcid schrieb:
>> Nennt sich DIVCLK8 oder so ähnlich und steht bei den Fuse Bits. Einfach
>> das Häkchen dahinter entfernen und Fusebits auf den Controller
>> schreiben.
>
> Es heißt CKDIV8 und der Atmega32, der hier zum Einsatz kommt, hat dieses
> Fusebit gar nicht. Blick ins Datenblatt hilft. ;)

Ausserdem wäre es egal.
Wenn der µC tatsächlich langsamer taktet als der Wert angibt, mit dem 
die Wartezeiten berechnet wurden, dann sind alle Verzögerungen zu lang. 
Was bei einem LCD unkritisch ist.
Der umgekehrte Fall ist da bei weitem tragischer.

Erst mal nachsehen, ob er sich nicht verfused hat und der µC überhaupt 
noch läuft. Wie vorgeschlagen eine LED mittels _delay_ms blinken lassen, 
dann weiss man mehr.