Tiny AVR

Calls on those AVR's store the return address in a small dedicated hardware stack, so you /can/ use them. But it is very limited in depth, and you can't have stack frames in functions. So you definitely don't want to have floating point there!

However, if you generate floating point calls here it's only because you've misunderstood your library, your tools, or your own code. Make your delays compile-time constants and ensure that you are not crippling the compiler by not enabling optimisation, and you should be fine.

Atmel provides formulas for calculating the time it will take it to resume processing based on power-down or power-save and the clock source. It's something like 20 clocks + 4ms or 20 clocks + 64ms (if you can't trust your power source to stabilise quickly). You get to pick 4 or 64ms delay. Sounds like you would want 4ms. You can even further reduce that to just

20 clocks (or approx 60us, says Atmel) if you enable brown-out detection (BOD) but that will increase power consumption in sleep mode. I don't know how much - didn't get to play with it yet. So, it looks like you get a choice of waking up time from 60us to 4.06ms based on power consumption you can afford.

You will just have to quantify the input and, really, there's no way around it anyhow - you do need to know how fast the pulses you're counting are arriving. What if they arriving too fast for the MCU to count anyway? If all you're doing is incrementing a counter, you may be talking about microseconds between interrupts. Maybe you can make it stay awake for a millisecond to catch fast-coming bursts of inputs, then put it to sleep when things quieted down for, say, longer than 1ms. Sort of like switch de-bounce?

What type of sensor is this, anyhow?

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

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

Is the pulse going at >1MHz??

.

Probably not.

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

32KHz, perhaps with 2uA.

But you can run at 9.6MHz in sleep @1uA and capture a 1KHz signal, do some processing and go back to sleep and be at 2uA average... If you can capture it at 32KHz ck, then where's the problem? Use the int RC osc and divide by 8 and you're even better off

y e w g

It's a variable speed rotational sensor, close to 50% duty cycle. This is the little brother watching the sensor and waking up the big brother if necessary. So, at long as we can keep the hardware counter on and processor idle at 1uA or 2uA. We should be OK. Pulse processing at higher clock speed might work, but not necessary better power savings.

Variable reluctance rotational speed sensor? What RPMs are expected?

I'm just curious: couldn't you harvest some power from its output, trickle-charge a big cap (supercap?) and only put the MCU to sleep when the RPMs are too low to charge the cap and don't require fast processing anyway?

I actually don't even know if they make digital VRSes - you were talking about *pulses* and this might only work with an analog output one.

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

It won't miss anything.

--
We have failed to address the fundamental truth that endless growth is  
impossible in a finite world.

Variable magnetic rotational sensor. Perhaps 100s Hz.

Actually, we need to provide some power to the sensor. Can't pull much power out of the output.

maybe he is trying to digitally maintain the position information of a device that has a A+B channel generating device on it.

Jamie

See for example page 9 of ATtiny15 datasheet:

--
Gof

How did you declare them? Using _MMIO_BYTE() from avr/sfr_defs.h (or similar alternative) to directly point to the register file, or maybe using "register" keyword?

--
Gof

The "register" keyword on its own has had no function in most compilers from the last decade - it is merely a hint to the compiler, and compilers ignore it.

For the two or three global variables I needed, I used "register asm" variables that dedicate a specific register to the variable, as in:

register uint8_t counter asm("r2");

Other than that, local variables are the key - avoid globals or static variables. When necessary, it's okay to pass the data to functions view pointers, as long as that function will end up inlined, which helps avoid having a single huge "main" function in the source code.

One thing that I didn't try, but which might have been interesting for the source code structure, is that gcc supports nested functions which can access the variables in the surrounding function (it has this support because gcc compiles many languages, include Pascal which requires this feature).

If you really want to, you can use the registers as ram too - and use the Z register to point to them for indirect addressing.

does he sensor generate power or consume it? is there enough innertia to switch modes during spin-up?

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net

r

We probably need two sensors. A passive triggering sensor (very little current) to signal the controller and to turn on the measuring sensor (several mA).