ATMEGA328P timer power consumption question

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

I was reading the datasheet and found something that seems odd.  Section 34.1.3, Supply Current of IO Modules, had the power usage of the various.  Timer 0 us listed as increasing power consumption (vs Idle) by 4.8%.  Timer 1 increases it by 14.5%.  But Timer 2 increases it by 17.8%!  Why the huge consumption by timer 2?  I can see the 16 bit timer consuming more power than the 8 but (though nearly triple seems high, I'd have expected double or so), but Timer 2 is also 8 bit.

 

Anyone know the reason for this?  

 

Anyone have experimental data on this?  A project I'm working on (where power consumption is tight) uses 2 timers.  I had planned to use 0 and 2, since I don't need 16 bits, but perhaps I should use 0 and 1 instead....

This topic has a solution.
Last Edited: Tue. Mar 13, 2018 - 08:54 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why the huge consumption by timer 2?

That's a question for the folks who designed the thing.

 

As a guess, I'd say it likely has to do with the fact that TIMER2 can be used in asynchronous mode, while the other timers cannot.

 

TIMER2 also has its own prescaler, wherease TIMER0 and TIMER1 share a prescaler.

 

The figures in the datasheet may be 'worst-case'.  It's possible, though not at all certain, then TIMER2 would draw less current when run in synchronous mode.  You'd have to do an experiment to determine if this is so.

"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."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"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

Timer2 has additional circuitry to support async mode plus external xtal osc.

building and programming for lowest power can be tricky, some of the freaks have a lot of experience with this.

 

 

Jim

 

Mission: Improving the readiness of hams world wide : flinthillsradioinc.com

Interests: Ham Radio, Solar power, futures & currency trading - whats yours?

 

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

 1. Why two timers?

 You can use just one with an external counter variable if one of the periods is a multiple of another.

 2. Is any of the timers used for periodic wakeups?

 If you sleep in power-save mode then T0 or T1 won't be able to wake you up. In power-down even T2 won't work. WDT is your only option then.

 3. Do you need it periodically?

 Sometimes it's worth going to the deepest sleep and configure an external low-power peripheral as a wakeup source instead of periodically polling it.

 Just general suggestions. Can't tell more not knowing the requirements.

 PM me if you need measurements for different timers and modes.

 


Qoitech AB, The Home of Otii Arc, an SMU for every developer

Check out Otii solution at www.qoitech.com

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

Ah!  The async and separate prescaler makes sense.

 

Why two timers?  Because I have 2 different tasks going simultaneously, at different speeds, with one controlling the other.  The project is an APRS beacon.  See here for more info:

https://www.avrfreaks.net/commen...

 

(note that that's an old version of the code.  It's evolved quite a bit based on suggestions in that thread, for better performance).

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

But usually you'd just run a single timer at the highest common denominator of the two periods. Then (say) you do one job every 7th tick and one every 13th or whatever.

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

One of the timers fires 1200 times per second, picking which frequency to use for the next transmitted bit.  The other timer fires 16 times the frequency, which is either 1200 or 2200 Hz, to feed data to the DAC.  When it's 1200Hz it's firing 19,200 times per second.  When it's 2200Hz, it's firing 35,200 times per second.  The lowest common multiple of that is 211,200.  At 8MHz, that's less than 38 clocks between interrupts.  In which time it needs to do a fair amount of work - determine whether this is a 1/1200 firing to set the next bit or a "regular" firing to feed the DAC, then check which frequency is currently set, then decide if it needs to update it right now, and then update the DAC if necessary.  I don't think I can write code that tight :)

 

So what I have is one timer firing 1200 per second, setting the compare register for the other timer.  That timer trigger either 19200 or 35200 times per second.  Which gives me a worst case 227 clocks to handle the ISR which needs to only do one thing - feed the next value to the DAC.  No decision making at all.

 

The downside is the occasional case where the two timer interrupts "collide".  That'll throw the timing a bit, inducing jitter.  So far, on the scope, it looks really clean with minimal jitter.  Whether that's acceptable or not remains to be seen - I need to code and build the rest of the system and see if the resulting signal is acceptable.

 

The other way to do it is to use a standard DDS algorithm.  That's my backup plan if the jitter proves too much.  But, so far, this approach works.

 

Edit to add: The APRS frequencies, 1200 and 2200, are specifically chosen to not be harmonically related, which is why their lowest common multiple is so high.

Last Edited: Sun. Mar 11, 2018 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another technique is ‘fractional n’. You change the period every tick so it averages out to the divisor you want. Say you wanted a divisor of 13.5. First tick would be 13, second tick 14, third tick 13 and so on. Your sequences can be 2 or more in length. Which is what dds basically achieves.