Hallo, ich beschäftige mich gerade mit dem RZ Raven. Dieser Kit benutzt den AT86RF230 (TRX) und den ATmega1284P (µC). Bei dem µC besteht die Möglichkeit, dass er duch das CLKM-Signal, das der TRX ausgibt, seinen Takt erhält. Dieses CLKM Signal kann durch programmieren unterschiedlich geteilt werden. Jetzt habe ich mir mal das Datenblatt des µC durchgelesen, dort steht geschrieben: "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." Wie soll man denn den MCU im Reset halten? Ebenso gibt es auch ein Problem wenn man den TRX in den Sleep Mode bringt, dann wird das CLKM Signal deaktiviert. Eine Reaktivierung des TRX ist aber nur durch ein Signalwechsel an SLP_TR möglich den der µC erzeugen soll, aber der µC läuft ja selbst gar nicht, da er kein CLKM Signal erhält. Ich denke, dass man dieses CLKM Signal eigentlich gar nicht gebrauchen kann oder hat das schon mal jemand erfolgreich benutzt?
Thomas schrieb: > Dieses CLKM Signal kann durch programmieren unterschiedlich > geteilt werden. Die reale Möglichkeit dafür wird aber schon dadurch stark eingeschränkt, dass man im Interesse einer guten HF-Performance (Vermeidung der Einstreuung von CLKM-Oberwellen in den Empfänger- eingang) an CLKM ein RC-Filter dran hat. Wenn das für 1 MHz dimensioniert ist, kannst du CLKM dann nicht auf 4 MHz hochziehen. > Wie soll man denn den MCU im Reset halten? Wird wohl nur mit externer Logik gehen. Der AT86RF230 hat ja extra so einen Modus, bei dem die Umschaltung des CLKM erst nach einem sleep cycle erfolgt, vielleicht könnte man diesen zusammen mit einem Watchdog-Reset benutzen. (Eigentlich müsste es auch funktionieren, wenn man die MCU nur schlafen legt, denn dann ist ihr der Takt ja auch egal, wird beim Tiefschlaf ja abgeschaltet. Das geht aber wegen des nächsten Punktes hier ohnehin nicht.) > Ebenso gibt es auch ein Problem wenn man den TRX in den Sleep Mode > bringt, dann wird das CLKM Signal deaktiviert. Eine Reaktivierung des > TRX ist aber nur durch ein Signalwechsel an SLP_TR möglich den der µC > erzeugen soll, aber der µC läuft ja selbst gar nicht, da er kein CLKM > Signal erhält. Mit trickreicher Beschaltung geht das, aber die wurde meines Wissens auf dem Raven nicht gemacht: wenn man SLP_TR an einen OC2x-Pin legt, dann kann man den TRX durch einen compare match interrupt des 32-kHz-basierten Timers wieder aufwachen lassen. Der läuft auch ohne CPU-Takt weiter. > Ich denke, dass man dieses CLKM Signal eigentlich gar nicht gebrauchen > kann oder hat das schon mal jemand erfolgreich benutzt? Auf dem Raven ist es wahrscheinlich nur nutzbar, wenn man es mit den standardmäßigen 1 MHz (die ja von Anfang an da sind) benutzt. Bei einer etwas anderen Beschaltung könnte man auch einen AVR-Timer damit takten, den AVR selbst dagegen vom RC-Oszillator laufen lassen.
Hallo Jörg, ich habe mir deine Vorschläge mal durchgelesen und mal in den Datenblätter nachgelesen. Das mit dem SLP_TR an den OC2x-Pin zu legen scheint wirklich eine Möglichkeit zu sein, den CLKM nutzen zu können. Das mit dem RC-Filter habe ich mir auch mal angeschaut, also im Datenblatt vom TRX ist ja eine Apllication Circuit drin. Dort wird der Tiefpass mit R2=680 Ohm und C3=2,2pF angegeben und das soll für 1 MHz ausgelegt sein. Mit diesen Werten komme ich auf eine Grenzfrequenz von 106,38 MHz. Meiner Meinung nach würde dieses Filter auch noch Dicke für CLKM=16MHz reichen, oder habe ich jetzt einen Denkfehler.
Thomas schrieb: > Mit diesen Werten komme ich auf eine Grenzfrequenz von 106,38 MHz. > Meiner Meinung nach würde dieses Filter auch noch Dicke für CLKM=16MHz > reichen, oder habe ich jetzt einen Denkfehler. Naja, du musst analog denken. ;-) Der Zweck des Filters ist es natürlich, die Oberwellen im 2,4-GHz-Bereich hinreichend zu dämpfen (und zwar, bevor sie an die als Antenne wirkende Leitung von CLKM zum Controller kommen). Auch hast du den Einfluss der Kapazität der Leitung selbst und des Controller-Eingangs nicht berücksichtigt. Auch bei einer Frequenz unterhalb der Grenzfrequenz werden jedoch die Flanken schon verschliffen. Damit reicht das ankommende Signal u. U. nicht mehr als sauberer Takt für den AVR aus. Das Filter auf dem Raven hat eine etwas höhere Grenzfrequenz (470 Ω und 1,2 pF), wenn man mal eine Gesamtkapazität von 10 pF annimmt, müsste es wohl wirklich bis 16 MHz benutzbar sein.
Die Grenzfrequenz (beim Raven 282,18 MHz; in der Schaltung vom Datenblatt 106,38 MHz ) ist minimum ca. 1 Dekade von der Signalfrequenz( max. 16 MHz) entfernt, ich denke das dürfte ausreichen, wenn nicht könnte man es auch mit 8 MHz probieren und den "Pin-Strom" kann man ja auch noch programmieren. Selbst bei deiner Annahme von R=470 Ohm und 10 pF ergibt sich noch eine Grenzfrequenz von 33,86 MHz. Jörg, hast Du noch weitere Hard-/ Software "Optimierungs-" Vorschläge oder Probleme entdeckt die beim AT86RF230/ AT86RF231 und einem Atmel µC auftreten können?
Thomas schrieb: > Die Grenzfrequenz (beim Raven 282,18 MHz; in der Schaltung vom > Datenblatt 106,38 MHz ) ist minimum ca. 1 Dekade von der Signalfrequenz( > max. 16 MHz) entfernt, ich denke das dürfte ausreichen, wenn nicht > könnte man es auch mit 8 MHz probieren 16 MHz kannste sowieso knicken, da die hier benutzten AVRs bei >= 2,7 V Versorgungsspannung nur bis 10 MHz spezifiziert sind. > und den "Pin-Strom" kann man ja > auch noch programmieren. Aber nur nach unten, initial dürfte er auf Maximum stehen. > Jörg, hast Du noch weitere Hard-/ Software "Optimierungs-" Vorschläge > oder Probleme entdeckt die beim AT86RF230/ AT86RF231 und einem Atmel µC > auftreten können? Wenn du den Controller mit CLKM taktest, gibt es eine potenzielle Deadlock-Gefahr, falls den Controller irgendein Reset außerhalb des power-on-Resets ereilen kann: dann ,,hebt er die Hufe hoch'', d. h. alle Pins sind hochohmig. Wenn der TRX in diesem Moment im TRX_OFF war und das Pin SLP_TR aus Versehen auf high läuft, dann hast du dich selbst erschossen. Gleiches kann dir passieren, wenn du einen Reset erhälst, während der TRX schlafen war (von dem dich eigentlich der compare match des timers 2 erlösen sollte, aber der kommt nach dem Reset natürlich nicht mehr). Gegen diese Gefahr hilft wohl nur ein Pulldown-Widerstand ans SLP_TR, der wiederum jedoch zieht permanent Strom, während der TRX schläft. Am sinnvollsten ist es meiner Meinung nach, den CLKM nur als Referenz- takt an T1 zu legen und den Timer 1 damit zu takten. Der Controller läuft dann vom RC-Oszillator. Damit hast du eine kürzestmögliche Startup-Zeit des Controllers, und du kannst den Quarzoszillator des TRX komplett abschalten, wenn du ihn nicht brauchst.
Thomas schrieb: > Wie soll man denn den MCU im Reset halten? Ein Trick fällt mir dazu noch ein (der allerdings nicht durch das Datenblatt gedeckt ist). Meines Wissens resultiert die Bedingung mit der Änderung <= 2 % aus dem sogenannten "flash sampling" (was das ist, ist bei der Picopower-Beschreibung kurz erläutert). Dies wird bei niedrigen Taktfrequenzen irgendwann aktiviert, um den Stromverbrauch zu verringern. Die genaue Frequenz ist nirgends dokumentiert und sehr wahrscheinlich auch exemplarabhängig. Was aber funktionieren müsste, ist dann folgender Fahrplan: . man aktiviert das flash sampling, indem man mitttels CLKPR eine CPU-Frequenz einstellt, die sehr niedrig ist, am besten wirklich den Vorteiler auf 256 setzen . man schaltet die Frequenz von CLKM um; dank des CLKPR befindet man sich jetzt immer noch auf einer niedrigen CPU-Frequenz, sodass keine Änderung am Status des flash sampling erfolgt (8 MHz / 256 = 31,25 kHz) . man schaltet CLKPR wieder auf 1; dabei kann sich nun zwar der Status des flash samplings ändern, aber da CLKPR ein definiertes Interface ist, bei dem dieses Risiko immer besteht, muss der AVR hier Vorkehrungen besitzen, die verhindern, dass beim Umschalten Müll aus dem Flash gelesen wird
Hallo Jörg, ich hatte nun mal etwas Zeit um über deine Antworten nachzudenken. Zum Pin-Strom: Für MISO und IRQ sind 2mA, 4mA, 6mA, 8mA möglich, nach einem Reset sind 2mA eingestellt. Für den CLKM sind 2mA, 4mA, 6mA, 8mA möglich, nach einem Reset sind 4mA eingestellt. Auf die Problematik mit dem hochlaufenden SLP_TR Pin bin ich auch schon gestoßen. An eine Lösung mit dem Pull-Down hatte ich auch schon gedacht. Wenn man den Pull-Down sehr hochohmig (1 Mega Ohm) wählt, könnte man den Strom auf wenige µA drücken. Auch die Reset-Problematik könnte man damit lösen, indem man den RST#-Pin mit einem Pull-Down versieht. Es gibt noch ein Problem bei einer CLKM-Takt-Versorgung, man kann den TRX nicht mit dem RST#-Pin während des Programms resetten, da man sich ja dann selbst den Takt abdreht. Den Sinn, CLKM als Referenz an T1 von Timer1 zu legen sehe ich nicht wirklich, hast du eine Beispielsanwendung? Mir scheint, das sinnvollste ist den TRX mit 16MHz Quarz und den µC mit den internen 1MHz/8MHz laufen zulassen und zusätzlich noch einen 32,768KHz Uhrenquarz für periodisches Aufwachen.
Thomas schrieb: > Für den CLKM sind 2mA, 4mA, 6mA, 8mA möglich, nach einem Reset sind 4mA > eingestellt. OK, stimmt. > Es gibt noch ein Problem bei einer CLKM-Takt-Versorgung, man kann den > TRX nicht mit dem RST#-Pin während des Programms resetten, da man sich > ja dann selbst den Takt abdreht. Nö, wenn ich Bild 7-4 im Datenblatt des AT86RF230 richtig deute, dann ist der Quarzoszillator auch im Reset an. (Sollte man aber überprüfen.) Es gibt aber eigentlich keinen Grund für ein derartiges Vorgehen. /RESET des AVR beschaltet man normalerweise nur mit einer kleinen ESD-Schutzschaltung und führt es zum ISP-Stecker. Dagegen sollte man das /RST des '230 auf einen IO-Pin des Controllers führen, damit man auch im Betrieb ggf. einen Reset auslösen kann (Herstellen eines definierten Zustands von der Software aus). > Den Sinn, CLKM als Referenz an T1 von Timer1 zu legen sehe ich nicht > wirklich, hast du eine Beispielsanwendung? In dem Falle läuft Timer 1 dann mit einem exakten Takt, der auch einigermaßen schnell ist, sodass man Zeitgeberfunktionen im Mikrosekundenbereich damit realisieren kann (das würde mit dem 32-kHz-Timer nicht gehen). Die anderen Timer kann man ggf. mit CPU-Takt laufen lassen. Auch kann man den RC-Oszillator gegen CLKM kalibrieren auf diese Weise. (Wenn man einen 32-kHz-Quarz hat, kann man ihn natürlich auch gegen diesen kalibrieren, allerdings sollte man berücksichtigen, dass der 32-kHz-Oszillator eine Anschwingzeit von bis zu 1 s benötigt.) > Mir scheint, das sinnvollste ist den TRX mit 16MHz Quarz und den µC mit > den internen 1MHz/8MHz laufen zulassen und zusätzlich noch einen > 32,768KHz Uhrenquarz für periodisches Aufwachen. Für Betrieb bis 1,8 V herunter kann man den ATmega1281 aber nur bis maximal 4 MHz takten.
Hi Jörg, du hast recht, der Takt CLKM läuft bei einem Reset weiter. Allerdings wird das Register mit dem Teilertakt zurückgesetzt auf 1MHz, so dass bei einem nächsten Sleep der TRX dann mit 1MHz läuft sofern man das Register nicht mit dem aktuellen Wert beschreibt (Abschnitt 9.6.4 im Datenblatt) Den /RST an eine I/O-Pin des µC war ja mein gedanke. Wäre dann im Betrieb ein Reset des TRX nötig gewesen und der Takt wäre danach weg dann wäre man auch in einem Deadlock gewesen, aber das ist ja nicht der Fall. ESD-Schutzbeschaltung? Du meinst einen Widerstand und einen Kondensator in Reihe und dazwischen das /RESET Signal für den µC abgreifen. Irgendwo hab ich auch mal gelesen, dass das gar nicht nötig sei, da das intern schon im µC vorhanden sei. Mit dem 32KHz Quarz denke ich an längere Ruhezeiten die bis in den Sekundenbereich gehen können. Mit 32768Hz und einem maximalen Vorteiler von 1024 und 8Bit-Timer2 komme ich auf periodische Überlaufzeiten von 8 Sekunden. Wenn man den µC bei 1,8V nur bis maximal 4MHz takten kann, kann man dann überhaupt den eingebauten 8MHz RC-Takt noch verwenden? Oder muss ich dann unbedingt den DIV8-Vorteiler in den FuseBits setzen, dann wäre ich wieder bei 1MHz.
Thomas schrieb: > ESD-Schutzbeschaltung? Du meinst einen Widerstand und einen Kondensator > in Reihe und dazwischen das /RESET Signal für den µC abgreifen. Ja. > Irgendwo hab ich auch mal gelesen, dass das gar nicht nötig sei, da das > intern schon im µC vorhanden sei. Sender Jerewan: ja, aber... in der Regel hast du /RESET auf den ISP-Stecker geführt, und dann hast du eine externe Antenne dran. > Mit dem 32KHz Quarz denke ich an längere Ruhezeiten ... Schon klar. Dafür will man den schon haben. > Wenn man den µC bei 1,8V nur bis maximal 4MHz takten kann, kann man dann > überhaupt den eingebauten 8MHz RC-Takt noch verwenden? Nur mit Vorteiler. > Oder muss ich > dann unbedingt den DIV8-Vorteiler in den FuseBits setzen, dann wäre ich > wieder bei 1MHz. Du musst CKDIV8 setzen, damit du beim Start nicht über der garantiert nutzbaren Frequenz bist, aber du kannst im Betrieb dann den Prescaler (CLKPR) auf 1:2 setzen. Die CKDIV8-Fuse macht ja weiter nichts, als selbigen auf 1:8 voreinzustellen.
> Die CKDIV8-Fuse macht ja weiter nichts, als selbigen auf 1:8 voreinzustellen.
Okay, das wusste ich nicht. Ich bin bisher immer davon ausgegangen, dass
dieser CKDIV8 Vorteiler unabhängig von dem internen Vorteiler ist und
während des Betriebs nicht geändert werden könnte.
@Jörg: Was passiert eigentlich mit dem Vorteiler, wenn ich diesen im Programm geändert habe und dann plötzlich ein Reset stattfindet? Bleibt das CKDIV8-Fuse-Bit gesetzt und der µC startet wieder mit dem gesetzten Bit bzw. mit den 1MHz oder bleibt die Vorteilerveränderung erhalten?
Thomas schrieb: > @Jörg: Was passiert eigentlich mit dem Vorteiler, wenn ich diesen im > Programm geändert habe und dann plötzlich ein Reset stattfindet? Bleibt > das CKDIV8-Fuse-Bit gesetzt und der µC startet wieder mit dem gesetzten > Bit bzw. mit den 1MHz oder bleibt die Vorteilerveränderung erhalten? Ja, der sollte mit der CKDIV8-Einstellung wieder starten, zumindest ist der Reset-Wert des CLKPR-Registers auf diese Weise dokumentiert.
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.