Searching \ for 'Retaining User Settings In EEPROM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=eeprom
Search entire site for: 'Retaining User Settings In EEPROM'.

Truncated match.
PICList Thread
'Retaining User Settings In EEPROM'
1999\09\12@181018 by David J Binnington

flavicon
face
Hi everybody,

As a Micro/PIC newbie (and EEPROM useage in particular) I would be grateful
if someone could point me in the right direction.

My current project will eventually use a 16F874 @ 16MHz (if and when
available!).  I am using the EEPROM to retain user settings after power down
(universal AC supply powered equipment).  Currently this only requires 6
bytes, of which 2 are used for status and 4 are absolute values, but this
may well increase.  All user inputs are by button presses with auto-repeat
on some.  Retaining the settings is more a user convenience rather than a
vital requirement but once implemented it really needs to be reliable.
Typical useage of the equipment is to power up two to ten times per day but
it could be a lot more.

The code I am using on the prototype is fairly simplistic in that during
initialisation a check is made to see if each of the absolute values is
within a valid working range.  If all are OK then the EEPROM copy is assumed
to be correct and so is copied over to the working registers.  If not OK
then 'safe' default values are used instead.  No other checks are used at
the moment.

A routine is called once per main program loop (8-10mS) to check if each of
the working registers matches the appropriate EEPROM location and if not
they are written back to EEPROM once per loop (if a previous write has
finished).

Precautions have been taken to prevent too many writes to the EEPROM such as
waiting for key repeats to end etc.  I have also implemented a system to
even out the 'useage' on the EEPROM whereby the location of the 6 bytes is
incremented after each power up. (the location of the first byte in the
block is stored in a fixed location).

This system seems to work OK but I am not convinced that it is secure
enough, particularly during noisy power ups and power downs.  There is also
a finite time between the user changing the settings and the EEPROM being
updated, as well as the additional time required for a previous write to
finish.  This is particularly the case when the user input affects more than
one byte.

Does such a simple system sound reasonable?  Since my requirement would seem
to be a fairly common one, are there any 'standard' ways of implementing
such a scheme reliably without requiring extensive code and cycles?  Call it
a challenge if you like!

Sorry for the length of this post.

TIA

David

1999\09\12@185623 by Mike Keitz

picon face
On Sun, 12 Sep 1999 23:09:19 +0100 David J Binnington
<spam_OUTdavidTakeThisOuTspamDJBELECT.KEME.CO.UK> writes:

>All user inputs are by button presses with
> auto-repeat on some.

Write the new values when the user releases the button.  This prevents
constant writes because of autorepeating but also has an immediate
update.  Unless you're storing data for more than one button in an EEPROM
byte the buttons should wear out before the EEPROM will.

I like to always get working data from the EEPROM right when needed.
That way there's no need to copy the EEPROM to RAM on power-up or deal
with a possible discrepancy between the two.  But it may be a problem
with your scheme if the user is expecting to be working with a "live"
value while updating.  If you don't write to the EEPROM until after the
button is released, any program running in the background would use the
old values.  Also the EEPROM is unavailable for reading during a write.

It is more likely for a glitch to upset a RAM value than EEPROM.  So your
scheme of writing RAM values to EEPROM whenever they differ is going to
be kind of susceptible.  I'd have the EEPROM writing routine only run if
the user is pressing buttons to change the settings.
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\09\13@180120 by David J Binnington

flavicon
face
Mike Keitz wrote:

> Write the new values when the user releases the button.  This prevents
> constant writes because of autorepeating but also has an immediate
> update.  Unless you're storing data for more than one button in an EEPROM
> byte the buttons should wear out before the EEPROM will.
>
> I like to always get working data from the EEPROM right when needed.
> That way there's no need to copy the EEPROM to RAM on power-up or deal
> with a possible discrepancy between the two.  But it may be a problem
> with your scheme if the user is expecting to be working with a "live"
> value while updating.  If you don't write to the EEPROM until after the
> button is released, any program running in the background would use the
> old values.  Also the EEPROM is unavailable for reading during a write.
>
> It is more likely for a glitch to upset a RAM value than EEPROM.  So your
> scheme of writing RAM values to EEPROM whenever they differ is going to
> be kind of susceptible.  I'd have the EEPROM writing routine only run if
> the user is pressing buttons to change the settings.

Thanks for the useful input Mike.

Looks like I need to integrate the EEPROM routines more fully into the key
reading routine.

I thought I had already taken care of the auto-repeat problem by using
'working' registers which are then copied to EEPROM after the user has
finished updating the values.  I was obviously worried about the time lag
and possible corruption using this method, hence my original question.

The values are live in that they are needed to be used by other routines and
are also shown on a display.  Because of the relatively long write time of
the EEPROM I cannot see an easy way to work directly with values stored in
EEPROM.  Am I missing something fundamental?


David

1999\09\13@193815 by Peter van Hoof

flavicon
face
If the user changes values and within a second or so the power fails the
actual change might not be relevant or even safe to use on restart of your
application, a good reason to wait till the last value has been stable for
seconds before copying from ram working values to eeprom.

If you do not trust the written values are finished being written to eeprom
use two copies , alternating between them and make your last write operation
the bit that determines which of the two copies is current.

as a last safeguard a simple checksum byte should do.

Peter van Hoof
-------------

{Quote hidden}

1999\09\14@021738 by root

flavicon
face
Mchip says 100 as minimum, 1000 as tipical. No maximum specified.
I hope this helps.

Imre

PS: Mchip has some article about EEPROM endurance. I think this applies
also for program memories.


On Mon, 13 Sep 1999, Ajay Nagarkar wrote:

{Quote hidden}

1999\09\14@192757 by Thomas Brandon

flavicon
picon face
What about the 16C77x's with the ability to rewrite program memory from
code? Do they have more enduring EEPROM for both program and data memory?

Tom.
{Original Message removed}

1999\09\15@135145 by paulb

flavicon
face
David J Binnington wrote:

> I thought I had already taken care of the auto-repeat problem by using
> 'working' registers which are then copied to EEPROM after the user has
> finished updating the values.  I was obviously worried about the time
> lag and possible corruption using this method, hence my original
> question.

 I'd have thought the trick was to update values five seconds after
last keypress, only if they'd been changed.  Unless you expect power
shutdown during that time.

> The values are live in that they are needed to be used by other
> routines and are also shown on a display.  Because of the relatively
> long write time of the EEPROM I cannot see an easy way to work
> directly with values stored in EEPROM.  Am I missing something
> fundamental?

 Well, actually, the write time is negligible compared to the speed of
keying, i.e., it is less than a key debounce time, so that's not a
problem.  Also, remember that EEPROM *read* is still full-speed (unless
you're writing a value at the time, but this harks back to the relative
speed of key entry).

 All-in all, it is neatest if you need the device to operate during key
entry, to cache all parameters in RAM along with a bitmap of which are
presently un-saved, and save to EEPROM according to the bitmap, five
seconds after key activity.
--
 Cheers,
       Paul B.

1999\09\16@211708 by David J Binnington

flavicon
face
Paul B. Webster wrote:

{Quote hidden}

Thanks Paul and everyone else for their thoughts.  I have already
implemented a more secure system using a cache and 'update' flags, much
along the lines suggested above.

I can see no real reason to delay updating the EEPROM for five seconds so
outstanding writes are completed a short time after a key is released.
EEPROM data checking at power-up is still a basic 'in range' check but I may
implement some form of CRC when I get a chance.

Any suggestions on a quick but reliable checking routine on only six bytes
without too much code overhead, bearing in mind the possible dynamic nature
of the data block in EEPROM just before power down?

Thanks again for the help.

David

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...