EEPROM / MIAC PIC

[gavo4]

Hi Leigh,

Hope all is well!,

I have my pulse meter working nicely, just the EEPROM side which is not working properly.

I am aware that we can only save 0-255 Decimal which becomes an issue if I am going to count pulses into the thousands and I also tried my EEPROM routine I used on the dspMIAC but I can't see any data saved. Do you have any ideas on how we can do this?, I have attached my code

I also assume each time I start the routine I should first read the EEPROM as I need to keep my calculations "live" and add the pulses when the unit is off, so it also has a reference point on where to start count from

Regards,

Gavin

[gavo4]

Hi Leigh,

I got it working - silly mistake,

Do you have a suggestion on how to keel the calculation "live"?,

Regards,

Gavin

[gavo4]

Hi Leigh,

I have written it in another way, only problem I can read the Saved Data after the unit is switch off but I can't seem to transfer it to Water Count side so it can start where the unit left off,

Any ideas perhaps?..

Regards,

Gavin

[mnf]

Hi Gavin,

You are currently writing String_Pulse to the eeprom (a string representation of a float) - this is overwritten in Total (converted from .w_pulse = count/2.0). You probably need to save the value of 'count' and at the start of main (power on) read this value back into count (it's a Long - so will take 4 bytes of eeprom)

It is typical practice to save a 'marker' byte - to notify the program that the memory locations contain a valid value (this prevents the program reading a 'random' value on first start). So, as one route, save 'Marker' at idx and then count at idx+1 to idx+4. (You'll need to write count >> 24, count >> 16 etc or write count & 255 then count = count >> 8 x 4 (big endian/little endian - it doesn't really matter which you use - it just affects the way you read back the number)

Note that one drawback with this is that if the power is cut part way through writing the value then the value stored may be incorrect - so clear the marker byte until after a successful write.

Another possible snag is that eeprom has a limited number of write cycles - which if your program is writing to it repeatedly can get used up surprisingly soon - in an ideal world you could write the data to a different location on each cycle - but this makes the coding more complicated. With values that don't change frequently read the eeprom value and only write if the new value it is different.

Martin

[gavo4]

Hi Martin,

My apologies for the delay

Thanks for this, makes 100% sense,

Do you short example?,

Regards,

Gavin

[mnf]

Attached is an example...

It saves a count (here just an incremented variable) to EEPROM - using 80 bytes to spread the values over (16 possible locations for a marker byte + 4 byte value)
The value is displayed to an i2c display and on restart it just carries on from where it left off.

It's not completely foolproof - and the value is saved before the 1s delay - so by hitting reset rapidly it is possible to make it count quicker. It shows the basic principles though - search for a marker byte indicating a valid value (marker is written after data - so should always be valid)

If power out occurs mid write - the previous marked value should be read.

Values are spread over a range of memory locations - spreading the wear (- I used an Arduino - so I could have allowed more values and used more of the 1024 byte EEPROM - adjust the constant MAXVALS to use more or less memory)

EEPROM is only written if the data has changed (this means here that the 5th byte of every data group changes and is written the most - other load balancing schemes are available)

restart.fcfx

(17.93 KiB) Downloaded 309 times

Hope that is helpful.
Martin

[gavo4]

Thanks Martin,

You are a champion!