Searching \ for 'challenge - which number is higher' 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/index.htm?key=challenge+which
Search entire site for: 'challenge - which number is higher'.

Truncated match.
PICList Thread
'challenge - which number is higher'
1999\11\30@161856 by Dwayne Reid

flavicon
face
I have an interesting problem that I'd like to throw to the gurus.

I am storing a number of records in eeprom - kind of a circular buffer
arrangement.  Part of each record is a 1 byte number used as a 'sequence'
counter - its purpose is to tell me which record is the newest.  The counter
will start at 00, increment to FF, then roll over back to 00.

This is the challenge:  how to tell which number is highest.  The records
are stored in a fixed sequence, with the oldest record being overwritten by
the current record.  Again, the sequence number is part of the record being
stored.

When the system powers up, I need to retreive the newest record and stick it
into RAM.

Eg.  Read the sequence number from 8 records and find the most recent record.

00 01 02 03 04 05 06 07  (easy)
F9 FA FB FC FD FE FF 00  (harder)
FE FF 00 01 02 03 04 05  (harder)

The problem is dealing with the wrap from FF to 00.

Thoughts, ideas?

dwayne



Dwayne Reid   <spam_OUTdwaynerTakeThisOuTspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\11\30@163938 by Don Hyde

flavicon
face
This is basically the same problem as using sequence numbers in TCP/IP
messages to locate a lost or misplaced packet.  As long as the number of
buffers in your EEROM is less than half the period of your sequence numbers,
then it will be possible to unambiguously find the discontinuity in your
buffer -- it will be the only spot where the difference between two
successive sequence numbers is not 1 modulo 256.  It will in fact be -n
modulo 256 where n is the number of records your buffer will hold. It is, of
course possible for that discontinuity to occur at the end of the buffer --
i.e. where the two "ends" of the buffer are "pasted" together to make a
circle.

> {Original Message removed}

1999\11\30@164355 by Craig Beiferman

flavicon
face
    try this!

 for (i=0;i<n-1;i++)
   {
    if (data[i] > data[i+1])
     {
     return data[i];
     }
   }
 return data[i];


-Craig Beiferman
______________________________ Reply Separator _________________________________
Subject: challenge - which number is higher
Author:  pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> at
INTERNET
Date:    11/30/99 2:17 PM


I have an interesting problem that I'd like to throw to the gurus.

I am storing a number of records in eeprom - kind of a circular buffer
arrangement.  Part of each record is a 1 byte number used as a 'sequence'
counter - its purpose is to tell me which record is the newest.  The counter
will start at 00, increment to FF, then roll over back to 00.

This is the challenge:  how to tell which number is highest.  The records
are stored in a fixed sequence, with the oldest record being overwritten by
the current record.  Again, the sequence number is part of the record being
stored.

When the system powers up, I need to retreive the newest record and stick it
into RAM.

Eg.  Read the sequence number from 8 records and find the most recent record.

00 01 02 03 04 05 06 07  (easy)
F9 FA FB FC FD FE FF 00  (harder)
FE FF 00 01 02 03 04 05  (harder)

The problem is dealing with the wrap from FF to 00.

Thoughts, ideas?

dwayne



Dwayne Reid   <dwaynerspamKILLspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\11\30@172859 by Tony Nixon

flavicon
picon face
Dwayne Reid wrote:
>
> I have an interesting problem that I'd like to throw to the gurus.

> I am storing a number of records in eeprom - kind of a circular buffer
> arrangement.  Part of each record is a 1 byte number used as a 'sequence'
> counter - its purpose is to tell me which record is the newest.

If you place the records in a circular buffer then surely the one that
the buffer pointer points to is the newest entered.

--
Best regards

Tony

http://www.picnpoke.com
.....salesKILLspamspam.....picnpoke.com

1999\11\30@182948 by Clyde Smith-Stubbs

flavicon
face
On Tue, Nov 30, 1999 at 02:17:06PM -0700, Dwayne Reid wrote:

> This is the challenge:  how to tell which number is highest.  The records

Just subtract one from the other, and look at the result only (not the
carry flag). E.g. if you have two adjacent numbers 7 and 8, subtract
7 from 8, you get 1. So 8 is higher. Similarly, if you subtract FF from
0, you get 1, so 0 is higher.

unsigned char   buffer[BLEN];

       unsigned char   i, j;

       for(i = 0 ; i != BLEN-1 ; i++) {
               j = buffer[i+1]-buffer[i];
               if(j != 1)
                       break;
       }

       /* now i points to the most recent entry in the buffer */

This will also give a sensible result if the buffer is all
zeros.

Regards, Clyde

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: EraseMEclydespam_OUTspamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydespamspam_OUThtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\11\30@191116 by Dwayne Reid

flavicon
face
>> I am storing a number of records in eeprom - kind of a circular buffer
>> arrangement.  Part of each record is a 1 byte number used as a 'sequence'
>> counter - its purpose is to tell me which record is the newest.
>
>If you place the records in a circular buffer then surely the one that
>the buffer pointer points to is the newest entered.

Thats the problem - I have to find *which* record is newest in order to set
the buffer pointer.

When the system powers down, all I have is the data stored in eeprom.  I am
currently using 8 records of 32 bytes each in the buffer - another record is
stored at some time varying from 1 minute to an hour.

Each record includes a CRC to warn me of a corrupted record or damaged
eeprom.  If a damaged sectoin of eeprom is found, I swap in one of 7 spare
chunks (just change the pointer in my 'housekeeping' section.

Essentially, I consider any location that gets written often to be subject
to damage.  Thats why I don't keep my buffer pointer in eeprom - it would
have to be written every time a new record was written - and, if that
location died, I would have no way of dealing with it.  The way I have it
set up now, my housekeeping section get written once upon first power-up,
then written only when necessary to map out a defective section of eeprom.
Each of the 8 records currently in use contains the 1 byte sequence count -
I simply need to find out which count is highest so that I can set my buffer
pointer to that record.

I start off with 512 bytes of eeprom.  This is divided into 16 chunks of 32
bytes each.  One of those chunks is reserved for what I call 'housekeeping'
- it contains 3 copies of the start addresses of the 8 records in my buffer.
This leaves me with 7 spare chunks of eeprom that will get swapped in as
required.  When the last of those is gone, my buffer drops from 8 records
down to 7, then 6, etc.  Of course, when I have lost more than a couple of
spare chunks, I'll signal that maintenance is required.

I hope this explains things a bit more clearly.

dwayne


Dwayne Reid   <@spam@dwaynerKILLspamspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\11\30@213536 by Tony Nixon

flavicon
picon face
> This is the challenge:  how to tell which number is highest.  The records

Perhaps if you treat '0' as the absolute highest number when it is
found. Then continue through the rest of the list.

--
Best regards

Tony

http://www.picnpoke.com
KILLspamsalesKILLspamspampicnpoke.com


'challenge - which number is higher'
1999\12\01@020518 by Nikolai Golovchenko
flavicon
face
Hello Dwayne.

>Eg.  Read the sequence number from 8 records and find the most recent
record.
>
>00 01 02 03 04 05 06 07  (easy)
>F9 FA FB FC FD FE FF 00  (harder)
>FE FF 00 01 02 03 04 05  (harder)
>
>The problem is dealing with the wrap from FF to 00.


You can solve the problem by searching for negative difference between
consecutive records sequence numbers. 7 bit signed value should be used for
difference. The trick is that 0 - 255 = +1 in this case, i.e. transition
from 255 to 0 is treated as usual ascending of numbers.

For example, scanning records
1) 00 01 02 03 04 05 06 07 will give differences +1 and -7 (0 - 7 = -7, so 7
is more recent)
2) 08 01 02 03 04 05 06 07 "    "    "    "    "    " (1 - 8 = -7. 8 -
recent)
3) F8 F9 FA FB FC FD FE FF "    "    "    "    "    " (F8 - FF = -7. FF -
recent)
4) 00 F9 FA FB FC FD FE FF "    "    "    "    "    " (F9 - 0 = -7. 0 -
recent)
5) 00 01 02 03 04 05 06 FF "    "    "    "    "    " (FF - 6 = -7. 6 -
recent)

This method will work for 7 and 6 records too.


Regards.
_

Nikolai Golovchenko, Electrical Engineering Student
National Mining University of Ukraine http://www.nmuu.dp.ua
Dnepropetrovsk, Ukraine
E-mail: RemoveMEgolovchenkoTakeThisOuTspammail.ru

1999\12\01@121609 by V sml

picon face
Hi Dwayne,

Latest is just before earliest, and earliest SeqNumber <> Latest + 1.
This point is reached when

SeqNumber (next) <> SeqNumber (now) + 1 [ignore overflow]

Run through by adding 1 to the last SeqNumber, if next SeqNumber equal
to that => the point is not reached.  Search until point is reached.
Or you can transverse in the opposite direction and look for SeqNumber
(now) <> SeqNumber(next) - 1.

Hope it helps.

Mail me a copy of your codes if possible when you are done.

Ling SM

1999\12\01@133254 by Wagner Lipnharski

flavicon
face
Hey Dwayne, I already went to that beach, the water is not so cold... :)
Simple and easy, you have two choices:

a) If you have an extra byte at the eeprom, just save the last
IDentification block number there, or circular buffer pointer, so when
you power up again, just read it and set the buffer pointer back, or
search for the ID into the circular buffer.

b) If you DO NOT have this extra byte, or don't want to keep reducing
the eeprom life, just reserve the "00" identification byte for the next
empty block, use block ID's from 01 to FF.  Whenever you write a block,
write an extra byte of "00" after that block, *that* will be your mark
of END OF CIRCULAR BUFFER.  For sure this "00" will be recorder over the
oldest block identification byte, but even so you would be able to read
that block of data.
With this option, at power up, you just need to go to the beginning of
the circular buffer, and start reading just the block ID's, looking for
"00", so the most recent is exactly the previous one, the oldest the one
with the "00".

Any other math solution doesn't work, since if your block ID's are also
circular from 00 to FF, there is NO WAY to find out which one was the
last, except in one condition:
If your circular buffer size is not a perfect multiple of the (block
data size + Id) * 256.  In this case you can search for a disrupt in ID
sequence.  For example, if you circular buffer is only 256 bytes long
and your block size is 32 bytes:

ID  DATA (31Bytes)- - - - - - - ->
01  00 01 02 03 04 ... 1E <--- begin of circular buffer
FD  00 01 02 03 04 ... 1E
FB  00 01 02 03 04 ... 1E
FC  00 01 02 03 04 ... 1E
FD  00 01 02 03 04 ... 1E
FE  00 01 02 03 04 ... 1E
FF  00 01 02 03 04 ... 1E.
00  00 01 02 03 04 ... 1E <--- end of circular buffer

If the block size is fixed, then you see that the difference between two
block ID's is different than 1 it means the lower address block is the
last one, if the circular buffer runs up address. In this example it is
clear that the last register is the first on the buffer.

Again, this technique will not works if your circular buffer holds only
2 blocks, or its size is exactly the block size times 256 (to a 8 bits
ID), so the disruption above 65 -- 62 would then be 65 -- 66.

As you said, you are using 256 bytes of buffer, 32 bytes per block, so
it is only 8 different block ID's, so the above technique will work.

Now, if you really don't need to store the block ID number, then:
If the first data byte values follows some kind of rule, for example, it
is always less than 7F, you could use the bit 7 turned on only for the
next buffer available byte, so easy to scan when powering back on. Or if
the data bytes never use some bit combination, use that combination at
the next buffer available byte.

In any way, you need to remember that you have a limited quantity of
write operations in the eeprom chip. There are eeproms for 100k or 1M
recordings (never clear from manufacturer, temperature changes it).
Suppose the worst scenario, 1 minute per recording, you are using 32
write cycles per recording, per minute, gives you 3125 recordings or
only 52 hours. A whole month has only 720 hours!!!
Suppose the best scenario, 1M recordings in one hour interval, 21250
recordings, 885 days.
Lets go for the average:  500k write cycles, 30 minutes per recording,
15625 recordings, 7812 hours, 325 days.
So, your unpredictable e2prom life can goes from less than a month to
almost 3 years... I would not bet on this solution as the best one, if
you need several months of working situation.

Do you already considered the possibility to use NVRAM? You could avoid
CRC and all, just write 3 times the same record, when reading just
compare and go for the majority in case of problems (you would not have
problems with NVRAM during 10 years).


Dwayne Reid wrote:
{Quote hidden}

1999\12\02@003732 by Nikolai Golovchenko

flavicon
face
Hi Wagner

>Any other math solution doesn't work, since if your block ID's are also
>circular from 00 to FF, there is NO WAY to find out which one was the
>last, except in one condition:
>If your circular buffer size is not a perfect multiple of the (block
>data size + Id) * 256.  In this case you can search for a disrupt in ID


Why should the block size be so restricted? You just have to know the block
size, whatever it is, to find IDs locations. The block size have to be fixed
though, because EEPROM failure may disrupt the whole sequence.

{Quote hidden}

Because of the possible record failure, looking for difference different
from 1 may not work.

>Again, this technique will not works if your circular buffer holds only
>2 blocks,

But it will if you are looking for *negative* difference.

2 blocks example:
00 01      1 - 0 = 1, next, 0 - 1 = -1, bingo! 1 is last
02 01      1 - 2 = -1, 2 is last
02 03      3 - 2 = 1, next, 2 - 3 = -1, 3 is last
FE FF      FF - FE = 1, next, FE - FF = -1, FF is last
00 FF      FF - 0 = FF = -1, 0 is last


With this technique, all possible IDs make up a circle,

               00  01
          FF           02
        FE                03
       .
       .                  04

        0A                05
           09          06
               08  07

where IDnext = IDprevious + 1. Because ID can overflow, this is not true
when IDprevious = FF. If you use for difference the same number of bits,
i.e. 8, then the difference will overflow too at the same place (00 - FF =
1). In this case, if you take any two consecutive numbers on the circle the
difference is *1* always. And different from 1 if distance between IDs is
greater than 1.

In Dwayne's case there is a possibility of EEPROM failure that may cause one
record to be bad (record writing cycle not finished in case of power down).
So difference may be 2 as well for ascending numbers. Value, different from
1 or 2, will indicate the end of sequence. This makes possible *254* length
of sequence!! Since Dwayne needs only 8 records I would suggest just test
the MSB of 8 bit difference.

Hope it helps :)

_

Nikolai Golovchenko, Electrical Engineering Student
National Mining University of Ukraine http://www.nmuu.dp.ua
Dnepropetrovsk, Ukraine
E-mail: spamBeGonegolovchenkospamBeGonespammail.ru

1999\12\02@084520 by Wagner Lipnharski

flavicon
face
I am sorry, I did not follow very well what you said, appears to me that
in case of eeprom writing problems, you still have problems anyway. If
the ID byte is recorded in failure, how can you recognize what is right
or wrong?

Suppose you need to record this ID's:   01 02 03 04 05 FF 00  (being 05
the last) and by a problem in the recording, it ended up this way: 01 02
07 04 05 FF 00, how can you identify which one is the last?   Even the
negative difference gets crazy here.

Memory data corruption is a problem anyway, and you simply can not avoid
them all, you can be sure that if you don't cover 100% of the error and
possible solutions, it will get you sooner than you can think.

For example, to avoid problems with power down while recording the
eeprom, you should have enough backup energy to complete the eeprom
recording, anything less is asking for problems.  An interrupt power
fault is a must to decide if it will or not record the eeprom, or any
other kind of NVRAM or flash. This is a traditional understanding of
"loose the new 8 data bytes" or "corrupt the old existent megabyte".

An easy way, avoid to use the block ID byte, just stablish a fixed
position at your e2prom to store the address of your last register. Use
two fixed locations. LAST1 and LAST2, they both are the same, but LAST1
is recorded before you write the register, LAST2 is recorded after you
write it. So, LAST1 will always be ok, because it is written fast. If
LAST2 is different than LAST1, it means you got a power loss during the
register recording and it is not valid, being LAST1 - 1 the last valid
recording.

Wagner

Nikolai Golovchenko wrote:
{Quote hidden}

1999\12\02@181410 by Dwayne Reid

flavicon
face
>I am sorry, I did not follow very well what you said, appears to me that
>in case of eeprom writing problems, you still have problems anyway. If
>the ID byte is recorded in failure, how can you recognize what is right
>or wrong?

Each of my 8 records includes a 16 bit CRC.  I try to detect bad eeprom 2
ways - after I have written a new record, I read back the data and ensure
that it is correct.  If I detect an error, I map in a new block of eeprom
and re-write the record.

Upon power-up, I check the CRC of each block to ensure that the sequence
number I am about to get is valid.  If it is not valid, I assume that system
power died before that block could written and that I have lost that record.
The record before the bad one should be the newest - the bad record becomes
the next to be over-written.  This should be quite unlikely - I've got
enough reserve power stored in capacitors to ensure that I could finish at
least 5 complete block saves.  But its a problem that I can detect and deal
with, so I will.

Thanks to everyone for their help and insight.  The answer seems pretty
simple now - because the records are always written in sequence, just look
for the discontinuity that always has to occur after the newest record.
I'll post code after its been written and tested.

Many thanks!

dwayne


Dwayne Reid   <RemoveMEdwaynerspamTakeThisOuTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\12\02@185216 by Wagner Lipnharski

flavicon
face
last time, I promise,

Dwayne Reid wrote:
> Each of my 8 records includes a 16 bit CRC.  I try to detect bad eeprom 2
> ways - after I have written a new record, I read back the data and ensure
> that it is correct.  If I detect an error, I map in a new block of eeprom
> and re-write the record.
>
> Upon power-up, I check the CRC of each block to ensure that the sequence
> number I am about to get is valid.  If it is not valid, I assume that system
> power died before that block could written and that I have lost that record.
> The record before the bad one should be the newest - the bad record becomes
> the next to be over-written.  This should be quite unlikely - I've got
> enough reserve power stored in capacitors to ensure that I could finish at
> least 5 complete block saves.  But its a problem that I can detect and deal
> with, so I will.

Using this CRC test technique, if you start to have a bad eeprom address
due excessive use, it will always tells you that the previous address
was the last recorded, what will be false. Even using the previous
suggestion to use two places to store same circular buffer pointer, you
still weak for the eeprom wearing problems, if one of those places start
also to fail, all your system will crash badly.  It is very difficult to
create a crash-proof system based on eeprom that is able to fail.

1999\12\02@202351 by Dwayne Reid

flavicon
face
>last time, I promise,

Hey!  Feel free to shoot as many holes as possible in what I'm trying to do
- thats why I'm asking questions!  If you find something I haven't thought
of, just helps me make a more robust system.

>
>Dwayne Reid wrote:
>> Each of my 8 records includes a 16 bit CRC.

>Using this CRC test technique, if you start to have a bad eeprom address
>due excessive use  <snip>

Thats the whole point of the CRC.  If I find a record with a bad CRC, I
don't use ANY portion of that record, including the sequence number.  I find
the newest record out of those with data I can trust.

Once I have found the newest record, I'll try writing the record with the
bad CRC once more, assuming that the CRC was bad because a previous write
failed.  If the write fails again, that chunk of eeprom is swapped out with
one of the spares.

Like I said earlier, I start out with 7 spare blocks of eeprom that can be
mapped to any of the record locations.  Once those are used up, my circular
buffer drops to 7 records, then 6, then 5 - until I have NO eeprom left.
But the box will be hollering for help long before then!

dwayne


Dwayne Reid   <dwaynerEraseMEspam.....planet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\12\02@235325 by V sml

picon face
>> Each of my 8 records includes a 16 bit CRC.
>Using this CRC test technique, if you start to have a bad eeprom
address due excessive use  <snip>

>Thats the whole point of the CRC.  If I find a record with a bad CRC,
I don't use ANY portion of that record, including the sequence number.
I find the newest record out of those with data I can trust.

At the point when you store, you do a check on E2PROM and storage
integrity by ensuring byte-by-byte the block of written record is
correct, this is better than CRC check.  At this point, CRC do not
serve a purpose here.  Am I right?

So CRC tries to detect E2PROM failure, in addition to ensuring data
integrity during transfer, after you have written.  Therefore this
block of data is lost when CRC fails.  But doing what you suggested
below might produce the same good result at the time when you write,
and your risk of loosing another block of record is very high.  I
would not assume the previous write has failed since it was proven
correct.  I would read the block of data again to rule out noise
during transfer, and mark off the that block right away.

>Once I have found the newest record, I'll try writing the record with
the bad CRC once more, assuming that the CRC was bad because a
previous write failed.  If the write fails again, that chunk of eeprom
is swapped out with one of the spares.

One question is how does E2PROM fail in max. wear-n-tear?  Does it
fail at the point of writing, or can it fail after a proper writing
has been done?  I need to refresh my memory.

Cheers,

Ling SM

1999\12\03@014007 by Dwayne Reid

flavicon
face
>>> Each of my 8 records includes a 16 bit CRC.
>>Using this CRC test technique, if you start to have a bad eeprom
>address due excessive use  <snip>
>
>>Thats the whole point of the CRC.  If I find a record with a bad CRC,
>I don't use ANY portion of that record, including the sequence number.
>I find the newest record out of those with data I can trust.
>
>At the point when you store, you do a check on E2PROM and storage
>integrity by ensuring byte-by-byte the block of written record is
>correct, this is better than CRC check.  At this point, CRC do not
>serve a purpose here.  Am I right?

That is correct.  After I have written eeprom, I read it back and make sure
that it is correct.  If it is not correct, I mark that block of eeprom as
defective and swap in a spare block.

The CRC is used to verify eeprom accuracy only when the system powers up.
In other words, I am supposed to have 8 good records stored in the eeprom.
The CRC simply ensures that the records are OK.  I then examine the records
to find out which one is the most recent and load RAM from that record.

{Quote hidden}

Nope - I'm assuming that I lost power while the write was in progress.
Thats why it the CRC did not match.

>>Once I have found the newest record, I'll try writing the record with
>the bad CRC once more, assuming that the CRC was bad because a
>previous write failed.  If the write fails again, that chunk of eeprom
>is swapped out with one of the spares.
>
>One question is how does E2PROM fail in max. wear-n-tear?  Does it
>fail at the point of writing, or can it fail after a proper writing
>has been done?  I need to refresh my memory.

I'm not expert on this subject.  I have been told that it is the act of
WRITING that wears out an eeprom cell.  I have also been told that I can
expect 100 year data rentention on data that is only being read.  So - I'm
trying to cover my bases.  I'll keep the 8 most recent records and use CRC
to detect read / wear errors.  If I lose a record, the data from the
remaining records is sufficient for my purposes.  What I cannot tolerate is
not having any data at all.

dwayne


Dwayne Reid   <EraseMEdwaynerspamplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\12\03@071101 by V sml

picon face
I see the picture now.  The microchip AN537 confirms what you said
about how EEPROM should fail in wear-n-tear.

>I'm not expert on this subject.  I have been told that it is the act
of WRITING that wears out an eeprom cell.  I have also been told that
I can expect 100 year data rentention on data that is only being read.
So - I'm trying to cover my bases.

> I'll keep the 8 most recent records and use CRC to detect read /
wear errors.

Hmm?? read/wear??  AN537 convinces me not to bother about read-wear
(data retention) problem.  Rewriting to check the failed block would
not catch read/wear if the problem is what I mentioned earlier because
it sure match at the point of checking, but this wastes another
write-cycle of the EEPROM life.  If the block is defective due to any
other causes, the next time it is used the write ritual should be
sufficent to tell.

Cheers,

Ling SM

1999\12\03@154407 by Mark Willis

flavicon
face
Dwayne Reid wrote:
> <snipped>
> I'm not expert on this subject.  I have been told that it is the act of
> WRITING that wears out an eeprom cell.  I have also been told that I can
> expect 100 year data rentention on data that is only being read.  So - I'm
> trying to cover my bases.  I'll keep the 8 most recent records and use CRC
> to detect read / wear errors.  If I lose a record, the data from the
> remaining records is sufficient for my purposes.  What I cannot tolerate is
> not having any data at all.
>
> dwayne
>
> Dwayne Reid   <RemoveMEdwaynerEraseMEspamEraseMEplanet.eon.net>
> Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
> (780) 489-3199 voice          (780) 487-6397 fax

My take on how to fix the Write-wear problem;  Socket the SEEProm, and
just replace it at sane intervals <G>  (If "Joe 10-thumbs", i.e. a
chemist or mechanic or other non-EE person is your field "Engineer",
just make a DB-9 solder cup/Perfboard housing for the SEEProm, use pins
1 and 5 both for ground, plus 6 and 9 maybe <G> - so ground should plug
in first, and even THEY cannot plug it in backwards.  I hope <G>)

 Mark

--
I ship small packages for small businesses, world-wide.
(And for private individuals at cost, just ask.)

1999\12\07@144745 by Roland Andrag

flavicon
face
How about always keeping an extra 'pointer', ie for successive writes:

FD FD 05 06 07 08 09 etc.

one write later:

FD FE FE 06 07 08 09 etc

one write later:

FD FE FF FF 07 08 09

one write later:

FD FE FF 00 00 08 09 etc.
and

FD FE FF 00 01 01 09 etc.

Cost is memory space of one record.. just search for the duplicate.. even
easier though is to have a pointer somewhere else pointing to the newest
record..






{Original Message removed}

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