David's reply/code brought me to thinking about the architecture of my ap=
p, so=20
here's some more detail on what I'm doing...

The application is an odometer.  It shows the current mileage (to the nea=
rest=20
mile), but every 1/10th mile (which it gets as a pulse from an external=20
source) it saves the new data to EEPROM.  It takes 4 EEPROM locations to =
save=20
a new distance value (0-999,999.9 miles).  On startup it reads the EEPROM=
 to=20
know where it left off.  Display intensity changes are also stored in EEP=
ROM,=20
but that happens very rarely.

To address the concern of EEPROM write endurance, I have setup the EEPROM=
 as a=20
30-unit circular buffer, of 4 bytes each.  It just moves to the next=20
index/location of the circular buffer and writes to that (set of 4 bytes)=
=20
location.  Each distance value uses 4 bytes, but 5 EEPROM writes -- The f=
irst=20
byte is marked as dirty, the distance is then written to the other 3 and =
the=20
first is then marked as valid.  On startup, all 30 locations are read, an=
d=20
the highest *valid* value is taken as the distance it left off with.

For a 1-million mile odometer, that means 10-million distances written.  =
Byte=20
1 of each 4-byte set would get the most abuse at 20 million writes.  But=20
splitting it up across 30 sets means 666,667 max writes for any single EE=
PROM=20
location.  This is well within the datasheet's EEPROM read/write enduranc=
e=20
limits (10mil cycles typical, and 1mil minimum).  For greater comfort lev=
el,=20
I'm thought of moving this to an 'F648 (256 bytes of EEPROM), so I can dr=
op=20
the EEPROM abuse to half of this by spreading it over 60 sets of 4 bytes,=
 but=20
another idea I had was that above a certain speed, I could set it to writ=
e=20
every mile or so, since the vehicle has to come back to a lower speed bef=
ore=20
stopping, and that would let it catch back up to the nearest 1/10-mile.  =
TBD=20
later.=20

The main code does its initialization stuff, scans for highest saved=20
distance-set, enables 2 timer interrupts, then goes into a loop that upda=
tes=20
the display if necessary, and writes a distance-set to EEPROM if necessar=
y. =20
One of the timer interrupts just updates the multiplexed display=20
periodically, and another polls for pulses at the ports and updates the=20
distance variables if necessary.  If so, it sets a flag to trigger the ma=
in=20
loop to write that to EEPROM.

It all works except for the EEPROM write issue, which was also working so=
me=20
time ago during development, but not sure what's causing this problem now=
=2E

=2E.. just in case you were wondering.

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads