ATTINY10 sleep mode

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm need help with ATtiny10 sleep mode, to be more specific with wake up vector. I can put it in to the sleep, but I can't

wake it up, because interrupts are disabled, but if I enabled interrupts ATtiny10 goes in sleep mode and wake up one second later.

Code below works fine (with only sleep mode) when I don't use PWM, with PWM does not work, I presume that INT0 is triggered by

PWM routine, instead of button).

 

#define F_CPU 1000000UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <avr/sleep.h>

#define LED_ON PORTB |= (1<<PORTB0)
#define  LED_OFF PORTB &= ~(1<<PORTB0)
#define  LED_TOGGLE PINB|=(1<<PINB0)

uint16_t duty;
uint8_t mode = 1;

void PWM_init (void);
void goToSleep ();
uint16_t mode1(uint16_t duty_value);
uint8_t i = 0;             

int main(void)
{

	DDRB |=(1<<DDB0); 

	DDRB &= ~(1<<DDB2);
	PUEB |=(1<<DDB2);
	PUEB |=(1<<DDB1); 

	sei(); 

	PWM_init();
	duty = OCR0B;

	while (1)
	{

		if (mode == 1)
		{
	       mode1(duty);
		}	

		if (!(PINB & (1<<PINB2)))
		{
			i=0;
			while( !(PINB & (1<<PINB2)))
			{
				i++;
				_delay_ms(500);
				if (i > 3)
				{
				cli();
				LED_OFF;
				_delay_ms(2000);
			//	sei(); ///////???????????????
				goToSleep();
				}
			}
		}

		OCR0B = duty;
	}
}

uint16_t mode1(uint16_t duty_value)
{
	if (duty < 800)
	{
		duty++;
	}
	else
	{
		duty = 0;
	}
	_delay_ms(2);
	return duty;
}

void PWM_init (void)
{
	TCCR0B |= (1<<CS00) | (1<<WGM02);
	TIMSK0 |= (1<<OCIE0A) | (1<<OCIE0B);
	OCR0A = 800;
}

void goToSleep ()
{
	EICRA = _BV(ISC00);
	EIMSK = _BV(INT0);
    ADCSRA &= ~_BV(ADEN);
	set_sleep_mode(SLEEP_MODE_PWR_DOWN);

	sleep_enable();
	sleep_cpu();
	sleep_disable();
}

ISR(PCINT0_vect)
{
	EIMSK = 0;
}

ISR(TIM0_COMPA_vect)
{
	LED_ON;
}

ISR(TIM0_COMPB_vect)
{
	LED_OFF;
}

Tnks in advance

This topic has a solution.
Last Edited: Sun. Feb 18, 2018 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gpugelni wrote:
if I enabled interrupts ATtiny10 goes in sleep mode and wake up one second later

That is "interesting", as the timers should be stopped if you are actually in power-down sleep.  If you put a trap into your ISRs, which is firing for the "one second wakeup"? 

gpugelni wrote:
EICRA = _BV(ISC00);
That selects "any change", but power-down only awakens with low-level.  [I'd suggest pin change]  Watchdog timer enabled with fuse?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fuse settings are default (factory). I need PB0(OC0A) i PB1(OC0B) for PWM, PB3 N/C and PB2(INT0) is used for button.

I'm also try to use _BV(ISC01); ,nothing, ATtiny goes in to sleep mode and wake up with interrupts enabled.

theusch wrote:
If you put a trap into your ISRs, which is firing for the "one second wakeup"?

How to do that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gpugelni wrote:
How to do that?

have each ISR light a distinct LED?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
have each ISR light a distinct LED?

No. And I also don't have a debugger (like Atmel-ICE) for troubleshoting.

Last Edited: Wed. Feb 14, 2018 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

have each ISR light a distinct LED?

 

gpugelni wrote:
No.

Why not?

 

 

And I also don't have a debugger for troubleshoting.

So how were you intending to trouble-shoot, then ... ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
So how were you intending to trouble-shoot, then ... ?

unfortunately by trial and error method...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

surely, LEDs are a key tool in that process, then?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tiny10 and friends have no OCD.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so LEDs it is, then ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Tiny10 and friends have no OCD.

Obsessive-Compulsive Disorder?  I resemble that remark.

 

Unfortunately, no EEPROM either.  What I'll do sometimes in apps is have significant events "logged" to EEPROM, then read back with ISP and decode.

 

I haven't worked with the Tiny10 family or other brain-dead models.  Datasheet examination makes it seem to me that sleep and wakeup should work pretty much like typical AVR8 models. 

 

So I'm confused about why OP's setup "doesn't work".  We may well need to hear more about that.  Both ISRs will fire continually in rapid succession while INT0 is low, right?  Hmmm--maybe the time...  I SEE THE PROBLEM! http://sethf.com/freespeech/memo...

 

First scan of the code, I saw

gpugelni wrote:
ISR(PCINT0_vect)
and assumed "pin change".  Further looking showed low-level INT0.

 

Wrong vector, so app restarts whenever the enabled interrupt hits, right?

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I SEE THE PROBLEM!

Wrong vector, so app restarts whenever the enabled interrupt hits, right?

Yup.  Good catch.

 

so LEDs it is, then ...

Challenging on a device with only three I/O pins.  Although, the OP is only using two at the moment, so the third could become a diagnostic LED.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm finally find out how to put ATTiny10 in to sleep...    I SEE THE PROBLEM! http://sethf.com/freespeech/memo...  laugh

 

theusch wrote:
Wrong vector, so app restarts whenever the enabled interrupt hits, right?

 

Close but not relay, this vector must be used because ATTiny10 have only INT0 interrupt vector.

The problem was in INT0 interrupt registers, which must be set up like this:

 

void goToSleep ()
{
	EICRA = _BV(ISC01);
	//EIMSK = _BV(PCINT2); left by error not needed
	PCICR |= (1<<PCIE0);
	PCMSK = 0x00;
        PCMSK |= (1<<PCINT2);   

	set_sleep_mode(SLEEP_MODE_PWR_DOWN);
	sleep_enable();
	sei();
	sleep_cpu();
	sleep_disable();
}

ISR(PCINT0_vect)
{
	PCMSK &= ~(1<<PCINT2);
}

 

theusch wrote:
I haven't worked with the Tiny10 family or other brain-dead models.

Me neither, but the clients just screams for savings smiley

Last Edited: Sun. Feb 18, 2018 - 09:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Close but not relay

Exactly, actually.

 

In your code in #1, you enabled the interrupt source for INT0, but didn't provide an ISR for INT0_vect (You instead provided an ISR for PCINT0_vect, but since you didn't enable the interrupt source for PCINT0, it will never be reached).

 

As a result, AVR GCC's default 'unhandled interrupt' mechanism caused a restart of your app every time an INT0 interrupt event occurred.

 

In your 'fix' in #13, you've avoided enabling the interrupt source for INT0, and managed to enable the the interrupt source for PCINT0, which matches the already-present ISR for PCINT0_vect.

 

But your code is a bit of a mess.  For instance, you've partially configured the INT0 interrupt source by writing to EICRA, and you've written a reserved (i.e. invalid) value to EIMSK.  There >>is<< no bit named PCINT2 in EIMSK.  The only bit present is INT0.  It's just dumb luck that your code works now.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

If my code is mess so please write your code which work like my right now or better.

Last Edited: Sun. Feb 18, 2018 - 08:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK gents... time out needed before tempers get inflamed and I have to start swinging the big stick.

Ross McKenzie ValuSoft Melbourne Australia

Topic locked