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...
Ich glaube nicht, dass er wirklich sleep() gemeint hat, vielmehr eine der Delay-Funktionen... Im Standard-C heisst das halt sleep() RSp
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.