AtTiny13: Watchdog Interrupt dauert lange

[flaschenpost (Gast)]

Hallo,

ich hab eine kurze Frage zur scheinbar sehr hohen Ausführungsdauer des 
Watchdog-Timers im attiny13. Timer0 steuert eine PWM auf Pin PB0, und 
per ISR(WDT_vect) will ich aller zB 4 Sekunden einen Counter hochzählen.

Im eigentlichen Loop, also außerhalb des Interrupts, will ich dann auf 
die erhöhte Variable reagieren.

Leider löst der Watchdog-Interrupt eine deutlich sichtbare Pause im PWM 
aus, mindestens 50-100 Millisekunden.

Deutet das auf einen Fehler in meinem Programm hin oder liegt das am 
Konzept des Watchdog-Interrupts? In 
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Watchdog#Aufwecken_aus_einem_Sleep_Mode 
hab ich nichts dazu gefunden.

uint_16t seccount=0;

ISR(WDT_vect) {
  seccount++;
}
...
void setup(){
...
  cli();
  WDTCR |= _BV(WDTIE);  // enable Watchdog Timer interrupt
  wdt_enable(WDTO_4S);  // set prescaler to 5s and enable Watchdog Timer
  sei();          
...

Ziel des Programms ist eine einfache Tag-Nacht-LED Ansteuerung, und im 
"Tag" Zustand (=14 Stunden aus) wollte ich lieber die watchdog + 
poweroff Variante nutzen zur Zeitmessung (Stromsparen). Da wäre es aus 
verschiedenen Gründen hilfreich, auch in der "on" Phase dieselbe Methode 
zu benutzen (gleicher Zeittakt, leichtere Verschiebung Tag/Nacht ohne 
Verlust des 24h- Loops).

Danke!

[Einer K. (Gast)]

flaschenpost schrieb:
> Leider löst der Watchdog-Interrupt eine deutlich sichtbare Pause im PWM
> aus, mindestens 50-100 Millisekunden.
Nein, das tut er nicht.

Glaskugel:
Dein Tiny geht durch den Reset.

flaschenpost schrieb:
> Deutet das auf einen Fehler in meinem Programm hin
Ja.

flaschenpost schrieb:
> oder liegt das am
> Konzept des Watchdog-Interrupts?
Nein.

[S. Landolt (Gast)]

> Dein Tiny geht durch den Reset.

Denke ich auch.
Executing the corresponding interrupt vector will clear WDTIE and WDTIF 
automatically by hardware ... To stay in Interrupt and System Reset 
Mode, WDTIE must be set after each interrupt.

[Claudio (Gast)]

flaschenpost schrieb:
> Leider löst der Watchdog-Interrupt eine deutlich sichtbare Pause im PWM
> aus, mindestens 50-100 Millisekunden.

Die Pause entsteht ziemlich sicher durch einen System Reset der durch 
den Watchdog ausgelöst wird.

> Deutet das auf einen Fehler in meinem Programm hin oder liegt das am
> Konzept des Watchdog-Interrupts? In
> 
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Watchdog#Aufwecken_aus_einem_Sleep_Mode
> hab ich nichts dazu gefunden.

Bei unerklärlichen Problemen schaut man immer zuerst im Datenblatt nach. 
Der Watchdog kann nur einen Interrupt auslösen, oder nur einen System 
Reset, oder aber beides zusammen. Das wird im Kapitel 'WDTCR – Watchdog 
Timer Control Register' beschrieben. Schau also nach, welche Bits in 
deinem Fall gesetzt sind.

>

> uint_16t seccount=0;
> 
> ISR(WDT_vect) {
>   seccount++;
> }
> ...
> void setup(){
> ...
>   cli();
>   WDTCR |= _BV(WDTIE);  // enable Watchdog Timer interrupt
>   wdt_enable(WDTO_4S);  // set prescaler to 5s and enable Watchdog Timer
>   sei();
> ...
>

'wdt_enable()' setzt das WDE Bit und dadurch wird der System Reset 
aktiviert.

[flaschenpost (Gast)]

Vielen vielen Dank für die schnellen Antworten!

Ein kompletter Reset kommt vom Timing schon deutlich eher hin. Na, der 
Sonntag ist ja noch lang. ;-)

[Einer K. (Gast)]

flaschenpost schrieb:
> Na, der
> Sonntag ist ja noch lang. ;-)


flaschenpost schrieb:
> uint_16t seccount=0;
Diese Variable möchtest du vermutlich als volatile deklarieren.

flaschenpost schrieb:
> ISR(WDT_vect)
In der ISR möchtest du den WDT Interrupt wieder aktivieren.

flaschenpost schrieb:
> WDTCR |= _BV(WDTIE);  // enable Watchdog Timer interrupt
>   wdt_enable(WDTO_4S);  // set prescaler to 5s and enable Watchdog Timer
Die beiden Zeilen möchtest du evtl vertauschen.

flaschenpost schrieb:
> wdt_enable(WDTO_4S);  // set prescaler to 5s and enable Watchdog Timer
Eins ist gelogen, entweder im Code oder im Kommentar.

[flaschenpost (Gast)]

Arduino Fanboy D. schrieb:
> flaschenpost schrieb:
>> wdt_enable(WDTO_4S);  // set prescaler to 5s and enable Watchdog Timer
> Eins ist gelogen, entweder im Code oder im Kommentar.

volatile ist mir auch noch aufgefallen, danke. Die 5s sind nicht 
gelogen, ich hab ne Reihe gemessen und kam auf ca 4,9925 Sekunden.

Jetzt muss nur noch der Sleepmode funktionieren - aktuell schaffe ich es 
nicht, dass der WDT ihn wieder aufweckt.

wdt_enable hab ich jetzt komplett rausgeworfen.

[HildeK (Gast)]

flaschenpost schrieb:
> Jetzt muss nur noch der Sleepmode funktionieren - aktuell schaffe ich es
> nicht, dass der WDT ihn wieder aufweckt.

Dein Programm ist bereits zu umfangreich, um die Grundproblem WD und 
sleep zu eruieren. Ich würde mal diese Funktionalitäten an einem 
reduzierten Teil testen.
Ich hänge dir mal ein Beispiel für den Tinyx5 an; das sollte ganz 
ähnlich auch bei anderen Atmel-Prozessoren funktionieren.

[Einer K. (Gast)]

flaschenpost schrieb:
> volatile ist mir auch noch aufgefallen, danke. Die 5s sind nicht
> gelogen, ich hab ne Reihe gemessen und kam auf ca 4,9925 Sekunden.

Angenommen jemand testet dein Programm....
Der nächste ATTiny13 tuts dann in 3,5 Sekunden.
Deine 5s entsprechen dann nicht dem Prinzip der geringsten Verwunderung.

Besser und logischer wäre, einen Korrekturwert (vielleicht sogar 
temperaturkompensiert) einzuführen.


 ISR(WDT_vect) {
   seccount += 4.0 * korrekturfaktor;

[HildeK (Gast)]

HildeK schrieb:
> das sollte ganz
> ähnlich auch bei anderen Atmel-Prozessoren funktionieren.

Ich sehe gerade, dass 'WDIE' vom Tinyx5 beim Tiny13 'WDTIE' heißt - das 
hast du auch so verwendet.
Sind halt ein paar inkonsequente Dinge, die man immer mal wieder findet.

[flaschenpost (Gast)]

HildeK schrieb:

> Ich hänge dir mal ein Beispiel für den Tinyx5 an; das sollte ganz
> ähnlich auch bei anderen Atmel-Prozessoren funktionieren.

Danke - dein einfaches Beispiel hat mir geholfen.

Jetzt suche ich nur noch eine Möglichkeit, von außen das Tuning zu 
beeinflussen (= Anteil An und Gesamtzeit).

Die offene Frage ist, ob man als Laie leichter eine Art extrem 
simplifiziertes 1-Wire hinbekommt, um das von außen zu setzen, oder doch 
eine Version mit verschiedenen Buttons (+, -, Poti).

[HildeK (Gast)]

flaschenpost schrieb:
> Die offene Frage ist, ob man als Laie leichter eine Art extrem
> simplifiziertes 1-Wire hinbekommt, um das von außen zu setzen, oder doch
> eine Version mit verschiedenen Buttons (+, -, Poti).

Die Hauptfrage ist doch, womit willst du die Einstellungen vornehmen?
Von einem anderen µC oder von einem PC aus würde ich UART verwenden 
(Achtung: PC hat RS232). Mit nur dem Receive-Signal käme man da aus.

Bei der Bedienung direkt am Gerät ist es dein Gusto, ob du Tasten oder 
Potis verwendest. Potis haben den Vorteil, dass man auch ohne 
elektronische Anzeige sehen kann, auf welchem Wert sie ungefähr stehen.
Ich nehme in solchen Fällen Poti und AD-Wandler.

[flaschenpost (Gast)]

HildeK schrieb:
> Die Hauptfrage ist doch, womit willst du die Einstellungen vornehmen?
> Von einem anderen µC oder von einem PC aus würde ich UART verwenden
> (Achtung: PC hat RS232). Mit nur dem Receive-Signal käme man da aus.

Das ist ein In-House- Teil, also anderer Arduino / ESP32 oder direkt PC 
wäre einfach. Ich hab nur hier im Forum gelesen, dass Attiny13 ziemlich 
winzig für eine Software-RSxxx ist.
Die Frage war also primär: ist es für einen Noob realistisch, das per 
Software stabil hinzubekommen. Reicht mir ja auch direkt nach dem Reset, 
um die Interrupt Routine einfach und stabil zu halten.

[HildeK (Gast)]

Mit dem Tiny13 habe ich noch nicht probiert, mit dem Tiny25 sende ich 
gelegentlich. Da ist es kein Problem. Der 25 ist ja fast SW-kompatibel, 
hat allerdings doppelten Flash.
Hauptproblem könnte sein, dass man für den Prozessor eine gut definierte 
und stabile Taktfrequenz haben sollte, also quarzstabil.