XMega: Laufend RTC-Periode umstellen

[Thomas L. (delfinis)]

Hallo,
ich benutze den RTC um den uc immer eine Minute schlafen zu legen.
Das erste mal soll er jedoch nur 10 sekunden schlafen, und dann immer 
eine Minute. Allerdings soll diese Minute variabel sein, um zeitdrift 
auszugleichen.

Nun hab ich den RTC mittels dem Periodenregister und dem 
Overflow-Interrupt so hingebracht, dass er zuerst 10 Sekunden schläft 
und dann auch wieder aufwacht. (RTC zählt vier mal pro Sekunde d.H. für 
10 Sekunden = 0x28)

Aber wenn ich das Periodenregister RTC.PER auf eine Minute (60 x 4 = 
0xF0) umstelle, weckt er trotzdem immer alle 10 Sekunden auf. Mit dem 
Debugger hab ich dann mal geschaut ob das RTC-Register tatsächlich 
umgeschrieben wird - und es wird auch umgeschrieben (siehe Foto)! Aber 
trotzdem bleibt die Periode auf 10s!

Prozessor: ATXMega32E5

main() {
.
.
  RTC.PER = 0x28;
  CLK.RTCCTRL = (CLK_RTCSRC_TOSC_gc | CLK_RTCEN_bm); //select 32768/32 ext. crystal
  RTC.CTRL = RTC_PRESCALER_DIV256_gc;  // prescaler to 0.25s for time synchroniz.
.
.
  while (1) {
    .
    .
    set_sleep_mode(SLEEP_MODE_PWR_SAVE);
    sleep_mode();
  }
}

[Plörensaugikus (Gast)]

Nun ja. Das  RTC.PER = 0x28; bleibt ja auch immer daselbe

[Thomas L. (delfinis)]

Plörensaugikus schrieb:
> Nun ja. Das  RTC.PER = 0x28; bleibt ja auch immer daselbe

Nein, wird ja in der Interrupt-Routine auf 0xf0 umgeschrieben, siehe 
Interrupt-Routine und markierte Memory-Stelle. Sorry, hab ich wohl zu 
wenig klar beschrieben.

[Volker B. (Firma: L-E-A) (vobs)]

Thomas L. schrieb:

> Aber wenn ich das Periodenregister RTC.PER auf eine Minute (60 x 4 =
> 0xF0) umstelle, weckt er trotzdem immer alle 10 Sekunden auf. Mit dem

Da Du uns leider nicht mitteilst welchen Xmega Du jetzt wirklich 
verwendest, habe ich in das Datenblatt der AU-Familie geguckt:

Abs. 18.2.2:

Due to the asynchronous clock domain, events will be generated only for 
every third overflow or compare match if the
period register is zero. If the period register is one, events will be 
generated only for every second overflow or compare
match. When the period register is equal to or above two, events will 
trigger at every overflow or compare match, just as
the interrupt request.

Abs. 18.3.2:

Bit 0 – SYNCBUSY: Synchronization Busy Flag
This flag is set when the CNT, CTRL, PER, or COMP register is busy 
synchronizing between the RTC clock and
system clock domains after writing any of these registers or when waking 
up from a sleep mode where the peripheral
clock is stopped. This flag is automatically cleared when the
synchronisation is complete.


Beachstest Du diese Hinweise? Leider ist Dein Code-Beispiel nicht 
vollständig...

Grüßle
Volker.

Nachtrag: Warum hast Du den Interrupt-Code nicht als Text eingefügt? 
Lustiges Suchspiel!

Also ich würde das Busy-Waiting im Hauptprogramm machen und erst nachdem 
sich die RTC synchronisiert hat den Interrupt freigeben. Bei der 
Änderung im Irpt-Handler ggf. ein Flag setzen, Irq. sperren und in 
main() auf die Synchronisierung warten.

[Thomas L. (delfinis)]

Volker B. schrieb:
> Da Du uns leider nicht mitteilst welchen Xmega Du jetzt wirklich
> verwendest

Hab ich doch:
"Prozessor: ATXMega32E5"


Hab die Lösung gefunden:
******************************

Hab eine Annotation note gefunden:
ww1.microchip.com/downloads/en/AppNotes/doc8047.pdf

Dort steht unter anderem:
"Note that the PER register  does  not  have  a  separate  synchronizer; 
the  synchronization  of  PER  is triggered by synchronization of the 
CNT, CTRL or COMP registers.

Hab in der Interrupt-Routine noch nachträglich das CTRL Register neu 
überschrieben, nun funktionierts! Nur leider steht davon nichts im 
Datenblatt....

ISR(RTC_OVF_vect) {
  while (RTC.STATUS & RTC_SYNCBUSY_bm);
  RTC.PERL = 0x28;
  RTC.PERH = 0x00;

  // ==> wichtig, für's Update des PER-Registers:
  RTC.CTRL = RTC_PRESCALER_DIV256_gc; 

  PORTA_OUTSET = 0x01; // 3.3V on
  PORTD_OUTSET = 0X80; //DEBUG
}

[Wolfgang (Gast)]

Thomas L. schrieb:
> Hab eine Annotation note gefunden:
> ww1.microchip.com/downloads/en/AppNotes/doc8047.pdf
> ...
> Nur leider steht davon nichts im Datenblatt....

Das Datenblatt beschreibt, was der Prozessor kann. Die Application Note 
beschreibt, wie man die Baugruppe anwendet - darum die Bezeichnung 
"Application Note".

Wenn man das natürlich als "Annotation Note" abtut, darf man sich nicht 
wundern ...