Hallo zusammen, in diesem (Beitrag "Reminder per Microcontroller realisieren") habe ich von meinem Projekt berichtet. Nachdem nun soweit alles funktioniert, bin ich dabei, das Ganze etwas stromsparender aufzusetzen. Dazu möchte ich alles, was ich nicht benötige (ADC, AC..) ausschalten und den Idle-Modus nutzen. Aufwachen soll der µC durch den TimerOverflow-Interrupt von Timer 1, in dem ich dann Timer 0 zum Blinken der LED starte und den µC dann wieder schlafen lege. Der Aufruf von set_sleep_mode(SLEEP_MODE_IDLE); sleep_mode(); führt nun dazu, dass der µC zwar schläft, aber nicht wieder aufwacht. Soll heißen, Timer 0 wird nicht gestartet bzw. sein Overflow-Interrupt tritt nicht auf - bzw. es passiert gar nichts mehr :) Meine Vermutung war, dass die Interrupts vielleicht gar nicht mehr aktiv sein könnten (wieso auch immer). Also habe ich die nochmal vor dem Schlafengehen global aktiviert und nun scheint es zu funktionieren: sei(); set_sleep_mode(SLEEP_MODE_IDLE); sleep_mode(); Meine Frage ist nun, ob meine Vermutung sowie der Schluß daraus korrekt ist, oder ob ich hier grundlegend etwas falsch mache/verstehe. Ich habe den Quellcode angehängt.
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?
Manche Rechner schlafen tatsächlich und nehmen nur noch einen Interrupt, an einem Pin (INT0) wahr. Da tickt nichts mehr, und der Timer kann lange warten...
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.
Guten Mittag, spannend, das ist ein Endlos-Speep-Mode in einer Schleife!
1 | while (1) |
2 | {
|
3 | set_sleep_mode(SLEEP_MODE_IDLE); |
4 | sleep_mode(); |
5 | }
|
Den Rest deines Codes prüfe ich jetzt nicht.
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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!
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).
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,
:
Bearbeitet durch User
> 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 :)
Angehängte Dateien:
-
schaltplan.png
58 KB
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
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.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.