Guten Tag. Ich bin gerade dabei ein Layout zu zeichnen und frage mich gerade was sparsammer ist: Den RTC verwenden um dem µController seinen Takt zu geben, oder dem µController seinen eigenen Quarz spendieren? Hierbei handelt es sich um einen ATtiny25/45/85. Der RTC ist ein DS1629. Der µController wird jede Sekunde durch den Alarm der RTC geweckt, speichert den letzten gemessenen Wert, startet eine neue Messung und geht bis zum zur nächsten Sekunde wieder in den Power-Down Modus. Zudem soll es möglich sein über einen Software UART die bisher gespeicherten Werte an den Computer zu übertragen. Die Übertragungsgeschwindigkeit ist egal. Es geht eig. nur darum was sparsamer/besser ist. Über die RTC würde der Chip max. 32,768kHz bekommen können. Leider konnte ich keine Angabe finden wie stark die Stromaufnahme sich verändert wenn der RTC Takt ausgibt / der ATtiny mit einem Takt gespeist wird.
Wenn Du keine Uhrzeit brauchst, ist die Verwendung einer RTC fragwürdig. Der Controller kann in den Tiefschlaf gehen und per Watchdog geweckt werden. Der Tiefschlaf mit laufenden Watchdog verbraucht etwa 6µA. Natürlich ist der Watchdog nicht hochgenau, so dass man ihn nicht als Sekundentimer hernehmen kann.
Wie genau muss der Takt sein? Wenn keine Uhrzeit erforderlich ist und keine Schnittstelle einen präzisen Takt erfordert, dann ist der interne RC-Oszillator des Controllers der sparsamste Takt, da er am schnellsten startet.
Êine Uhr wird benötigt, da der gemessene Wert mit der Uhrzeit gespeichert werden soll um den Logger auch zur Überwachung und Rekonstruktion verwenden zu können. Der Temperatursensor ist in der RTC enthalten.
Michael Dierken schrieb: > Êine Uhr wird benötigt Dann gibt es 2 Möglichkeiten: 1. ATtiny + RTC-Chip: Der ATtiny läuft mit maximalem Takt, dann kann er schneller schlafen gehen. Der RTC weckt ihn per Pin-Change auf. Der RTC dient auch zum Kalibrieren der Baudrate für die UART. 2. ATmega48 mit Uhrenquarz: Aufwachen über T2 Interrupt, sonst wie 1. Peter
Der µC direkt mit dem Uhrenquarz ist schon Grenzwertig für den AD. Das ist eigentlich schon zu langsam. Solange es aber nicht zu warm wird sind die Chancen aber noch ganz gut das es trotzdem geht. Eine Alternative wäre ggf. noch ein 455 kHz Resonator - nicht so genau wie ein Quarz aber nach Abgleich OK für die UART und mit 455 kHz ist der Stromverbrauch auch noch nicht so hoch. Auch ein 1 MHz Quarz mit internem Teiler (z.B. /8) für den Takt sollte noch nicht so schlimm beim Stromverbrauch sein.
Ich dachte immr mit internem R/C oder externen Resonator könnte man UART vergessen. Peter Dannegger schrieb: > Der RTC dient auch zum Kalibrieren der Baudrate für die UART. Wie meinst du das? Per Interrupt? Bei jedem Int ein Bit?
Michael Dierken schrieb: > Ich dachte immr mit internem R/C oder externen Resonator könnte man UART > vergessen. Resonator mit z.B. 0,5% geht. Beim internen RC hängt es vom Controller und von den Rahmenbedingungen wie Spannungs/Temperaturvarianz ab. Neuere AVRs sind beispielsweise deutlich präziser als alte. Würde ich in produktionskritischem Umfeld zwar nicht so gern machen, aber wenn nicht so drauf ankommt, wie bei activity logs, kann das akzeptabel sein. Leider besitzen die AVRs nicht die anderswo verbreitete Fähigkeit, die Taktqeuelle ad hoc umschalten zu können, um beispielsweise beim Schlafen auf den Watchdog-Oszillator zu gehen, aber aktiv auf Quarz. RC hat den bei Batteriebetrieb unschlagbaren Vorzug, in Nullkommanix auf Trab zu kommen. Was man von einem Quarzoszillator nicht behaupten kann. >> Der RTC dient auch zum Kalibrieren der Baudrate für die UART. > Per Interrupt? Bei jedem Int ein Bit? Die bekannte genaue RTC-Zeit mit dem ungenauen internen Takt nachmessen und daraus den Fehler des internen Taktes ableiten.
> Resonator mit z.B. 0,5% geht.
Aber nicht als Uhr, das sind 7 Minuten pro Tag.
Als Uhr gehen nur 32kHz Quartze, und auch die
möglichst nur bei 21 GradC.
MaWin schrieb: > Aber nicht als Uhr, das sind 7 Minuten pro Tag. Ich bezog mich ebenso wie derjenige auf den ich antwortete auf UART.
MaWin schrieb: > Als Uhr gehen nur 32kHz Quartze, und auch die > möglichst nur bei 21 GradC. Ich neige da eher zu DCF77, mit oder ohne Quarz zur Stützung. Muss man nicht stellen und die Module sind billig genug. Geht u.U. auch bei Batteriebetrieb, wenn quarzgestützt.
A. K. schrieb: > Ich neige da eher zu DCF77 Nur leider passt das nicht auf mein Layout (22,6 x 20mm) Ich habe das Layout fertig und schaue einfach mal was sich Programmieren lässt. Ich werde das wohl so machen das ich den internen RC nutze um den AVR zu tackten, wenn er geweckt wurde Temperatur auslese, Temperatur speicher, Zeit auslese, Zeit speicher, neuen Alarm konfiguriere, neue Messung starte und bis zum nächsten Alarm schlafen geht. Bei Anschluss an USB erhält er einen Interrupt auf einem anderen Pin, aktiviert den Clock vom RTC, deaktiviert den Alarm, misst den Fehler und wartet auf den Empfang des Befehls zum Senden der Daten über den UART. Sobald er den bekommen hat ließt er Stück für Stück den Speicher aus und sendet die Daten. Sobald er fertig ist markiert er sich intern die Speicherstelle (damit der große Speicher erst voll geschrieben wird bevor eine Speicherzelle doppelt beschrieben wird), Schaltet den Tackt ab, konfiguriert den Alarm und geht wieder schlafen. Mal schauen was das wird (alles in Software) Und wenn das am Ende alles nichts wird so habe ich bis dahin wieder ne Mege an Programmierung gelernt und bin besser geworden (ist eig.ein Lern Projekt).
A. K. schrieb: > Leider besitzen die AVRs nicht die anderswo verbreitete Fähigkeit, die > Taktqeuelle ad hoc umschalten zu können, um beispielsweise beim Schlafen > auf den Watchdog-Oszillator zu gehen, aber aktiv auf Quarz. Hier würde ich gerne mal nachfragen. Laut Datenblatt haben einige AVRs spezielle Anschlüsse (TSOSC)für einen Uhrenquarz, der einen Timer takten kann. Hab ich zwar noch nicht gemacht, aber so wie ich das Datenblatt verstehe, kann man den Atmel z.B mit dem internen Oszillator oder mit einem Quarz an XTAL betreiben. Dann den Atmel in den Power Save Modus schicken, dabei läuft nur noch der Uhrenquarz und bei einem Timer-Overflow oder Compare wacht der Atmel dann wieder auf. Hat das schonmal jemand gemacht ? würd mich interessieren, ob das so funktioniert wi ich das verstanden habe....
Wenn du diesen ClockTimer oder wie das Ding hieß meinst, dann ja. Um die Zeit zu behalten läuft der weiter selbst wenn der Chip im Stromsparmodus ist. Hier musst du nur nochmal im Datenblatt nachschauen nicht das du ausversehen einen Sparmodus nimmst wo dieser Tackt auch angehalten wird. (Arbeitet soweit ich weiß ungefähr so wie der Watchdog). Irgendwas wollte ich noch dazu schreiben, habe es aber bereits vergessen ^^.
Ja, genau das ist der Sinn davon. Anders als der Watchdog ist das halt ein Quarzstabiler Takt, also kann man den Atmel periodisch aufwecken und eine Uhr hochzählen. Wenns nichts zu tun gibt, schläft der Atmel weiter. Ansonsten läuft er halt mit normalem Takt. Damit müsste es doch auch eigentlich auch möglich sein, den internen Oszillator gegen den Uhrenquarz abzugleichen (OSCCAL) und vielleicht ausreichende Genauigkeit für USART zu bekommen... Wenn ich Zeit hab, probier ich das mal aus.
Angehängte Dateien:
-
Layout1.png
22 KB
Joa.. ich mach das über den RTC da ich dann nur einen Quarz habe welcher Strom verbaucht. Der RTC muss ja wieso laufen um die Zeit zu halten. Ich muss nur mal schauen wie das mit der langzeit stabilität läuft, da ich das Gerät teilweise in extremen Temperaturen betreiben will (versuche es im vollen Temperaturbereich loggen zu lassen). Wenn es aus dem Ruder läuft ist das halt so! Lade hier mal stolzerweise das Layout hoch ^^ (nur die Pins den MLF sind genau falschrum, was ich gerade am berichtigen bin.
Was hast Du für eine RTC? von http://www.mcrystal.ch/ gibts einige interessante Teile, mit digitaler Temperaturkompensation. Die gefallen mir gut, die werd ich demnächt mal ausprobieren. Gibts glaub auch bei Reichelt!
Ich habe den DS1629 vom Maxim-IC (gabs kostenfrei bei Maxim 3pcs), 1Woche Lieferzeit. Daher das dies nur ein Lernprojekt ist habe ich nicht drauf geachtet wie genau der ist (gesehen und gedacht damit lässt sich was machen). Von den aus der Liste würde ich wohl den RV-4162-C7 nehmen da ich kleine Gehäuse liebe (desto kleiner desto besser). Ansonsten den RV-3029-C2-A aufgrund der Genauigkeit und des I²C Kommunikation womit man sich zwei Adern sparen kann und somit auch wieder größe Spart. Der hat nur leider keinen Temperatursensor intern.
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.