ATMEGA328p Standalone 8MHz @ 2.5v

If you move the Red lead and move it to the other socket far left as Nick pointed out, you'll get a more accurate reading...

(o) (@)- (@)+

^ ^

swap them around.

What model meter do you have? Judging by the manual I found for one of the Radio Shack meters you may have the lead in the right socket, but this is guess-work a bit.

I measured through just a 10k resistor and read 0.46 mA. I'm not sure if that is what you were asking for. How does this measure the accuracy of the meter?

If you connect a 10K resistor to your 2.5V battery, and measure the current, you should get 0.25 mA.

That is: current = voltage / resistance, or 2.5 / 10000, which is 0.00025 A

If you have this model: RadioShack® 29-Range Digital Multimeter Model: 22-813

I found this review:

This meter is just plan bad. I bought it to use with some solar projects. It works ok for things like say measuring a 20V panel but anything else it just seems to not work. I have the same problem of a negative reading on a battery or showing no voltage not matter what setting I try. Doesn't read any small things acurately, was not happy I spend a good chunk of change for something so bad.

By the way, on my own page here:

I have the comment:

(Caveat: under testing I found that it did not seem to work reliably much under 2.8V at 8 MHz).

When testing the power consumption I found it somewhat higher at first, presumably the bootloader was doing stuff. If you are not supplying enough voltage it might be resetting and using more power than you expect.

I've received quite a few responses and I would like to thank everyone for their input. I've come to accept the multimeter I bought is terrible. Thank you RadioShack. I should have realized that if it doesn't cost much, it's probably because it's not worth much. I recommend it to no one.

With that aside, I added the .01uF capacitors between the ground and Vcc pins as close to the chip as possible per dc42's request (and in Nick's page).

Nick, the socket on the right you couldn't read in the picture says V / ohms / mA. However, I moved to the left socket as suggested and I am seeing a reading that jumps between .002 and .003 Amps (2 - 3 mA). That's the highest resolution I can get from the socket. This reading is consistent with what I had from the borrowed (non RadioShack) meter and is also consistent with the ATMEGA328p datasheet as pointed out by user dc42.

Regarding the note on the ATMEGA328p's reliability under 2.8V @ 8MHz, I will keep this in mind. I tested with a 3V CR2032 and saw the roughly the same results for current. I also loaded a sketch to blink pin 13 and I didn't see any inconsistent blinking to indicate it is rebooting. The project this will be used in will run @ 3.3V, I just don't have an unregulated 3.3V power source at the moment.

Overall, I'm quite happy to see the current drop from about 16 mA to just under 3 mA, but I do see a conflict between what the ATMEGA328p datasheet states and what Nick's test is showing me.

I'm curious to see what other people are reading for current.


As dc42 points out, 2.5 mA or so is what the datasheet predicts. So, I'm setting up some new tests ...

Voltage  Clock  Current
         (MHz)   (mA)
  5.0     16*a   16.5
  4.0     16      9.1
  3.3     16      6.7
  3.0     16      6.0
  2.5     16      1.0  did not run

  5.0      8*b   12.3
  4.0      8      5.5
  3.3      8      3.7
  3.0      8      3.3
  2.8      8      3.0
  2.5      8      0.4 did not run

*a Low fuse = 0xFF
*b Low fuse = 0xE2

You can see that the really low current I reported was an anomaly. Although it supposedly runs at 2.5V at 8 MHz in this case it wasn't. I uploaded the Blink sketch to check that the chip was alive, and measured the current during the "off" part of the blink cycle.

The figure above roughly agrees with the datasheet.

So, you might say that your measurements were correct, and my page was wrong. I had better fix it. ;)

I originally had the same issue with 2.5V not running the sketch. I disabled brown-out detection by setting the extended fuse to 0x07 and that fixed it.

So it looks like 2.5 mA is normal for this circuit. That's still much better than 16.5 mA and is going to increase battery life in my project quite a bit.

Looks like I'm going to invest in a better meter. Merry Christmas me!

I was wondering why my chip seemed to be "out of spec" until I realized about the brown-out detection (which you have also commented on). Turning off brown-out detection, I got these figures:

Voltage  Clock  Current
         (MHz)   (mA)
  5.0     16*a   16.5
  4.0     16      9.1
  3.3     16      6.7
  3.0     16      6.0
  2.8     16      5.5
  2.5     16      4.8
  2.4     16      4.6
  2.3     16      4.3
  2.2     16      4.1
  2.1     16      3.8
  2.0     16      did not run

  5.0      8*b   12.3
  4.0      8      5.5
  3.3      8      3.7
  3.0      8      3.3
  2.8      8      3.0
  2.5      8      2.7
  2.4      8      2.5
  2.3      8      2.4
  2.2      8      2.3
  2.1      8      2.1
  2.0      8      2.0

*a Low fuse = 0xFF
*b Low fuse = 0xE2

As you can see, now we can run down to quite low voltages.

Of course, you can save a lot more current by actually sleeping, this is running normally.

I disabled brown-out detection

Generally, three things consume a lot of current:

1) watchdog; 2) BOD; 3) crystal oscillator.

If you want to lower current consumption, that's where you start.

From there, I would deal with unused pins, and any modules that you can turn off.

After that, put the mcu to sleep.

has everyone including nick been ignoring the fact that unconnected inputs can increase current big time? ive seen a 1000:1 variation in consumption when running empty endless loop like used here simply by waving my hand near the chip. internal or external pullups are essential in low current tests like this. and you must remember to disconnect programming leads too before making measurements.

Can you or anyone else post some tests? I can't until I buy a new meter.

I think the unconnected inputs would make a difference, but only once you get into low power modes (ie. sleep). My measurements previously indicated configuring the pins as outputs made a difference, but we are talking around 1 microamp, not milliamps.

A quick test shows that waving the hands over the bare leads (on my bare-bones board) seems to make some minor differences, but the readings weren't steady anyway. Quite possibly because I hadn't grounded the pins.

Another test had all pins set to input with internal pull-ups. That should have been reasonably resistant to noise. However if anything it consumed slightly more (4.82 mA compared to 4.75 mA).

I don't see any evidence of 1000 x more consumption with the pins floating. However once again this was not in sleep mode.

This test (running at 2.5V) consumed 100 nA (0.1 uA):

#include <avr/sleep.h>
void setup() 
  for (int i = 0; i <= A5; i++)
    pinMode (i, OUTPUT);
    digitalWrite (i, LOW);
  // disable ADC
  ADCSRA = 0;  
  // turn off various modules
  PRR = 0xFF; 
  set_sleep_mode (SLEEP_MODE_PWR_DOWN);  
  sleep_cpu ();          

void loop() { }

So, sleep mode is the way to go. :slight_smile:

Setting the pins output and low seemed to rule out having to worry about floating inputs.

[quote author=Nick Gammon link=topic=138473.msg1042891#msg1042891 date=1356307812]My measurements previously indicated configuring the pins as outputs made a difference, but we are talking around 1 microamp, not milliamps. [/quote]

ive seen it range into amps with unconnected pins on at90s1200. the chip not only got too hot to hold but started smoking. rare but ive seen that happen more than once. probably due to lockup or oscillation rather than sitting at threshold but definitely caused by floating pins. modern avrs have improved design to help with this but still not to be ignored. of course we are entitled to our own design practices but imo good idea to be careful when doling out advice to those less experienced.

in virtually all avr docs:

atmel: One of the most important considerations is to ensure a defined level on all I/O pins. A floating pin will give a significant increase in the overall power consumption.

also here:

MarkT: Basically any "standard" CMOS input stage is an inverter and will consume non-trivial power if the input is somewhere in the middle of the range (the "forbidden region"). Here non-trivial means its an issue for battery-powered circuitry in sleep mode - something on the scale of 1mA might flow from that one input circuit when the whole chip is supposed to be shutdown (a few uA usually).

atmel recommends at least activating the built-in pull ups. considering it costs nothing i suggest its good advice.

On my power saving page: Gammon Forum : Electronics : Microprocessors : Power saving techniques for microprocessors

I have this:

  • All pins as outputs, and LOW: 0.35 uA (same as before).
  • All pins as outputs, and HIGH: 1.86 uA.
  • All pins as inputs, and LOW (in other words, internal pull-ups disabled): 0.35 uA (same as before).
  • All pins as inputs, and HIGH (in other words, internal pull-ups enabled): 1.25 uA.

All pins inputs and low is the one case where floating voltages might affect it. My test above had outputs and low, so that should not be susceptible to floating voltages.

Page 43 of the Atmega328P datasheet says:

9.10.6 Port Pins

When entering a sleep mode, all port pins should be configured to use minimum power. The most important is then to ensure that no pins drive resistive loads. In sleep modes where both the I/O clock (clkI/O) and the ADC clock (clkADC) are stopped, the input buffers of the device will be disabled. This ensures that no power is consumed by the input logic when not needed. In some cases, the input logic is needed for detecting wake-up conditions, and it will then be enabled. Refer to the section ”Digital Input Enable and Sleep Modes” on page 79 for details on which pins are enabled. If the input buffer is enabled and the input signal is left floating or have an analog signal level close to VCC/2, the input buffer will use excessive power.

This suggests that the input pins are disabled anyway (especially since I do not have any configured to wake it up).

So it would seem you don't need to obsessively put pull-down (or pull-up) resistors on all unused pins, since in the deep sleep modes the pins will be disabled. And if you had one configured as an interrupt to wake it up, presumably that would not be floating.

However I take it as a good point that in some sleep modes, floating voltages on input pins could well be a bad idea.

id have to agree that disabling input buffers is a better solution for unused pins. that way it dont matter what they might be connected to or what mode the chip is in. out of habit i use the pull ups because not all avrs have that capability and it is a little easier.

btw thanks for directing me to your field programmer project a while back. not so much for the usbasp problem but very useful being able to quickly burn lots of chips w/o having to lug around a pc.

Its probably like my meter, the regular (non shunted) terminal has a max 200ma current measue ability and it works just like that
You could alternatively put a precision 1 or .1ohm resistor in series with the supply and measure the mv across it to get the current

precision 1 or .1ohm resistor

They are tough to find.

Alternatively, you can use a small power resistor (0.1, 0.22, or 0.47ohm, or in parallel), to measure the current. You can calibrate / measure the resistor's value via a constant current source.

Hard part is having a reliable precision device to start with to calibrate thr rest, unless its a precision current source it won't be accurate, unless its a precision resistor it won't be accurate, might as well just buy a better multimeter lol