Very long sleep possible?

[cpainchaud]

Hi,

So I went through sleep modes pages and code examples but I feel like I am missing a piece to make the device sleep for long time (like 1+ hours). Using the 1K clock and biggest period RTC_PERIOD_CYC32768_gc , I can achieve like 32second maximum.

What is the obvious thing I am currently missing ?

thank you !

[freemovers]

Did you change the prescaler as well? Maximum prescaler is RTC_PRESCALER_DIV32768_gc, but looks like yours is set to RTC_PRESCALER_DIV1_gc.

[grandaspanna]

Have a look at the code I posted the other day in another discussion in this repository. In standby mode, using the RTC interrupt, I was measuring single digit microamps so you can use the RTC in that mode. By setting the prescaler and appropriate target, the datasheet says you can get to 18 hours. If you have to use the PIT, then maybe just keep a counter and increment it each time the interrupt is generated if the interval is too short. You can scale up as big as you want this way. It means a short piece of code running each interrupt which will raise power consumption (someone posted that they got overall lower power usage with a higher clock rate because it reduced the runtime of the code, but YMMV).

[cpainchaud]

thank @grandaspanna I came to the same conlusion!

[amadeuspzs]

@grandaspanna do you have an example of how to implement:

If you have to use the PIT, then maybe just keep a counter and increment it each time the interrupt is generated if the interval is too short.

?

I have the PIT setup to wake every 8s, and want to set a total sleep in increments of this:

volatile int sleeps = 0; // how many sleeps, used in conjuction with:
int TRANSMITPERIOD = 16; //transmit a packet to gateway so often (in s), factor of 8

ISR(RTC_PIT_vect)
{
  sleeps += 1; // will this work as PIT is a reset, ie it will lose state?!
  RTC.PITINTFLAGS = RTC_PI_bm;          /* Clear interrupt flag by writing '1' (required) */
}

void loop() {
  if (sleeps == 0 || sleeps >= (TRANSMITPERIOD / 8) ) {
    // transmit here
  }
  sleep_cpu();
}

The PIT interrupt triggers a reset, so the sleep variable will lose it's value?

Currently, it's just waking up every 8 seconds?

I'd like to get to 10 minute wake up cycles ultimately (8s is just for testing!).

[grandaspanna]

I wouldn't have thought that the wakeup was generating a reset - well, that's not what I'd expect.

What does your RTC setup look like?

[amadeuspzs]

You are correct; I was confusing the wakeup behaviour with the ESP8266 which is a reset.

It's all working nicely: https://github.com/amadeuspzs/attiny1614-rtc/blob/main/attiny1614-rtc-blink-long-sleep/attiny1614-rtc-blink-long-sleep.ino

Thanks for the help!

[SpenceKonde]

Thanks for the code examples. A future version of the core which addresses the longstanding issue #158 will add a library tentatively called SleepLib. which would have the following features:

• Switch to RTC millis and sleep. If woken by the RTC overflow interrupt, adjust current millis count and go back to sleep. If woken for other reasons, adjust millis based on current RTC count, stop the RTC, and switch back to the normal millis timer and resume user code
• Switch to RTC millis. Wake every after a configurable period of time and switch back to a HF timer.
• Handle the incredibly nasty errata on most 0/1-series relating to the RTC. This bug is described in the errata as if it were a ladybug, when it';s closer to that bad guy in Men in Black, and more confusing too. Also the only errata on modern AVRs that will be impossible to fix without infuriating some people, because there is a way to exploit it to get otherwise impossible functionality.
• (maybe) An option to wake every (period of time) call a user defined function, and then go back to sleep (to make dataloggers supereasy). Same RTC treatment as above.
• (maybe) debug option: Count number of times there is a wake determined to be just related to RTC which never runs user code, and number of times there's a wake that runs user code.
• .(hopefully) if library is included, find way to warn people or throw an error if they have left in something that goes to sleep while bypassing the new methods (ie, ensure that sleep_cpu() at minimum gives a warning, and preferably won't compile.
• (tentative due to hardware bugs) Try to make USART SOF interrupt work (may be extremely challenging, see errata)
• Use Standby sleep so that user can choose to leave whichever peripherals they desire on to wake with, (in stark contrast with classic AVRs where standby sleep barely saves any power whatsoever, if you don't have anything's RUNSTBY bit set, the power consumption on tinyAVR is supposed to be the same as power down! This may only be the case on tinyAVR - in which case the Dx and such wuiold need a way to use powerdown.
• Add a more convenient facility to disable digital input buffers in order to save power - it is widely known that despite insistance to the contrary from some corners, floating pins are power hogs on modern AVRs.. (Better power saving docs #695 )
• Support all modern AVRs with a single library.

[SpenceKonde]

What the heck is this sorcery? I got an email about a reply here, with a screenshot of a figure from the datasheet that I'm kind of confused by. The words in the datasheet imply that the prescaled clock is what gets counted by the PIT, but I'm not sure how that timing diagram doesn't show the opposite, which would make it inaccurate.

Example 23-1. PIT Timing Diagram for PERIOD = CYC16

This diagram unambiguously shows the prescaled clock going to the PIT

Figure 23-2. Timing Between PIT Enable and First Interrupt

But this one says that the PIT that the PIT is derived from the state of the RTC prescaler, not something attached

Do note also that the ATtiny 0-series and 1-series (except with rev C 1-series parts with 32k of flash), have some very mean chameleon hornets nesting behind the CTRLA registers, try to avoid using impacted parts if you need the RTC, and if you must, you must never turn on the RTC without also turning on the PIT before any further interaction with the peripheral. As long as you do that, you'll be fine, as long as you don't touch RTC.CTRLA. If you do, the hornets still get one chance to sting you every time you write to it, resetting the current RTC period.

When they finally fix that, it's gonna be a fuckin shitshow. I guarantee you there will be multiple instances of devices in mass production that didn't realize that was a bug, or even that something else wasn't resetting it (nothing is supposed to short of a reset or turning off the PIT), or completely misapprehended how the PIT works (I went back and forth with someone for days before it was made plain that they expected to be able to set the delay, go to sleep, and have the pit wake them that many second later. Uh, sorry, nope, not on the menu, not on those parts or any other AVRs. You can have the RTC wake you like that, but he wanted to use power down sleep mode.

Thinking about it - it has to be that he didn't know that the only thing about standby sleep unchanged since classic AVRs is the name - it used to be something a little lower power than IDLE, but only a little, because the main power hog at that point is the oscillator - which it explicitly keeps on to eliminate the startup time of an external crystal; that was it's only purpose. Now it's an omnibus deeper-than-idle-less-deep-than-power-down mode, which can be tuned to anything from being lit up like a christmas tree, sucking down near-IDLE current, or you can leave everything off and it's nearly identical to power-down.