Hallo zusammen, ich möchte eine Schaltung bauen mit einem Atmega644 und einem RFM12-Modul. Meine Frage bezieht sich aber nicht direkt auf das Funkmodul selbst. Das RFM12-Modul beinhaltet einen Quarz und der so erzeugte Takt kann ausgegeben werden, um z.B. einen Mikrocontroller damit zu versorgen. Nun ist es allerdings so, dass dieser Takt beim Einschalten nur 1 MHz beträgt und über spezielle Befehle auf 10 MHz nachträglich umgeschaltet werden muss. Beim Durchlesen des Atmega644-Datenblatts unter http://www.atmel.com/dyn/resources/prod_documents/doc2593.pdf finde ich unten auf Seite 35 allerdings folgenden Hinweis: > When applying an external clock, it is required to avoid > sudden changes in the applied clock frequency > to ensure stable operation of the MCU. A variation > in frequency of more than 2% from > one clock cycle to the next can lead to unpredictable > behavior. If changes of more than 2% is > required, ensure that the MCU is kept in Reset during the changes. Ist denn so überhaupt eine Verwendung des 10 MHz Takts des RFM12 nutzbar? Eine Umschaltung kann ich erst bei laufendem Prozessor vornehmen und dann verletze ich die maximal erlaubte 2% Variation aus dem Datenblatt. Übersehe ich etwas? Ich kann nicht abschätzen, inwiefern eine solche Frequenzumschaltung gleich nach dem Einschalten des Prozessors zu Problemen führen kann. viele Grüße Stephan
@ Stephan M. (stmz) >Ist denn so überhaupt eine Verwendung des 10 MHz Takts des RFM12 >nutzbar? Ja. > Eine Umschaltung kann ich erst bei laufendem Prozessor >vornehmen und dann verletze ich die maximal erlaubte 2% Variation aus >dem Datenblatt. Theoretisch ja, praktisch funktioniert es aber, wenn gleich es da schon komische Effekte gab. Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12"
Hallo Falk, Falk Brunner schrieb: > @ Stephan M. (stmz) > >>Ist denn so überhaupt eine Verwendung des 10 MHz Takts des RFM12 >>nutzbar? > > Ja. > >> Eine Umschaltung kann ich erst bei laufendem Prozessor >>vornehmen und dann verletze ich die maximal erlaubte 2% Variation aus >>dem Datenblatt. > > Theoretisch ja, praktisch funktioniert es aber, wenn gleich es da schon > komische Effekte gab. > > Beitrag "Re: bidirektionale RS232 Funkbrücke mit RFM12" super, vielen Dank für diesen Link. Beim Überfliegen des Threads habe ich jedoch keine Beschreibung gefunden, zu welchen Problemen die schnelle Frequenzumschaltung geführt hat. Hast du da konkrete Informationen? Werde mir aber auf jeden Fall den Thread nochmal genauer durchlesen und das ganze gegebenenfalls einfach mal testen. Gruß Stephan
@ Stephan M. (stmz) >ich jedoch keine Beschreibung gefunden, zu welchen Problemen die >schnelle Frequenzumschaltung geführt hat. Hast du da konkrete >Informationen? Ja, ich war damals das Versuchskanninchen 8-0 Der Atmega8 kam durch die Umschaltung von 1 auf 10MHz aus dem Tritt. Ursache unklar, nur der Verweis aus dem Datenblatt steht als Erklärung. Ich hab es gemessen, der Takt vom RFM10 wird glitchfrei umgeschaltet, somit sollte es eigentlich keine Probleme geben. Aber wahrscheinlich ist in der Taktaufbereitung der neuen AVRs zuviel Schnickschnack drin, der sich daran unter bestimmten Umständen verschluckt. MFG Falk
Der Grund läßt sich im Datenblatt z.B. des ATMega16 unter "Instruction Execution Timing" erahnen: Innerhalb eines (externen) Clock-Zyklus erfolgen bei ALU-Operationen; - 2 Operanden lesen - Operation - Ergebnis speichern (in einen der Operanden). Diese Schritte erfolgen nacheinander und setzen voraus, daß die CPU einen aus dem externen Takt abgeleiteten schnelleren internen Takt besitzt. Derartiges wird vielfach per PLL durchgeführt. Der Regelkreis einer derartigen PLL mag Sprünge in der Steuerfrequenz nicht besonders gern. Bernhard
@Stephan M. eine Idee währe folgende Vorgehensweise ... 1. Reset 2. prüfen ob die RMF schon auf 10MHz eingestellt ist, wenn ja weiter zum normalen Programmablauf 3. Watchdog aktivieren 4. RMF auf 10MHz umschalten 5. Endlosschleife und auf den Watchdogreset warten Sascha
@ Bernhard R. (barnyhh) >Der Grund läßt sich im Datenblatt z.B. des ATMega16 unter "Instruction >Execution Timing" erahnen: >Innerhalb eines (externen) Clock-Zyklus erfolgen bei ALU-Operationen; >- 2 Operanden lesen >- Operation >- Ergebnis speichern (in einen der Operanden). Ja und? Wer sag, das dazu zwei TAKTE nötig sind? Das kann man problemlos statisch in einem Takt machen, kurze Logikdurchlaufzeiten vorausgesetzt. >Diese Schritte erfolgen nacheinander und setzen voraus, daß die CPU >einen aus dem externen Takt abgeleiteten schnelleren internen Takt >besitzt. Nein. > Derartiges wird vielfach per PLL durchgeführt. Der Regelkreis >einer derartigen PLL mag Sprünge in der Steuerfrequenz nicht besonders >gern. Schon klar, nur haben die meisten AVRs keine PLLs. Zumindest nicht laut Datenblatt. Was an versteckten Features in den Taktblöcken steckt, weiß nur Atmel. Das Datenblatt sagt dazu. "Fully Static Operation" Also nix PLL & Co. MfG Falk
Gibt es da einen Taktgenerator der den Takt im 1-2% Bereich pro Takt an den neuen Takt anpasst ? Die prinzipielle Anpassung des Externen Taktes für einen Atmega würde mich auch interessieren.
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.