Tiny AVR

We need a small chip with absolutely lowest power, so for the attiny4:

Top of the spec stated 200uA at 1MHz, but nothing about 125KHz.

Bottom of the spec has some chart of around 30uA at 125KHz. Can this be trusted? If so, why don't they say so at the top? I would think that's an important marketing data.

Can it run at 32KHz like some other AVR chips?

Anyone with real experiences? Thanks.

formatting link

Reply to
linnix
Loading thread data ...

one of the first lines say fully static, so I should run at any speed down to zero

-Lasse

Reply to
langwadt

Usually these things are based on estimated characteristics, rather than being thoroughly statistically tested. They will typically pick a few fixed points (such as 1 MHz) and do full testing - lots of chips, lots of temperature ranges, lots of voltage ranges, and running different code - to get a figure they can guarantee. Then they will do spot tests combined with known characteristics to give estimates of the rest.

Are you sure you want to do that? In many cases, you will get lower average power by running fast for a very short time, and spending a larger proportion of the time in deep sleep.

I once made a system using an AVR Tiny (I can't remember which one, but it had no ram at all - it took a little fiddling to get gcc to compile code for it) that ran from the internal RC oscillator, mostly in power-down modes. I estimated that if the button cell that powered it were perfect, I would get a lifetime of around 200 years.

If that's not low enough power, then Atmel have a 4-bit series (MARC4).

Reply to
David Brown

TINY25s will go

Reply to
TTman

One thing is for sure: it won't work reliable at 1.8V.

This seems a better choice:

formatting link

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

ADC, low voltage trigger etc. are all very power hungry..

Yes, I think the best in this category are going to be ROM-based. 8-(

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

We learn our lesson with using uC's near a magnetic mass while the uC is passing through it (moving). Care must be taken in how and where you position them. The little energy that you can endued in the circuit passing through the field (Webers) will actually hit the chip at the correct position one day and cause it to get corrupted. I suppose using Mu metals may help. We just relocated our device..

Jamie

Reply to
Jamie

Can you write something more about it? Is it possible to write in C or C++ and compile with avr-gcc or avr-g++ for AVRs without a RAM-based stack? Are you able to use avr-libc with them?

--
Gof
Reply to
Gof

rote:

+

re

Yes, but you have to run everything in main(), no functions. No g++ or lib at all. You also have to do your own crt.o. That what we are planning anyway.

Reply to
linnix

I've noticed that gcc for AVR is very aggressive about inlining functions, to the point that small-ish ATMega** programs may not actually call functions at all. I help it out with `static inline` declarations, but I only started that after I inspected some code and found out what was happening.

Mel.

Reply to
Mel Wilson

but

le

re

,
I

Yes, definitely inspect the code. I called "_delay_us()". Gcc puts it inline, which is OK. But then it calls mulsf (floating point signed multiple), which is not OK.

59 002e 6D89 ldd r22,Y+21 60 0030 7E89 ldd r23,Y+22 61 0032 8F89 ldd r24,Y+23 62 0034 988D ldd r25,Y+24 63 0036 2BEA ldi r18,lo8(0x402aaaab) 64 0038 3AEA ldi r19,hi8(0x402aaaab) 65 003a 4AE2 ldi r20,hlo8(0x402aaaab) 66 003c 50E4 ldi r21,hhi8(0x402aaaab) 67 003e 0E94 0000 call __mulsf3 68 0042 DC01 movw r26,r24 69 0044 CB01 movw r24,r22 70 0046 898B std Y+17,r24 71 0048 9A8B std Y+18,r25 72 004a AB8B std Y+19,r26 73 004c BC8B std Y+20,r27
Reply to
linnix

Have you followed the precautions in the documentation? You must have optimizations enabled, and the delay must be a compile-time constant. IIRC some other parts of AVR Libc require optimizations to be enabled as well.

-a

Reply to
Anders.Montonen

Does the application allow/tolerate putting the uC to sleep (power down) often? I've played with ATtiny13 and the consumption goes down to less than one uA (I can't even measure it with my 4-digit multimeter on 4mA range setting). You just have to allow some time for it to wake up. The wake-up time shortens significantly if the chip is running on the internal

9.6MHz osc., so if it sleeps most of the time, you may not even need to use the slow clock speeds for the actual work it needs doing. It'll just complete the cycle quicker and go back to sleep.

Without knowing what the application needs to do, it's hard to tell if it's going to work but you can wake it up on external interrupt or internal watchdog timer. Again, the trick would be to make it sleep as much as the application would tolerate.

------------------------------------- /_/ ((@v@)) ():::() VV-VV

Reply to
DA

htm

l

The application needs to monitor sensor pulses that can come in at any time. I don't think we can afford the sleep/wake delay.

Reply to
linnix

The application needs to monitor sensor pulses that can come in at any time. I don't think we can afford the sleep/wake delay.

Easy... put the TINY in sleep mode (1uA) and wake it up on the pulses using PCINT (Pin Change Interrupt, pos or neg edge, or both). Do your processing ASAP then go back to sleep. Simples :)

Reply to
TTman

)

nal

t

ng

But it could miss some pulses while waking-up. We need to count every pulse.

Reply to
linnix

You mean your pulsed _fast_ clocked uC won't react faster that that your wanted LF clocked permanently running at 32KHz?

How fast are those events you want to catch? How many in line, and how fast?

--
Thanks,
Fred.
Reply to
Fred Bartoli

wn)

s
A

he

ernal

to

ust

using

SAP

y

Probably not.

But we can run it in idle mode (with hardware counter running) at

32KHz, perhaps with 2uA.
Reply to
linnix

Hmm, let's see. So what if the call processing for __mulsf3 generated

30 bytes of code here? You're talking about a 500-byte(!) function, which no doubt takes quite a while to run, too --- software floating point usually does. How exactly is it "not OK" to avoid making dozens of copies of a behemoth like that?
Reply to
Hans-Bernhard Bröker

CALL stores the return address onto the stack.

He's using a AVR without any RAM.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.