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.
Angehängte Dateien:
-
scope1.jpg
95 KB -
scope2.jpg
93 KB
:
Bearbeitet durch User
Kann es EMV sein? Hat noch niemand so was gesehen? (Auser bei Oszilatoren bei denen man 10 Hz an den Enable-Eingang legt :) )
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.
:
Bearbeitet durch User
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.
Tastkopf auf 1:10 gestellt? Tastkopf bedämpft Quarz zu sehr?
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.
:
Bearbeitet durch User
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
1 | trx_io_init(SPI_RATE_1_2); |
2 | DELAY_US(TRX_INIT_TIME_US); |
3 | TRX_RESET_LOW(); |
4 | TRX_SLPTR_LOW(); |
5 | DELAY_US(TRX_RESET_TIME_US); |
6 | TRX_RESET_HIGH(); |
7 | trx_reg_write(RG_TRX_STATE, CMD_TRX_OFF); |
8 | DELAY_US(TRX_INIT_TIME_US); |
9 | trx_bit_write(SR_TX_AUTO_CRC_ON, 1); |
10 | /--------------------------------------------------
|
11 | trx_bit_write(SR_CLKM_SHA_SEL, 0); // required for direct change of clock out |
12 | trx_bit_write(SR_CLKM_CTRL, CLKM_8MHz);// Clock Output from AT86RF230 to 8MHz, can be used as Clock In for ATmega1281 |
13 | /--------------------------------------------------
|
14 | trx_reg_write(RG_IRQ_MASK, TRX_IRQ_TRX_END | TRX_IRQ_RX_START); |
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.
:
Bearbeitet durch Moderator
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
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.