How low can I go with RTC_CLKSEL and how high with RTC_PERIOD_CYC?

[tobivan]

Hello,

first of all: thanks a lot for that fantastic project!
These are my first steps on an ATTiny412. I would like to make it sleep for a long time (hours) and then be awake for a long time, too.
Right now I use both 32.768 Hz for Oscillator and for RTC Clock Cycle:

RTC.CLKSEL = RTC_CLKSEL_INT32K_gc;
RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc | RTC_PITEN_bm;

That gives me a nice 1 Hz = 1 second of sleep.
In the ISR the code counts up, and within the loop() we compare how often the device has woken up.

ISR(RTC_PIT_vect) {
  current_sleeps += 1;                  // increment sleep counter
  RTC.PITINTFLAGS = RTC_PI_bm;          // clear interrupt flag by writing '1' (required)
}

But to increase sleeping time: how low can I go with RTC_CLKSEL (256? 512? 1024?) and how high can I go with RTC_PERIOD_CYC?
And if doing so does it affect accuracy?

Thanks a lot!
Tobias

[hmeijdam]

I get the feeling you think you can use RTC.CLKSEL to select the clock speed. But it is to select the clock source.
See datasheet

[tobivan]

Oh dear, thanks, you are absolutely right!
I didn't know that there was a 1 kHz source, I thought there was only the 32 kHz source.

Leading back to my question: I chose INT1K as source now and set RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc
Is my Math right then: 32768/1024 Hz = 32 seconds of sleep? The chip however only sleeps for about 12 seconds (stopwatch, sorry...)
If I chose INT32K as source it is exactly 32768/32678 Hz = 1 second

[SpenceKonde]

Using the PIT interupt to wake with a 12 second cycle will sleep for between 0 and 12 seconds, not 12 seconds. The counter in question is the unprescaled clock, not the PTC. You cannot use the PTC to "sleep for X seconds", you can only use it to "Wake every X seconds". This is stated, albeit very (suspiciously) obtusely in the documentation. In your case, on the 412, it is possible to exploit the erratum to achieve that with it, though other functionality of the RTC will be deranged. There is a looooong issue thread on here about this topic, where they kept tweaking it with my advice, getting some other problem, then it was hanging the second time they tried to use it... and eventually I check the errata and find the relevant section and include it.

Also, be sure to review the Errata. There is a large colony Chameleon Wasps living in the control registers. Their camoflage allows them to pass as simple code bugs, except they are immortal as far as man is concerned, so users encountering that bug will try multiple attempts to fix a suspected code bug, getting stung painfully each time. They can only get out when only one of the two (RTC or PIT) is enabled. Their stings give really nasty welts if the wasps are able to sting you, in addition to causing deranged behavior in the peripheral.

This is particularly relevant here, because due to the bug, which will be fixed in the next silicon rev, which could be released any time between now and when the sun exhausts it's fuel and expands to a supergiant, rendering conditions on the planet's surface unsuited to semiconductor manufacture it IS possible to reset that timer on the bugged chips, resulting in the full delay. As the things that do that are things you often want to do without resetting the timer - the wasps sting just as badly there.

As of my last errata survey, they still had yet to ship corrected silicon for any tinyAVR device except Rev C of the 3216/3217 (which are the same die (note: I have no proof of this, but considerable evidence). Rev C t321x's came out years ago, and they dominate parts in the wild. No other tinyAVRs to my knowledge have had to fix.

Note: no matter the severity of the errata or unavailability of corrected silicon, they will never mention there when features ship that have issues. And since Tiny0, Tiny1, DA and DB prior to the recent Rev. B0/B1 (depending on flash size - they did it on one size, screwed up and had to respin once, and then ported the changes to other sizes without issue.) had more bugs than the National Entomology Museum*, the errata is a must-read for those parts.

Oh - and it's actually worse than the errata says, because if you follow best practice for interacting with the timer, it will work once and than hang forever - one of the "busy" flags gets set, but never unset when onlyone of the two peripherals is on. This is in addition to the above described issue with the incorrect resets of the unscaled timer.

Making the RTC millis timekeeping work with the same code on bugged and non-bugged parts... lordie, that was a challenge, and I'm super unhappy with how it came out and need to redo it (that's why DxCore doesn't have it; it doesn't meet my standards for features and functionality), but before I can do that I need to finish the plumbing to support that complex of functionality. Because - i think like everyone else whose thought about it, I consider the true prize the RTC could offer to Arduino is millis that keeps count while sleeping, WITHOUT gimping timekeeping.

Something like:

SleepWithMillis() - This will stop the currently selected (high speed) timer used for millis, and record it's value. Then, it will switch to the RTC.It will reawaken still in the routine. The RTC ISR would set a flag, which is detected upon returning from the ISR, where it would be noticed and the code would go back to start of loop. If it wakes up any other way, when it exits the ISR wouldn't have set the flag. So it's time to wake up, and the routine stops the ISR, records the time on the RTC, calculates what that would be in microseconds, and then updates the millis count and restarts millis, and then user code would resume, and millis would give correct answers. (with the caveat that micros() can't be relied upon to recognize time passing in sleep mode correctly, and the millis() times being inaccurate by milliseconds are not unexpected). If implemented, this would be available only on parts with a working RTC (hence, no tiny0 or tiny1, unless they start fixing more of them, or it's a drop-in addition for the 3216/7); 2-series, Dx and Ex parts, which don't have this issue all have working RTCs. 

* - entomology is the study of insects. Hence, a museum dedicated to the matter would have a large collection of them - thankfully, deceased and not permitted to "help" their

[SpenceKonde]

Oh - and you know there are two sets of very similarly named constants for the clock divider there right? One for the RTC, and one for the PIT. They both are #defines equal to numbers from 0 to 15 (or maybe one of them is Off or something, I don't feel like checking atm) and represent divisors that are powers of two. However, they don't start and end at the same power of two, thus, if you use the wrong one, the resulting frequency will be off by a factor of two. And as noted they are formatted named and look very very similar.

[tobivan]

Thanks a lot, however I am not able to understand it (due to my very limited knowledge) :-)
How then can I let the device go to sleep for hours and wake it up "on time"? Thought it could be that easy as in your PowerSave.md ;-(

[hmeijdam]

Your math is right, so I suspect something else is going on.

You may want to post a minimal but working sketch here that demonstrates the 12 second sleep, while you expect a 32 second sleep. Others may load that and try to reproduce what you observe.

[tobivan]

Thanks for your help.
This code lets the device sleep for 12 seconds for the first time, with the second period of sleep and further periods the sleeping time is 27 seconds.
According to my Maths 32768/1024 Hz it should be 32 seconds.
As soon as I change RTC.CLKSEL = RTC_CLKSEL_INT1K_gc; to RTC.CLKSEL = RTC_CLKSEL_INT32K_gc; I get quite an exact period of time.

#include <avr/sleep.h>
#define led 2

unsigned long previousMillis=0;
int interval = 5000;  //testing interval
 
volatile int current_sleeps = 0;
int target_sleeps = 1;

// setup for the RTC
void RTC_init(void) {
  while (RTC.STATUS > 0)
  {
    ; 
  }                 
  RTC.CLKSEL = RTC_CLKSEL_INT1K_gc;
  RTC.PITINTCTRL = RTC_PI_bm;
  RTC.PITCTRLA = RTC_PERIOD_CYC32768_gc | RTC_PITEN_bm;
}

// interrupt subroutine, runs when PIT wakes up
ISR(RTC_PIT_vect) {
  current_sleeps += 1;
  RTC.PITINTFLAGS = RTC_PI_bm;
}

void LichtAn() {
  digitalWrite (led, HIGH);
  previousMillis = millis();

  while (millis() - previousMillis < interval) {
  }

  digitalWrite(led, LOW);
}

void disableAllPeripherals(void) {
  PORTA.DIRCLR = PIN0_bm;
  //PORTA.DIRCLR = PIN1_bm; //needed for LED
  PORTA.DIRCLR = PIN2_bm;
  PORTA.DIRCLR = PIN3_bm;
  PORTA.DIRCLR = PIN6_bm;
  PORTA.DIRCLR = PIN7_bm;     
        
  PORTA.PIN0CTRL = PORT_ISC_INPUT_DISABLE_gc;
  //PORTA.PIN1CTRL = PORT_ISC_INPUT_DISABLE_gc; //neded for LED
  PORTA.PIN2CTRL = PORT_ISC_INPUT_DISABLE_gc;
  PORTA.PIN3CTRL = PORT_ISC_INPUT_DISABLE_gc;
  PORTA.PIN6CTRL = PORT_ISC_INPUT_DISABLE_gc;
  PORTA.PIN7CTRL = PORT_ISC_INPUT_DISABLE_gc;
}

void setup() {
  pinMode(led, OUTPUT);
  digitalWrite(led, LOW);

  ADC0.CTRLA &= ~ADC_ENABLE_bm; 
  RTC_init();
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
  sei();
}

void loop() {
  if (current_sleeps == 0 || current_sleeps == target_sleeps ) {
  
    // main code to run here
      LichtAn();
    // end main code
    
    current_sleeps = 0;
  }
  // Before sleeping
  disableAllPeripherals();
  sleep_cpu();
}

[jvasileff]

Without carefully reviewing your code and the data sheet, I think everything is working correctly. You are expecting the PIT to fire on a 32s cycle, and you are doing 5s of work, leaving the remaining 27s to sleep.

Keep in mind that when you put the mcu to sleep, it will sleep forever unless an interrupt fires to wake it up. This can be the PIT, a pin change interrupt, or many other things. And, the PIT will continue count regardless of the sleep state. Bottom line: the PIT will fire every 32s, and if the mcu happens to be asleep when it fires, it will wake up.

If you want to sleep for a specific amount of time, the only way to do that is to sleep in a loop, and continually check how much time has passed before exiting the loop. With your 32s PIT timer setup, this won't work so well, because, for example, at some point within your loop, if you only need to sleep for another 10s, your only option will be to sleep for (up to) the 32s PIT interval - you may oversleep by 22s. You might be inclined to re-configure the PIT so that it fires exactly when you want to wake up, but due to bugs in the microcontrollers, you probably won't succeed.

So, instead of using the PIT, you may want to look at the RTC.CMP interrupt. I wrote some test code a while ago to do this in a PR - #793 (comment). The code may need some work, but it should help to get you started. Note that the test code assumes you are using the RTC for millis(), so that millis() continues to work even after sleep. (If you don't want to use the RTC for milis(), you'll have to do something like Spence suggested, and update the millis value every time the mcu wakes up, using the RTC to keep track of time slept.)

[tobivan]

I see, thanks. So I will go through your link and see if I can understand it :-)
Boy, I wish could learn what you know, but I even don't know with what to start: learn proper C, or C++? Learn how to manipulate bits and registers....?
Fantastic job, you're doing!