Low Power - MSP 430 vs ATtiny (sleep mode)

PIC12LF1822

im SLEEP (Timer, Brownout, etc aus):
20nA bei 1,8V
30nA bei 3V

aktiv (ohne Peripherie):
2µA bei 31 kHz und 1,8V
4µA bei 31 kHz und 3V

Es gibt bei Microchip noch mehr Prozessoren mit der XLP-Technologie.

Danke für die schön strukturierte Antwort!

Falk Brunner schrieb:
> @  Verwirrter Anfänger (Gast)
>
>>eine Ecke sparsamer sein. Ich frag mich allerdings, ob das viel
>>Unterschied macht, wenn der Sensor die meiste Zeit schläft.
>
> Mal rechnen?
Naja, nach Datenblatt scheint beim Tiny der Verbrauch im powerdown bei 
3.3V um ca. 100 nA höher zu sein, das ist jetzt allerdings geschäzt aus 
den Kurven.

>
>>Stromverbrauch aktiv: ~ 10mA +/- 5mA (Habe gerade kein Oszi um das
>>genauer zu messen)
>>Stromverbrauch schlafend: ~ 1.2 uA (Ich trau meinem Multimeter in dem
>>Bereich nichtmehr so genau)
>
> Kommt hin.
>
>>Verhältnis aktiv / schlafen: ~ 1 / 75.000
>>Gebrauchte Hardware: ADC, INT0, evtl. SPI (bitbanged)
>
>>Hat jemand schon Erfahrungen gemacht, ob in diesem Bereich ein MSP430
>>einen großen Unterschied zu dem ATtiny machen würde?
>
> Mal anders herum gefragt. Wieviel sparsamer müsste der MSP430m sein,
> damit sich das lohnt?
>
> 1s Arbeiten, 75.000 schlafen, ist fast ein Tag.
>
> 1s*10mA + 75.000 * 1.2uA = 10mC + 90mC.
>
> Hmmm. Der Brocken liegt also beim Schlafen. Aber auch aktuelle AVRs
> kommen mit Power Down auf 300nA oder so, also nochmal 1/4 deines
> Messwertes. Muss man halt die Regeln für Ultra low power und Sleep
> Mode beachten.

Ich vermute, dass ein Teil des Restes auf den RFM12 geht (der muss ja 
zumindest den Timer weiterlaufen lassen) und vielleicht ein kleiner Teil 
über pullups und den Entkopplungs Kondensator verloren geht. Es aber ist 
natürlich durchaus noch möglich, dass es in meinem Code auch noch 
Verbesserungsmöglichkeiten gibt.
Das Verhältnis ist etwa 1-2ms Messen, Rechnen, Funken zu 150s schlafen.

Angenommen ich nutze den AVR bereits effektiv und der Unterschied 
besteht im power down im Schnitt aus 150nA (Der Verbrauch beim MSP430 
scheint erheblich weniger von der Spannung abzuhängen als beim Tiny).
Ausserdem scheint der MSP430 im aktiven Zustand ca. 1mA weniger zu 
verbrauchen.
Dann würde sich ergeben:

1s * 10mA + 75.000 * 1.2uA = 10mC + 90mC = 100 mC
vs
1s * 9mA + 75.000 * 1.05uA = 9mC + 78.75mC = 87.75mC

also eine Verbesserung um ca. 12%. Hierbei ist noch nicht eingerechnet, 
ob das Auschalten der Peripherie bei beiden Chips gleichviel ausmacht, 
ob die ADC Berechnungen gleich lange brauchen und ob der Umstieg evtl. 
andere Folgen hat.

Stellt sich nur für mich wiederum die Frage, gibt es irgendeinen solchen 
Grund, der den MSP interessanter machen würde? Und machen die 12.25mC 
über 20h überhaupt einen Unterschied, ist die Selbstentladung des 
Kondensators um soviel höher, dass das nicht relevant ist?

Ich wunder mich halt gerade etwas, wieso bei dem MSP 430 immer so die 
Sparsamkeit hervorgehoben wird.

Ciao,
VA

usuru schrieb:
> PIC12LF1822
>
> im SLEEP (Timer, Brownout, etc aus):
> 20nA bei 1,8V
> 30nA bei 3V
>
> aktiv (ohne Peripherie):
> 2µA bei 31 kHz und 1,8V
> 4µA bei 31 kHz und 3V
>
> Es gibt bei Microchip noch mehr Prozessoren mit der XLP-Technologie.

Der sieht schon sehr interessant aus!
Um den direkt zu Vergleichen:
Active, 8mhz, 3V:
ATtiny : 2.8mA
MSP 430: 2.0mA
PIC    : 0.9mA

Powerdown, 3V:
ATtiny : 250nA
MSP 430:  80nA
PIC    :  30nA

passt das in etwa, oder ist das irgendwo unfair?
Dann werd ich mir den PIC mal genauer angucken.

P.S. mir ist schon klar, dass das nur wirklich Sinn macht wenn ich auch 
den Rest der Peripherie reduzieren kann, aber das ist jetzt vor allem 
eine Ehrgeiz Sache geworden, und hat nicht mehr viel mit Sinn und 
Verstand zu tun ;-)

frage am rande, was steckt da für ein system hinter der ganzen 
geschichte.. also sensoren welche über funk angesteuert werden, wer oder 
was bereitet die php daten auf?

wär echt toll da mal ein paar details zu bekommen, meinetwegen auch 
schlagworte um sich mal umzusehn?

Ok, kurzer Überblick:

Das Ganze ist mein erstes richtiges Projekt und immer noch nicht fertig 
;-)

Grundsätzlich ist das ganze ein Home Automation System, allerdings unter 
den Constraints "Student", d.h.
- billig
- kleine Wohnung
- keine baulichen Veränderungen
- learning-while-doing

Das Kernstück ist ein Arduino mit Ethernetshield und selbstgebauten 
Controllshield. Der Plan ist das ganze durch ein selbstgemachtes Board 
zu ersetzen, und den Arduino wieder zum Prototypen zu nutzen, aber ich 
bin noch nicht dazugekommen mich mit AVR und Ethernet zu beschäftigen.

Das Controllshield hat:
1 Temperatursensor (NTC)
2 Optokoppler um externe Geräte zu schalten
1 IR empfänger
1 IR Sender
2 Anschlüsse für externe Temperatursensoren
1 RFM12 Funksender
1 LED

Die Temperatursensoren sind wie oben beschrieben ein Tiny 45 + RFM12 
plus NTC und passen in eine alte Filmdose, die sind durch die Wohnung 
verteilt

Grundsätzlich was kanns:
- Knopfdrücke simulieren (Optokoppler, z.B. Computer anschalten in dem 
Frontknopf "gedrückt" wird)
- Funksteckdosen an und ausschalten (RFM12, OOK modus)
- IR Commandos senden (Stereoanlage)
- Regelmäßige Updates an einen Server senden)
- Reagieren wenn etwas passiert / nicht passiert (z.B Server antwortet 
seit 20 min nicht mehr auf Ping => schalte Steckdose einmal aus und 
wieder an)
- Befehle per IR, Funk, Uart oder Ethernet entgegen nehmen.

Serverseitig läuft das ganze so ab, dass der Controller in einer Tabelle 
alle Sensorwerte speichert, die reinkommen, und die gesammelt alle 3 
Minuten an meinen Webserver schickt. Der speichert die in einer SQL 
Datenbank ab (SQLite, zur Zeit zum testen), und stellt die dann nach 
aussen zur Verfügung. Weil ich mit den AVR nur IP Adressen direkt 
ansprechen kann, aber mein Server nur per Domain Name zuverlässig 
erreichbar ist, sitzt dazwischen noch ein WRT54GL router mit Tomato 
Firmware drauf, der den Befehl per CGI Skript umleitet.
Auf dem Server läuft alles in PHP, die Graphen werden direkt per PHP als 
SVG erstellt, die Abfragen an den Arduino werden mit curl 
weitergeleitet, der Arduino ist per dyndns Adresse erreichbar. Ansonsten 
ist alles Standard HTML mit sowenig Javascript wie möglich.

Die Controllseite gibts hier:
http://www.justgeek.de/automation/info.php
(abgespeckte Version für Demo Zwecke)
die ist leider etwas sehr langsam wegen der SQLite Datenbank dahinter.


Geplante features:
- Lichtsteuerung (zur Zeit kann ich über die Funksteckdosen Lichter ein 
/ aus schalten, aber nicht dimmen und keine RGB werte eingeben)
- Integration mit meinem Wecker (wenn es Zeit ist aufzu stehen wird 
langsam der Raum heller gemacht, oder wenn man Nachts aufsteht, werden 
automatisch ein paar Lichter angemacht, nach dem Aufstehen wird 
automatisch Computer und Kaffemaschine angemacht ...)
- Ein paar schönere Funkschalter, die aussehen wie normale Wandschalter
- Automatische Heizungssteuerung durch die Funksensoren
- ... ?

Brauchst Du denn wirklich 8 MHz??? Egal ob PIC oder AVR: bei niedriger 
Spannung und langsameren Takt sinkt der Stromverbrauch dramatisch.

Wenn der PIC mit 31 kHz läuft braucht er 4 µA, bei 8 MHZ braucht er 350 
µA und bei 32 MHz braucht er 1.6 mA  (alles bei 3V).

Wenn Du also bei DEINEM Prozesssor bleiben willt, dann arbeite bei 3 V 
und macht den Takt so langsam wie möglich. Wobei noch zu sagen ist, dass 
der interne Oszillator meistens sparsamer ist als der Oszillator für den 
Quarz (alledings nicht so genau - brauchts Du höchst exakte Zeiten?).

hey, du hast da ja nen ziemlich tolles system aufgebaut..

- ich hab selbst genau die gleichen "constraints" wie du, bin momentan 
mehr oder weniger in der planungsphase für nen ganz ähnliches projekt...
irgendwie fehlt auch etwas die zeit dazu, neben dem studium..

allerdings plane ich das ganze mit nem NetIo aufzuziehen, ohne extra 
webserver, auch mehr zur fernsteuerung als zur fernüberwachung..

jedenfalls will ich mich demnächst mal mit dem aufbau von nem rfm12 
protokoll beschäftigen.. hast du da was selbstgebautes im einsatz, oder 
gibts irgendwelche sourcen, auf denen du aufgebaut hast?

MfG

usuru schrieb:
> Brauchst Du denn wirklich 8 MHz??? Egal ob PIC oder AVR: bei niedriger
> Spannung und langsameren Takt sinkt der Stromverbrauch dramatisch.
>
> Wenn der PIC mit 31 kHz läuft braucht er 4 µA, bei 8 MHZ braucht er 350
> µA und bei 32 MHz braucht er 1.6 mA  (alles bei 3V).
>
> Wenn Du also bei DEINEM Prozesssor bleiben willt, dann arbeite bei 3 V
> und macht den Takt so langsam wie möglich. Wobei noch zu sagen ist, dass
> der interne Oszillator meistens sparsamer ist als der Oszillator für den
> Quarz (alledings nicht so genau - brauchts Du höchst exakte Zeiten?).

Ich benutz den internen Oszillator, genaue Zeiten brauch ich gar nicht. 
Ich denke ich könnte auf 1 mhz runtergehen, aber bei 32 khz hab ich zwei 
Bedenken:
- Ich bin mir nicht sicher, ob der SPI des RFM12 moduls mit so langsamen 
Takt noch arbeitet, insbesondere, falls ich den in Software durchführe
- Ich bin mir nicht sicher, ob ich dem RFM12 bei der Geschwindigkeit 
noch schnell genug die Daten liefern kann, insbesondere, wenn der SPI 
auch langsamer ist.
Ich denke ich könnte das mal überprüfen, wenn ich mir endlich mal ein 
Logikanalysator besorgt habe. Allerdings frage ich mich auch, ob das 
soviel einspart, da ich ja bei 32kHz wahrscheinlich auch länger auf die 
ADC Ergebnisse warten müsste, und dadurch länger im aktiven Modus 
bleiben würde.

Oo schrieb:
> allerdings plane ich das ganze mit nem NetIo aufzuziehen, ohne extra
> webserver, auch mehr zur fernsteuerung als zur fernüberwachung..
Bei mir war halt klar, dass ich die Daten auch abspeichern will, und 
dadurch hat sich der externe Server ziemlich gut angeboten.
Wenn du allerdings die CSS und JS dateien auslagern kannst, könnte das 
glaub ich ganz gut auf dem NetIo klappen. Was bei mir viel 
Programmspeicher und RAM wegnimmt sind die diversen Befehle im Sinne von 
"Wenn der IR Code 0x4223 ankommt sende OOK Befehl 8484", etc...

> jedenfalls will ich mich demnächst mal mit dem aufbau von nem rfm12
> protokoll beschäftigen.. hast du da was selbstgebautes im einsatz, oder
> gibts irgendwelche sourcen, auf denen du aufgebaut hast?
Ich hab mit den Code von Jeelabs angefangen 
(http://jeelabs.net/projects/cafe/wiki/RF12) aber während ich versucht 
hab den zu verstehen mir meinen eigenen parallel geschrieben. Mein Code 
ist teilweise etwas unelegant, weil ich den auch auf einem Tiny2313 und 
Tiny13 zum laufen bringen wollte, aber dafür hab ich halt inzwischen 
fast alles gut verstanden.
Grundsätzlich hab ich mein Protokoll ziemlich standardmäßig aufgebaut:

2 Byte: Preambel / Sync Byte
1 Byte: Länge
1 Byte: Sender ID
1 Byte: Empfänger ID
1 Byte: Flags (REPLY_REQUESTED, IGNORE_CRC,...)
1 Byte: Message Type
2 Byte: Message ID
x Byte: Daten
2 Byte: CRC

Ich denke im nachhinein würde ich Sender und Empfänger tauschen, dann 
kann man ein Byte früher aufhören, wenn die Nachricht nicht für dich 
bestimmt ist. Die Flags und der Message Type sind vor allem auch dafür 
da, um den Verarbeitungsaufwand zu verringern, wenn einer der beiden 
Teilnehmer nicht genug Speicher, RAM oder Energie hat.
Und die Message ID wird zur Zeit zwar hochgezählt, aber beim Empfang 
ignoriert. Wenn ich irgendwann mal soweit bin ein echtes routing 
aufzubauen, soll die dafür genutzt werden doppelt einkommende 
Nachrichten zu ignorieren.

Das Senden mach ich bei den Sensoren zur Zeit blockierend, weil ich 
sowieso schlafen gehen will, sobald der Versand fertig ist. Ich hab 
allerdings auch schon interrupt basierten Code dafür.
Ich hab schon länger vor, das ganze mal schön aufzuschreiben, und den 
Code zu veröffentlichen. Ich kann dir aber gerne auch schon vorher was 
zuschicken.

Ich hab ger

Falk Brunner schrieb:
> Hmmm. Der Brocken liegt also beim Schlafen. Aber auch aktuelle AVRs
> kommen mit Power Down auf 300nA oder so, also nochmal 1/4 deines
> Messwertes. Muss man halt die Regeln für Ultra low power und Sleep
> Mode beachten.

Ich hab gerade mal einen älteren Sensor genommen, den Funk Code 
auskommentiert, und nur den Verbrauch des Tinys und der anderen passiven 
Komponenten gemessen. Dann zeigt mein Multimeter nur noch 0.1 uA an, 
allerdings ist das mit Vorsicht zu genießen, da der kleinste Messbereich 
von 0-200uA geht.

Ich würde aber anhand dieser Ergebnisse schätzen, das der Großteil des 
Verbrauchs im schlafenden Zustand auf den RFM12 zurückzuführen ist. Ich 
werde da mal gucken was sich an den Einstellungen drehen lässt, und ob 
es evtl. sinnvoller ist den Tiny ein paar mal per watchdog wieder 
aufzuwecken, anstatt den timer des RFM12 zu nutzen.

Ich werd auch mal versuchen die Geschwindigkeit auf 1 MHz zu reduzieren, 
allerdings muss ich damit warten, bis der Kondensator endlich alle ist, 
damit ich das dann gleich komplettt testen kann.

Ciao,
VA

> Dann zeigt mein Multimeter nur noch 0.1 uA an,
> allerdings ist das mit Vorsicht zu genießen,
> da der kleinste Messbereich von 0-200uA geht.

Allerdings, das ist ja gerade 1 Digit. Ich habe mir das da nachgebaut 
http://alternatezone.com/electronics/ucurrent/ und finde es für 
Messungen von kleinen Strömen ideal.