Verständnisfrage SleepMode

Allenfalls wuerde sich ein Blick ins Datenblatt des betreffenden 
Controllers lohnen. Da steht alles drin. Welche Moeglichkeiten wann 
bestehen, und wie die Konfigurationen dazu aussehen.

Sinnvollerweise ist das ganze Programm eine Zustandsmaschine, dh der 
Sleep ist nur an genau einer Stelle vorhanden.

Sascha M. schrieb:
> Meine Vermutung war, dass die Interrupts vielleicht gar nicht mehr aktiv
> sein könnten (wieso auch immer).

Weil Du in einem Interrupt bist.
Sleep darf immer nur im Main-Kontext aufgerufen werden!
Es gibt keine Ausnahme.

Peter D. schrieb:
> Sascha M. schrieb:
>> Meine Vermutung war, dass die Interrupts vielleicht gar nicht mehr aktiv
>> sein könnten (wieso auch immer).
>
> Weil Du in einem Interrupt bist.
> Sleep darf immer nur im Main-Kontext aufgerufen werden!
> Es gibt keine Ausnahme.

Bedeutet das, dass diese 
(Beitrag "Re: Reminder per Microcontroller realisieren") Empfehlung falsch 
ist?

Ich habe den Quellcode jetzt mal angepasst, und die Logik zum 
Ausschalten von ADC, AC usw. sowie das Schlafenlegen in die 
Main()-Routine bzw. deren Endlosschleife geschrieben.

Ist das nun so korrekt?

Wie gesagt; ich bin am Lernen und möchte nicht, dass etwas Falsches 
hängen bleibt.

Danke für Eure Antworten.

Anstatt nur zu schreiben, dass dieses oder jenes falsch ist, wäre es 
allerdings schön, wenn Ihr auch Lösungsmöglichkeiten aufzeigen würdet.

Man schrieb, dass das 'Schlafenlegen' nur an einer Stelle und nur im 
Main-Kontext vorkommen darf.
Da ich aber, nachdem die ISR für Timer 1 durchgelaufen ist, den µC 
wieder schlafen legen möchte, muss ich das doch in der While-Schleife 
machen, denn was anderes wird in Main() doch nicht mehr aufgerufen 
confused

Und wiese ist das ein Endlos-Sleep-Mode? Der Overflow-Interrupt weckt 
den µC doch wieder, oder nicht?

Ich stehe gerade echt vor einer Wand und Kommentare wie 'Den REst deines 
Codes prüfe ich jetzt nicht' (bzw. deren gedanklichen Hintergrund) finde 
ich schon sehr herablassend.

Ich bin kein Schüler, der hier seine Hausaufgaben gemacht bekommen 
möchte.
Mich interessiert die Thematik hobbymässig, aber solche Sachen 
demotivieren halt.

Amateur schrieb:
> Ich habe mal ins Datenblatt des ATTiny85 geschaut. Solltest Du auch mal
> machen! Kann nicht schaden!
>
> T.O.
>>>Both internal RC oscillator and PLL are switched off in power down and stand-by
> sleep modes. <<
>
> Im Bereich von "SLEEP MODES" heißt es, dass nur noch der INT0 (wie schon
> vermutet), der USI-Interrupt und der Wachhund funktionieren.
>
> Also nix mit Tick-Tack. Aber wenn Du vielleicht lang genug wartest...
>
> Die Zeit kannst Du dann ja nutzen um zu lesen.

Wenn Du Dir den Code angeschaut hättest, wäre Dir aufgefallen, dass ich 
Idle nutzen möchte, bei dem der Timer sehr wohl weiter läuft.
Und nebenbei: das Datenblatt habe ich mir angeschaut, ansonsten hätte 
ich kaum gesehen, wie ADC usw. deaktiviert wird.

"
7.1.1 Idle Mode
When the SM[1:0] bits are written to 00, the SLEEP instruction makes the 
MCU enter Idle mode, stopping the CPU
but allowing Analog Comparator, ADC, USI, Timer/Counter, Watchdog, and 
the interrupt system to continue oper-
ating. This sleep mode basically halts clkCPU and clkFLASH, while 
allowing the other clocks to run.
"

Bitte schert nicht jede Anfrage, die nicht Eurem Niveau entspricht, über 
einen Kamm und stellt den Fragensteller als 'faule Sau' da, ohne Euch 
selber angeschaut zu haben, was ich eigentlich tue.

Sascha M. schrieb:
> muss ich das doch in der While-Schleife
> machen, denn was anderes wird in Main() doch nicht mehr aufgerufen

Die Mainloop ist genau richtig.
Und sobald die Mainloop noch andere Sachen machen soll, stehen die auch 
darin.

Der Idle-Mode spart allerdings nicht viel (~50%), Power-Down ist der 
richtige Sparer.
Im Power-Down gehen aber nur Pin-Change und Watchdoginterrupt zum wieder 
aufwachen.

Sascha M. schrieb:
> Danke für Eure Antworten.
>
> Anstatt nur zu schreiben, dass dieses oder jenes falsch ist, wäre es
> allerdings schön, wenn Ihr auch Lösungsmöglichkeiten aufzeigen würdet.

In deiner Mainloop schläfst du von Interrupt zu Interrupt, deshalb wäre 
es gut die auch in jeder Runde zu sei();en.

Konkret sieht die AVRlibc Doku vor:

1

 while(1) {

2

    sleep_enable();

3

    sei();

4

    sleep_cpu();

5

    sleep_disable();

6

  }

Sascha M. schrieb:
> Bitte schert nicht jede Anfrage, die nicht Eurem Niveau entspricht, über
> einen Kamm und stellt den Fragensteller als 'faule Sau' da

Am besten ignorierst Du Antworten, die nicht zielführend sind. Das spart 
Nerven.

Peter D. schrieb:
> Sascha M. schrieb:
>> muss ich das doch in der While-Schleife
>> machen, denn was anderes wird in Main() doch nicht mehr aufgerufen
>
> Die Mainloop ist genau richtig.
> Und sobald die Mainloop noch andere Sachen machen soll, stehen die auch
> darin.
>
> Der Idle-Mode spart allerdings nicht viel (~50%), Power-Down ist der
> richtige Sparer.
> Im Power-Down gehen aber nur Pin-Change und Watchdoginterrupt zum wieder
> aufwachen.

Okay, somit ist die Umsetzung also doch richtig.
Mein Problem ist, dass ja alles visuell so funktioniert, wie es soll.
Leider bin ich nicht in der Lage, zu sehen, ob der µC wirklich schläft.
Daher frage ich halt die Erfahrenen, ob die Umsetzung so korrekt ist, 
oder nicht.

Peter D. schrieb:
> Der Idle-Mode spart allerdings nicht viel (~50%), Power-Down ist der
> richtige Sparer.
> Im Power-Down gehen aber nur Pin-Change und Watchdoginterrupt zum wieder
> aufwachen.

Es ist interessant, wie unterschiedliche die Aussagen hier sind.
Der eine schreibt, dass sich in meinem Fall der µC zu 99% im Schlafmodus 
befindet, und hier stehts schon wieder ganz anders :(
Da weiß man echt nicht, was man gla
uben soll, vor allem darum, weil ich es ja nicht überprüfen kann 
schnief
Da der Watchdoginterrupt nicht sehr genau sein soll, hatte ich mich für 
Idle und Timer 1 entschieden.
Aber wenn das mit dem WD BestPractice ist, mache ich das natürlich auch 
:)

Carl D. schrieb:
> Sascha M. schrieb:
>> Danke für Eure Antworten.
>>
>> Anstatt nur zu schreiben, dass dieses oder jenes falsch ist, wäre es
>> allerdings schön, wenn Ihr auch Lösungsmöglichkeiten aufzeigen würdet.
>
> In deiner Mainloop schläfst du von Interrupt zu Interrupt, deshalb wäre
> es gut die auch in jeder Runde zu sei();en.
>
> Konkret sieht die AVRlibc Doku vor:
>

1

 while(1) {

2

>     sleep_enable();

3

>     sei();

4

>     sleep_cpu();

5

>     sleep_disable();

6

>   }

7

>

Ahh, okay. Das werde ich mal austesten.
Danke!

Sascha M. schrieb:
> Der eine schreibt, dass sich in meinem Fall der µC zu 99% im Schlafmodus
> befindet, und hier stehts schon wieder ganz anders :(

Nein, da ist kein Widerspruch.
Das eine ist die Stromabsenkung (50%) im Sleep, das andere das 
Tastverhältnis Sleep zu aktiv.
Der mittlere Stromverbrauch ist demzufolge:
99% * 50% + 1% * 100%

Peter D. schrieb:
> Sascha M. schrieb:
>> Der eine schreibt, dass sich in meinem Fall der µC zu 99% im Schlafmodus
>> befindet, und hier stehts schon wieder ganz anders :(
>
> Nein, da ist kein Widerspruch.
> Das eine ist die Stromabsenkung (50%) im Sleep, das andere das
> Tastverhältnis Sleep zu aktiv.
> Der mittlere Stromverbrauch ist demzufolge:
> 99% * 50% + 1% * 100%

Alles klar; ich probiere beides mal aus.
Danke!

Nach lesen deines Original-Thread
("ich hab gehört ein AVR verbraucht soviele mA wie man Spannung 
anlegt"):
Lad dir ein Datenblatt runter!

Ein Tiny85 ist zwar klein, aber kann stromsparend eben nur auf 
Tastendrücke warten bzw. der WatchDog ist sicher nicht genau genug für 
deine 15min.

Den Tiny kann man durch minimalen Takt (128kHz, es wird ja eh nichts 
gerechnet, sonder nur auf Timer gewartet) und Abschalten aller nicht 
benötigten Dinge via PRR zum Sparen zwingen.

Sparsam eine bestimmte Zeit warten kann ein AVR mit Asynchron 
arbeitendem Timer2.
Ob sich der Aufwand angesichts der Signal-LED aber lohnt, ist eine 
andere Frage.

c-hater schrieb:
> Sascha M. schrieb:
>
>> Nachdem nun soweit alles funktioniert, bin ich dabei, das Ganze etwas
>> stromsparender aufzusetzen.
> [...]
>> Aufwachen soll der µC durch den TimerOverflow-Interrupt von Timer 1
>
> Damit hast du die einzige Möglichkeit, tatsächlich nennenswert (also in
> Größenordnungen) Energie sparen zu können (PowerDown) bereits
> ausgeschlossen. Sprich: wenn es wirklich wichtig ist, Energie zu sparen,
> musst du dein gesamtes Konzept überdenken. Alles andere ist einfach
> nicht wirklich zielführend. Relativ viel Aufwand für praktisch kaum
> einen Vorteil.
>
> Die höheren Energiesparmodi sind eher dafür gedacht, in bereits mittels
> PowerDown optimierten Anwendungen noch das letzte Quäntchen während der
> unbedingt nötigen Wachzeiten herauszuholen (oder haben sogar mit dem
> Ziel des Energiesparens eigentlich garnix zu tun, sondern passen nur
> hardwaremäßig mit in's Thema).

Okay, das ist schade :)
Nur leider ist es mir nicht wirklich möglich, mein Konzept zu 
überdenken, da ich keine Ahnung der bestehenden Möglichkeiten habe. Da 
hilft mir dann das Datenblatt auch nicht weiter, wenn es als Alternative 
nur noch den PowerDown-Modus gibt und der WatchDog zu ungenau ist :(

Es ist natürlich nicht unabdingbar, Energie zu sparen, das Ding wird 
schließlich nicht unwiderbringlich in der Erde verbuddelt und die 
Batterie wird sicherlich auch so ein paar Tage halten.
Mir ging es mit Umsetzung des SleepModes viel mehr um das Ausloten der 
Möglichkeiten bzw. den Standards/Best Practices.

Carl D. schrieb:
> Nach lesen deines Original-Thread
> ("ich hab gehört ein AVR verbraucht soviele mA wie man Spannung
> anlegt"):
> Lad dir ein Datenblatt runter!

Das habe ich natürlich und mittlerweile habe ich auch die entsprechenden 
Grafiken dazu gefunden, unter welchen Umständen wieviel Strom verbraucht 
wird.
Ganz ehrlich: bei ~300 Seiten ist es nicht einfach, das wirklich 
Wichtige an Infos rauszuziehen.

> Ein Tiny85 ist zwar klein, aber kann stromsparend eben nur auf
> Tastendrücke warten bzw. der WatchDog ist sicher nicht genau genug für
> deine 15min.

Daher das Vorgehen, so wie es aktuell ist.

> Den Tiny kann man durch minimalen Takt (128kHz, es wird ja eh nichts
> gerechnet, sonder nur auf Timer gewartet) und Abschalten aller nicht
> benötigten Dinge via PRR zum Sparen zwingen.

Das mache ich ja schon (ADC, AC aus, siehe Code)

> Sparsam eine bestimmte Zeit warten kann ein AVR mit Asynchron
> arbeitendem Timer2.
> Ob sich der Aufwand angesichts der Signal-LED aber lohnt, ist eine
> andere Frage.

Den hat der Tiny85 leider nicht ;)

Es debug-kreativitaet bitte.

Wenn man so ein Problem untersuchen moechte beginnt man mit :

 main() {
   init();
   sei();
   while 1 {
     pina.1=0;
     pina.1=1;
     MachIrgendwas();
     SetSleepRegister()
     sleep();
   }

Den Pin A1.1 schaut man sich auf dem Oszilloskop an. Dann sieht man, 
wann geloopt wird.

Jeder AVR hat ein anderes Verhalten, daher das Datenblatt konsultieren.
Falls das Erwachen mit einem Interrupt geschehen soll/muss/darf muss der 
richtig initialisiert sein.

Und hoert mit dem Tiny Scheiss auf. Die paar Cents gegenueber einem Mega 
sind an einem falschen Ort gespaart,

> den hat der Tiny85 leider nicht
Ja und deshalb ist er vielleicht auch nicht die beste Wahl.
Im DB ist auch rauszulesen, daß der Timer1 10-mal soviel Strom wie 
Timer0 braucht, vermutlich wegen dem ganzen Highspeed-Gedöns. Da beide 
8-Bit sind, würde ich lieber mit Timer0 warten und mit Timer1 blinken. 
Oder vielleicht gleich mit einem Timer auskommen.

Strom sparen geht natürlich auch durch pures Absenken des CPU-Taktes.
Z.B. mit einem 32kHz Quarz, wie im anderen Tread bereits erwähnt.

Dampf T. schrieb:
> Wenn man so ein Problem untersuchen moechte beginnt man mit :
>
>  main() {
>    init();
>    sei();
>    while 1 {
>      pina.1=0;
>      pina.1=1;
>      MachIrgendwas();
>      SetSleepRegister()
>      sleep();
>    }
>
> Den Pin A1.1 schaut man sich auf dem Oszilloskop an. Dann sieht man,
> wann geloopt wird.

Das hört sich interessant an. Leider fehlts hier an der technischen 
Ausstattung (noch) :)

> Und hoert mit dem Tiny Scheiss auf. Die paar Cents gegenueber einem Mega
> sind an einem falschen Ort gespaart,

Ok, das war jetzt weniger hilfreich. Irgendeine Daseinsberechtigung 
werden die Tiny doch haben; bei mir war es eine Platzfrage im kleinen 
Gehäuse (nein, SMD ist für mich keine Alternative).

Carl D. schrieb:
>> den hat der Tiny85 leider nicht
> Ja und deshalb ist er vielleicht auch nicht die beste Wahl.
> Im DB ist auch rauszulesen, daß der Timer1 10-mal soviel Strom wie
> Timer0 braucht, vermutlich wegen dem ganzen Highspeed-Gedöns. Da beide
> 8-Bit sind, würde ich lieber mit Timer0 warten und mit Timer1 blinken.
> Oder vielleicht gleich mit einem Timer auskommen.

Ja, das leuchtet ein. Ich denke, dass es dann einfacher umzusetzen wäre 
die Funktionen der Timer zu tauschen. Obowhl es dann ja auch weniger 
Wachphasen gibt, da der Timer 0 nur einen Prescaler bis 1024 hat, es 
also mehr Overflowinterrupts gibt. Aber da denke ich wahrscheinlich auch 
wieder zu menschlich und das fällt gar nicht ins Gewicht :)

Peter D. schrieb:
> Strom sparen geht natürlich auch durch pures Absenken des CPU-Taktes.
> Z.B. mit einem 32kHz Quarz, wie im anderen Tread bereits erwähnt.
Und auf 15 Minuten käme ich damit ja auch recht genau.
Vielleicht in Version 2.0 des Reminders, denn Platz ist auf der Platine 
jetzt keiner mehr lach

Die Leiterplatte ist schon voll .. zeig mal.
SMD ist wirklich eher trivial solange man bei bei 1206, 0805, oder 0603 
bleibt.

Dampf T. schrieb:
> Die Leiterplatte ist schon voll .. zeig mal.
> SMD ist wirklich eher trivial solange man bei bei 1206, 0805, oder 0603
> bleibt.

Ich habe leider gerade kein Photo parat... Asche auf mein Haupt.

Ich habe eine Lochrasterplatine mit 6*7 Lötpunkten.
Darauf ist der Tiny, in der Reihe darüber der Widerstand vom Reset zu 
VCC,
in der Reihe unter dem Tiny ist die LED mit Vorwiderstand an Port B0 und 
GND und der Abblockkondensator ist auf der Unterseite der Platine direkt 
an die Pins des Sockels gelötet.

Das Ganze musste in ein kleines Gehäuse passen...

Schau Dir mal Abschnitt "6.3 System Clock Prescaler" an.
Damit kannst Du den CPU-Takt runterteilen.
Z.B. 8MHz / 256 oder 128kHz / 4
Du kannst die Stromaufnahme mal messen, wieviel das bringt.

Allerdings solltest Du ein Delay (60s) abwarten, ehe Du den Takt runter 
setzt. Sonst kann das Programmieren fehl schlagen. Der Teiler bleibt 
nämlich während des ISP eingeschaltet.
Damit hast Du 60s Zeit, die VCC einzuschalten, das ISP zu starten und 
ein Flash-Erase abzuschicken.

Nette Idee :)

Ich werde die Schaltung nochmal auf dem Breadboard nachbauen um das 
Multimeter dazwischen hängen zu können.

Dann sehe ich auch mal, was da so strommässig passiert :)

Duerfen wir dann mal noch ein Schema sehen ?

Dampf T. schrieb:
> Duerfen wir dann mal noch ein Schema sehen ?

Du meinst den Schaltplan? So wie es aktuell aufgebaut ist, sieht es so 
aus.

(Das der Vorwiderstand zu klein dimensioniert ist, weiß ich bereits)

Sascha M. schrieb:
> (Das der Vorwiderstand zu klein dimensioniert ist, weiß ich bereits)

Zum Stromsparen würde ich aber eine LED eher sehr kurz, sehr stark 
bestromen.

Der Reset sollte noch einen 100nF am Pin haben, und die Programmierpins 
fehlen, die aendern aber nichts. Und die LED benoetigt ein paar 
Versuche, was man denn sehen, resp beleuchten will.

Die Speisung sollten wir aber auch noch haben. Denn wenn da ein LM317 
ist, hast du auch schon verloren. Es gibt DC/DC die laufen mit ein paar 
uA.

Carl D. schrieb:
> Sascha M. schrieb:
>> (Das der Vorwiderstand zu klein dimensioniert ist, weiß ich bereits)
>
> Zum Stromsparen würde ich aber eine LED eher sehr kurz, sehr stark
> bestromen.

Okay, aber dann fehlt leider der visuelle Efekt des Blinkens, der schon 
auffälliger ist.

***

Dampf T. schrieb:
> Der Reset sollte noch einen 100nF am Pin haben

Ich habe diesbezüglich mal das hier gelesen: 
Beitrag "Re: saubere Reset Schaltung - Atmel Mega 8"

> und die Programmierpins fehlen

Nein, die fehlen (aktuell) nicht. Zum Programmieren nehme ich den µC aus 
dem Sockel und stecke ihn in mein Programmierboard, welches ebenfalls 
über eine LED verfügt, mit der ich das gewünschte Programmierergebnis 
prüfen kann.
Wenn ich die Schaltung jetzt auf dem BB nochmal nachbaue, um den Strom 
messen zu können, werde ich die natürlich berücksichtigen.
Wie gesagt, der Schaltplan entspricht dem Ist-Zustand.

> Und die LED benoetigt ein paar
> Versuche, was man denn sehen, resp beleuchten will.

Kannst Du das bitte genauer erklären? Verstehe nicht, was Du meinst.

> Die Speisung sollten wir aber auch noch haben. Denn wenn da ein LM317
> ist, hast du auch schon verloren. Es gibt DC/DC die laufen mit ein paar
> uA.

Die Stromversorgung besteht aus einer 3,6V Lithiumbatterie.
Einen Spannungsregler habe ich nicht. Ist der essentiell wichtig?

Arduino F. schrieb:
> Sascha M. schrieb:
>> Ist der essentiell wichtig?
>
> nööö

Okay, falsch gefragt. Wäre er sinnvoll?

Arduino F. schrieb:
> Sascha M. schrieb:
>> Wäre er sinnvoll?
>
> Sinnvoll ist er, wenn du auf einen bestimmten Spannungsbereich
> angewiesen bist.
> Z.B. wegen der Taktfrequenz.
> Oder dicht an den 1,8V bis 5,5V Grenzen arbeitest.
>
> Scheint mir alles bei dir nicht der Fall zu sein.

Okay, sehr gute und verständliche Antwort :)
Danke Dir!

Wie niedrig soll der Stromverbrauch denn sein?
Bei 128 kHz Takt und 3.6V liegt er im Idle bei ca. 70uA (Datasheet 
Fig.22-10).
Damit kommt man bei den üblichen Spannungsquellen doch schon recht weit.

Horst M. schrieb:
> Wie niedrig soll der Stromverbrauch denn sein?
> Bei 128 kHz Takt und 3.6V liegt er im Idle bei ca. 70uA (Datasheet
> Fig.22-10).
> Damit kommt man bei den üblichen Spannungsquellen doch schon recht weit.

Sagen wir mal so: es gibt keine bestimmte Anforderung.
Wahrscheinlich wird die Batterie auch ohne aktuelle Anpassungen relativ 
lange halten (< 1mA bei 1 MHz im Active Mode).
Mein Ziel ist es, zu lernen und zu schauen, was möglich ist. Das ist mir 
wichtiger, als eine höhere Batterielebensdauer :)

Ich wuerd einen Lowpower Mega empfehlen, den auf 1.8V zu drosseln, und 
mit 32kHz am T2 laufen zu lassen. Wenn man noch mehr sparen muss, den 
32kHz Quarz raus und eine RTC wie DS1302 an den Interrupt ran, die 
weniger als 1uA zieht. Die kann man auf einen Zeitpunkt programmieren, 
und die macht dann das auch so.
Dann gibt es auch Spannungsregler von Texas, die machen 1.8V von 5V oder 
weniger runter, und ziehen selbst nur 10uA. eim aufwachen aus dem Sleep 
muss dann erst der richtige Quarz anschwingen und dann wird die Spannung 
wieder erhoeht.

Dampf T. schrieb:
> Ich wuerd einen Lowpower Mega empfehlen, den auf 1.8V zu drosseln, und
> mit 32kHz am T2 laufen zu lassen. Wenn man noch mehr sparen muss, den
> 32kHz Quarz raus und eine RTC wie DS1302 an den Interrupt ran, die
> weniger als 1uA zieht. Die kann man auf einen Zeitpunkt programmieren,
> und die macht dann das auch so.
> Dann gibt es auch Spannungsregler von Texas, die machen 1.8V von 5V oder
> weniger runter, und ziehen selbst nur 10uA. eim aufwachen aus dem Sleep
> muss dann erst der richtige Quarz anschwingen und dann wird die Spannung
> wieder erhoeht.

Mit externem RTC kann das dann aber der Tiny auch wieder. Per PinChange.
Und er braucht PowerDown egal bei welcher Spannung kein 1μA Laut DB, 
ohne WD).

> Okay, aber dann fehlt leider der visuelle Efekt des Blinkens, der schon
> auffälliger ist.

Der wird durch den Effekt des Blitzens ersetzt.
Kurze Impulse mit allem was der Tiny-Ausgang hergibt.

Carl D. schrieb:
>> Okay, aber dann fehlt leider der visuelle Efekt des Blinkens, der schon
>> auffälliger ist.
>
> Der wird durch den Effekt des Blitzens ersetzt.
> Kurze Impulse mit allem was der Tiny-Ausgang hergibt.

Okay, aber dann muss ich erst noch von weiß auf rot umlöten. Tut jetzt 
schon in den Augen weh :)