AVR Tiny Serie 2:Sleep Controller, sleep_cpu()

[Wulf D. (holler)]

Es geht um Ein- und Ausstieg in den Power-Down (Standby wäre auch ok) 
bei einem AVR Tiny 1627, ist aus der Series 2.
Der soll aus dem Power-Down entweder auf Tastendruck (funktioniert) oder 
nach einer Zeitspanne wieder zurückkehren und ein paar Dinge 
verarbeiten.

Für das zyklische will ich die RTC bzw deren Mode "Periodic Interrupt 
Timer (PIT)" verwenden.
PIT verwende ich schon im aktiven Betrieb, nur soll der vor dem Einstieg 
in den Power down stark verlangsamt werden. Meine Erwartungshaltung 
wäre, dass beim ersten Interrupt des PIT die CPU wieder aufwacht.
Tut sie nicht: manchmal läuft sie ungebremst über sleep_cpu() hinweg, 
manchmal kommt die nie wieder da raus. Es sei denn, ich löse einen Port 
i/o Interrupt aus.

Initialisierung des Sleep Controllers:

SLPCTRL.CTRLA = SLPCTRL_SMODE1_bm;

Und hier der zyklische Power-Down, der definitiv nicht funktioniert:

if (  task & (1<<tasksleep)) 
  {
  PORTA.OUTCLR = LED;  
  RTC.CTRLA &= ~(1<< RTC_RTCEN_bp);
  RTC.PITCTRLA &=  ~(1<< RTC_PITEN_bp);
  RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc | (1<< RTC_PITEN_bp);
  RTC.CTRLA |= (1<< RTC_RTCEN_bp);
  sleep_enable(); 
  sleep_cpu();
  sleep_disable();
  PORTA.OUTSET = LED;  
  RTC.CTRLA &= ~(1<< RTC_RTCEN_bp);
  RTC.PITCTRLA &=  ~(1<< RTC_PITEN_bp);
  while (RTC.PITSTATUS & RTC_CTRLBUSY_bm);
  RTC.PITCTRLA = RTC_PERIOD_CYC256_gc | (1<< RTC_PITEN_bp);
  RTC.PITINTFLAGS = RTC_PI_bm;
  RTC.CTRLA |= (1<< RTC_RTCEN_bp);
  task &= ~(1<<tasksleep);
  }

Ist etwas überladen, um den Fehler auf die Spur zu kommen. Leider 
vergeblich.
Vielleicht hat das schon mal jemand hinbekommen und kann mir einen Tipp 
geben.
Oder klarstellen, so gehts gar nicht, was mich wundern würde :-)

[Veit D. (devil-elec)]

Hallo,

habe die Serie nicht zur Hand, denke jedoch du musst noch "Standby" der 
jeweiligen Einheit aktivieren damit sie weiterläuft.

[Jörg W. (dl8dtl) (Moderator)]

Nur mal vom Draufgucken:

Warum gibt es die Warteschleife auf RTC_CTRLBUSY_bm nur in einem der 
beiden Zweige?

Hast du auch eine ISR für den PIT-Interrupt? Solltest du ja ;-) Dann 
würde ich aber auch konsequenterweise das RTC_PI_bm da drin gleich 
löschen.

Habe den PIT schon benutzt, aber noch nicht, um aus dem Sleep 
aufzuwachen.

Achso, gibt es einen Grund, nicht gleich sleep_mode() zu nehmen?

[Georg M. (g_m)]

Beispielcode:

#include <avr/io.h>
#include <avr/interrupt.h>

uint8_t flag;

ISR(RTC_PIT_vect)
{
  RTC.PITINTFLAGS = RTC_PI_bm;                              // clear PIT flag
}

int main(void)
{
  RTC.CLKSEL = RTC_CLKSEL_INT1K_gc;                         // 1024 Hz from OSCULP32K
  while(RTC.PITSTATUS > 0) {}                               // wait for RTC.PITCTRLA synchronization
  RTC.PITINTCTRL = RTC_PI_bm;                               // enable periodic interrupt
  RTC.PITCTRLA = RTC_PERIOD_CYC2048_gc | RTC_PITEN_bm;      // 2s, enable PIT

  PORTA.DIRSET = PIN3_bm;                                   // PA3 output (LED)

  SLPCTRL.CTRLA = SLPCTRL_SMODE_PDOWN_gc | SLPCTRL_SEN_bm;  // POWER-DOWN sleep mode, Sleep Enable

  sei();                                                    // enable interrupts

  while(1)
  {
    if(!flag)
    {
      PORTA.OUTSET = PIN3_bm;                               // PA3 on
      while(RTC.PITSTATUS > 0) {}                           // wait for RTC.PITCTRLA synchronization
      RTC.PITCTRLA = RTC_PERIOD_CYC128_gc | RTC_PITEN_bm;   // 125ms, enable PIT
      flag = 1;
    }
    else
    {
      PORTA.OUTCLR = PIN3_bm;                               // PA3 off
      while(RTC.PITSTATUS > 0) {}                           // wait for RTC.PITCTRLA synchronization
      RTC.PITCTRLA = RTC_PERIOD_CYC2048_gc | RTC_PITEN_bm;  // 2s, enable PIT
      flag = 0;      
    }
    __asm__ __volatile__ ("sleep" "\n\t" :: );
  }
}

[Peter D. (peda)]

Ich würde mal vermuten, daß auch bei den neueren AVRs Sleep nur in 
Zusammenarbeit mit einem Interrupthandler funktioniert.

Und bei den klassischen AVRs muß man vor dem nächsten Sleep noch warten, 
bis die RTC-Register mit dem RTC-Takt synchronisiert sind, sonst wird 
der Interrupt mehrfach getriggert. Dafür sind die xx_Update_Busy Bits 
gedacht.

Das sleep_disable(); ist akademischer Furz (vollkommen überflüssig) und 
kann weg. Einmal sleep_enable(); ins Init und gut.

[Peter D. (peda)]

Jörg W. schrieb:
> Achso, gibt es einen Grund, nicht gleich sleep_mode() zu nehmen?

Ja, (Race Conditions).

[Jörg W. (dl8dtl) (Moderator)]

Peter D. schrieb:
> Jörg W. schrieb:
>> Achso, gibt es einen Grund, nicht gleich sleep_mode() zu nehmen?
>
> Ja, (Race Conditions).

Welche können das realistisch sein? Vor dem Sleep hat man normalerweise 
eh nur die Peripherie aktiv, die einen daraus aufwecken soll. Auch sehe 
ich nicht, welchen Schaden ein zwischen den drei Teilschritten 
eintreffender Interrupt anrichten sollte.

Also ja, man kann das sleep_enable() auch ganz am Anfang machen und dann 
aktiv lassen (und nur noch sleep_cpu() benutzen), aber ich sehe keinen 
wirklichen Sinn drin, statt eines sleep_mode() die drei darin 
enthaltenen Teilschritte selbst einzeln hinzumeißeln.

[Peter D. (peda)]

Jörg W. schrieb:
> Welche können das realistisch sein?

Z.B. wenn der Aufwachinterrupt sich selbst disabled und dann genau vor 
das sleep_cpu(); reinhaut.
Es gibt doch schon reichlich Threads mit dem "sleep forever Problem".

Wie schon gesagt, das sleep_disable(); hat absolut keine sinnvolle 
Funktion.
Jedes Programm verhält sich exakt gleich, wenn man es wegläßt. Es ist 
also nur vergeudeter Flash und CPU-Zyklen.

[Wulf D. (holler)]

Veit D. schrieb:
> Hallo,
> habe die Serie nicht zur Hand, denke jedoch du musst noch "Standby" der
> jeweiligen Einheit aktivieren damit sie weiterläuft.

Ja richtig, ist gewährleistet. Init des Timers:

void timer_setup(void) /*Periodic Interrupt Timer (PIT) wird hier benutzt */
{  
RTC.CTRLA |=  RTC_RUNSTDBY_bm | (1<< RTC_RTCEN_bp) ;
RTC.PITINTCTRL = RTC_PI_bm; // Enable the interrupt
RTC.PITCTRLA |= RTC_PERIOD_CYC256_gc | (1<< RTC_PITEN_bp);
sei(); //enabling global interrupt
}

Peter D. schrieb:
> Ich würde mal vermuten, daß auch bei den neueren AVRs Sleep nur in
> Zusammenarbeit mit einem Interrupthandler funktioniert.
Es gibt eine ISR (RTC_PIT_vect).

> Das sleep_disable(); ist akademischer Furz (vollkommen überflüssig) und
> kann weg. Einmal sleep_enable(); ins Init und gut.
Danke für den Hinweis, dann muss ich mir den Sleep-Controller im Detail 
anschauen. Hatte die Sequenz nur irgendwo abgekupfert.

Jörg W. schrieb:
> Warum gibt es die Warteschleife auf RTC_CTRLBUSY_bm nur in einem der
> beiden Zweige?
Hast Recht, das ist inkonsequent. Im Datenblatt steht, man muss das 
busy-Flag beim Schreiben auf die PIT-Register abpollen. Müsste man dann 
immer tun. Wobei ich bisher ohne auskam.

Georg M. schrieb:
> Beispielcode: ...
Herzlichen Dank, schaue ich mir genau an.

[Jörg W. (dl8dtl) (Moderator)]

Peter D. schrieb:
> Z.B. wenn der Aufwachinterrupt sich selbst disabled und dann genau vor
> das sleep_cpu(); reinhaut.

Das hat aber nicht viel mit sleep_mode() zu tun, außer dass das Fenster 
für diese race condition damit etwas größer wird. Am Ende ist das ein 
Designfehler.

[Peter D. (peda)]

Jörg W. schrieb:
> Das hat aber nicht viel mit sleep_mode() zu tun

Doch, daß hat sehr viel damit zu tun. Schließlich ist sogar in der 
"sleep.h" ein Beispielcode für die korrekte Lösung angegeben.

Jörg W. schrieb:
> außer dass das Fenster
> für diese race condition damit etwas größer wird.

Ein "Sleep forever" würde ich nicht gerade als nur "etwas größer" 
bezeichnen.
Aber auch, wenn die Mainloop um einen zusätzlichen Timerzyklus 
verzögert, kann das schon Auswirkungen haben.
In einer BA eines MP3 Players habe ich mal gelesen: "Die Zeitanzeige 
kann bei häufiger Benutzung etwas nachgehen". Schönes Eingeständnis für 
Unfähigkeit.

[Peter D. (peda)]

Wulf D. schrieb:
> Es gibt eine ISR (RTC_PIT_vect).

Und warum zeigst Du sie dann nicht?

Fehlersuche geht immer erheblich besser bei vollständigem Code.

[Wulf D. (holler)]

Peter D. schrieb:
> Wulf D. schrieb:
>> Es gibt eine ISR (RTC_PIT_vect).
>
> Und warum zeigst Du sie dann nicht?
>
> Fehlersuche geht immer erheblich besser bei vollständigem Code.

Ist hier, hab ich für das Problem als irrelevant angesehen. Aber ja, 
hätte erwähnen müssen, dass es eine ISR gibt.

ISR (RTC_PIT_vect)    // ca 12ms
{
ticker++;
if (intr_count==TIMEIRQ) // ca 1/10 sec Takt
  {
  task |= (1<<task100ms);
  if (blink==2) PORTA.OUTTGL = LED;  // LED toggeln
  intr_count=0; //making intr_count=0 to repeat the count    
  if (intr_c10==9)
    {        // ca 1 sec Takt
    intr_c10=0;
    ++sec;
    sleepsec++;
    if (sleepsec==10)
      {
      task |= (1<<tasksleep);        
      sleepsec=0;
      }
    if (blink==1) PORTA.OUTTGL = LED;  // LED toggeln
    anz |= (1<<anzjetzt);
    if (klickrep>2 && klickinc<256) klickinc<<=1;
    else if (klickrep<2 && klickinc>1) klickinc>>=1;
    klickrep=0;
    }
  else intr_c10++;
  }
else  intr_count++;
RTC.PITINTFLAGS = RTC_PI_bm;
}

Habe Georgs Democode adaptiert und der Power-Down wird damit jedesmal 
zuverlässig betreten und verlassen!
Jetzt funktioniert zwar mein restlicher Code nicht mehr, aber das ist 
sicher irgend ein Randeffekt mit dem RTC. Finde ich sicher selbst raus, 
komme da aber erst morgen zu.

Wäre interessant woran es gelegen hat. Georgs Code ist sehr kompakt, 
werde ich noch rausfinden.

Hier die Adaption. Init:

SLPCTRL.CTRLA = SLPCTRL_SMODE_PDOWN_gc | SLPCTRL_SEN_bm;

Die Umschaltung des PIT mit sleep-Command.

if (  task & (1<<tasksleep)) 
  {
  PORTA.OUTCLR = LED;  
  while(RTC.PITSTATUS > 0) {} // wait for RTC.PITCTRLA synchronization
  RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc| RTC_PITEN_bm;
  __asm__ __volatile__ ("sleep" "\n\t" :: );
  PORTA.OUTSET = LED;  
  while(RTC.PITSTATUS > 0) {} // wait for RTC.PITCTRLA synchronization
  RTC.PITCTRLA = RTC_PERIOD_CYC256_gc | RTC_PITEN_bm;
  task &= ~(1<<tasksleep);
  }

[Wulf D. (holler)]

Wulf D. schrieb:
> Jetzt funktioniert zwar mein restlicher Code nicht mehr, aber das ist
> sicher irgend ein Randeffekt mit dem RTC.
Nee, hatte nichts mit der RTC zu tun, die läuft.

Es war der ADC, der nach dem Power-Down neu gestartet werden muss.
Der ist so konfiguriert, dass nach erfolgter Konvertierung der beim 
Setzen seines Eingangs-Multiplexer automatisch eine neue Konvertierung 
startet.
Da passiert nach einem Power-Down nichts mehr. Muss neu angestoßen 
werden.
Also zum Code oben noch eine Zeile hinzugefügt:

ADC0.MUXPOS = uadc[adcindex].muxpos;

Die rechte Seite ist einfach eine Portnummer.

Vielen Dank für die Tipps, hat das Problem in kürzester Zeit gelöst!

Schaue morgen mal, was der entscheidende Punkt war.

[Georg M. (g_m)]

Wulf D. schrieb:
> PIT verwende ich schon im aktiven Betrieb

Beim laufenden Mikrocontroller braucht man den asynchronen PIT 
eigentlich nicht. Stattdessen kann ein TCB eingesetzt werden.