Hy Leute, ich habe mir vor kurzem einen Attiny85 und Arduino Nano (als Isp) gegönnt und wollte den Attiny85 als "einfachen" 8/16 Timer der "durchläuft" programmieren. Da liegt auch mein Problem, ich finde keine Anhaltspunkte wie ich den Attiny direkt programmieren kann. Ich habe minimal grundlegendes Wissen in C und konnte über den Arduino Sketch immerhin schon einen Wechselblinker mit Delay programmieren. Ich bin auf der Suche nach einer Seite die mir "c" für den Attiny etwas näher bringt. Es geht in erster Linie nur um den Timer. Dieser soll natürlich so energiesparend wie möglich sein und auch keinen zusätzlichen Taster haben. 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. Vielleicht habt ihr ja eine Seite oder vielleicht sogar direkt antworten oder einfache Codeschnipsel. Ich möchte keinen 100% fertigen Code. Ich danke euch :D
Und im Zweifelsfall findet sich das auch alles im Datenblatt der Attiny24/45/85-Reihe.
https://gist.github.com/joefutrelle/61d7c359ee29f6138c3a http://www.technoblogy.com/show?KX0 https://arduino-projekte.webnode.at/meine-projekte/attiny-im-schlafmodus/wecken-mit-wdt/
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.
Sandro G. schrieb: > ich glaube das wird ne lange nacht :D Lese es lieber tagsüber. Dann bist du wach und lernst auch was dabei. Sandro G. schrieb: > bis die 16 > stunden rum sind. was wahrscheinlich wieder problematisch wird durch den > "kleinen" Speicherplatz und die Codegröße wahrscheinlich sprengen wird. Ein normaler Timer z.B auf 1ms gesetzt kann mit einem 32-Bit Zähler bis ca. 50 Tage zählen. Da braucht es weder RAM noch Flash dazu. Dann kann auch ein ATTiny4 mit max. 10% seiner Ressourcen.
:
Bearbeitet durch User
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
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
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…
Jetzt muss ich doch aber mal ganz blöd fragen: Wie machen das diese billigen Led Lichterketten mit Timer funktion? die haben doch nicht etwa ein Quartz mit an board?
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: > Wie machen das diese billigen Led Lichterketten mit Timer funktion? die > haben doch nicht etwa ein Quartz mit an board? Sie werten die Netzfrequenz aus, wenn sie an der Steckdose hängen. Die Netzfrequenz beträgt im Mittel ziemlich exakt 50 Hz. Mal (übertrieben formuliert) 49 Hz, mal 51 Hz - aber im Mittel ziemlich genau 50 Hz. Und das ist meist mehr als genau genug. Oder ja, eben ein einziger Quarz - nimmt nur sehr wenig Platz weg und kostet nicht viel.
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?
Also von Anfang an: Meine Frau hat hier massig dieser Batteriebetriebenen Lichterketten run fliegen. 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. Kurze Zeit später kam halt die Idee das ganze automatisch zu relaisieren. Da ich aber keine "einfache" 3V Zeitschaltuhr gefunden habe wurde das Interesse an Mikrokontrollern immer Größer ( Habe es mir irgenwie einfacher Vorgestellt) 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). Um das möglichst automatisch passieren zu lassen wollte ich den derzeit einfachen On/Off schalter gegen einen On/Off/On schalter tauschen. On= Dauerlicht Off= Ist klar ;) On= Timerfunktion OHNE Manuellen eingriff. Das ganze soll natürlich so Energiesparsam wie möglich sein.
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.
Die Idee mit dem LDR ist eine Interessante Sache, 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. Das einzige was mich jetzt noch etwas verzweifeln lässt ist der WD kann ich den Attiny nicht einfach nach den (beispiel) 4 stunden komplett in Sleep setzen bis der LDR durchschaltet? ich weis jetzt zwar nicht wieviel Strom so ein LDR verbraucht wenn er den ganzen Tag an ist aber ich behaupte das das nicht soviel sein kann. Zu testzwecken könnte ich ja einfach einen Taster nehmen. Also als Codebeispiel (Sketch):
1 | int LEDPin = 4; |
2 | int LDRPin = 3; |
3 | |
4 | void setup(){ |
5 | pinMode(LEDPin,OUTPUT); |
6 | pinMode(LDRPin,INPUT); |
7 | }
|
8 | |
9 | void loop(){ |
10 | if (digitalRead(LDRPin)==HIGH){ |
11 | digitalWrite(LEDPin, HIGH); |
12 | delay(4h) |
13 | } else { |
14 | Sleep; |
15 | }
|
16 | }
|
ich habe den Code jetzt in 10min geschrieben und das mit meinem Anfängerwissen. Deshalb sind die 4stunden als 4h und auch nur ein grobes Sleep. Nicht das es zu verwirrung kommt. Ich glaube das wäre das einfachste. ich verstehe zwar immernoch nicht wie die das bei den Lichterketten so genau hin bekommen. Würde da gern mal einen Quellcode sehen ;)
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).
Hy, 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 möchte ungern 2 Ketten mit jeweils 100mA direkt über den Attiny schalten: Ich ging davon aus das die LDR bei gewisser dunkelheit "durchschalten" und nicht als widerstand fungieren. also muss ich grob gesagt eine Spannungsmessung durchführen und sobald diese über oder unter wert x fällt soll geschalten werden. ich gucke mir jetzt auch mal die Links und das "Buch" nochmal an und werde mich mal daran versuchen. 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. Deshalb hänge ich noch an dem Sketch obwohl ich das auch irgendwie übersichtlicher finde.
:
Bearbeitet durch User
Fachmann schrieb: > 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🤮 Und Du kannst generell nicht lesen. Wo schrieb ich etwas von einem 32-Bit Timer? Einen 32-Bit Zähler setzt man aus 4 8-Bit Registern oder auch aus Ram zusammen. An den TO: Sowohl der Tiny4 als auch der Tiny85 haben einen Analog Comparator, wo Du einen LDR anschließen kannst (als Spannungsteiler). Als Vergleichseingang ein Poti, wo Du die Triggerschwelle einstellst.
:
Bearbeitet durch User
ich habe mich jetzt mal ein bisschen mit dem WD befasst. Ich habe dazu den Code genommen der mir hier gestellt wurde ;) ich habe aber keine wirkliche Ahnung wie da etwas passiert. konktrett will ich jetzt rausfinden wo der Taster definiert wurde und wo ich dann den LDR einbinden muss. von meinem Zeitlichen Problem mal ganz zu schweigen. ich werde mich morgen erstmal weiter mit Millis befassen da ich noch keine Idee habe wie ich egal ob mit delay oder millis dem Attiny sage das der Pin 4 stunden an sein soll. wenn ich die 4 Stunden auf ms umrechne kommt ja eine Utopische Zahl raus. Kurz noch: der Attiny soll nur die 4 stunden an sein und danach kontrollierne ob der LDR den wert unterschreitet also ist es mir egal ob Delay oder mit Millis. Kann man den mehrer Delays "stacken" also
1 | Delay (100000) |
2 | Delay (100000) |
3 | ...
|
Das ist zwar wahrscheinlich äußerst unschön geschrieben aber funktionell
:
Bearbeitet durch User
Mach den Timer doch so dass der nach einschalten des Gerätes die Beleuchtung x Stunden einschaltet, dann ausschaltet und das nach ca. 24 Stunden wiederholt. Wenn der Frau das aus welchen Gründen auch immer (Drift, Sonnenstand usw.) dann nach einigen Tagen nicht mehr passt soll sie das Gerät einfach zur gewünschten Zeit neu einschalten und alles ist gut.
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.
Lutz: So war mein Ursprungsplan, aber anscheind hat der Attiny ein gewisses Zeitspiel. Also 1 Sekunde ist nicht gleich 1 Sekunde. Das Problem dabei ist, das sich dadurch die "einschaltzeit" nicht gleich hält. was mir dabei einfällt: der LDR wird ja nach den 4 stunden kontrolliert und da ist es ja immernoch dunkel. da fängt das Programm ja wieder an.
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.
Ja das habe ich vorhin auch gelesen, ich werde mich damit morgen nochmal in aller Ruhe befassen auch was den Programmier und stromsparaufwand bringt
Sandro G. schrieb: > was mir dabei einfällt: der LDR wird ja nach den 4 stunden kontrolliert > und da ist es ja immernoch dunkel. da fängt das Programm ja wieder an. Aber "noch dunkel" ist nicht dasselbe wie "schon dunkel".
Klopp den Tiny85 in die Tonne. Das bringt nichts. Das ist ein Bauteil fuer Leute, welche bei hohen Stueckzahlen guenstig produzieren muessen. Nimm etwas vernuenftiges, wit etwas Peripherie drin. Zb einen Mega 644 oder so. Und ja, auch hier. Der Hersteller hat sich tatsaechlich dazu hinreissen lassen ein Datenblatt herauszugeben. Herunterlader nur beim Hersteller, nicht bei einem Trittbrettfahrer.
:
Bearbeitet durch User
Moin, Das mag ja sein und ich gestehe das ich mir das einfacher erhofft habe. Jetzt aber einen weiteren Chip zu kaufen wird nicht passieren. Es muss jetzt eine Lösung mit dem attiny85 her
Pandur S. schrieb: > Klopp den Tiny85 in die Tonne. Das bringt nichts. Welche Resourcen fehlen dem Tiny85 Deiner Meinung nach für diese simple Aufgabe? Der ist dafür bereits Overkill. Selbst ein Tiny4 reicht dafür und der langweilt sich noch dabei. Aber Arduino Programmierer kennen es scheinbar nicht anders. > Zb einen Mega 644 > oder so. Warum nicht gleich einen Blackpill, um eine LED einzuschalten? Sandro G. schrieb: > Es muss > jetzt eine Lösung mit dem attiny85 her Wo ist jetzt konkret Dein Problem? Grundsätzliche Lösungsansätze wurden Dir bereits genannt: Timer (Problem der Reproduzierbarkeit) oder über Helligkeit. Oder eben beides: Wenn es dunkel ist 30min warten und dann LED einschalten.
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.
Guten morgen Leute. Ich muss das ganze ding jetzt mal außeinander pflücken. Ich möchte das Projekt über den LDR realisieren. ich habe mich jetzt auch schon bissl hingesetzt und gelesen und geschrieben aber ohne es zu Probieren. Da ich es noch nicht gescahft habe den Avrdude zum laufen zu bekommen, das ist aber ein anderes Problem. Ich würde euch jetzt darum bitten das ihr den Code mal anseht ob das überhaupt so funktionieren kann,oder wo fehler aufgetretten sind. Ich glaube anders komme ich hier auf keinen wirklichen nenner. Ich weis das ich wahrscheinlich die LDR einbindung fehlerhaft, die Delay funktion schlecht (aber denke mal ausreichend) und die WD abfrage noch fehlerhaft ist.
1 | #include <avr/sleep.h> // Sleep Modes |
2 | #include <avr/power.h> // Power management |
3 | #include <avr/wdt.h> // Watchdog timer |
4 | |
5 | const int LED = 3; |
6 | const int LED2 = 4; |
7 | const int LDR = 2; |
8 | |
9 | void setup(){ |
10 | pinMode(LED, OUTPUT); |
11 | pinMode(LED2, OUTPUT); |
12 | pinMode(LDR, INPUT); |
13 | }
|
14 | |
15 | ISR (PCINT0_vect) |
16 | {
|
17 | |
18 | } // end of PCINT0_vect |
19 | |
20 | // watchdog interrupt
|
21 | ISR (WDT_vect) |
22 | {
|
23 | wdt_disable(); // disable watchdog |
24 | } // end of WDT_vect |
25 | |
26 | void resetWatchdog () |
27 | {
|
28 | // clear various "reset" flags
|
29 | MCUSR = 0; |
30 | // allow changes, disable reset, clear existing interrupt
|
31 | WDTCR = bit (WDCE) | bit (WDE) | bit (WDIF); |
32 | // set interrupt mode and an interval (WDE must be changed from 1 to 0 here)
|
33 | WDTCR = bit (WDIE) | bit (WDP3) | bit (WDP0); // set WDIE, and 8 seconds delay |
34 | // pat the dog
|
35 | wdt_reset(); |
36 | } // end of resetWatchdog |
37 | |
38 | void setup () |
39 | {
|
40 | resetWatchdog (); // do this first in case WDT fires |
41 | |
42 | pinMode (LED, OUTPUT); |
43 | pinMode (LED2, OUTPUT); |
44 | pinMode (LDR, INPUT); |
45 | |
46 | // pin change interrupt (example for D4)
|
47 | PCMSK = bit (PCINT4); // want pin D4 / pin 3 |
48 | GIFR |= bit (PCIF); // clear any outstanding interrupts |
49 | GIMSK |= bit (PCIE); // enable pin change interrupts |
50 | } // end of setup |
51 | |
52 | void loop () |
53 | {
|
54 | int val_ldr; |
55 | |
56 | val_ldr = analogRead(LDR); |
57 | |
58 | if (val_ldr >= 200) |
59 | {
|
60 | digitalWrite (LED, HIGH); |
61 | digitalWrite (LED2, HIGH); |
62 | delay (4 * 60 * 60 * 1000); |
63 | digitalWrite (LED, LOW); |
64 | |
65 | goToSleep (); |
66 | } // end of loop |
67 | |
68 | void goToSleep () |
69 | {
|
70 | set_sleep_mode (SLEEP_MODE_PWR_DOWN); |
71 | ADCSRA = 0; // turn off ADC |
72 | power_all_disable (); // power off ADC, Timer 0 and 1, serial interface |
73 | noInterrupts (); // timed sequence coming up |
74 | resetWatchdog (); // get watchdog ready |
75 | sleep_enable (); // ready to sleep |
76 | interrupts (); // interrupts are required now |
77 | sleep_cpu (); // sleep |
78 | sleep_disable (); // precaution |
79 | power_all_enable (); // power everything back on |
80 | } // end of goToSleep |
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.
ich habe bis jetzt immer auf 1Mhz getaktet weil mir da die delayzeit bis jetzt am genauesten war. Ob das Sinnvoll ist weis ich nicht ;)
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.
Andreas B. schrieb: > An den TO: Sowohl der Tiny4 als auch der Tiny85 haben einen Analog > Comparator, wo Du einen LDR anschließen kannst (als Spannungsteiler). > Als Vergleichseingang ein Poti, wo Du die Triggerschwelle einstellst. Braucht aber natürlich alles dauerhaft Strom. Sandro G. schrieb: > Kurz noch: der Attiny soll nur die 4 stunden an sein und danach > kontrollierne ob der LDR den wert unterschreitet also ist es mir egal ob > Delay oder mit Millis. Warum soll der 4 Stunden an sein? > Kann man den mehrer Delays "stacken" also > Delay (100000) > Delay (100000) > ... > Das ist zwar wahrscheinlich äußerst unschön geschrieben aber funktionell Wozu überhaupt ein Delay? Leg den µC doch einfach schlafen. Das tust du in der anderen Zeit doch auch.
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 😀.
HildeK schrieb: > 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 😀. Und dazu muss der µC währenddessen ein paar Milliarden mal im Kreis rennen?
4 stunden sollen die Ledketten leuchten die ich über ein Relais schalten möchte, meiner Meinung muss der Attiny dafür den pin die 4 stunden "an" halten. Ich habe jetzt auch gerade mal genau die Stromaufnahme im "betrieb" angeguckt. die beläuft sich auf ca 1mA laut Google und da wir hier ja gerade über "tode" sprechen würde ich den Attiny für den Anfang permanent laufen lassen und im härtefall einen größeren Akku nehmen. Ich bin jetzt bei ca 1800maH kapazität des Akkus und nach meiner groben rechnung: 24h* 14mA + 4h *200mA pro Tag sind das grobe 2 Tage die das System ohne nachladen funkionieren würde Transistor, LDO und LDR jetzt nicht direkt mit einberechnet. Ich werde also ein eine einfache If schleife für den LDR schreiben und die dann einfach wiederholen lassen. Ja "Sleep()" wäre perfekt aber anscheinend Sprengt das meinen derzeitigen Wissens und Zeittechnischen Stand des ganzen.
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.
Sorry Jungs! Das war reiner Gedankenmatch von mir!!!! Ich möchte die Ledketten über einen TRANSISTOR schalten NICHT über Relais , Sorry Norbert: genau an so eine schaltung habe ich ganz am Anfang gedacht und so wird es wahrscheinlich auch wieder werden. Geschalten wird das ganze dann über den On/Off/On schalter und schon sind wir/ich fertig. Ich danke euch trotzdem wie verrückt. Ich melde mich bestimmt die nächsten Tage mal über das langzeitergebniss oder ob ich doch noch etwas am Code verändert habe.
Stefan ⛄ F. schrieb: > Statt Sleep Modus und Watchdog kannst du alternativ und wahrscheinlich > viel einfacher die CPU Frequenz herab setzen, indem du das CLKPR > Register beschreibst. > CLKPR = 128 + 8; // divide 8 Mhz clock by 256 -> 31.250 kHz 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: CLKPR = (1<<CLKPCE); //Clear Clock Prescaler Change Enable CLKPR = (1<<CLKPS3); //Set Clock Prescaler Select Bits
:
Bearbeitet durch User
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.
Man könnte auch ganz einfach mit dem LDR den Tiny im Reset halten, solange er beleuchtet wird. Dazu kann man am Reset auch noch einen Elko schalten, um das ganze träger zu machen. Wird der LDR abgedunkelt, erwacht der Tiny und lässt dann den 4 Stunden Timer loslaufen. Am Ende setzt sich der Tiny ins Powerdown und wartet auf den Tagesreset vom LDR.
Stefan ⛄ F. schrieb: > 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. Erst mal das und zum zweiten sollte man für diese Anwendung den uC mit den 128kHz Oszillator oder, wenn es genauer sein soll, mit einem 32kHz Uhrenquarz laufen lassen. Das kann man mittels Vorteile auch noch weiter treiben. Der uC hat doch fast gar nicht zu tun. Wenn der regulär mit 128kHz läuft, sind es 0.2mA im laufenden Betrieb. Wenn die LEDs 4/24h laufen, ist das absolut vernachlässigbar. Sandro G. schrieb: > Ich habe jetzt auch gerade mal genau die Stromaufnahme im "betrieb" > angeguckt. die beläuft sich auf ca 1mA laut Google Deine Quelle soll nicht Google, sondern das Datenblatt von Microchip sein! Hier: Typical characteristics -> Active supply current > Ja "Sleep()" wäre perfekt aber anscheinend Sprengt das meinen > derzeitigen Wissens und Zeittechnischen Stand des ganzen. Brauchst Du nicht. Das kannst Du auch später lernen. Im Moment hast Du zu viele Baustellen.
Andreas B. schrieb: > Erst mal das und zum zweiten sollte man für diese Anwendung den uC mit > den 128kHz Oszillator oder, wenn es genauer sein soll, mit einem 32kHz > Uhrenquarz laufen lassen. Da lauert allerdings eine Falle. Man muss sich dann erstmal vergewissern, das der Programmer den ISP so langsam takten kann, um den kleinen Kerl zu programmieren. Beim AVRISP MkII weiss ich, das es geht, beim ISP mit Arduino erstmal testen. 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.
Matthias S. schrieb: > Man könnte auch ganz einfach mit dem LDR den Tiny im Reset halten, > solange er beleuchtet wird. Dazu kann man am Reset auch noch einen Elko > schalten, um das ganze träger zu machen. Wozu dann noch den Controller, da kann mans ja gleich komplett analog aufbauen (was wahrscheinlich auch ausreichen würde). Wenn schon digital, dann richtig: regelmäßiges Sampeln des LDR (Minutentakt?) um die Abenddämmerung zu erkennen (Helligkeit muss stetig abnehmen, nicht nur Schaltschwelle erreichen). Dann 4 Stunden einschalten, Reset mit der Morgendämmerung.
Sandro G. schrieb: > 4 stunden sollen die Ledketten leuchten die ich über ein Relais schalten > möchte, meiner Meinung muss der Attiny dafür den pin die 4 stunden "an" > halten. Das hat nicht viel mit Meinung zu tun. Wenn der µC im Sleep-Modus ist, ändern sich die Ports nicht. Die bleiben einfach so, wie sie sind. Wenn du den also schlafen legst, nachdem du die LEDs eingeschaltet hast, gehen die dadurch nicht wieder aus. Aber ja, wenn die LEDs eh 200 mA brauchen und dann auch noch über ein Relais geschaltet werden, ist der Verbrauch des µC sicherlich vernachlässigbar. 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.
:
Bearbeitet durch User
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 ;-)
Matthias S. schrieb: > Da lauert allerdings eine Falle. Man muss sich dann erstmal > vergewissern, das der Programmer den ISP so langsam takten kann, um den > kleinen Kerl zu programmieren. Stimmt, guter Einwand. 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.
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.
Stefan ⛄ F. schrieb: > Sandro G. schrieb: >> Arduino Nano (als Isp) > > Kein USBASP. Ob man da den Takt herunterziehen kann, entzieht sich meiner Kenntnis.
Andreas B. schrieb: > Ob man da den Takt herunterziehen kann, entzieht sich meiner Kenntnis. Sag ich doch. Ich hatte nämlich schon gelesen, das der TE einen Nano als ISP benutzt - nix USBASP, nix STK500. Alexander S. schrieb: > Wozu dann noch den Controller, da kann mans ja gleich komplett analog > aufbauen (was wahrscheinlich auch ausreichen würde). Einfch weil Timer ICs mit 4 Stunden teurer, grösser und komplizierter sind als der kleine Tiny.
:
Bearbeitet durch User
Matthias S. schrieb: > Sag ich doch. Ich hatte nämlich schon gelesen, das der TE einen Nano als > ISP benutzt - nix USBASP, nix STK500. Wobei es natürlich auch keine schlechte Idee wäre, sich ordentliches Werkzeug zuzulegen. Ein USBASP kostet in D etwas mehr als 10€. Wenn man mit den Nano als ISP den Takt nicht heruntersetzen kann (ist das wirklich so?), klingt das für mich mehr nach einer Notlösung.
Norbert schrieb: > 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! Wozu?
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.
Beitrag #6790785 wurde von einem Moderator gelöscht.
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 😉.
Rolf M. schrieb: >> Takt weiter runter! > > Wozu? Zum Strom sparen ;-) (ohne viel Aufwand) HildeK schrieb: > Das frage ich mich auch. Im SLEEP_MODE_PWR_DOWN nimmt der unter 1µA auf, > weniger als die Selbstentladung einer Batterie. Das Problem ist grundsätzlicher Natur. Der TO hat (da Anfänger) bereits viele Baustellen offen. Ich würde es auch aus Prinzip mit Sleep machen, aber das ist hier nicht unbedingt notwendig, weil der Tiny im Prinzip eigentlich nichts zu tun hat und daher auch mit 100Hz laufen könnte. ;-) > 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. Deshalb würde ich das mit dem Komparator und auch nicht mit dem ADC machen. Der TO (und nicht nur er) wird die Schaltschwelle selbst nicht kennen. Da ist ein Trimmer zum einstellen der Schaltschwelle nicht so ganz unsinnig. Pins dazu sind ja hier genug da. > Bei 4h Betrieb mit 200mA ist das alles vernachlässigbar eben!
:
Bearbeitet durch User
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: > Deswegen würde ich den Ansatz mit Timer weiter verfolgen, den man auch > von kommerziellen Produkten gewohnt ist. Das wird schon seinen Grund > haben. Das bekommst Du halbwegs vernünftig nur mit einem Uhrenquarz hin. Kann man machen. > 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. 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.
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.
HildeK schrieb: > 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. Ich habe das vorgeschlagen, um ein wenig frischen Wind reinzubringen, denn manchmal geht es auch einfach (KISS). Der Pullup am Reset jedenfalls liegt im richtigen Bereich (30-60k) und braucht nur den LDR nach Masse. Ausprobieren schadet nicht und hat den Vorteil, das kein anderer Pin benötigt wird. Auch der interne RC Oszillator kann dann die 4 Stunden abnudeln, ohne gross aus dem Ruder zu laufen. HildeK schrieb: > Jedoch: > - Die Stromaufnahme im Reset ist weit weg von 0mA; sie lag bei etwa > 300µA. Ok, das kam gerade rein und ist natürlich ein Killerkriterium. Dann vergessen wir es :-P
:
Bearbeitet durch User
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 ...
Hy Leute Ich werde es wie oben geschrieben erst einmal ohne sleep als simple Schleife laufen lassen und ab und zu halt mal manuell nachtriggern. jetzt habe ich aber das Problem das er sich im delay (4*60*60*1000); aufhängt. Ich habe es gestern nochmal getestet und nach guten 6 Stunden dann den Stecker gezogen. Ich bin mir ziemlich sicher das ich den takt auf 1MHz gesetzt habe also sollte er ja annähernd bei 4 Stunden ausschalten. Oder habe ich da irgendwas übersehen? Also 2 Stunden 'rechentolleranz' finde ich schon extrem
:
Bearbeitet durch User
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); |
HildeK schrieb: > Nur meine Hoffnung, dass die Stromaufnahme im Reset beim Power-Down-Wert > liegt, muss ich begraben ... Darauf hatte ich ja auch spekuliert, hatte nur gerade keine Zeit zum Messen. Aber umso besser, das du das mal gemacht hast - danke dafür. Ich vermute, da der Resetzustand ja der ist, in dem programmiert wird, das der Tiny da schon mal das ISP scharfmacht. Da die Stromaufnahme im Resetmodus im DB nicht steht, muss man wirklich nachmessen.
> 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? Jaja, ist ja richtig. Man kommt nicht dran 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.
Sandro G. schrieb: > Moin, > > ... Es muss > jetzt eine Lösung mit dem attiny85 her und, wo isse denn?
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.