Tiny AVR

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

-Lasse

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

TINY25s will go

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

This seems a better choice:

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

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

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?

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.

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.

but

le

re

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.

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

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

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

htm

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.

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 :)

nal

ng

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

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?

wn)

he

ernal

to

ust

using

SAP

Probably not.

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

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

CALL stores the return address onto the stack.

He's using a AVR without any RAM.

Simon.