Attiny85 anfänger

Sandro G. schrieb:
> Also eine Watchdog funktion die irgendwie länger als 8s geht. oder er
> muss halt aller 8s "aufwachen" bis die 16 stunden rum sind. was
> wahrscheinlich wieder problematisch wird durch den "kleinen"
> Speicherplatz und die Codegröße wahrscheinlich sprengen wird.

Wie genau müssen die Zeiten sein?
Mit dem Watchdog-Timer ist diese Zeit kein Problem, nur ist der WD-Timer 
relativ ungenau, auch temperaturabhängig. Man kann jedoch mit einem Test 
einen Abgleich für den vorliegenden IC durchführen.
Codegröße bzw. Speicherplatz sind hier kein Thema, das sind so wenig 
Codezeilen, dass auch ein Tiny25 damit bei weitem nicht ausgelastet ist.
Der 8s WD-Timer muss nur 7200 mal ablaufen: Counter auf 7200 setzen und 
durch den WD-Interrupt dekrementieren, bei Null ist die Zeit um. In den 
jeweiligen 8s-Abschnitten kann man ihn noch in den Sleep schicken um 
Strom zu sparen.

Andreas B. schrieb:
> Dann kann
> auch ein ATTiny4 mit max. 10% seiner Ressourcen.

Du kannst kein dabla lesen.
Der hat keinen 32 Bit Timer!
Keine Ahnung aber mitreden wollen🤮

Sandro G. schrieb:
> Da liegt auch mein Problem, ich finde keine Anhaltspunkte wie ich den
> Attiny direkt programmieren kann.
> Ich bin auf der Suche nach einer Seite die mir "c" für den Attiny etwas
> näher bringt.

http://stefanfrings.de/mikrocontroller_buch/index.html

Der Tag hat 24 Stunden, da sind 30 Minuten ungefähr 2%. Das entspricht 
der Genauigkeit, die du mit dem internen R/C Oszillator erreichen 
kannst, wenn due die Temperatur und Spannung einigermaßen konstant 
halten kannst.

Aber natürlich werden sie die Fehler von tag zu Tag aufaddieren. Selbst 
Quarzuhren sind davon betroffen. Sie kommen typischerweise auf 1 Minute 
Abweichung pro Monat.

Wenn dir das noch zu viel ist, brauchst du eine externe Quelle der Zeit 
(DCF-77, GPS, Internet, ...). In dem oben verlinkten Buch wird gezeigt, 
wie man das DCF-77 Signal auf so einem kleinen ATtiny dekodiert.

Sandro G. schrieb:
> Guten Morgen Leute,
>
> also der Timer sollte auf grob 30min genau sein sich dabei aber nicht
> "verschieben" also wenn ich als Beispiel. 16 uhr den schalter betätige
> das der Attiny85 strom bekommt soll dann möglichst auch am nächsten Tag
> ungefahr 16 uhr das licht angehen. Also nicht das ich in 14 Tagen dann
> mal bei Abends 20 Uhr bin das das Licht angeht, ich hoffe ihr versteht
> was ich meine

Dann musst du dir über den Takt (die Takt-Erzeugung) Gedanken machen.

Sehr, sehr grob und sehr, sehr überschlägig abgeschätzt:
Interner Schwingkreis: 1% (bis zu 14½ Minuten pro Tag daneben)
Keramik Schwinger: 0.1% (1½ Minuten pro Tag)
billiger Quarz: 0.01% (9 Sekunden pro Tag)

Ohne Kalibrierung…

Sandro G. schrieb:
> Jetzt muss ich doch aber mal ganz blöd fragen:
> Wie machen das diese billigen Led Lichterketten mit Timer funktion?

Sie sind oft genau so ungenau, wie du es nicht haben willst.

Abgesehen davon: Quarze sind nicht ungewöhnlich. Jede billige 3€ 
Armbanduhr enthält eine Quarz, da kannst du dir mal überlegen, wie viel 
von den 3€ wohl für die Herstellung Elektronik drauf ging.

Sandro G. schrieb:
> also der Timer sollte auf grob 30min genau sein sich dabei aber nicht
> "verschieben" also wenn ich als Beispiel. 16 uhr den schalter betätige
> das der Attiny85 strom bekommt soll dann möglichst auch am nächsten Tag
> ungefahr 16 uhr das licht angehen. Also nicht das ich in 14 Tagen dann
> mal bei Abends 20 Uhr bin das das Licht angeht, ich hoffe ihr versteht
> was ich meine
Wenn du jeden Tag manuell triggerst, dann kann man das schon auf wenige 
Minuten genau machen mit dem WD-Timer. Den kann man schon anpassen, dass 
er die Ablaufdauer nur um wenige Minuten verfehlt.
Wenn das allerdings automatisch alle x Stunden eine Reaktion haben 
willst ohne manuellen Eingriff dazwischen, dann eignet sich der WD-Timer 
nicht, denn dann verschiebt sich der Ablaufzeitpunkt natürlich an jedem 
Tag um den vorhandenen Fehler. Wurde oben schon erläutert.

Soll der jetzt 16h laufen oder 24h? Bzw. was heißt:
Sandro G. schrieb:
> "einfachen" 8/16 Timer
und
Sandro G. schrieb:
> bis die 16 stunden rum sind

Stefan ⛄ F. schrieb:
> Wenn dir das noch zu viel ist, brauchst du eine externe Quelle der Zeit
> (DCF-77, GPS, Internet, ...). In dem oben verlinkten Buch wird gezeigt,
> wie man das DCF-77 Signal auf so einem kleinen ATtiny dekodiert.
Auch einen DCF-Empfänger wird der Tinyx5 noch nebenbei dekodieren 
können, GPS weiß ich nicht, Internet wird schwierig.
Auch möglich ist ein kleines RTC-Modul. Da bleibt es dann bei weniger 
als 1-2 Minuten pro Jahr an Ablage. Dort kann man eine Alarmzeit 
einstellen, wann der µC wieder reagieren soll. Und der kann komplett 
schlafen in der Zwischenzeit und schafft z.B. 3 Jahre Laufzeit mit drei 
AA-Zellen...

@TO: Vielleicht erklärst du nochmals ganz genau, was du machen willst, 
wie das Ganze bedient werden soll und was jeweils passieren soll. 
Triggerst du immer zum Start jedes Zyklus manuell und dann soll nach 
Ablauf einer Zeit was passieren oder willst du einfach alle x Stunden 
automatisch eine Reaktion über das ganze Jahr hinweg?

Sandro G. schrieb:
> Die Kette soll entweder 4 oder 6 Stunden Leuchten und dann 20 oder 18
> stunden aus sein (vergesst die 8/16 von oben bitte, das war nur ein
> Beispiel).

Ok.
Weiterer Vorschlag: Das Aktivieren der Lichterkette ist ja nur bei 
Dunkelheit sinnvoll. Also könnte man z.B. mit einem LDR feststellen, 
wann es dunkel genug ist und erst dann einschalten. Eine feste Uhrzeit 
am Tag ist dabei eher nicht notwendig. Die 4h oder 6h Leuchtdauer müssen 
vermutlich auch nicht auf die Minute genau sein, also wird der WD-Timer 
problemlos ausreichen.
Mein Ansatz: WD-Timerinterrupt mit 8s-Intervall (längste mögliche 
Intervallzeit, die ist übrigens 8192ms) betreiben. Nach Aufwachen mit 
dem ADC die Helligkeit messen (LDR oder direkt am Solarmodul), wenn es 
dunkel genug ist, das Licht einschalten und den WD jetzt für die Zählung 
der Ablaufzeit verwenden. Danach wieder zum triggern des ADC, um den 
nächsten Übergang von Hell nach Dunkel zu finden. Dann summieren sich 
die WD-Zeitfehler nicht ständig auf, allerdings schwankt die 
Einschaltzeit je nach Wetterlage.
Das kann man noch verfeinern, wenn man den ADC erst wieder nach z.B. 23h 
aktiviert, denn der braucht auch Energie wenn damit in der Nacht- bzw. 
der dann folgenden Tagphase dauernd gemessen wird. Auch muss man nicht 
unbedingt alle 8s die Helligkeit messen, da reichen Abstände von 5 oder 
10 Minuten.

Sandro G. schrieb:
> in der Theorie müsste ich den LDR ja als eingang definieren und dann
> aller 10min (sollte dicke reichen) auslesen lassen ob er "betätigt"
> wurde oder nicht.
> ... in Sleep setzen bis der LDR durchschaltet?

LDRs werden nicht "betätigt", das sind analoge Bauteile. In meinem Buch 
beschriebe ich die Nutzung von Fototransistoren für diesen Zweck.

Sandro G. schrieb:
> in der Theorie müsste ich den LDR ja als eingang definieren und dann
> aller 10min (sollte dicke reichen) auslesen lassen ob er "betätigt"
> wurde oder nicht.

Ein LDR ist ein mit der Helligkeit sich ändernder Widerstand, er wird 
nicht 'betätigt' bzw. er schaltet nicht. Er wird zusammen mit einem 
recht hochohmigen Widerstand als Spannungsteiler verschaltet. Der LDR 
ist hochohmig bei Dunkelheit (MegOhm) und bei Helligkeit geht er runter 
bis unter 1kΩ. Es fließt also immer ein Strom. Der ADC liest die 
Spannung am Abgriff. Also eine rein analoge Angelegenheit.
Deshalb ist es notwendig, dass der WD den µC immer wieder weckt und du 
dann, evtl. jedes 50. oder 100. Mal (sind dann 400s bzw. 800s) mit dem 
ADC eine Messung durchführst. Das Aufwecken des WD alle 8s und dann 
festzustellen, dass nichts zu tun ist und wieder einzuschlafen, kostet 
nur sehr wenig Energie. Den ADC zu aktivieren und zu messen schon etwas 
mehr, aber das ist ja auch in <1ms längst vorbei.
Sonst müsstest du einen Komparator verwenden, der dann den digitalen Pin 
triggern kann und ja, dann kann man quasi die ganze Pausenzeit 
durchschlafen. Das wird aber definitiv keine Energie einsparen!

Ich kann dir leider nicht sagen, wie sich das in der Arduino-Umgebung 
verhält - ich programmiere alles außerhalb, direkt in C. Ob da z.B. 
Aktivieren und Deaktivieren vom ADC leicht möglich ist. Jedenfalls 
müsste man in deinem Beispiel den Spannungsteiler mit 'analogRead' 
einlesen.

Sandro G. schrieb:
> Jetzt habe ich für den Balkon ein kleine Solarmodul aus einer 5V Zelle
> einem Tp4055 Laderegler, einem 18650 Lipo Akku und einem
> LP 2950 ACZ3,0 LDO gebaut, die Lichterkette wird derzeit über einen
> einfachen schalter geschalten.
Brauchst du da den LDO auf 3.0V? Wozu? der Tiny läuft direkt an einer 
18650, die ja zwischen knapp 3V und 4.2V Spannung liefert. Ich würde 
direkt drauf verzichten. Dann kann man auch direkt eine 
Unterspannungsabschaltung mit einbauen (UBatt als Referenz und Messung 
der internen 1.1V-Referenz).

Sandro G. schrieb:
> Der Ldo ist nur zur Spannungsstabilisierung für die Leds das die bei
> abnehmender Spannung nicht dunkler wird. Der Attiny klemme ich direkt an
> den Akku und werde dann wahrscheinlich einen Transistor zur schaltung
> der Leds nehmen

In diesem Fall wäre ein Spannungsregler mit Enable-Eingang sinnvoller. 
Oder gleiche eine schaltbare Konstantstromquelle.

Sandro G. schrieb:
> Ich würde auch lieber in C schreiben, mein Problem dabei ist das ich mit
> dem Atmel studio noch keine möglichkeit gefunden habe das Program über
> den Arduino Nano auf den Attiny zu schreiben.

Du kannst aber avrdude außerhalb der IDE nutzen, gerne auch mit einer 
GUI. Das in der IDE eingebettete Programmiertool bringt dir da sowieso 
keinen wesentlichen Zusatznutzen, verglichen mit einem externen 
Programm.

Mal ganz kurz ins Unreine gedacht:
Uhrenquarz als Systemtakt.
System clock:   32768Hz
System Clock Prescaler: 0b1000 (÷256)
Systemtakt: 128clk/s

Timer 1 (8Bit):
free running
Timer/Counter1 Prescale Select: 0b1111 (÷16384)
Überlauf mit IRQ alle 128s

Nach dem Reset sofort Laternen einschalten und Zähler auf null.

Einen Software Zähler bemühen und bei jedem IRQ des Timers hochzählen.
Falls Triggerpunkt erreicht:
* Ausgang entsprechend aus- bzw. wieder einschalten

Sofort wieder in den Sleep Mode (für die nächsten 2min).

Stromaufnahme: praktisch null
Aufwand: praktisch null

Eventuell Kalibrierung für Frequenzabweichung, ansonsten Batterie 
abklemmen und wieder anklemmen um Zyklus zu starten.

Statt Sleep Modus und Watchdog kannst du alternativ und wahrscheinlich 
viel einfacher die CPU Frequenz herab setzen, indem du das CLKPR 
Register beschreibst.

1

CLKPR = 128 + 8; // divide 8 Mhz clock by 256 -> 31.250 kHz

Die Stromaufnahme des Mikrocontrollers ist dann wahrscheinlich schon 
geringer, als die deiner Spannungsteiler an den analogen Eingängen.

Sandro G. schrieb:
> Ich würde euch jetzt darum bitten das ihr den Code mal anseht ob das
> überhaupt so funktionieren kann

Bringe doch erstmal deinen Programmieradapter ans Laufen und probiere es 
aus. Das geht schneller, als hier theoretisch über ungetesteten Code zu 
diskutieren.

Sandro G. schrieb:
> ich habe bis jetzt immer auf 1Mhz getaktet weil mir da die delayzeit bis
> jetzt am genauesten war.

Die Genauigkeit ändert sich nicht bei geringeren Taktfrequenzen (es sei 
denn dire geht es um Mikrosekunden).

Den Aufwand mit Sleep Modi würde ich nur betreiben, wenn du den 
Mikrocontroller ganz anhalten wirst. Nur dann lohnt es sich. Du brauchst 
aber noch einen laufenden Timer.

Was nützt es dir, die Stromaufnahme der CPU auf < 1µA zu bringen, wenn 
da noch ein Oszillator läuft der alleine schon mehr als 100µA aufnimmt?

Zudem ist der Watchdog Oszillator erheblich weniger genau, als der 
Hauptoszillator. Dafür nimmt er allerdings auch weniger Strom auf. Einen 
Tod muss man sterben.

Rolf M. schrieb:
> Warum soll der 4 Stunden an sein?

Er soll nach Einbruch der Dunkelheit eine Lichterkette für 4h 
einschalten und das täglich wiederholen.
Die 4h sind halt der Wunsch des TO bzw. seiner Frau 😀.

Rolf M. schrieb:
> Und dazu muss der µC währenddessen ein paar Milliarden mal im Kreis
> rennen?

Ist doch egal, die Stromaufnahme wird von den LEDs dominiert.

Sandro G. schrieb:
> 4 stunden sollen die Ledketten leuchten die ich über ein Relais
> schalten
Relais?
Da brauchst du dir um die Stromaufnahme des µC keine Gedanken mehr zu 
machen! ;-)

Strom sparen und Relais...
Ist das nicht ein Widerspruch?

Der Tiny kann auch im Tiefschlaf Relais und FET aktiv halten.

Noch was, Arduino delay(unsigned long) // in ms

Damit reduziert sich dein Programm auf

1

loop() {

2

Einschalten()

3

delay(4*60*60*1000)

4

Ausschalten()

5

delay((24-4)*60*60*1000)

6

}

Wenn's irgend wann mal nicht mehr präzise genug ist, einfach Abends 
power-off und wieder power-on.

EAF schrieb:

> Strom sparen und Relais...
> Ist das nicht ein Widerspruch?

Nicht unbedingt - siehe bistabile Relais.

Ich hänge mal einen Softwarevorschlag an. Vor längerer Zeit mal 
angefertigt und vermutlich auch getestet 😀.
Mit WD_PRESCALE stellt man den WD-Timer ein. Im Beispiel 4s.
Mit TIME_MULTIPLY das gewünschte Vielfache für die Dauer, im Beispiel 
ist es 2, also insgesamt 8s Dauer.
Für dein Beispiel würde ich WD_PRESCALE auf 9 setzen für 8s-Perioden und 
TIME_MULTIPLY auf 4h*3600s/h/8s = 1800. Wenn es genauer werden soll, 
muss dieser Wert für den vorhandenen IC angepasst werden.
Da es als Treppenlichtautomat gedacht war, wird es über eine Taste 
(aktiv LOW) gestartet; da besteht noch die Erweiterungsmöglichkeit für 
den Lichtsensor. Problem in obigem Beispiel: die SW ist für einen kurzen 
Tastendruck ausgelegt und nicht für ein dauerhaftes LOW am Eingang. Man 
müsste hier mit dem Pin Change Interrupt arbeiten.
Während der aktiven Leuchtdauer (PB1 ist auf HIGH) wacht der µC hier 
alle 4s auf und dekrementiert den l_wcount bis er auf Null angekommen. 
Dann wird das Licht abgeschaltet. Nach Abschalten geht der µC in den 
Power-Down-Tiefschlaf und wartet auf das erneute Aufwecken mit Taste 
über INT0 (PB2).

Mit dem 32 Bit Wert für l_wcount wären dann theoretisch über 1000 Jahre 
möglich 😀.
Auf eine Atomic-Block habe ich verzichtet, weil nach dem Aufwachen mit 
dem WD genügend Zeit vorhanden ist, um l_wcount zu prüfen ohne das was 
anderes dazwischenfunkt.

Alexander S. schrieb:
> Ganz so einfach wie Stefan es vorführt ist es nicht, zuerst muss CLKPCE
> mit "1" gecleart und anschliessend innerhalb von 4 Takten der Teiler
> gesetzt werden

Ach ja stimmt.

Noch ein Hinweis: das obige Programm lastet einen Tiny25 nur zu 17% aus 
...

Rolf M. schrieb:
> Matthias S. schrieb:
>> Und bevor man was anderes macht,
>> erstmal die CKDIV8 Fuse im Tiny löschen, sonst läuft der Tiny mit 16kHz
>> oder gar mit 4kHz.
>
> Was für die Aufgabe immer noch mehr als genug wäre - sofern man ihn noch
> geflasht bekommt.

Takt weiter runter! Uhrenquarz ÷ 256! (oder aus dem Auto ein altes 
Blinkrelais)
Man kann dann ja immer noch mit 'ner Morsetaste flashen ;-)

Andreas B. schrieb:
> Das kann man auch gut mit avrdude und USBASP in
> den Griff bekommen, wenn man den -B Parameter verwendet. Aber Achtung:
> Das geht nur mit einer neueren USBASP Firmware. Bei vielen Chinaclones
> ist eine steinalte FW drauf.

Sandro G. schrieb:
> Arduino Nano (als Isp)

Kein USBASP.

Rolf M. schrieb:
> Wozu?

Das frage ich mich auch. Im SLEEP_MODE_PWR_DOWN nimmt der unter 1µA auf, 
weniger als die Selbstentladung einer Batterie.

Bei der Aufgabe wäre es sinnvoller sich auf die Triggerung zu 
konzentrieren.  Der Vorschlag mit dem LDR am Resetpin ist auf den ersten 
Blick bestechend, aber die Resetschwelle ist nirgends definert und liegt 
irgendwo zwischen 0.2VCC und 0.9VCC. Es gibt keine Aussage, wovon das 
abhängt (Temperatur, Exemplar usw.) und wie stabil das bleibt. Auch ist 
die interne HW am Resetpin nicht beschrieben; es muss anders sein als 
bei einem normalen IO, denn PB5 wird dann als 'weak IO' bezeichnet.
Zudem ist immer der interne PU am Resetpin aktiv, was den Betrieb eines 
LDR an der Stelle etwas erschwert und der notwendige Spannungsteiler 
wird auf jeden Fall mehr Strom 'fressen' als der Tiny im Power-Down.
Wobei: Bei 4h Betrieb mit 200mA ist das alles vernachlässigbar, auch bei 
einer Variante mit dem ADC, der alle n*8s den Pegel am 
LDR-Spannungsteiler misst.
200mA*4h sind 800mAh, z.B. 10µA*20h wären 0.2mAh. Peanuts.

Ihr beiden habt ein ernsthaftes Defizit im Bereich eurer 
Spass-Detektoren.
War der Hinweis auf ein Kfz-Blinkrelais zur Takterzeugung zu 
unterschwellig?

Norbert schrieb:
> War der Hinweis auf ein Kfz-Blinkrelais zur Takterzeugung zu
> unterschwellig?

Post in dem Kontext, die das Wort 'Relais' enthalten, ignoriere ich; es 
dringt also nicht mal vor zum Spaßdetektor 😉.

Ich habe arge Zweifel, ob das mit dem LDR am Reset Eingang 
zufriedenstellend funktionieren wird.

HilfeK wies am 15.08.2021 17:49 darauf hin, dass die Schaltschwelle 
nicht klar definiert und wahrscheinlich nicht stabil ist. Dazu kommt die 
Stromaufnahme durch den internen Pull-Up Widerstand an diesem Pin. Dem 
stimme ich zu.

Außerdem glaube ich, dass man je nach Jahreszeit andere Bedürfnisse hat, 
wann man das Licht einschalten will. Wenn du es zum Beispiel für den 
Juli so einstellst, dass das Licht nachts um 22:00 an geht, dann wird es 
im September vielleicht schon Nachmittags um 17:00 an gehen. Dann wird 
der Akku schon leer sein, bevor der gemütliche Abend kommt.

Deswegen würde ich den Ansatz mit Timer weiter verfolgen, den man auch 
von kommerziellen Produkten gewohnt ist. Das wird schon seinen Grund 
haben.

Für einen halbwegs genauen Timer braucht man den Haupt-Oszillator des 
Mikrocontrollers (mit R/C oder Quarz). Der Watchdog Oszillator wäre mir 
viel zu wankelmütig. Alleine wegen dem Timer sind wir bei einer 
Stromaufnahme im bereich um 100µA. Wenn man diese Kröte erstmal 
geschluckt hat, kann man sich überlegen, ob die Nutzung des (für den TO 
komplizierten) Sleep Modus überhaupt noch Sinn macht. Meiner Meinung 
nach nicht, denn die langsam getaktete CPU braucht nimmt bereits weit 
weniger Strom auf, als der Oszillator. Das wird keinen großen 
Unterschied bezüglich der Laufzeit machen.

Wenn er dann später etwas fortgeschrittener ist, kann er das Programm ja 
immer noch umschreiben.

Ich würde mich eher auf vernünftige Hardware konzentrieren. Das heisst 
für mich z.B., dass der LDR nicht ständig am Akku hängt, sondern nur bei 
bedarf während der Messungen. Ansonsten können wir und das Feilschen um 
Mikroampere gleich sparen.

Stefan ⛄ F. schrieb:
> Ansonsten können wir und das Feilschen um
> Mikroampere gleich sparen.

Muss man nicht, wie ich oben versucht habe, vorzurechnen. Die LEDs 
verbrauchen in den 4h 800mAh.
Selbst wenn der WD-Oszillator 100µA braucht (meine Erfahrung ist eine 
andere: gerade 7µA @ 4.5V an einer vergleichbaren Schaltung gemessen; µC 
läuft sonst mit 1MHz), dann sind es für die restlichen 20h eben nur 2mAh 
für den µC.
Deshalb sind die Verwendung des ADC, des Komparators oder des 
Spannungsteilers mit dem LDR in Bezug auf den Stromverbrauch 
unbedeutend.

Andreas B. schrieb:
> Na, ja. LDRs sind ziemlich hochohmig wenn es dunkel ist. D.h. Der
> Spannungsteiler kann da auch im MOhm Bereich liegen. Es spricht aber
> auch nichts dagegen, den LDR mit einem Port zuzuschalten.
Exakt, wenn man einen freien Port hat. Kür!

Stefan ⛄ F. schrieb:
> Ich habe arge Zweifel, ob das mit dem LDR am Reset Eingang
> zufriedenstellend funktionieren wird.

Ich habe mal ein paar Messungen durchgeführt. Takt 1 Mhz intern, wie 
Neuzustand.
Ergebnis: Reset ist nicht gut geeignet!
- Die Schwellen an mehreren Exemplaren von Tiny 25/45/85 lag bei knapp 
2.0V @5V VCC bzw. bei 1.4V @3.0V VCC, (fast) keine Hysterese. Das sieht 
noch nicht ganz schlecht aus.
Jedoch:
- Die Stromaufnahme im Reset ist weit weg von 0mA; sie lag bei etwa 
300µA.
- Dabei müssen aber alle IOs mit externem PU/PD beschaltet werden, sonst 
floaten sie und die Stromaufnahme ist noch höher.

Das Datenblatt nennt eine Stromaufnahme bei "Idle" zwischen typ. 100µA 
und max. 2mA, je nach VCC und Taktfrequenz - ich weiß aber nicht, ob 
damit die Stromaufnahme im Reset gemeint ist. Es würde aber passen.

Matthias S. schrieb:
> Ok, das kam gerade rein und ist natürlich ein Killerkriterium. Dann
> vergessen wir es :-P

Mich hat deine Idee ja fasziniert, weshalb ich auch mehr wissen wollte 
und gemessen (und mich gewundert) habe.
Vergessen muss man es trotzdem nicht. Ein Killerkriterium ist es nur, 
wenn man maximal viel Strom sparen will/muss. Aber die 300µA sind 
gegenüber den 200mA für 4h immer noch unbedeutend in dieser Anwendung, 
zumal im Rest der Nacht der µC ja zunächst im Tiefschlaf wäre und dann 
<<1µA benötigt. Erst wenn es Tag wird, wird der Reset ausgelöst und da 
bringt die Solarzelle ja schon Energie.
Meine Aussage oben muss ich nach den Überlegungen also etwas 
abschwächen:

HildeK schrieb:
> Ergebnis: Reset ist nicht gut geeignet!
Das gilt also nur, wenn es reiner Batteriebetrieb wäre.
In der gewünschten Anwendung ist es mit dem Reset auch sinnvoll möglich. 
Nur meine Hoffnung, dass die Stromaufnahme im Reset beim Power-Down-Wert 
liegt, muss ich begraben ...

Sandro G. schrieb:
> jetzt habe ich aber das Problem das er sich im delay (4*60*60*1000);
> aufhängt.

1

delay (4 * 60 * 60 * 1000);

Bei mir gibt der Compiler eine entsprechende Warnung aus:

> warning: integer overflow in expression [-Woverflow]

Aktiviere mal in den Voreinstellungen alle Warnungen, denn sie sind 
nützlich.

Hier kommt es zu einem Integer-Überlauf, denn das würde laut 
Taschenrechner 14400000 ergeben. Wenn du eine der Zahlen als 
long-integer kennzeichnest, wird er es korrekt umsetzen:

1

delay (4 * 60 * 60 * 1000l);

> die Stromaufnahme im Reset beim Power-Down-Wert liegt
> Darauf hatte ich ja auch spekuliert

Das verstehe ich jetzt nicht - wie käme man am 'Reset Pull-up Resistor' 
von 30..60 kOhm vorbei?

S. Landolt schrieb:
> Das verstehe ich jetzt nicht - wie käme man am 'Reset Pull-up Resistor'
> von 30..60 kOhm vorbei?

Du hast ja recht! Man muss halt an den auch denken - Asche auf mein 
Haupt.

Stefan ⛄ F. schrieb:
> Hier kommt es zu einem Integer-Überlauf, denn das würde laut
> Taschenrechner 14400000 ergeben. Wenn du eine der Zahlen als
> long-integer kennzeichnest, wird er es korrekt umsetzen:delay (4 * 60 *
> 60 * 1000l);

Dann machs doch gleich richtig!
Das kleine l kann man mit einer 1 verwechseln.
Zudem fehlt  da noch ein U.

1

delay (4UL * 60 * 60 * 1000);

Zusatztipp:
Da das C++ ist, kann man es sich auch noch ein bisschen schöner 
machen...

1

delay(4_Stunden);

>Ich habe es gestern nochmal getestet und nach guten 6 Stunden dann den
>Stecker gezogen.

Sowas macht man auch erstmal mit einem Test-Delay von einer Minute. Geht 
schneller :-)

Zum Stromsparen könntest Du auch einfach die Taktfrequenz stark 
heruntersetzen, z. B. auf 125 kHz: Interner Oszillator auf 8 MHz plus 
Clock Prescaler auf 64 (CLKPS3:0 = 0b0110). Siehe DB. Mit dem ISP gibts 
dabei keine Probleme, weil der Prescaler ja erst zur Programmlaufzeit 
gesetzt wird, d. h. während des Flashens läuft der µC mit 8 MHz.