Keeping a relatively large running average with arrays?

[s_mack]

Each time my code runs, I get a value for x. I want to keep track of a history of x. I'm assuming this is best done in an array.

[PCM programmer]

You don't have to physically shift the contents of the array each time.
Just increment an index. See this post for examples:
http://www.ccsinfo.com/forum/viewtopic.php?t=3462&start=1
These two routines implement a running median filter and a
running average filter.

[asmboy]

int8's is very ez and needs no push down ever - BUT you must insure that you have at least 100 data items or more

[s_mack]

I guess there's no magical way of not taking the RAM hit is there?

My RAM just jumped from 48 to 60 % to 70 to 82% and I need the space!

Ouch.

[asmboy]

U R not using 18F parts then - right ?

U never did say

if in 16F 28 /40 pin land -- there is almost sure to be an 18F
equivalent part with lots more RAM

$$ will fix the problem

[s_mack]

18F4480

[asmboy]

18f4580

double your code space double your user ram

same hardware

close enuf?

[s_mack]

Yes, it would have been. But that's not what is in our devices

You advice is good, but its a "woulda, shoulda, coulda.... didn't" kind of situation. I'm trying to make our device do more than it was originally designed to do with software upgrades alone. If I can, then great. If I can't then it still does what it was designed to do very well.

Thanks for your help. It fits as-is and works. I just have 2 or 3 more features to add that are a higher priority and I'm pretty sure they won't all fit.

Can I use the EEPROM instead of an array I wonder? Then all I need is a temp variable and a sum variable. Hmm....

[s_mack]

Ok, someone stop me here before I waste too much time on this

How fast is an eeprom read? Thanks to the nature of the program and the fact there is an interrupt for writing I suppose I don't care how long a write takes (within reason) but I need some assurance that a read happens reliably fast.

Is there a "lifespan" to eeprom? Am I just going to burn out the chip by reading and writing to it constantly?

If not... I figure I can use 100 locations of eeprom each storing the initial values of the 100 aforementioned elements. Once the 100th spot is taken, the first is replaced and a "ticker" variable increments thereby keeping track of the new "first" spot. My sum variable just needs to know the value of the kicked out value (1 eeprom read) and the value of the new one that replaced it (1 eeprom write) to make the average calculations.

If this can be done practically, then instead of 100 int8 variables taking up RAM I just have 3 int8s (ticker, addvar, subvar) in addition to the 1 int16 (running total) I would need anyway. That seems to be a whole lot of savings in RAM. But at the obvious (and perhaps ludicrous) expense of (much?) slower eeprom read/writes.

And if there is a finite number of times that the EEPROM can be accessed then this obviously isn't the way to go.

[asmboy]

yes writing constantly to eeprom will eventually FAIL
and it will slow down execution too - whether internal or external

you could make the running average array smaller as one way to save ram tho making the code to handle it smaller is not so EZ since there is not much of it 2 start with

an array of 50 vals would return 50 bytes of ram for other stuff but thats about it short of changing pics OR a rigorous analysis ( profiling) of the
.LST file you have now to see where all the weight is

if you can dispense with FLOATS - that usually unbloats code and being parsimonius with printf and other such code hog calls is another way to cut down program size

check your LST to c what can be done

[s_mack]

Thanks.

Getting rid of floats is what brought me here

I replaced all my float code with fixed, at the inevitable expense of precision. That precision has led to an oscillation that is undesirable. We determined that taking a running average of the last 100 data points eliminates the oscillation without introducing too much retardation. Significantly less than 100 doesn't do much.

But using 100 is slightly worse for the code then using floats was so in the end I'm not better off.

I'll try some other low-cost (code, not $$) methods for reducing the oscillation and if that's a no-go then I'll just go back to floats and eliminate the extra features we were hoping to introduce.

Thanks for the suggestion and help, and for confirmation that using eeprom wasn't a good way to go. It worked, by the way It wasn't as slow as I thought it might be. But yeah, I don't want to be burning out chips doing this. Plus it wasn't 100% reliable - about 0.5% of the data reads were lost. Thanks to the averaging that isn't really an issue. Interesting exercise anyway!

[Ttelmah]

The alternative it might be worth considering, is external FRAM. Basically instantaneous reads/writes (timing is limited only by the speed you can transfer the data to/from the chip, up to SPI rates as high as 25MHz). Using the SPI versions, on a 40MHz PIC, you can transfer a byte in under 1uSec....

Best Wishes

[Ken Johnson]

Look at my post next to the bottom of this thread:

http://www.ccsinfo.com/forum/viewtopic.php?t=19509&highlight=

Mebbe this'll help ?

Ken

[RLScott]

s_mack,

The kind of running average you are describing is sometimes called a "box car average" because the graph of which points are included looks like a box car. There is another kind of running average that takes much less RAM, and that is an exponential decay average. That is like what you would get if you filtered your values with a very long time-constant RC filter. This can be implemented by the recursive formula: