Guten Tag!! Im Moment arbeite ich an einem Atmega8. Er soll zusammengefasst Sensordaten sammeln und über TWI weiterleiten. Nachdem die Daten von allen Sensoren gesammelt würden sollte der Atmega8 in Ruhezustand gehen und erst am Nächsten Tag wieder losgehen. Wie kann ich das Problem implementieren? Viele Grüße
Hallo Patrick! > Wie kann ich das Problem implementieren? Duden sagt zu implementieren: >...in ein bestehendes Computersystem einsetzen, einbauen und so ein >funktionsfähiges Programm erstellen... Du willst das Problem also nicht implementieren sondern die Aufgabe lösen. So das dazu. Frage: Wozu willst du das so tun? Vermutlich um Energie zu sparen. Lass den µC doch ruhig so selten wie nötig sich wecken und nur bei jedem x ten wach werden deine Sensoren auslesen.
erstmal danke für die schnelle antwort! >> Wie kann ich das Problem implementieren? da habe ich mich vertippt danke für die korrektur! > Wozu willst du das so tun? Vermutlich um Energie zu sparen. Nicht nur das. es mehr darum dass 8 sensoren an den µC angeschlossen sind und ich brauche jeden tag nur einmal die Daten von jeden sensor.
Patrick N. schrieb: > und ich brauche jeden tag nur einmal die Daten von jeden sensor. Also lässt du den µC warten, bis der Tag rum ist. Dafür brauchst du eine Zeitbasis. Während dem Warten kannst du Strom sparen, wenn du das willst. z.B: RTC-Chip dazulöten. Viele kann man als "Wecker" Konfigurieren, den Wecker-Ausgang an einen INT-Pin des µCs, und schon kann dieser Tiefschlafen. Was auch geht: Uhrenquarz an den µC, AVR - Die genaue Sekunde / RTC: Echtzeituhr mit Uhrenquarz Der µC wacht dann öfter auf, um seine Uhr mitlaufen zu lassen. Oder, wenn der Stromverbrauch nicht so wichtig ist, gehts auch mit beliebigem Quarz ohne Sleep.
Gast
#2586146
Nimm den langsamsten Quarz, größten Timer, den größten Vorteiler und lass den uC von einem Overflow wecken. Wenn x Overflows rum sind ist ein Tag vergangen... Die alternative sind die schon genannten RTCs, wobei der minimalste Aufwand (HW wie SW) wirklich ersteres sein wird.
Wenn die 24h nicht ganz exakt gemessen werden müssen, nimm einfach den internen RC-Oszillator. Den Takt kannst du auf 16 kHz einstellen, dann frisst der uC kaum noch Strom, obwohl er aktiv läuft! Bin mir jetzt beim ATmega8 nicht sicher, aber der ATtiny13 zum Beispiel braucht dann weniger als 100uA. Zudem gibts ja auch die Low-Power-Varianten.
Gast
#2586755
Aber der SLEEP ist immer noch sparsamer. Und RC ist verdammt ungenau. Dann schon lieber einen RV-3029-C2 oder RV-8564-C2 (die sind verdammt genau und ziehen nur 600-1500 nA, je nach Betriebszustand), der den µ…C aus dem SLEEP aufweckt.
...-. schrieb: > Aber der SLEEP ist immer noch sparsamer. Und RC ist verdammt ungenau. > Dann schon lieber einen RV-3029-C2 oder RV-8564-C2 (die sind verdammt > genau und ziehen nur 600-1500 nA, je nach Betriebszustand), der den µ…C > aus dem SLEEP aufweckt. Stimmt. Aber wie so oft gibt es hier kein Richtig oder Falsch. Es ist immer eine Abwägung. Dein Vorschlag spart Energie, meiner spart Bauteile. Je nachdem, wo der Schwerpunkt liegt - Genauigkeit, Sparsamkeit, Kompaktheit - muss sich der Thread-Ersteller selbst eine Lösung raussuchen. "Verdammt ungenau" ist sowieso ein dehnbarer Begriff. Ein kalibrierter interner RC-Oszillator ist genau genug, um das geforderte "einmal täglich" zu realisieren. Also immer dann, wenn es nicht auf eine halbe Stunde hin oder her ankommt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.