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.
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).
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...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
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
Embedded software/hardware/analog Info for designers: http://www.speff.com
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..
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?
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.
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.
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.
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 :)
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?
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.