Hallo Mikrocontrollerfreunde,
ich habe ein Problem mit meinem Atmega644 und würde darüber hinaus auch
eine Wissenslücke füllen wollen. Beim Programmieren habe ich mich immer
wieder über den zu schnellen Takt geärgert und habe die Fusebits auf
CKSEL=1101 SUT=11 (3.0 - 8MHz) gestellt. Das funktionierte auch ganz
gut. Als ich jedoch Probleme mit der Baudrate bekam, wollte ich ihn noch
weiter runtertakten. Mit der Auswahl CKSEL=1011 SUT=11 (0.9 - 3MHz)
sollte er nun wohl auf 3 MHz laufen. Aber leider ist er mit dem AVRISP
MKII nicht mehr erreichbar (Programmierfrequenz wurde auf 250KHz
runtergeschraubt). Der Atmega hat einen 18,432MHz als Taktgeber.
Nun die passenden Fragen:
- Muss ich jetzt einfach einen 3MHz Quarz einbauen, um den Atmega644
wieder zu erreichen?
- Fangen (zu große) Quarze ab bestimmten (niedrigen) Taktfrequenzen
nicht mehr an zu schwingen?
- Gibt es irgendwo eine Website, auf der ich mich über solche
Zusammenhänge informieren kann?
Gruß,
Dorschkopp
Heißt das, du hast einen "standard" Quarz mit 18.432 MHz angeschlossen
und Softwareseitig im µC eine andere Taktrate eingestellt?
Ich wusste gar nicht, dass ein Quarz überhaupt mit einer anderen
Freuquenz betrieben werden darf, als die, die oben drauf steht...
Hallo Alex,
ja genau das habe ich getan. Was aber wiederum bedeuten würde, dass ich
einfach einen 3MHz Quarz verlöten muss um wieder an den Mikrocontroller
zu kommen. :) Der hat ja jetzt in den Fusebits 0.9 - 3MHZ eingestellt.
Hast du noch eine interessante Seite zu dem Thema?
Gruß,
Dorschkopp
Hallo,
ein Quarz schwingt auf seiner mechanisch bedingten Freuquenz oder
garnicht.
Mit den Fuses änderst Du die Parameter des Oszillators für den Quarz.
Die sind für die jeweiligen Frequenzbereiche des rangelöteten Quarzes
optimiert. Wenn dem die nicht mehr passen, schwingt er eben garnicht
mehr an, wenn er anschwingt, schwingt er immer auf seiner aufgedruckten
Frequenz, also bei Dir auf 18,xxx MHz.
Außerdem: was bitte ist an einem schnellen AVR-Takt störend??? Dann geht
wenigstens das Programmieren schneller, weil man den ISP-Takt höher
setzen kann...
Ansonsten ja, einen Quarz mit niedriegerer Frequenz ranhängen und
richtig fusen. Sollte alles greifbare gehen, vermutlich auch bis 8MHz.
Gruß aus Berlin
Michael
äh zwar ne weile her, aber nachdem was ich gelernt hab, ist es extrem
schwirig einen Quarz ausserhalb seiner resonanzbedinnungen wirklich
Frequenzstabil zu betreiben...
Ach noch eine Anmerkung dazu:
Warum kann man dann im µC keine Taktraten einstellen sondern nur "grob
über den Daumen 3.0 -8MHZ? Bzw. 8.0-X MHz? Wird der Quarz dann nicht
auch kurzzeitig mit anderen Frequenzen betrieben, als die die oben drauf
steht?
Hmm, falls dich das Thema wirklich interessiert:
http://www.qsl.net/dk1ag/buch.html
Viel Erfolg, ich hoffe mit dem 3MHz Quarz kannst du den µC dann wieder
erreichen...
@Michael
Danke, das war eine der Aussagen, die ich hören wollte :)
Zu den Taktraten: (mal abgesehen davon, dass ich ja den CLDIV hätte
benutzen können) Ich hatte am Anfang versucht mir Ergebnisse an Ports
via LED anzeigen zu lassen. Du kannst dir vorstellen, wie lehrreich das
ist wenn man trotz Prescaler von 1024 ein durchgehendes Leuchten sieht
;)
Der Quarz allein bestimmt, mit welcher Frequenz er schwingen will!
Die Einstellungen der Fuse-bits ändert vermutlich nur die µC-interne
Oszillatorschaltung (also Kapazitäten usw.) und stellt damit lediglich
einen optimalen Zustand für den jeweiligen Frequenzbereich des Quarzes
her!
Hi Dorschkopp,
anstatt den Takt des uC zu quälen könntest Du doch auch nen simplen
sleep nach dem Schalten der LED's in Dein Programm einbauen oder?
Wieso hast Du das nicht gemacht?
Gruss
Jan
Jan Raddatz wrote:
> Hi Dorschkopp,> anstatt den Takt des uC zu quälen könntest Du doch auch nen simplen> sleep nach dem Schalten der LED's in Dein Programm einbauen oder?> Wieso hast Du das nicht gemacht?
Nen simplen sleep, soso. Überleg mal, ob die Beschäftigung mit den
sleep-Modes und den Möglichkeiten, den µC aus dem sleep auch wieder
zurückzuholen, für jemanden, der gerade versucht, die Funktionsweise der
Taktquelle zu begreifen, nicht vielleicht ein bisschen viel ist.
Vielleicht solltest Du Dich aber selber mal damit befassen. sleep ändert
nämlich gar nichts an der Problematik, eben weil man den µC ja auch
irgendwie wieder aufwecken muss. Ob der µC aktiv ist, bis der Timer
überläuft oder ob er solange schläft, spielt in diesem Zusammenhang gar
keine Rolle. Verzögerungen kann man durch einfaches Zählen der
Timer-Interrupts erreichen...
Hmm dann habe ich Dein Problem vieleicht nicht ganz verstanden. Du
schreibst, daß Du Dich über den hohen Takt ärgerst und Deine blinkenden
LED's nicht richtig sehen kannst weil die zu schnell blinken.
Mit simplem Sleep meinte ich eigentlich ne Reihe von NOP's in einer
Schleife verpackt als delay wie duselbaer schreibt.
Vieleicht hab ich aber auch Dein Problem bzw. Dein Ziel einfach falsch
verstanden.
Kann ja mal passieren :)
Gruss
Jan
duselbaer wrote:
> Ich glaube nicht, dass er wirklich sleep() gemeint hat, vielmehr eine> der Delay-Funktionen... Im Standard-C heisst das halt sleep()
Dann muss er das auch schreiben. sleep im Zusammenhang mit AVR-µCs hat
eine ziemlich genau definierte Bedeutung und hat nichts mit Standard-C
zu tun.
Ich habe es mit Timerinterrupts (hochzählen von Registern) gemacht. Da
ich aber keinen höheren Prescaler als 1024 wählen kann kam ich dann vom
µs in den ms Bereich. Meine Augen konnten es auf jeden Fall nicht
wahrnehmen :)
Da ich mich mit Assembler versuche könnte ich höchstens nop statt sleep
nehmen ;) (So cirka 10238819283432mal hintereinander)
Gruß,
Dorschkopp
Dorschkopp wrote:
> Ich habe es mit Timerinterrupts (hochzählen von Registern) gemacht.
Das ist schonmal genau die richtige Methode...
> Da ich aber keinen höheren Prescaler als 1024 wählen kann kam ich dann vom> µs in den ms Bereich. Meine Augen konnten es auf jeden Fall nicht> wahrnehmen :)
Ein 8-Bit-Timer mit Prescaler 1024 macht bei der von Dir angegebenen
Taktfrequenz ungefähr alle 14 ms einen Overflow. Wenn Du die Overflows
mit einem 8-Bit-Register zählst, läuft das Register alle 3,6 s über. Das
sollte wahrnehmbar sein.
CKDIV8 ist schon mal ne gute Möglichkeit, den Takt runterzusetzen. Aber
hast Du auch schon mal an den internen RC-Oszillator gedacht? Solange Du
nicht asynchrone serielle Datenübertragung machst, kann der nämlich
eigentlich für alle Anwendungen gut verwendet werden...
Auch der interne RC ist keine Problem fuer serielle Uebertragungen. Man
muss lediglich einen Abgleich mit einem 32k Quarz bei powerup machen.
http://www.ibrtses.com/embedded/avrosccal.html
Conrad hatte nur einen 2MHz Quartz, ich hatte gerade ein bisschen
Probleme mit dem Entlöten des alten Quarzes aber jetzt komme ich wieder
sauber auf den Mikrocontroller.
Vielen Dank für das Erklären der Umstände...
(1,53€ Lehrgeld ;) )
Gruß,
Dorschkopp
