Es soll gezählt werden, wie oft ein Maschinenteil in einem Jahr hin- und her bewegt wird. Die Frequenz berägt max. 3Hz, es kann aber auch deutlich weniger sein oder gar tagelang garnix passieren. Dazu dachte ich an einen Tiny, der nach dem Programmstart einen Zähler im EEProm hochzählt und danach sofort in den Tiefschlaf "fährt". Bei jedem Durchgang des bewegten Teiles wird der Tiny von einem Magneten/SMD-Reedschalter resettet und das Spiel beginnt von vorne.** Soll der Zähler ausgelesen werden, wird mittels eines anderen Reedkontaktes an einem Pin des Tiny verhindert, dass dieser in den Tiefschalf geht, statt dessen lässt er eine LED in einem speziellen Rhytmus blinken, so dass ein Lesegerät mit optischem Sensor die Signale empfangen und auswerten/aufzeichen kann. Hat jemand Erfahrungen, ob sich sowas mit einer Lithiumzelle CR2032 über einen zeitraum von mind. 1 Jahr machen lässt? Das rel. energieaufwändige Auslesen findet höchstens 2 mal im Jahr statt und dauert nur 2..3 Sekunden. ** ein Algorithmus, um Zählfehlern durch Alterung/Abnutzung der EEProm-Zellen vorzubeugen, ist implementiert.
:
Bearbeitet durch User
Hallo, rechne es grob aus. Nimm den ungünstigsten Fall, daß ein Jahr lang 3x pro Sekunden gezählt wird. Wieviel mA braucht Dein Tiny beim Zählen und wie lange ist er dazu wach? Wieviel mA (µA) braucht er im Schlaf? Dann hast Du den durchscnittlichen Stromverbrauch pro Sekunden, eine CR2032 hat wohl ca. 220mAh. Mein CR2032 im Gefriefach betreibt einen Tiny45 und einen RFM02 433MHz Sender. Sendet ca. alle Minute, Spitzenstrom ist ca. 12mA, hält 6-9 Monate. Gruß aus Berlin Michael
Kann man schon so machen, allerdings würde ich den Tiny über einen Interrupt aufwachen lassen.
Wenn du das Programm gut schreibst kommst du mit einer CR2032 wahrscheinlich 5-10 Jahre aus. da du über einen ext. Interrupt aufwachen kannst würde ich den Power Down Modus wählen im sleep hat der uC dann einen Stromverbrauch von <1uA. Statt Reset lieber Programm mit sleep und nur alle 100 oder 1000 Aktivierung in das eeprom schreiben, da das Schreiben im Vergleich zum Sram ewig dauert und mehr Strom kostet. Um entprellen solltest du dich noch kümmern, da es sonst zu sehr falschen Werten kommen kann. Datenübertragung am besten mit crc am Ende um sicher zu sein das es auch stimmt. Gruß Matthias
Das muss mit einer wesentlich kleineren Zelle machbar sein. Beispiel: Fahrradfahrtenschreiber, ATmega328 mit angeschlossenem 512 KiB-RAM, 8000 km/a entsprechend rund 4 Millionen Kontakte, es wird im Schnitt alle 80 km, also 100 mal pro Jahr, ausgelesen per Infrarot für etwa 1 Minute: der Akku mit 60 mAh wird 2-3 mal im Jahr geladen.
Frank E. schrieb: > Dazu dachte ich an einen Tiny, der nach dem Programmstart einen Zähler > im EEProm hochzählt und danach sofort in den Tiefschlaf "fährt". Bei > jedem Durchgang des bewegten Teiles wird der Tiny von einem > Magneten/SMD-Reedschalter resettet und das Spiel beginnt von vorne.** > ** ein Algorithmus, um Zählfehlern durch Alterung/Abnutzung der > EEProm-Zellen vorzubeugen, ist implementiert. Naja, im schlechtesten Fall sind es (bei 3 Schreibvorgängen/s) rund 10^8 Zugriffe auf das EEPROM. Nimmst du jedes Mal eine andere Speicherzelle, dann ist der Maximalwert (10k Writes) nach einem Jahr schon überschritten - worst case! Warum kannst du die Werte nicht im RAM lassen? Angst vor Stromausfall musst du ja wegen der Batterieversorgung nicht haben. Das ist vermutlich auch sparsamer im Batterieverbrauch als die EE-Zugriffe. Reset ist dann allerdings nicht das Mittel, um den Tiny wieder zu aktivieren, aber mit dem INT0 kannst du ihn aus dem Tiefschlaf holen, ohne dass der RAM-Inhalt verloren geht. Zum weiteren Strom sparen kann man mit dem PRR-Register noch einige ungenutzte Hardwareblöcke ruhig stellen.
Muss das so winzig sein? Die CR123 sind auch nicht so groß, bieten aber viel mehr Energie
Im Prinzip sollte das machbar sein. Allerdings dauert das schreiben ins eeprom relativ lange. Dann kann das evtl. eng werden. Vielleicht wäre es besser einfach nur im RAM eine variable hochzuzählen zu und nur alle paar Stunden oder Tage ins eeprom zu schreiben
HildeK schrieb: > Naja, im schlechtesten Fall sind es (bei 3 Schreibvorgängen/s) rund 10^8 > Zugriffe auf das EEPROM. Nimmst du jedes Mal eine andere Speicherzelle, > dann ist der Maximalwert (10k Writes) nach einem Jahr schon > überschritten - worst case! Bei 512 EEPRom-Zellen und 4Byte (256 hoch 4 ist ca. 10 hoch 8) Zählerumfang kann ich die Einer- und Zehner-Stelle ziemlich oft wechseln ...
Das ist nicht der Punkt - wie von vielen bereits geschrieben, benötigt das häufige Schreiben ins EEPROM zuviel Strom.
S. Landolt schrieb: > Das ist nicht der Punkt - wie von vielen bereits geschrieben, > benötigt > das häufige Schreiben ins EEPROM zuviel Strom. Ok, akzeptiert. Dann werde ich nur z.B. alle 100mal eine Kopie des Zählers im EEPRom ablegen. Das reduziert den Stromverbrauch, sichert trotzdem die Daten in einer akzeptablen Genauigkeit und reduziert zusätzlich die "Abnutzung", so dass ich evtl. auf aufwändigere EEPROM-schonende Algorithmen verzichten kann (die ja auch Rechenzeit und damit Strom kosten) ...
:
Bearbeitet durch User
Frank E. schrieb: > S. Landolt schrieb: >> Das ist nicht der Punkt - wie von vielen bereits geschrieben, >> benötigt >> das häufige Schreiben ins EEPROM zuviel Strom. > > Ok, akzeptiert. Dann werde ich nur z.B. alle 100mal eine Kopie des > Zählers im EEPRom ablegen. Wenn du jedes 100ste mal ins eeprom schreibst, schreib doch auch einfach nur ein 100stel ins eeprom. also schreib 1,2,3 statt 100, 200, 300. Dann kommst du mit 3 byte auch 150Jahre aus.
>Warum kannst du die Werte nicht im RAM lassen? >Reset ist dann allerdings nicht das Mittel, um den Tiny wieder zu aktivieren Wieso? Ein Reset hat auf den SRAM überhaupt keine Auswirkung, d. h. dessen Inhalt bleibt erhalten.
LostInMusic schrieb: > Warum kannst du die Werte nicht im RAM lassen? > > Reset ist dann allerdings nicht das Mittel, um den Tiny wieder zu > aktivieren > > Wieso? Ein Reset hat auf den SRAM überhaupt keine Auswirkung, d. h. > dessen Inhalt bleibt erhalten. Aber dann sollte man noinit nicht vergessen
1 | int foo __attribute__ ((section (".noinit"))); |
LostInMusic schrieb: > Wieso? Ein Reset hat auf den SRAM überhaupt keine Auswirkung, d. h. > dessen Inhalt bleibt erhalten. Timmo H. hat einen Vorschlag gemacht, was man wohl tun kann (gut, das kenne ich nicht). Aber in C sollte man üblicherweise eine Variable, die man z.B. hochzählen will, eingangs mal mit einem Startwert vorbelegen. Nach dem Reset wird sie eben wieder mit dem neuen Startwert vorbelegt. Und dann? Kann aber auch sein, dass ich da was übersehen habe oder dass man das trickreich umgehen kann.
HildeK schrieb: > Kann aber auch sein, dass ich da was übersehen habe oder dass man das > trickreich umgehen kann. Gibt ein Statusregister, wo man nachgucken kann, wo der Reset herkam. Und dann initialisieren, solange der Reset nicht vom externen Reset-pin kommt.
>Aber in C ...
Deshalb würde ich dem TO ja auch raten, sein kleines Programm in
Assembler zu schreiben. Kein C --> keine Probleme :-)
HildeK schrieb: > Aber in C sollte man üblicherweise eine Variable, die man z.B. > hochzählen will, eingangs mal mit einem Startwert vorbelegen. > Nach dem Reset wird sie eben wieder mit dem neuen Startwert vorbelegt. > Und dann? Startwert wird aus EEPROM gelesen, ebenso die letzte, bzw. aktuelle Adresse. Beim programmieren sind die beiden auf Null, beim bewegen werden die Daten ins RAM geschrieben - wenn RAM-Variable >= 250, wird die EEPROM-Variable (WORD) um eins erhöht, wenn EEP-Variable > 65000, wird der EEPROM-Pointer um eins erhöht... Somit hast du in einer EEP-Variable 16,250,000 Bewegungen, das ist im ungünstigsten Fall (24 Stunden mit 3Hz) 1 EEP-Zelle pro 2 Monate, bzw. mehr als 1000 Monate ununterbrochen mit 3Hz. Allerdings ist möglicher Fehler bei Stromausfall +/- 250 Bewegungen, mit nur 10 Bewegungen in RAM-Variable ist Fehler +/- 10 Bewegungen und ununterbrochenem Betrieb von 3,5 Jahren. Frank E. schrieb: > ** ein Algorithmus, um Zählfehlern durch Alterung/Abnutzung der > EEProm-Zellen vorzubeugen, ist implementiert. Unnötig, allerdings ist EEP-Page 4 Bytes, da würde ich zur Sicherheit EEP-Pointer auch um 4 erhöhen, anstatt um zwei. Oder long, anstatt word nehmen.
:
Bearbeitet durch User
Marc V. schrieb: > das ist > im ungünstigsten Fall (24 Stunden mit 3Hz) 94.608.000 Daten in einem Jahr.
Falls dies noch jemand liest (ist schon lange her): Ganz klar einen externen Zählerbaustein verwenden.
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.