Forum: Mikrocontroller und Digitale Elektronik Atmega328p in Sleep und mit Watchdog wecken


von Peter (Gast)


Lesenswert?

Hallo Leute,

ich hab hier ein kleines Testprogramm geschrieben, was mir meinen 
Atmega328p der mit dem internen 1 Mhz Takt und 3,3V betrieben wird alle 
8 Sekunden aufwecken soll und Daten per Funk versenden soll. Nur sendet 
dieser nur genau einmal beim einschalten. Irgendwie stehe ich auf dem 
Schlauch. Weiß jemand wieso er nur einmal sendet?
1
//  Atmega328p intern 1 Mhz
2
#define    F_CPU        1000000UL
3
#include  <avr/io.h>
4
#include   <util/delay.h>
5
#include   <avr/interrupt.h>
6
#include   <avr/power.h>
7
#include   <avr/wdt.h>
8
#include   <avr/sleep.h>
9
#include   "rfm69.c"
10
11
uint8_t array[MAX_ARRAYSIZE + 1];
12
uint8_t tx_length;
13
14
volatile uint8_t sekunden=0;
15
16
void sleep_now() 
17
{
18
    power_all_disable();
19
    set_sleep_mode(SLEEP_MODE_PWR_DOWN);
20
    sleep_mode();
21
}
22
23
void todo()
24
{
25
  //Daten auswerten und senden
26
  sekunden++;
27
  array[0]=sekunden;
28
  array[1]++;
29
  tx_length=2;
30
  rfm_transmit(array, tx_length);  
31
}
32
33
int main( void )
34
{
35
  wdt_enable(WDTO_8S);
36
  rfm_init();
37
  while(1)
38
  {
39
    todo();
40
    sleep_now();
41
  }
42
}

von derjaeger (Gast)


Lesenswert?

http://www.avrfreaks.net/forum/difference-between-sleepcpu-and-sleepmode

With sleep_mode() you select the sleep mode you like to enter.
With sleep_cpu() you enter the sleep mode you have selected by calling 
sleep_mode().

von Peter (Gast)


Lesenswert?

Heißt soviel wie das ein "sleep_cpu();" hinter mein "sleep_mode();" 
kommen muss?

Wobei das ja eigentlich egal wäre weil der Watchdog Reset alle 8 
Sekunden käme oder?

von Thomas E. (thomase)


Lesenswert?

Peter schrieb:
> Wobei das ja eigentlich egal wäre weil der Watchdog Reset alle 8
> Sekunden käme oder?

Ja, das ist es wohl.

Aber was hält der initialisierte RFM davon, wenn er mit einem Init 
einfach nochmal übergebügelt wird? Oder bekommt der vorher noch einen 
Reset? Beim Einschalten bekommt er den ja auf jeden Fall(Power On).

Oder ist er falsch initialisiert und hängt sich nach dem ersten Senden 
auf?

Teste das einfach mal in einer Schleife: Senden - Delay - Senden usw...
Und wenn das geht, packst du ein Init in die Schleife. Dann siehst du, 
ob er das mag oder nicht.

Allerdings ist ein Reset zum Beenden des Sleep nun wahrlich nicht der 
Weisheit letzter Schluß. Weniger nett ausgedrückt, könnte man auch 
sagen, daß das totaler Mist ist.

Den WD kann man auch als Timer benutzen, sowohl mit als auch ohne Reset.

Grundsätzlich bringt man das erstmal ohne Sleep zum Laufen und erst wenn 
alles funktioniert, baut man den Sleep ein.

von M. K. (sylaina)


Lesenswert?

Hast du den Watchdog auch entsprechend eingestellt damit er nicht im 
Watchdog-Reset kleben bleibt? Mit der wdt.h kenne ich mich nicht aus, 
würde aber sagen der AVR bleibt da im Watchdog-Reset kleben.

Versuche mal deinen Code umzubauen und zwar so:
1
//  Atmega328p intern 1 Mhz
2
#define    F_CPU        1000000UL
3
#include  <avr/io.h>
4
#include   <util/delay.h>
5
#include   <avr/interrupt.h>
6
#include   <avr/power.h>
7
#include   <avr/sleep.h>
8
#include   "rfm69.c"
9
10
uint8_t array[MAX_ARRAYSIZE + 1];
11
uint8_t tx_length;
12
13
volatile uint8_t sekunden=0;
14
15
void sleep_now() 
16
{
17
    power_all_disable();
18
    sleep_mode();
19
}
20
21
void todo()
22
{
23
  //Daten auswerten und senden
24
  sekunden++;
25
  array[0]=sekunden;
26
  array[1]++;
27
  tx_length=2;
28
  rfm_transmit(array, tx_length);  
29
}
30
31
int main( void )
32
{
33
  // watchdog konfigurieren
34
  // zunaechst Schutz des Registers aufheben gemaess Datasheet
35
  WDTCSR = (1 << WDCE)|(1 << WDE);
36
  // Interruptmode an, Zeit auf 8s einstellen
37
  WDTCSR = (1 << WDIE)|(1 << WDP3)|(1 << WDP0);
38
39
  rfm_init();
40
  
41
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
42
43
  // globale Interrupts einschalten
44
  sei();
45
  while(1)
46
  {
47
    sleep_now();
48
  }
49
}
50
ISR(WDT_vect){
51
  // watchdog interrupt
52
  todo();
53
}

Das sollte alle 8s die todo() aufrufen.

: Bearbeitet durch User
von S. Landolt (Gast)


Lesenswert?

Das eingangs gezeigte Programm funktioniert als solches schon irgendwie: 
wenn ich, in Ermangelung dieses Funkteils, in todo eine LED kurz 
einschalte, dann blinkt diese im 8 s-Rhythmus. Also hat wohl Thomas 
Eckmann mit seiner Vermutung Recht.

von S. Landolt (Gast)


Lesenswert?

Was allerdings das Konzept betrifft, so würde ich auf jeden Fall einen 
32 KiHz-Quarz als Zeitgeber vorziehen, vorausgesetzt, die beiden Pins 
sind frei; ist genauer und stromsparender als der Watchdog.

von batman (Gast)


Lesenswert?

Quarzbetrieb stromsparender als der interne Watchdog-Timer? Das hab ich 
mal anders gelesen, wenn auch nicht nachgemessen.

von S. Landolt (Gast)


Angehängte Dateien:

Lesenswert?

Nachmessen ist immer gut, man kann es aber auch nachlesen.

von batman (Gast)


Lesenswert?

Da les ich jetzt aber nicht, was der WDT im Power-Down zieht. Obwohl 
alles unter 1µA sowieso meistens egal ist.

von S. Landolt (Gast)


Angehängte Dateien:

Lesenswert?

Ich dachte, es sei klar, dass der RC-Oszillator des Watchdog nicht unter 
1 uA kommt.

von batman (Gast)


Lesenswert?

Ja dann haste Recht und mein Amperemeter lügt. Gut zu wissen.

von M. K. (sylaina)


Lesenswert?

batman schrieb:
> Ja dann haste Recht und mein Amperemeter lügt. Gut zu wissen.

Naja, um so 1/2/3 uA mit nem Amperemeter wirklich zu messen braucht man 
schon ein relativ Gutes. Die 08/15-Dinger schätzen in dem Bereich ja 
schon irgendwie mehr als dass sie wirklich messen, ich trau da ja nicht 
mal meinem Agilent U1253B wobei das kein schlechtes MM ist.

von Thomas E. (thomase)


Lesenswert?

M. K. schrieb:
> würde aber sagen der AVR bleibt da im Watchdog-Reset kleben.

Wie klebt ein AVR im WD-Reset?

von M. K. (sylaina)


Lesenswert?

Thomas E. schrieb:
> M. K. schrieb:
>> würde aber sagen der AVR bleibt da im Watchdog-Reset kleben.
>
> Wie klebt ein AVR im WD-Reset?

Mit "kleben" meinte ich, dass der AVR vielleicht ständig nur resetet und 
zu nix anderem mehr kommt. Deshalb "kleben" ;)

von Thomas E. (thomase)


Lesenswert?

M. K. schrieb:
> Mit "kleben" meinte ich, dass der AVR vielleicht ständig nur resetet und
> zu nix anderem mehr kommt. Deshalb "kleben"

Und warum sollte er das tun?

von M. K. (sylaina)


Lesenswert?

Thomas E. schrieb:
> Und warum sollte er das tun?

Ist ja schon gut, ich habs ja verstanden, dass das wohl ne blöde Idee 
war...

von Thomas E. (thomase)


Lesenswert?

M. K. schrieb:
> Ist ja schon gut, ich habs ja verstanden, dass das wohl ne blöde Idee
> war...

Grundsätzlich ist die Idee gar nicht blöd. Das kann nämlich dann 
passieren, wenn man die Einschaltung und das Setzen des Timeouts des WD 
irgendwo in einer Init versteckt und dies nicht als erstes in der Main 
durchführt. Denn bei einem WD-Reset werden zwar die Register mit den 
Default-Werten geladen, nicht aber der WD abgeschaltet. Und dann muß man 
sich u.U. einigermaßen beeilen, den Timeout wieder zu verlängern, da 
dieser nach Reset auf der kürzesten Zeit steht. Der WD wird erst mit 
Power Off abgeschaltet.

Ist aber in dem Programm des TO richtig:
1
int main( void )
2
{
3
  wdt_enable(WDTO_8S);

: Bearbeitet durch User
von Ralph G. (rhg)


Lesenswert?

Moin,

aus dem Datasheet 15.9.2:

Executing the corresponding interrupt vector will clear WDIE and WDIF 
automatically by hardware (the Watchdog goes to System Reset Mode).
This is useful for keeping the Watchdog Timer security while using the 
interrupt. To stay in Interrupt and System Reset Mode, WDIE must be set 
after each interrupt.

Du musst den WDInt nach jedem auslösen neu setzen.
1
int main( void )
2
{
3
  wdt_enable(WDTO_8S);
4
  rfm_init();
5
  while(1)
6
  {
7
    todo();
8
    sleep_now();
9
    wdt_enable(WDTO_8S);
10
  }
11
}

von Stefan E. (sternst)


Lesenswert?

Thomas E. schrieb:
> Das kann nämlich dann
> passieren, wenn man die Einschaltung und das Setzen des Timeouts des WD
> irgendwo in einer Init versteckt und dies nicht als erstes in der Main
> durchführt.

Auch wenn es direkt das Erste in main() ist, kann es passieren, nämlich 
dann, wenn .data und .bss groß genug sind und deren Initialisierung 
entsprechend lange dauert. Der Default nach dem Reset liegt bei ca 16ms, 
also bei 1 MHz gerade mal 16000 Takte. Wir wissen nicht, was 
MAX_ARRAYSIZE genau ist und welche weiteren Buffer sich vielleicht in 
rfm69.c verstecken. Es ist also nicht ganz abwegig, dass das sein 
Problem sein könnte.

von batman (Gast)


Lesenswert?

Ralph G. schrieb:
> Du musst den WDInt nach jedem auslösen neu setzen.

Das gilt aber nicht für den reinen System-Reset-Mode, der anfangs 
benutzt wurde und so schon funktionierte. Da muß man nur einmal WDE 
setzen.

Wenn man dagegen nur den Timer des WD nutzt, sollte man WDE und 
wdt_enable() gar nicht verwenden. Hier mal meine sleep-Routine:
1
/--------------------------------------------------------------------------------------------
2
#define WDTIME 4
3
4
5
// WDT ISR
6
ISR(WDT_vect) {}
7
8
9
void sleep_long(u16 sleeptime)
10
// sleep seconds, interrruptable by any active irq
11
{
12
13
  // --- perform sleep cycles ---
14
#if WDTIME==1
15
  WDTCR |=  0<<WDP3 | 1<<WDP2 | 1<<WDP1 | 0<<WDP0;  // prescale for 1s
16
#elif WDTIME==4
17
  WDTCR |=  1<<WDP3 | 0<<WDP2 | 0<<WDP1 | 0<<WDP0;  // prescale for 4s
18
#elif WDTIME==8
19
  WDTCR |=  1<<WDP3 | 0<<WDP2 | 0<<WDP1 | 1<<WDP0;  // prescale for 8s
20
#else
21
#error NO WDTIME!
22
#endif
23
24
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
25
  SBIT(WDTCR,WDIE)=1;            // enable watchdog IRQ
26
  for(u16 elapsed=0; elapsed<sleeptime; elapsed+=WDTIME)  {
27
    sleep_mode();            // in den Schlafmodus wechseln
28
    // --- wake up ---
29
  }
30
  SBIT(WDTCR,WDIE)=0;    // disable watchdog IRQ
31
32
}
33
34
//--------------------------------------------------------------------------------------------

von Peter D. (peda)


Lesenswert?

Thomas E. schrieb:
> Denn bei einem WD-Reset werden zwar die Register mit den
> Default-Werten geladen, nicht aber der WD abgeschaltet.

Du vergißt, daß er noch seine ATmega8 Schätzchen aufbrauchen will.
Und die schalten den Watchdog ab, wenn er nicht per Fusebit permanent an 
ist.
Es hilft also nichts, aus dem ATmega88 Datenblatt zu zitieren.

von M. K. (sylaina)


Lesenswert?

batman schrieb:
> Hier mal meine sleep-Routine:

Funktioniert das sicher? Gemäß Datenblatt zum Atmega328p muss man, um 
den Prescaler wechseln zu können, doch zunächst das WDCE und WDE Bit 
setzen. Das vermisse ich irgendwie bei dir.

von Thomas E. (thomase)


Lesenswert?

Peter D. schrieb:
> Du vergißt, daß er noch seine ATmega8 Schätzchen aufbrauchen will.

???:

Peter schrieb:
> ich hab hier ein kleines Testprogramm geschrieben, was mir meinen
> Atmega328p

von derjaeger (Gast)


Lesenswert?

Bisher hat es nur Peter Dannegger angesprochen:

Hast du das Fusebit gesetzt beim Mikrocontroller: Watch-dog Timer always 
on; [WDTON=0] ?

von batman (Gast)


Lesenswert?

M. K. schrieb:
> batman schrieb:
>> Hier mal meine sleep-Routine:
>
> Funktioniert das sicher? Gemäß Datenblatt zum Atmega328p muss man, um
> den Prescaler wechseln zu können, doch zunächst das WDCE und WDE Bit
> setzen. Das vermisse ich irgendwie bei dir.

Bezieht sich das vielleicht exklusiv auf den System-Reset-Mode?
Meine Sleep-Funktion läuft so auf mehreren  m328p, mega8 und tinys.

von M. K. (sylaina)


Lesenswert?

Ich habs nicht probiert aber im Datasheet steht halt auch drin, dass zum 
ändern der Zeit zunächst WDCE und WDE gesetzt werden müssen und man dann 
vier Zyklen Zeit hat zum Einstellen der neuen Zeit. Vielleicht gilt das 
auch nur wenn das WDTON-Fuse gesetzt ist. Das hab ich jetzt nicht auf 
dem Schirm.

von batman (Gast)


Lesenswert?

Für mich nicht ganz eindeutig. Die Prozedur würde jedenfalls keinen Sinn 
machen, wenn man den Timer nur als Trigger für die ISR nutzt. Bei diesen 
Datenblättern muß man manchmal zwischen den Zeilen lesen. :)

von Peter (Gast)


Lesenswert?

Also, der 328er soll eigentlich nur alle 30-60 Sekunden Aufwachen, 
Temperatur und relative Luftfeuchtigkeit eines sht21(der noch unterwegs 
ist) einlesen und über das RFM69CW Modul senden. Das alles sollte 
Natürlich so sparsam wie möglich betrieben werden. Wollte zwar eine 
14500 Trustfire 800mAh als Versorgung benutzten, aber man will ja so 
lange wie möglich damit kommen.

Ich muss auch ehrlich dazu sagen, dass ist mein erstes Projekt wo ich 
mich überhaupt mit Low Power bzw Sleep Modus aber auch Watchdog 
beschäftige.

Den internen Watchdog wollte ich verwenden um weniger Bauteile zu haben.

Bin aber über Tips Tricks dankbar und hab jetzt schon neue Sachen hier 
gelernt.

von derjaeger (Gast)


Lesenswert?

Kannst du deine FUSE-Konfiguration  zeigen?

von Peter D. (peda)


Lesenswert?

Thomas E. schrieb:
> Peter D. schrieb:
>> Du vergißt, daß er noch seine ATmega8 Schätzchen aufbrauchen will.
>
> ???:

Sorry, war gedanklich im falschen Thread.

von M. K. (sylaina)


Angehängte Dateien:

Lesenswert?

batman schrieb:
> Für mich nicht ganz eindeutig. Die Prozedur würde jedenfalls
> keinen Sinn
> machen, wenn man den Timer nur als Trigger für die ISR nutzt. Bei diesen
> Datenblättern muß man manchmal zwischen den Zeilen lesen. :)

Warum sollte die Prozedure keinen Sinn machen? Das ist eine 
Fail-Safe-Procedure, die verhindern soll, dass die Time-Out aus 
versehen/zufällig geändert werden kann.
Im Anhang der Beispiel-Code dazu. Da wird u.a. auch empfohlen, den 
Watchdog zu reseten bevor man die Zeit ändert da es sonst zum Reset 
kommen kann was auch irgendwie logisch ist, in deiner Funktion fehlt das 
aber auch. ;)

Peter schrieb:
> Also, der 328er soll eigentlich nur alle 30-60 Sekunden Aufwachen,

Würde ich im Watchdog-Interrupt-Mode machen, also so wie schon oben 
gezeigt. Hierzu einfach eine Variable nehmen, die die Interupts zählt 
und sowie eine gewisse Anzahl erreicht ist das todo() ausführen lassen. 
Die ISR könnte so aussehen:
1
volatile uint8_t myWatchDogInterrupts = 0;
2
...
3
ISR(WDT_vect){
4
  myWatchDogInterrupts++;
5
  if(myWatchDogInterrupts > 5){
6
    // ist der Watchdog auf 8 Sekunden eingestellt 
7
    // so tritt dies hier alle 6*8s = 48s auf
8
    todo();
9
    myWatchDogInterrupts=0;
10
  }
11
}
12
...

von batman (Gast)


Lesenswert?

M. K. schrieb:
> Warum sollte die Prozedure keinen Sinn machen? Das ist eine
> Fail-Safe-Procedure, die verhindern soll, dass die Time-Out aus
> versehen/zufällig geändert werden kann.

Schön, und die Frage war, welchen Sinn das hier machen sollte.

> Im Anhang der Beispiel-Code dazu. Da wird u.a. auch empfohlen, den
> Watchdog zu reseten bevor man die Zeit ändert da es sonst zum Reset
> kommen kann was auch irgendwie logisch ist, in deiner Funktion fehlt das
> aber auch. ;)

Nein, das fehlt nicht. Durch das Löschen des WDIE-Flag wird der WD 
deaktiviert und startet dann neu bei Null. Einen Reset kann der Timer in 
meiner Sleep-Funktion aber gar nicht auslösen. Das ist völlig falscher 
Kontext.

von HildeK (Gast)


Lesenswert?

Peter schrieb:
> Also, der 328er soll eigentlich nur alle 30-60 Sekunden Aufwachen,

Aufwachen an sich geht längstens im 8s-Intervall mit dem WD. Natürlich 
kannst du bei jedem Aufwachen in der WD-ISR einen Zähler nehmen und dann 
beim Stand 4 ... 7 (32s ... 56s) nur senden.

Welche Besonderheiten der 328 enthält, weiß ich nicht.
Bei Tiny x5 braucht man jedenfalls die WDTON Fuse nicht aktivieren, um 
zyklische WD-Interupts zu generieren und so den WD-Timer zu nutzen.
WDTON ist bei Atmel der "safety level 2", bei dem der WD vom Power-On an 
aktiv ist und der per Programm auch nicht abgeschaltet werden kann.
Um die WD-Zeiten zu ändern, braucht man im Level 2 die 'Timed sequence', 
ohne WDTON-Fuse jedoch nicht. Für Level 1 kann die selbe Funktion auch 
per SW aktiviert werden, nur dass der WD dann auch unterwegs 
abgeschaltet werden kann.
Wenn auf die Sicherheitsfunktion des WD verzichtet werden will (kein 
WD-Reset bei wild gewordenem Prog, sondern nur Nutzung des WD-Timers), 
dann braucht man WDE nicht setzen, nur WDIE für den Interrupt.

Wie gesagt, das gilt für die Tinys und auch für den 164A, 324A, 644A und 
1284, ich vermute aber, dass der 328 auch so arbeitet. Genaueres weiß 
das Datenblatt.

von M. K. (sylaina)


Lesenswert?

batman schrieb:
> Schön, und die Frage war, welchen Sinn das hier machen sollte.

Default ist der Watchdog auf 16 ms eingestellt, hier soll er nun auf 8 s 
geändert werden und das ist die dazu, lt. Datenblatt, nötige Procedure 
um die Time-Out zu ändern. Mag sein, dass es auch anders geht, ich würde 
mich aber definitiv ans Datenblatt halten.

batman schrieb:
> Nein, das fehlt nicht. Durch das Löschen des WDIE-Flag wird der WD
> deaktiviert und startet dann neu bei Null.

Wo hast du denn das raus gelesen? Im Datenblatt steht das auf jeden Fall 
nicht oder ich bin blind.
Ist aber auch egal erstmal, deine sleep-Funktion wird aufgerufen und 
soll nun starten, das WDIE löscht sie aber erst zum Schluss, nicht zu 
Beginn. Und wenn der Watchdog nun schon läuft? Deine sleep-Funktionn ist 
schön und gut, hat aber ein paar Randbedingungen, die man beachten 
sollte ;)

von Thomas E. (thomase)


Lesenswert?

M. K. schrieb:
> Wo hast du denn das raus gelesen? Im Datenblatt steht das auf jeden Fall
> nicht oder ich bin blind.

Doch das steht da. Da hat der Fledermausmann teilweise recht. Aber seine 
Rückschlüsse sind auch nicht ganz richtig.

Wenn sowohl WD-Reset als auch WD-Timer aktiv sind, wird nach Ablauf des 
ersten Timeout die ISR ausgeführt und nach einem weiteren Timeout der 
Reset.

Damit das in dieser Reihenfolge passiert, wird bei gesetztem WDIE-Bit 
die ISR ausgeführt und nicht nur das WDIF-Flag sondern auch das WDIE-Bit 
gelöscht. Dann erfolgt beim nächsten Timeout der Reset.

Möchte man diesen Reset verhindern, muß das WDIE-Bit wieder gesetzt 
werden. Dann wird beim nächsten Timeout wieder die ISR ausgeführt.

Das ist der Sinn und Zweck dieser Prozedur. Der WD-Timercounter wird 
dabei nicht zurück gesetzt. Auch ist das wiederholte Setzen des WDIE-Bit 
im reinen Timer-Mode nicht erforderlich, da dieses nur bei gesetztem WDE 
gelöscht wird. Also im kombinierten Mode.

: Bearbeitet durch User
von batman (Gast)


Lesenswert?

Thomas E. schrieb:
> Wenn sowohl WD-Reset als auch WD-Timer aktiv sind, wird nach Ablauf des
> ersten Timeout die ISR ausgeführt und nach einem weiteren Timeout der
> Reset.

Tja wenn das Wörtchen wenn nicht wär, ne. Worum ging es hier denn 
gleich.

von M. K. (sylaina)


Lesenswert?

Thomas E. schrieb:
> Doch das steht da.

Wo steht das da? Du beschreibst was passiert wenn die ISR angesprungen 
wurde und das WDIE-Bit automatisch gelöscht wurde. Wo bitte steht im 
Datenblatt, dass das manuelle Löschen des WDIE-Bits den Timer zurück 
setzt, wie es batman oben schrieb? Das lese ich nirgends im Datenblatt, 
Sorry. Das ist eine nicht beschriebene Funktionalität auf die man sich 
IMO nicht verlassen sollte, sonst ist man irgendwann mal verlassen.

von Peter (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

so hab noch einige sachen Probiert...
Hier das Programm sendet genau ein mal, geht in Sleep (ca 4.3uA) wird 
nach 8 Sekunden geweckt (sieht man am Strom ca 680uA und bleibt da dann 
hängen.

Ab dann werden keine neuen Werte mehr gesendet. Wie verhält der uC sich? 
Arbeitet dieser nur die WD Routine ab oder auch die RFM_init (Also 
ganzes Programm)?

von S. Landolt (Gast)


Lesenswert?

sleep_now in der ISR - ob das eine gute Idee ist? Auf jeden Fall fehlt 
da ein sei; normalerweise erfolgt das am Ende der ISR per reti.

von S. Landolt (Gast)


Lesenswert?

sleep_now in der ISR - vermutlich eine schlechte Idee; wenn ich mich 
nicht täusche (kann kaum c), läuft da der Stack voll.

von M. K. (sylaina)


Lesenswert?

Ja, das sleep_now würde ich auch in die Main-Loop verfrachten und nicht 
in der ISR belassen.

von Dieter F. (Gast)


Lesenswert?

M. K. schrieb:
> Wo bitte steht im
> Datenblatt, dass das manuelle Löschen des WDIE-Bits den Timer zurück
> setzt, wie es batman oben schrieb?

Nirgendwo. Es steht da nur, dass das Interrupt-Enable-Register 
zurückgesetzt wird (wenn die WDT-ISR ausgeführt wird)

von Thomas E. (thomase)


Lesenswert?

M. K. schrieb:
> Wo steht das da? Du beschreibst was passiert wenn die ISR angesprungen
> wurde und das WDIE-Bit automatisch gelöscht wurde. Wo bitte steht im
> Datenblatt, dass das manuelle Löschen des WDIE-Bits den Timer zurück
> setzt, wie es batman oben schrieb? Das lese ich nirgends im Datenblatt,
> Sorry. Das ist eine nicht beschriebene Funktionalität auf die man sich
> IMO nicht verlassen sollte, sonst ist man irgendwann mal verlassen.

Nun reg dich mal wieder ab. Ich hab doch klar beschrieben, was da 
passiert. Und auch, was nicht passiert. Nämlich, daß der Timer-Counter 
beim Setzen des WDIE-Bits nicht zurückgesetzt wird. Vom manuellen 
Löschen war zumindest bei mir nie die Rede.

von Peter (Gast)


Angehängte Dateien:

Lesenswert?

Siehe an es funktioniert. Zieht jetzt 4,3uA im Power down Modus.
Waren scheinbar mehrere Faktoren dafür Schuld.
power_all_disable();
War aber mit der Hauptgrund wieso es nicht weiter ging.

So funktioniert es jetzt bisher.

Der RFM69CW soll im Sleep Modus Typ 0.1uA Max 1uA ziehen.
Der Atmega328p Power Down Modus WDT enabled Typ 3.9uA Max 15uA ziehen.

Heißt die Werte sollten also grob passen. Vor allem bei meinem alten 
Benning CMM3 Messgerät.

Vielen dank an alle!
Für Verbesserungen bin ich gerne zu haben. Man lernt nie aus!

von M. K. (sylaina)


Lesenswert?

Thomas E. schrieb:
> Nun reg dich mal wieder ab. Ich hab doch klar beschrieben, was da
> passiert. Und auch, was nicht passiert. Nämlich, daß der Timer-Counter
> beim Setzen des WDIE-Bits nicht zurückgesetzt wird. Vom manuellen
> Löschen war zumindest bei mir nie die Rede.

Ich konnte ja nicht ahnen, dass du dem Faden nicht folgen konntest:

batman schrieb, dass durch das Löschen des WDIE-Bits in seiner Funktion 
sleep der Watchdog resetet werden würde (Post #5157819). Ich fragte ihn 
daraufhin wo er das gelesen hätte (kann ja sein, dass das in einer 
AppNote drin steht), denn im Datenblatt stünde das nicht (Post #5157859) 
worauf von dir kam, dass das sehr wohl im Datenblatt stehen würde (Post 
#5157936) und du dann den "automatischen" Reset des Watchdogs durch die 
ISR beschrieben hast (das ist der Teil, den ich auch gar nicht 
angezweifelt hatte, hatte halt nur nichts mit dem Thema zu tun). Bevor 
du das nächste Mal in eine Diskussion einsteigst lies doch erst mal 
worüber genau diskutiert wird. Hält den Blutdruck bei allen unten und 
verringert die Missverständnisse.

Peter schrieb:
> Siehe an es funktioniert.

Sehr schön.

Peter schrieb:
> Vielen dank an alle!
> Für Verbesserungen bin ich gerne zu haben. Man lernt nie aus!

Ich würde noch das set_sleep_mode() in den Init-Bereich werfen, damit 
wird die sleep_now() praktisch überflüssig. Außerdem muss man den 
Sleep-Modus nicht ständig neu einstellen wenn man eh nur einen nutzt ;)
Das sei() im watchdog-init() würde ich an Ende des Init-Bereichs stellen 
und ich würde das watchdog-init() aus dem todo() raus werfen. Macht IMO 
da keinen Sinn drin. Also in etwa so würde ich es machen:
1
//  Atmega328p intern 1 Mhz
2
#define    F_CPU        1000000UL
3
#include  <avr/io.h>
4
#include   <util/delay.h>
5
#include   <avr/interrupt.h>
6
// #include   <avr/power.h>
7
#include   <avr/sleep.h>
8
#include   "rfm69.c"
9
10
uint8_t array[MAX_ARRAYSIZE + 1];
11
uint8_t tx_length;
12
13
volatile uint8_t sekunden=0;
14
15
void watchdog_init()
16
{
17
  // watchdog konfigurieren
18
  WDTCSR = (1 << WDCE)|(1 << WDE);  // zunaechst Schutz des Registers aufheben gemaess Datasheet
19
  WDTCSR = (1 << WDIE)|(1 << WDP3)|(1 << WDP0);  // Interruptmode an, Zeit auf 8s einstellen
20
}
21
22
void todo()
23
{
24
  //Daten auswerten und senden
25
  sekunden=sekunden+8;
26
  array[0]=0;
27
  array[1]++;
28
  array[2]=0;
29
  array[3]=array[3]+10;
30
  array[4]=sekunden;
31
  tx_length=5;
32
  rfm_transmit(array, tx_length);  
33
}
34
35
ISR(WDT_vect)
36
{
37
  todo();
38
}
39
40
int main( void )
41
{
42
  watchdog_init();
43
  rfm_init();  
44
  todo();
45
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);  //  SLEEP_MODE_PWR_SAVE SLEEP_MODE_PWR_DOWN
46
  sei();
47
  while(1)
48
  {
49
    sleep_mode();
50
  }
51
}

Bitte 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
Noch kein Account? Hier anmelden.