Autor Thema: AskSin++ Library  (Gelesen 128992 mal)

Offline PeMue

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4843
Antw:AskSin++ Library
« Antwort #1170 am: 12 Januar 2019, 18:55:42 »
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.

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.
« Letzte Änderung: 12 Januar 2019, 19:13:46 von PeMue »
1x FB7170 (29.04.88) 5.7 1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F)
1x RPi BV2LCDCSM 1.63 5.7 2xMAX HKT, 1xMAX RT, V200KW1
1xFB 7490 (113.06.05) 5.7 1xCUL V3 1.63 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 1xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU 1xRFXtrx 90 1xWT440H 1xCM160 3xTFA30.3150 5xFA21

Offline fhemfreund

  • Full Member
  • ***
  • Beiträge: 166
Antw:AskSin++ Library
« Antwort #1171 am: 18 Januar 2019, 00:23:35 »
@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

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1172 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. 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
Informativ Informativ x 1 Liste anzeigen

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1173 am: 18 Januar 2019, 12:01:48 »
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:
Zitat
Figure 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.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1174 am: 22 Januar 2019, 19:56:52 »
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,
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1175 am: 22 Januar 2019, 20:19:21 »
Ja in SleepRTC passt.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1176 am: 25 Januar 2019, 18:58:16 »
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).
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1177 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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1178 am: 25 Januar 2019, 20:08:06 »
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.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1179 am: 25 Januar 2019, 21:14:02 »
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1180 am: 25 Januar 2019, 23:03:34 »
Hattest du den 32kHz Quarz an PC6/7 angeschlossen? Und Lastkapazitäten auch dran?
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline kaihs

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1031
Antw:AskSin++ Library
« Antwort #1181 am: 25 Januar 2019, 23:08:31 »
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, FHEM V5.9, CULFW V1.61, div. Homematic Komponenten, Pollin Funksteckdosen, Selbstbau CUL433 MHz, Jeelink Clone, EC3000
Selbstbau CUL868MHz für Wireless M-Bus, FHEMduino mit Logilink Temp.-sensoren und Auriol Wetterstation

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1182 am: 26 Januar 2019, 11:17:28 »
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

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1478
Antw:AskSin++ Library
« Antwort #1183 am: 26 Januar 2019, 11:18:47 »
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

Offline Tom Major

  • Full Member
  • ***
  • Beiträge: 426
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1184 am: 26 Januar 2019, 12:30:21 »
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  ;)
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

 

decade-submarginal