Exaktes Timing trotz PowerDown und externer Interrupts?
Moderator: Co-Administratoren
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Exaktes Timing trotz PowerDown und externer Interrupts?
Hallo zusammen,
ich sitze an einem Wetterdatensensor (moechte mein ELV-Teil mit neuer Hardware auf Basis des 1284P reanimieren). Ziel ist moeglichst Batteriebetrieb. Software orientiert sich stark an Jérômes Wetterstation, allerdings mit Schlafenlegen in der loop. Dann bringen jedoch die haeufigen Interrupts des Anemometer-Reedkontaktes das Sleep-Timing arg durcheinander, so dass viel zu viele Messages gesendet werden. Erscheint mir (inzwischen) logisch, da man nicht ermitteln kann, wie lange vor WDT-Ablauf ein ext. Interrupt zugeschlagen hat, um das zu korrigieren.
Nun die Frage, bevor ich umsonst einen Uhrenquarz bestelle und den CSTNE wieder von der Platine rupfe: Wird das Timing der Messages wieder deterministisch trotz externer Interrupts, wenn ich auf AskSinRTC umsteige? Konnte leider den Code nicht so weit durchdringen, um sicher zu sein, ob da eine entsprechende Korrektur existiert.
Danke und viele Gruesse,
Stephan
ich sitze an einem Wetterdatensensor (moechte mein ELV-Teil mit neuer Hardware auf Basis des 1284P reanimieren). Ziel ist moeglichst Batteriebetrieb. Software orientiert sich stark an Jérômes Wetterstation, allerdings mit Schlafenlegen in der loop. Dann bringen jedoch die haeufigen Interrupts des Anemometer-Reedkontaktes das Sleep-Timing arg durcheinander, so dass viel zu viele Messages gesendet werden. Erscheint mir (inzwischen) logisch, da man nicht ermitteln kann, wie lange vor WDT-Ablauf ein ext. Interrupt zugeschlagen hat, um das zu korrigieren.
Nun die Frage, bevor ich umsonst einen Uhrenquarz bestelle und den CSTNE wieder von der Platine rupfe: Wird das Timing der Messages wieder deterministisch trotz externer Interrupts, wenn ich auf AskSinRTC umsteige? Konnte leider den Code nicht so weit durchdringen, um sicher zu sein, ob da eine entsprechende Korrektur existiert.
Danke und viele Gruesse,
Stephan
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Das wird wahrscheinlich auch nicht viel bringen, da die ständigen Interrupts die CPU immer wieder aufwecken.
Ich empfehle Dir einen PCF8583P - der kann zählen und wird per I2C ausgelesen. Arduino Unterstützung gint es hier https://bitbucket.org/xoseperez/pcf8583/src/master/
Ich empfehle Dir einen PCF8583P - der kann zählen und wird per I2C ausgelesen. Arduino Unterstützung gint es hier https://bitbucket.org/xoseperez/pcf8583/src/master/
Anfragen zur AskSin++ werden nur im Forum beantwortet
- FUEL4EP
- Beiträge: 586
- Registriert: 01.11.2017, 17:26
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 76 Mal
- Danksagung erhalten: 78 Mal
- Kontaktdaten:
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
.. oder einen ABLIC S35770 24-Bit Binary Counter.
Software gibt es hier https://github.com/FUEL4EP/HomeAutomat ... LIC_S35770
Software gibt es hier https://github.com/FUEL4EP/HomeAutomat ... LIC_S35770
Grüße
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Danke fuer Eure Empfehlungen, ein separater Zaehler ist vermutlich wirklich sinnvoll, auch wenn's wieder mal ein PCB Redesign erfordert.
Da die Regenwippe seltener umkippt, wuerde ich die wahrscheinlich weiterhin ueber die Interrupts zaehlen lassen - der Stromverbrauch fuers Aufwachen allein zum Zaehlen ist hier vernachlaessigbar. Wuerde hier die AskSinRTC das gewuenschte erreichen, also keine (nennenswerte) Beinflussung der Clock durch die Interrupts, so dass der Sendetakt des Sensors konstant bleibt?
Viele Gruesse,
Stephan
Da die Regenwippe seltener umkippt, wuerde ich die wahrscheinlich weiterhin ueber die Interrupts zaehlen lassen - der Stromverbrauch fuers Aufwachen allein zum Zaehlen ist hier vernachlaessigbar. Wuerde hier die AskSinRTC das gewuenschte erreichen, also keine (nennenswerte) Beinflussung der Clock durch die Interrupts, so dass der Sendetakt des Sensors konstant bleibt?
Viele Gruesse,
Stephan
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
mit AskSinRTC kannst Du den Sendetakt ja direkt an den RTC-Timer koppeln. Dann sendetst Du auch immer schön im richtigen Takt. Das geht auch, wenn viele andere Interrupts kommen. Aber die versauen Dir halt den Deep-Sleep, der für Batterie nötig ist.
Anfragen zur AskSin++ werden nur im Forum beantwortet
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Super, danke. Fand nach einigem Suchen noch einen alten Uhrenquarz und konnte das -erstmal testweise- so umsetzen.
Viele Gruesse,
Stephan
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Hallo Ewald,FUEL4EP hat geschrieben: ↑20.03.2021, 21:00.. oder einen ABLIC S35770 24-Bit Binary Counter.
Software gibt es hier https://github.com/FUEL4EP/HomeAutomat ... LIC_S35770
Danke. Vorteil dieses Zaehlers fuer meinen Zweck waere, dass er noch etwas sparsamer als der PCF8583 und sogar der RAM-lose PCF8593 ist. Hast Du mit dem S35770 praktische Erfahrungen mit dem Zaehlen flacher Flanken? Denn was mich im Datenblatt irritiert: Es wird zwar ein Schmitt-Trigger-Eingang hingemalt, aber als maximale Anstiegszeit 300ns angegeben. Das schaffe ich "nicht ganz" mit einem Reedkontakt mit RC-Tiefpass.
Viele Gruesse,
Stephan
- FUEL4EP
- Beiträge: 586
- Registriert: 01.11.2017, 17:26
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 76 Mal
- Danksagung erhalten: 78 Mal
- Kontaktdaten:
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Hallo Stephan,
ich habe den S35770 Zähler erst seit kurzer Zeit in einer Applikation erfolgreich im Betrieb. Welche Anstiegszeit brauchst Du denn? Ich kann dann eine Messung mit einem Signalgenerator aufsetzen. Kannst Du einen Signalverlauf bereitstellen?
Nachtrag 22. März 2021 11:29 Uhr: Der S35770 zählt ein Dreieckssignal mit 100 kHz, 3.3Vpp, 50% DutyCycle korrekt. 50 kHz gehen auch. 1 MHz auch. 10 kHz auch. Also sind langsame Flanken kein Problem. Die 300 ns scheinen ein Fehler im Datenblatt zu sein. Es liest sich ja auch ziemlich Chinglisch
ich habe den S35770 Zähler erst seit kurzer Zeit in einer Applikation erfolgreich im Betrieb. Welche Anstiegszeit brauchst Du denn? Ich kann dann eine Messung mit einem Signalgenerator aufsetzen. Kannst Du einen Signalverlauf bereitstellen?
Nachtrag 22. März 2021 11:29 Uhr: Der S35770 zählt ein Dreieckssignal mit 100 kHz, 3.3Vpp, 50% DutyCycle korrekt. 50 kHz gehen auch. 1 MHz auch. 10 kHz auch. Also sind langsame Flanken kein Problem. Die 300 ns scheinen ein Fehler im Datenblatt zu sein. Es liest sich ja auch ziemlich Chinglisch
Grüße
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
Ewald
Meine SmartHome Entwicklungen gibt es hier: FUEL4Ps Homeautomation Github Repository oder als ZIP
Das passende RaspberryMatic Addon ist hb-ep-devices-addon
Passende Platinen gib es hier: PCBs
-
- Beiträge: 539
- Registriert: 20.08.2019, 06:23
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 95 Mal
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Hallo Ewald,
ich habe einen Tiefpass mit 100n/100R vorgesehen, da sollte ich unter 50us bleiben, insofern danke fuer Deinen 10kHz-Versuch, sollte also ohne zusaetzliche Schaltungstechnik klappen. Muss nur dran denken, alles umzudrehen, da der S35770 steigende Flanken zaehlt.
Viele Gruesse,
Stephan
ich habe einen Tiefpass mit 100n/100R vorgesehen, da sollte ich unter 50us bleiben, insofern danke fuer Deinen 10kHz-Versuch, sollte also ohne zusaetzliche Schaltungstechnik klappen. Muss nur dran denken, alles umzudrehen, da der S35770 steigende Flanken zaehlt.
Viele Gruesse,
Stephan
Re: Exaktes Timing trotz PowerDown und externer Interrupts?
Hallo zusammen,
ich möchte das ganze nochmal aufgreifen, weil ich genau das selbe Problem habe.
Mein Arduino schläft und wird auch von den interrupts meines Windsensors aufgeweckt.
Dabei ist mir nun aufgefallen, dass der Arduino verschiedene "Intervalle" schlafen kann (siehe Sleep Klasse in Activity.h)
Das intervall wählt er basierend auf der "Restzeit" die noch zu schlafen ist. Z.b. bei 60 Sekunden wählt er zunächst immer die "8 Sekunden" (800 Ticks) aus. Wenn jetzt ein Interrupt kommt, ist der Fehler (offset) maximal 8 Sekunden falsch. Das ist enorm.
Wenn ich jetzt aber alles auskommentiere und immer das kleinste Intervall (15 ms) schlafen lasse, so ist der Fehler in der Offset-Berechnung nur maximal 15ms, was mir nicht weh tut!
Jetzt ist die Frage, ob das kleine Intervalll auf Dauer schädlich ist, oder nicht..
ich möchte das ganze nochmal aufgreifen, weil ich genau das selbe Problem habe.
Mein Arduino schläft und wird auch von den interrupts meines Windsensors aufgeweckt.
Dabei ist mir nun aufgefallen, dass der Arduino verschiedene "Intervalle" schlafen kann (siehe Sleep Klasse in Activity.h)
Code: Alles auswählen
class Sleep : public Idle<ENABLETIMER2> {
public:
static uint32_t doSleep (uint32_t ticks) {
uint32_t offset = 0;
period_t sleeptime = SLEEP_FOREVER;
if( ticks > seconds2ticks(8) ) { offset = seconds2ticks(8); sleeptime = SLEEP_8S; }
// else if( ticks > seconds2ticks(4) ) { offset = seconds2ticks(4); sleeptime = SLEEP_4S; }
// else if( ticks > seconds2ticks(2) ) { offset = seconds2ticks(2); sleeptime = SLEEP_2S; }
else if( ticks > seconds2ticks(1) ) { offset = seconds2ticks(1); sleeptime = SLEEP_1S; }
// else if( ticks > millis2ticks(500) ) { offset = millis2ticks(500); sleeptime = SLEEP_500MS; }
// else if( ticks > millis2ticks(250) ) { offset = millis2ticks(250); sleeptime = SLEEP_250MS; }
else if( ticks > millis2ticks(120) ) { offset = millis2ticks(120); sleeptime = SLEEP_120MS; }
// else if( ticks > millis2ticks(60) ) { offset = millis2ticks(60); sleeptime = SLEEP_60MS; }
// else if( ticks > millis2ticks(30) ) { offset = millis2ticks(30); sleeptime = SLEEP_30MS; }
else if( ticks > millis2ticks(15) ) { offset = millis2ticks(15); sleeptime = SLEEP_15MS; }
if( ENABLETIMER2 == false ) {
LowPower.powerDown(sleeptime,ADC_OFF,BOD_OFF);
}
else {
LowPower.powerExtStandby(sleeptime,ADC_OFF,BOD_OFF,TIMER2_ON);
}
return offset;
}
Wenn ich jetzt aber alles auskommentiere und immer das kleinste Intervall (15 ms) schlafen lasse, so ist der Fehler in der Offset-Berechnung nur maximal 15ms, was mir nicht weh tut!
Jetzt ist die Frage, ob das kleine Intervalll auf Dauer schädlich ist, oder nicht..