Hallo,
bei meinen weiteren Versuchen mit dem WDB-A1281-P1 Modul bin ich auf ein
Problem gestoßen: Die ungenauigkeit des internen RC-Oszillators vom
Mikrocontroller. Da auf diesem Modul ja ein 16 MHz Quarz am RF230 hängt,
würde der sich ja zur Takterzeugung gut eignen.
Da hab ich, ohne Software auf dem µC, einfach mal am XTAL1 (der am CLKM
vom RF230 hängt) das Scope angeschlossen. Da kommt das, was man in
scope1 sieht: 10 Hz. Wenn man sich aber die Flanken anguckt, sehen die
etwas seltsam aus. In scope2 ist an die Flanke "rangezoomt". Das sind 1
MHz.
Aber WARUM? VCC ist stabil. In einer Test-Software habe ich RST und CS
auf 1 gezogen, Sleep auf 0. Hat jemand schon mal sowas gesehen? Im
Datenblatt habe ich nichts nüzliches gefunden.
Noch was: Seite 18, Datenblatt.
Verabschiedet der sich in den Sleep-Mode?
Was auch ganz interessant sein könnte: Wenn ich auf den Reset-Taster
drücke, höre ich ein hohfrequentes Pfeifen, obwohl dort IMHO keine
Spulen oder so drauf sind.
Oder weil mir wahrscheinlich niemand helfen kann:
Irgendeine Idee, wie ich das Modul mit einem stabilen Takt füttern kann?
Ich könnte einen kleinen Quarzoszillator auf die Platte setzen und den -
mit der DeadBug-Methode - an XTAL1 anschließen, dann ärgert mich das
RF-Vieh wieder, weil der ja auch noch was an XTAL1 zu sagen hat/sagen
will.
Falls es jemanden interessiert: Bei µracoli gibt es die selben
"Symptome".
Ist das ganze so gedacht? Also das der Mikrocontroller für ein paar
Takte gepowert wird, dabei die paar Daten schreibt und dann wieder
schläft? Ich würde auch mal unter den "Metallhäubchen" messen, ob der
Quarz schwingt, ...
ABER: Wie bekomme ich diese Haube da am besten runter?
So schnell kann es gehen. Ich hab gerade meinen LA rausgekramt und da
sieht es so aus, wie es aussehen söllte. Also nach dem Motto: "Wer
misst, misst mist."
Jetzt aber die Preisfrage an die Experten: WARUM macht mein Oszi das?
Modell ist (nicht hauen) UTD2052CEX. Wenn ich im Acquire-Menü von
"Sample" auf "Peak" umschalte, sieht es auch so aus wie es sein söllte.
Torsten W. schrieb:> Tastkopf auf 1:10 gestellt?
Natürlich.
> Tastkopf bedämpft Quarz zu sehr?
Den Quarz nicht, höchstens den Taktausgang vom RF230, der kann in der
Standardeinstellung nur 2mA, was bei 1MOhm Eingang reichen dürfte.
Thread hatte ich uebersehen.
CLKM gibt per default den stabilisierten Takt des RF230 aus, default war
es wohl 1 MHz. Den Takt gibt es aber nur, wenn der Transceiver nicht in
Reset oder Sleep ist. Man kann den Takt auch hoeher stellen, per
Register. Nach dem aufrufen des Sleep-Modes des RF230 kommen noch 35
Clock-Zyklen auf CLKM raus, so dass sich der Controller auch in Ruhe
schlafen legen kann. ...
Damit das System dann jemals wieder aufwecken kann, muss der AVR auf
einen
alternativen Takt umgeschalten werden ... alles in allem wurde CLKM als
AVR Takt aufgrund der vergnuselten Konfiguration bisher kaum verwendet.
Wenn du auf Powermanagment und Sleep in deiner Anwendung verzichten
kannst, ist CLKM aber eine Moeglichkeit fuer einen stabilen AVR-Takt.
A.W. schrieb:
>Wenn du auf Powermanagment und Sleep in deiner Anwendung verzichten>kannst, ist CLKM aber eine Moeglichkeit fuer einen stabilen AVR-Takt.
genau das habe ich mal beim Zigbit versucht. In meiner Init Sequenz des
AT86RF230 habe ich
eingefügt. Den ATmega1281 habe ich auf externen Takt gefuset. Das
Ergebnis war aber eher ernüchternd. Der RX schaltete nach 1-2 Sekunden
von 1MHz Takt auf 8MHz um, der TX brauchte so um die 10-15 Sekunden.
Warum auch immer. Ich habe dann noch ein paar Tage gesucht/getestet,
warum das so ist, aber nichts gefunden. Letztendlich habe ich dann aber
wieder den internen Oszillator des ATmega1281 genutzt.
Habe ich da ggf. eine falsche Init Sequenz?
Grüße
Ralf
elral schrieb:> Der RX schaltete nach 1-2 Sekunden von 1MHz Takt auf 8MHz um, der TX> brauchte so um die 10-15 Sekunden.
Was meinst du hier mit Rx und Tx? Die vom AT86RF230? Die lassen
sich doch in dieser Form gar nicht trennen, da sie einen gemeinsamen
Taktgenerator haben.
Der AT86RF230 hat eine etwas „verknispelt“ wirkende verzögerte
Umschaltung, wenn man den CLKM ändert, die sich hinter dem Bit
SR_CLKM_SHA_SEL verbirgt. Standardmäßig ist er so eingestellt,
dass die Umschaltung erst beim nächsten Transceiver-SLEEP erfolgt.
Der Grund, warum man das so implementiert hat ist, dass man einen
AVR nicht einfach zwischen 1 MHz und 8 MHz am Takteingang wechseln
lassen kann. Im Datenblatt heißt es, dass sie die Taktfrequenz um
nicht mehr als 2 % pro Taktzyklus ändern darf, sowie:
1
If changes of more than 2% is required, ensure that the MCU is kept
2
in Reset during the changes.
(Der Grund liegt darin, dass zum Stromsparen bei niedrigen
Taktfrequenzen ein so genanntes flash sampling durchgeführt wird.
Beim plötzlichen Umschalten des Takts liest man demzufolge Unsinn
aus dem Flash.)
Genau dafür ist diese Mimik im AT86RF230 ausgelegt: man aktiviert
die neue Taktfrequenz im '230 und zieht danach das SLP_TR-Pin auf
high. Der '230 verzögert die Umschaltung der CLKM-Frequenz jetzt
noch um einige Takte, sodass der ATmega mit der alten Frequenz noch
sicher in der Lage ist, sich schlafen zu legen, und den Watchdog
einen Reset vornehmen zu lassen. Nach dem Reset arbeitet der
Controller dann mit dem neuen Takt.
Hallo Jörg,
Vielen Dank für die Erklärung!
RX/TX = mein gebauter Sender und Empfänger mit jeweils einem Zigbit
(eigentlich sind es ja beide Sender und Empfänger :) )
Grüße
Ralf
scope1.jpg
(95 KB)
scope2.jpg
(93 KB)
