AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

PeMue

#1170
Zitat von: Tom Major am 11 Januar 2019, 16:47:50
Hast du wirklich einen 644 oder einen 644P?
Der 644P wird in der LowPower lib supported:
#elif defined __AVR_ATmega644P__ || defined (__AVR_ATmega1284P__)

Für den 644 kann man das sicher leicht patchen (nachdem man gecheckt hat das beide bezüglich Sleep mode register usw. kompatible sind)  ;)
Ich habe das mit der Mighty Core Atmega 644 -> Atmega 644P/PA compiliert. Da scheint dann was nicht zu passen. Muss ich mir mal im Detail anschauen.

Zitat von: gloob am 11 Januar 2019, 17:09:17
Soll ich euch mal den Sketch für den Entfernungsmesser kompilieren oder ein HEX file schicken?
Danke, nicht notwendig. Ich will ja auch noch was lernen und die Software ist nicht ganz so stark bei mir  ;)

Gruß Peter

Edit: Problem gelöst. Die Low-Power Library, die der Bibliotheksmanager holt, ist zu alt. Ich habe per ZIP die aktuelle eingebunden und jetzt funktioniert es. Außerdem ist im library.json noch die alte Versionsnummer drin   ::).

Der Sketch verwendet 18618 Bytes (28%) des Programmspeicherplatzes. Das Maximum sind 64512 Bytes.
Globale Variablen verwenden 706 Bytes (17%) des dynamischen Speichers, 3390 Bytes für lokale Variablen verbleiben. Das Maximum sind 4096 Bytes.
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

fhemfreund

@papa

habe mal die letzte Zeit mit Tom (Major) einen RTC Sketch (sowohl seine angepasste Version also auch deine https://github.com/pa-pa/AskSinPP/tree/master/examples/HM-WDS10-TH-O) getestet, um den Sensor im Sleep möglichst stromsparend zu bekommen. Leider messe ich ca. 70uA im Sleep mit beiden Sketches (getestet auf 2 verschiedenen Hardware Versionen: 1x Breadboard, 1x https://github.com/pa-pa/HMSensor/tree/master/HMSensor-CR2032/files). Sketches mit int. SysClk brauchen auf beiden Hardware Versionen ca. 4uA wie erwartet.

Gibt es vielleicht noch etwas zu beachten? Hast du bei deinen RTC Versionen niedrigere Ströme gemessen?

Folgende Fuses sind gesetzt:


BODLEVEL  = DISABLED
RSTDISBL  = [ ]
DWEN      = [ ]
SPIEN     = [X]
WDTON     = [ ]
EESAVE    = [X]
BOOTSZ    = 1024W_3C00
BOOTRST   = [X]
CKDIV8    = [ ]
CKOUT     = [ ]
SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS

EXTENDED = 0xFF (valid)
HIGH     = 0xD2 (valid)
LOW      = 0xE2 (valid)


Andreas

papa

Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom. Was man durch die RTC gewinnt, ist die höhere Genauigkeit des Timers, da er durch den 32kHz Quarz getaktet wird. Der sonst verwendete Watchdog Timer ist absolut unterirdisch in der Genauigkeit.

Also die Entscheidung für die RTC ist nicht der Verbrauch, sondern die Einhaltung von Timings (z.B. Kommunikationsslot mit einem Thermostat).

Sieh auch https://www.mikrocontroller.net/articles/Sleep_Mode
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 18 Januar 2019, 08:38:27
Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom.

Im Datenblatt wird bei 32kHz Quarz Running auch der Power-Save mode referenziert, allerdings mit ca. 1uA bei 3V:
ZitatFigure 33-13. ATmega328: Power-Save Supply Current vs. V CC (Watchdog Timer Disabled and 32kHz Crystal
Oscillator Running

- deswegen hätte ich vermutet, man kann die 4uA sleep Strom mit Watchdog durch Einsatz der 32kHz RTC auf 1uA bringen.  8)
Habe es aber selbst noch nie getestet.
70uA kommen mir def. zu hoch vor (auch mit Timer2 running), IMHO stimmt irgendwas  noch nicht ganz mit dem RTC code.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: papa am 18 Januar 2019, 08:38:27
Hm - 70µA ist etwas viel - ABER die Verwendung der RTC erhöht grundsätzlich den Verbrauch, da nicht mehr der "Power Down" sondern "Power Save" Mode der CPU genutzt wird. Dieser braucht - schon durch den aktiven Timer2 - immer mehr Strom.

@papa

ok, habe noch ein paar Test gemacht da mir die 70uA wie gesagt zu hoch vorkommen.
Und fhemfreund hat auch keine Ruhe gegeben  :) :)

Der Timer2 im async mode war etwas tricky, aber jetzt habe ich das Resultat.
Der AVR braucht ca. 0,75uA im power-save mode mit Uhrenquarz am laufenden Timer2. Dies stimmt auch mit dem Diagramm "Power-save Supply Current" im Datenblatt überein.

Hier habe ich die Erkenntnisse etwas beschrieben und 2 Testsketche zum Prüfen des Ruhestroms abgelegt.
https://github.com/TomMajor/AskSinPP_Examples/tree/master/Info/Ruhestrom#%C3%BCberpr%C3%BCfung-des-avr-ruhestroms-power-save-mode

Danach habe ich mir die Sleep Klassen in der AskSinPP, Datei Activity.h angeschaut. Ich glaube der Fehler ist das du im RTC/Timer2/32kHz Fall
LowPower.powerExtStandby(..)
anstatt
LowPower.powerSave(..)

aufrufst. Das lässt den internen 8MHz RC OSzillator an und dies ist IMHO die Ursache für die 70uA.
Mit powerSave sollte sich das hoffentlich auf die 0,75uA reduzieren lassen.

Ich könnte auch einen PR machen, nur ich verstehe nicht vollständig warum
LowPower.powerExtStandby(..)
an 2. Stellen auftaucht, ich vermute nur die 2. Stelle in der SleepRTC Klasse wäre die Richtige, deswegen warte ich erst mal auf deinen Kommentar   :)

Danke,
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Ja in SleepRTC passt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

ok, PR für den Fix des RTC sleep modes wurde gemacht und von papa gemerged.
Jetzt ist im RTC mode ca. 1uA Ruhestrom erreichbar (ohne Sensoren).
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Sehr cool.

Hat eigentlich jemand die RTC mit einem ATMega644P zum Laufen gekriegt ? Hatte das letztens mal versucht, aber da kommen die Interrupts nichts :-(
Eigentlich sollte meiner Meinung nach der gleiche Code wie für den ATMega328P funktionieren.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 25 Januar 2019, 19:36:59
Sehr cool.

Hat eigentlich jemand die RTC mit einem ATMega644P zum Laufen gekriegt ? Hatte das letztens mal versucht, aber da kommen die Interrupts nichts :-(
Eigentlich sollte meiner Meinung nach der gleiche Code wie für den ATMega328P funktionieren.

Die relevanten Register sehen auf den ersten Blick gleich aus.
Hast du den 32k Quarz an TOSC1/2 angeschlossen? Das ist ein Unterschied zum mega328, dort gibt es nur XTAL, beim 644 verschiedene OSC pins.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Hattest du den 32kHz Quarz an PC6/7 angeschlossen? Und Lastkapazitäten auch dran?
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

kaihs

Ich möchte eine Überwachung der Stellventile meiner Fußbodenheizung bauen.
Dazu sollen minimal vier (besser sechs) Gabellichtschranken zyklisch (ca. alle 3 Minuten) abgefragt und deren Zustand (on/off) gemeldet werden.
Das Ganze soll batteriebetrieben sein.

Welcher Beispielsketch wäre dafür die Beste Vorlage?

HM-RC-8 und den Zustand der Lichtschranken als Tastendrücke übermitteln?
Wie könnte das zyklische Aufwachen implementiert werden?

Am Besten von den Standard Homematic Komponenten würde wahrscheinlich das 8-Bit HM-MOD-EM-8Bit passen, erweitert um das zyklische Aufwachen mit Ansteuerung und Abfrage der Lichtschranken.
Dafür gibt es aber noch keine Asksin++ Beispielimplementierung, oder?


Banana Pi, Add-On Board mit 1.8" TFT LCD und IR-Sender, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, SIGNALduino mit Logilink Temp.-sensoren und Auriol Wetterstation

papa

Zitat von: Tom Major am 25 Januar 2019, 23:03:34
Hattest du den 32kHz Quarz an PC6/7 angeschlossen? Und Lastkapazitäten auch dran?
Das ist es wahrscheinlich. Der Quarz auf der Platine geht an XTAL und nicht OSC. Mist :-(
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

papa

Zitat von: kaihs am 25 Januar 2019, 23:08:31
Am Besten von den Standard Homematic Komponenten würde wahrscheinlich das 8-Bit HM-MOD-EM-8Bit passen, erweitert um das zyklische Aufwachen mit Ansteuerung und Abfrage der Lichtschranken.
Dafür gibt es aber noch keine Asksin++ Beispielimplementierung, oder?
Schon mal hier nach was passenden gesucht ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 26 Januar 2019, 11:17:28
Das ist es wahrscheinlich. Der Quarz auf der Platine geht an XTAL und nicht OSC. Mist :-(

Das passt zum Fehlerbild, ohne Timer2 Quarz kommt der overflow interrupt nicht, alles andere läuft wie bisher  ;)
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker