Hi Neil,

Does sound very similar to what I'm proposing to do, and encouraging that i=
t's been=20
working out well for you. I take your point of the careful sequnce in makin=
g sure the=20
data is written/validated/marked clean/re-validated.

And I like the idea of the clean/dirty flag. Previously I wasn't planning o=
n having one,=20
but see it could be helpful in managing the case where hours rollover from =
9999.99=20
to 0, when it's no longer as simple as just checking for the record with th=
e highest=20
count.

Previously I was recording 1000ths of an hour to EERPOM whenever there was =
a=20
power down event (12V supply drops below 10V =3D expected power failure imi=
nent) =20
and regular EEPROM updates every 0.1 operating hours. On power up I would=20
pickup the 1000ths and continue from there so nothing was lost. I may do so=
 again,=20
but I'm still a little nervous about writing while power is starting to fai=
l, since I'm not=20
100% sure where my odd corruption problems have been coming from.

Thanks for the tips~!

On 10 Dec 2017 at 22:42, Neil wrote:

> Here's a slightly alternate option, which I use for odometer data. That=20
> the data is always increasing is required for this to work.
>=20
> I virtually divide the EEPROM space into groups of 5 bytes.  4 for=20
> storing the data, and one as a "dirty" flag.
> There's a special value indicating that the group is clean/good. When I=20
> write a new value, I first set the dirty byte to anything other than=20
> that special value, write all the bytes to hold the new value, verify=20
> everything, then set the dirty bit to the special value.  Then I verify=20
> or repeat to ensure that value gets saved.
> On power up, I scan through all groups, and for all clean groups, I pick=
=20
> the highest value, then start writing new values in the group after that.
>=20
> I store a new value every 0.01 miles, so theoretically/statistically I=20
> could be losing 0.005 miles on average for every power cycle.  I could=20
> just re-add that on each power-up, but haven't (yet?).
>=20
> This has worked well for over a decade now, and I used it for a Hobbs=20
> hour meter with no issues reported also.
>=20
> You'll need to think about what happens if you have a roll-over, but at=20
> first thought you can clear all the data (mark all the dirty bytes as=20
> dirty), when you do so.
>=20
> Cheers,
> -Neil.
>=20
>=20
>=20
> On 12/10/2017 7:52 PM, Brent Brown wrote:
> > Hi all,
> >
> > I have a math problem that is a little interesting. Background first: I=
'm storing
> > "operating hours" in internal EEPROM on a PIC16F887. It's in a product =
I've been
> > making for some time, but despite my best efforts so far the hours coun=
ter
> > occasionally gets corrupted. I suspect the biggest problem is writing t=
o EEPROM in
> > a "dying gasp" when power supply falls, with simply not enough time to =
reliably do
> > so.
> >
> > A new scheme is planned. Hours increment in units 0.01hr (36s) up to 99=
99.99,
> > then roll over to 0. On each increment it will be stored in a different=
 EEPROM
> > location. This addresses three issues 1) the byte endurance of EEPROM (=
1M typ
> > but 100k guaranteed), 2) ability to retrieve a previous record if corru=
ption is
> > detected, loosing as little as 36 seconds (fairly insignificant), and 3=
) no longer
> > writing to EEPROM as power fails.
> >
> > I plan to encode the number essentially as 6 x BCD digits, 1 digit per =
byte. I take the
> > BCD value, add 3 to it (avoids 0 being a valid code), shift to upper ni=
bble, and write
> > the inverted value into the lower nibble. This results in 10 symbols fo=
r numbers 0-9
> > as follows: 0x3C, 0x4B, 0x5A, 0x69, 0x78, 0x87, 0x96, 0xA5, 0xB4, 0xC3.
> >
> > Corruption in a digit is detected when a byte does not equate to one of=
 the valid
> > symbols (10 valid 8 bit codes out of 256). In addition I'll add a check=
sum. Preferably
> > I'd like the checksum to never equal FF, as that is the "erased" value =
of EEPROM, I
> > will also use that as a "start of record" marker. Thus a complete recor=
d will be 8
> > bytes:
> >
> > start_record, digit1, digit2, digit3, digit4, digit5, digit6, checksum
> >
> > Example: (0000.01 hours)
> >
> > 0xFF, 0x3C, 0x3C, 0x3C, 0x3C, 0x3C, 0x4B, 0x77
> >
> > My curious math question is can the checksum ever be 0xFF? It's complic=
ated by
> > the values I'm using for the symbols, and the checksum being the LS 8 b=
its of the
> > sum.
> >
> > Simplifying the symbols back to decimal values the question becomes: in=
 the
> > sequence 000000 - 999999 what are all the possible values for the sum o=
f digits?
> > One can see fairly easily that the minimum would be 0+0+0+0+0+0=3D0, th=
e
> > maximum would be 9+9+9+9+9+9=3D54. Also: there are 1 million possible s=
ums
> > (10^6), all will be in the range 0-54 (9*6), all integer values will be=
 covered as the
> > step size is 1, and there will be many identical results.
> >
> > Wondering if/how I could solve this mathematically. I did make a spread=
sheet with
> > 1000 rows to calculate the sums of digits from 000-999 and graphed the =
results in a
> > histogram. 1,000,000 rows is possible in Excel, but takes a bit of time=
, working on
> > that now. Interestingly, the 1000 row spreadsheet showed sum of digits =
covered all
> > values from 0-27, as expected, and the distribution of values is a bell=
 curve.
> >
> > I can of course work around and allow for the checksum being 0xFF, or c=
hange the
> > value if/when it ever does match 0xFF, but still curious to know if it =
is necessary.
> >
> >
>=20
> --=20
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.