Deep sleep functionalities in ATTINY 1607 - explanation for wake up cycle using button interrupt - example 😅

[dattasaurabh82]

Hello all.

The task at hand:

1. Detect a button press -> Fire an ISR -> clear the flag
2. Wake up the uC [ ATTINY1607 ] from sleep. (Should happen automatically on interrupt detection)
3. Do some thing for few seconds with one of the following [ delay() over millis() over internal RTC() based timer ]
4. After task completion, go to sleep
5. Save power as much as possible during sleep (like do not keep any unused pins floating etc. Anything more? )
6. Then Step 1

Basically I want to have repetition of :

press button to wake up from deep sleep and do something for some time with as much power saving as possible during the running process phase and sleep mode.

I'm using / kind of have to use PB4 for that button and is initiated in setup() with INPUT_PULLUP
Now there are few ways of doing this and needs to be declared if to be used as interrupt pin.
And moreover, if I'm correct (not sure 😕), for ATTINY 1607, all the pins are asyncronous and can be used for interrupt detection, meaning: they can wake up the uC from sleep mode.

So the ways I have first tried, declaring them as INPUT_PULLUP are:

method 1:

/*
    FOR Low Power ATtiny1607
*/

#include <avr/sleep.h>

volatile byte interrupt1;

ISR(PORTB_PORT_vect) {
  PORTB.INTFLAGS = PORT_INT4_bm;        // Clear PB4 interrupt flag
}

void setup() {
  PORTB.PIN4CTRL = PORT_PULLUPEN_bm;    // Same as pinMode(Button, INPUT_PULLUP);

  Serial.begin(115200);
  delay(10);
  Serial.println("Startup");

  // Don't keep any othe IO floating, init them with internal pullups [ for saving power...]
  // TBD ...

  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
}


void loop() {
  if (interrupt1) {
    interrupt1 = 0;
    Serial.println(F("Woke up"));
  }

  // fake task holding simulation
  delay(5000); // TBD: try other methods like RTC and avoid delay() and millis()

  PORTA.PIN3CTRL = PORT_PULLUPEN_bm | PORT_ISC_LEVEL_gc; // Pullup + Trigger on low level
  // *** Instead of using detect LOW if I use FALLING or other methods, it also doesn't work
  
  Serial.println(F("Sleeping..."));
  Serial.flush(); // flush everything before going to sleep
  delay(10);
  sleep_cpu();

  // Continue after interrupt
  PORTA.PIN3CTRL = PORT_PULLUPEN_bm;                     // Turn off pin sense interrupt
}

method 1 issues:

The awakening of the uC happens only first time button press and then it doesn't work. Basically next time it skips the delay(). also instead of detecting LOW as an interrupt on the button pin, if I use FALLING or other methods, it also doesn't work. What am I missing here? A structured example based on the above would help a lot ☺️

method 2:

#include <avr/sleep.h>

volatile byte interrupt1;

ISR(PORTB_PORT_vect) {
  byte flags = PORTB.INTFLAGS;
  PORTB.INTFLAGS = flags; //clear flags
  interrupt1 = 1;
}

void setup() {
  PORTB.PIN4CTRL = 0b00001001; 
  // ISR will be fired on noticing CHANGE on that pin (other 3 modes don't bring this uC out of sleep mode)

  Serial.begin(115200);
  delay(10);
  Serial.println("Startup");

  // Don't keep any othe IO floating, init them with internal pullups [ for saving power...]
  // TBD ...

  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_enable();
}


void loop() {
  if (interrupt1) {
    interrupt1 = 0;
    Serial.println(F("Woke up"));
  }

  // fake task holding simulation
  delay(5000); // TBD: try other methods like RTC and avoid delay() and millis()
  
  Serial.println(F("Sleeping..."));
  Serial.flush(); // flush everything before going to sleep
  delay(10);
  sleep_cpu();
}

method 2 issues:

This works but I'm not sure why only CHANGE interrupt is usable for waking up the uC and also not sure if there are other better ways of doing so! 😶

Avoiding delay() [ separate from this particular issue ]:

I believe ( amateur in embedded AVR world ), that we should definitely avoid delay() [ also not suitable for my use case] and millis() to save some memory and empty work by CPU. One option is using internal RTC of the ATTINY 1607.
Now I'm no expert and I copied something from hackaday:
//--- uC's internal RTC based interrupt based delay method ---//

void RTC_DELAY_init(int RTCdelay) {
  RTC.CLKSEL = RTC_CLKSEL_INT32K_gc;    // 32.768kHz Internal Crystal Oscillator (INT32K)

  while (RTC.STATUS > 0);               // Wait for all register to be synchronized
  RTC.PER = RTCdelay;                   // Set period for delay
  RTC.INTCTRL |= RTC_OVF_bm;            // Enable overflow Interrupt which will trigger ISR
  RTC.CTRLA = RTC_PRESCALER_DIV32_gc    // 32768 / 32 = 1024 (sec) ~ 1 ms
              | RTC_RTCEN_bm                        // Enable: enabled
              | RTC_RUNSTDBY_bm;                    // Run In Standby: enabled
}

ISR(RTC_CNT_vect) {
  RTC.INTFLAGS = RTC_OVF_bm;            // Clear flag by writing '1':
  showTimePeriodOver = 1;
} 

Then we can use the function RTC_DELAY_init(int RTCdelay) as a replacement for delay() and millis() based custom delay. Basically this promises to offer less to none CPU load and doesn't occupy too much memory (in laymen's terms).
I know that this also triggers an interrupt, which have the potential to bring the uC out of sleep, which is okay for me as I'm only using it while the uC is awake.
Is there a better way? May be an example can help.

Recommendations in general: ( if I may 😅 )

1. Example of Wake up from deep-sleep with pin interrupt across multiple ATTINYs would also be helpful.
2. Some potential examples related to certain topics in one place would helpful in general.
3. Some other place to have discussions on topics would be, as well, helpful as this topic for example is not an issue.

[SpenceKonde]

Only pins 2 and 6 in each port are "fully asynchronous" (as PB2 or PB6 - those would be arduino pins 9 or 5, or PIN_PB2 and PIN_PB6. and able to wake the part from sleep modes where the main clock is turned off. They are marked with a symbol on the pinout charts, and this is described at some length in the page on interrupts and covered "fully" in 16.3.3, (though the identities of the fully async pins is over in note 2 of table 5.1, the most important table in the entire datasheet - like every other part released since the 2016 revolution, including all of the parts supported by megaTinyCore
Like the classic AVRs, the interupt on all pins only works to wake from power down mode on change (the so called Pin Change Interrupt, PCINTs that worked on all pins, in contrast to the INTn type of interrupt available on, usually, 1 or 2 specific pins upon rising, falling,, amd low level a

The usual way that change would be used is exactly the same as it was on classic AVRs, you read the pin immediately after it wakes you, and do your debouncing then. and don't do anything until they let go of the button (the same thing happens if the interrupt is LOW level triggered, by default.) If you play with most consumer electronics, you will find that they work the same way - buttons take effect when you finally let go of them, and if you hold a button down with a rock or something, the battery gets drained significantly faster than if no button was pressed (and this would be the case even if it weren't for the internal pullups,

What it looks like you want instead of delay is a "sleep for X time" type function, which is on the list of features for the sleep library that I haven't gotten to write yet. I realize that there is a huge amount of demand for this, but I've only been on vacation for 2 days, I haven't gotten to it yet and megatinycore is not next in line for major work (sorry guys - ATTinyCore has been waiting longer) for a big update.

On your closing notes 1, 2:
No further work on the old sleep guide is planned pending the new sleep library which will provides wrappers around that sort of functionality including such features as keeping count of millis() while sleeping whilest not sacrificing micros as you do now using RTC for millis. That guide is, as far as I am concerned, just a placeholder until we have a proper wrapper around the full power [or of the sleep modes on these devices.

On point 3:
Is there a reason that Github Discussions is unsuitable for discussing this? A discord

[dattasaurabh82]

Thank you @SpenceKonde for your prompt reply as always.

Starting with point 3, I actually didn't pay close attention that there is a discussion group. No need of discord. It works just fine here 🤗

Can't wait for the sleep wrapper and the good work. Please take your time.

I see your logic now. I will try tomorrow or day after (after work as soon as possible) and post the outcomes here. 😁

[SpenceKonde]

And sorry that got cut off, I was saying a discord had been discussaed, but I didn't think it was a priority what with usnow having this.

[dattasaurabh82]

Yeah agree