next topic »

[Reply #15 on:]

60 is not the only thing greater than 59. For example, 61 is. And since you are adding 8 it is more likely you will get from 56 to 64.


I am adding 8s, but taking off 60 will keep the timing in check. If I reset every 60, the timer could be anywhere up to 8 seconds off. Makes sense to me.
Eg:
Seconds = 56,
then the timer overflows, seconds now = 64. Seconds - 60 = 4. Now if I went to 0 on that, what happened to the extra 4 seconds the timer counted??




My point is that after adding 1 to the number of minutes, surely you need to subtract 60 from the number of seconds? Not 59?
True, thanks for correcting me on that. Guess I got messed up on timing in my head . Wasnt exactly having a great day when I wrote it



So the circuit you posted is not the one you are using?

Everything is the exact circuit I am using, but I put the load caps in for my board design, just in case I needed some load caps on the crystal. They are merely placeholders. Sorry for the confusion this might have caused.

[Reply #16 on:]

I don't see any variables being declared as volatile. If an interrupt service routine is going to update variables they should be marked as volatile.

Specifically:
seconds -- TIMER2_OVF_vect
minutes -- TIMER2_OVF_vect
hours -- TIMER2_OVF_vect
show_the_time -- INT0_vect

[Reply #17 on:]

Like this?

Code:

volatile long seconds = 54;
volatile int minutes = 24;
volatile int hours = 3;

So... volatile just means they are handled from RAM instead of being loaded and changed from a memory bank?

Edit: BTW doing this even with the show_the_time variable didn't seem to change anything, still no incrementing.

[Reply #18 on:]

Consider this code which "checks" the value of foo, a global variable that gets updated via ISR

Code:

unsigned int foo = 0;
ISR(blahblah)
{
//update foo here
}

void loop ()
{
 while (foo == 0); /wait for foo to get updated
//do stuff after foo gets updated
}

Your while loop would never exit, because the compiler will read from the register(memory bank) which previously held "latest" value of foo instead of force reading the actual value from RAM.

Check out Nicks awesome page about interrupts: http://www.gammon.com.au/forum/?id=11488

Is there any way you can add in some debugging functions to send some output to the serial port, etc? I think that will be the easiest way to debug whats going on instead of just eye-balling the code and making changes

[Reply #19 on:]

I also didn't see anything referring to #include <interrupts.h> (I didn't need to in my case) nor interrupts() or sei()

[Reply #20 on:]

Ok, will read through the page. Looks very interesting and I am understanding most of what I read so far.

I /can/ create a debug version, sorta. Mainly the only thing I have that does serial is an arduino board (Uno), or my avrisp mkii/UsbASP (which I dont know if it does serial).

I suppose I could just program the board to output serial, and then just connect RX and TX to the respective/opposite (RX to TX, TX to RX, etc) pins on my Uno board? (I assume RX and TX are all thats needed for the serial output?). That shouldnt be hard. If I am right about the serial comms, it shouldnt be hard...

[Reply #21 on:]

Let's get down to basics. You want the timer interrupt to work, right? All the rest is mumbo-jumbo for now. Here is a cut-down sketch:

Code:

#include <avr/sleep.h> //Needed for sleep_mode
#include <avr/power.h> //Needed for powering down perihperals such as the ADC/TWI and Timers

const byte LED = 8;

//The very important 32.686kHz interrupt handler
ISR (TIMER2_OVF_vect)
{
}

//The interrupt occurs when you push the button
void buttonPress (void)
{
}

void setup()
  {                
  pinMode (LED, OUTPUT);  
  digitalWrite (2, HIGH);  // pull-up

  //Power down various bits of hardware to lower power usage  
  set_sleep_mode (SLEEP_MODE_PWR_SAVE);

  //Shut off ADC, TWI, SPI, Timer1

  ADCSRA &= ~ _BV (ADEN);     // Disable ADC
  ACSR = _BV (ACD);           // Disable the analog comparator
  DIDR0 = 0x3F;               // Disable digital input buffers on all ADC0-ADC5 pins
  DIDR1 = _BV (AIN1D) | _BV (AIN0D); //Disable digital input buffer on AIN1/0

  power_twi_disable();
  power_spi_disable();
  power_usart0_disable();
  power_timer1_disable();
  
  //Setup TIMER2
  TCCR2A = 0;
  TCCR2B = _BV (CS22) | _BV (CS21) | _BV (CS20);
  ASSR   = _BV (AS2);         // Enable asynchronous operation
  TIMSK2 = _BV (TOIE2);       // Enable the timer 2 interrupt

  attachInterrupt (0, buttonPress, FALLING);
  }

void loop()
  {
  digitalWrite (LED, LOW);
  sleep_mode();   //  Stop everything and go to sleep. Wake up if the Timer2 buffer overflows or if you hit the button
  digitalWrite (LED, HIGH);  
  }

On my Uno (which has a 16 MHz resonator) this outputs a pulse on pin 8 with a period of 16.327 mS which is what you expect.

Code:

1/16 MHz = period of 62.5 nS
62.5 nS * 1024 * 256 = 16.384 mS

(The figure isn't exact, but the resonator would be off by about 0.2% or so).

The 1024 is the prescaler and the 256 is how many counts the timer does before overflowing.

An LED on pin 8 glows faintly (you could make it brighter by putting a small delay after writing it high.

So I suggest you test that. If you can't get the LED to glow there is something fundamentally wrong with the hardware.

[Reply #22 on:]

For my own interest I wired up a "bare bones" board and uploaded that exact program. It worked!



Note that there was a gap of 8 seconds between pulses.

This is the board:




The current drain during the sleeping part was 21 uA.

You can save a considerable amount of power by turning off brown-out enable. This amended sketch does that:

Code:

#include <avr/sleep.h> //Needed for sleep_mode
#include <avr/power.h> //Needed for powering down perihperals such as the ADC/TWI and Timers

const byte LED = 8;

//The very important 32.686kHz interrupt handler
ISR (TIMER2_OVF_vect)
  {
  }

//The interrupt occurs when you push the button
void buttonPress (void)
  {
  }

void setup()
  {               

  pinMode (LED, OUTPUT); 
  digitalWrite (2, HIGH);  // pull-up

  //Power down various bits of hardware to lower power usage 
  set_sleep_mode (SLEEP_MODE_PWR_SAVE);
  sleep_enable();

  //Shut off ADC, TWI, SPI, Timer1

  ADCSRA &= ~ _BV (ADEN);     // Disable ADC
  ACSR = _BV (ACD);           // Disable the analog comparator
  DIDR0 = 0x3F;               // Disable digital input buffers on all ADC0-ADC5 pins
  DIDR1 = _BV (AIN1D) | _BV (AIN0D); //Disable digital input buffer on AIN1/0

  power_twi_disable();
  power_spi_disable();
  power_usart0_disable();
  power_timer1_disable();
 
  //Setup TIMER2
  TCCR2A = 0;
  TCCR2B = _BV (CS22) | _BV (CS21) | _BV (CS20);
  ASSR   = _BV (AS2);         // Enable asynchronous operation
  TIMSK2 = _BV (TOIE2);       // Enable the timer 2 interrupt

  attachInterrupt (0, buttonPress, FALLING);
  }  // end of setup

void loop()
  {
  digitalWrite (LED, LOW);
  // turn off brown-out enable in software
  MCUCR = _BV (BODS) | _BV (BODSE);  // turn on brown-out enable select
  MCUCR = _BV (BODS);        // this must be done within 4 clock cycles of above
  sleep_cpu ();              // sleep within 3 clock cycles of above
  digitalWrite (LED, HIGH); 
  }  // end of loop

Running that sketch, while the LED was not flashing (ie. during the 8 second interval) it used 1.4 uA of current.

Note that the flash is extremely hard to see. Even with a higher-power LED it is almost invisible. But the logic analyzer detected it.

[Reply #23 on:]

http://www.gammon.com.au/power

[Reply #24 on:]

Further tests show that if you drop the supply voltage to 3.3V (which may be reasonable) you can reduce the sleep power consumption to around 1 uA.

[Reply #25 on:]

Which implies years from a lithium button cell, 10 years at 1uA ~= 87mAh

[Reply #26 on:]

Ok, tested Nicks sketch (Oh, hey nick!!! Love your work, great page on power savings. Muchas Gracias ). Nothing.

I tested a bare bones board as well as an arduino board, and got some pulses on pin 8 (I could very faintly see them on an oscilloscope, and added a delay(100); after the pin high so I could see it on a bare bones. This was all done with a 16mHz crystal, so it IS working.

However, I tried it with 4 different 32.768 crystals from 2 different manufacturers. Nothing, nada, zilch, uno (oh wait, that means one...). Anyways, no overflows, nothing in the oscilloscope. I got *some* results trying to test if the oscillator was running but I heard you cant do it with an oscilloscope very well, and am anyways not sure what the results should be..

So it seems I am the victim of possibly a very bad run of crystals... Or maybe something else is up that wont let the low speed crystals run. Any thoughts? Where do you get your verified crystals from? I prefer digikey (where most of these xtals are from) (digikey ships to me in < 3 days, on the cheapest shipping, yay!), but am open to other suggestions.

[Reply #27 on:]

I can't remember where I got mine (it was a while ago), maybe Element14. You could try a 20 pf cap between each leg and ground, but that's just a guess. I didn't use one as you can see from the photo.

Are you sure you have the processor configured to run off the internal oscillator? It would be slow if it is using the crystal for its processor clock.

[Reply #28 on:]

Sorry i got back late.... nothing. Only keeping clock settings as normal provided blinking... anything with the internal clock just fails on me.... WHY?? really ticked at myself... this is starting to get out of hand...

[Reply #29 on:]

What fuses are you using??