"linnix" <me@linnix.info-for.us> wrote in message
news:1124718852.726530.213940@g43g2000cwa.googlegroups.com...
> First of all, it depends on whether we are talking about NAND or NOR
> flash.  NOR flash is like static ram, which is cell addressable.  NAND
> flash is like dynamic ram, which is row & col addressable.  In fact,
> for most NAND flash devices (CF,SD,etc), you can't even deal with the
> flash directly.  You send a block of data to the on-board controller,
> it may or may not rewrite the block in the same space.  Depending on
> the implementation, it might even be advantageous to write to a new
> block every time.  This would spread out the cell wearing.
> Unfortunately, writing a bit would cause an entire block of writing.

I was referring to normal flash chips, like Am29F010 and the like. I don't
know if these are NAND or NOR flash, but the datasheet shows a matrix, but
they're all byte addressable and they write a single byte at a time. Similar
flashes from Atmel however, do write a page at a time (256 bytes, for
instance). These are all "normal" chips with an address and databus
(parallel).

Meindert

Thad Smith wrote:
> Meindert Sprang wrote:
> > "Thad Smith" <ThadSmith@acm.org> wrote in message
> > news:4305dc6e$0$79779$892e0abb@auth.newsreader.octanews.com...
> >
> >>linnix wrote:

First of all, it depends on whether we are talking about NAND or NOR
flash.  NOR flash is like static ram, which is cell addressable.  NAND
flash is like dynamic ram, which is row & col addressable.  In fact,
for most NAND flash devices (CF,SD,etc), you can't even deal with the
flash directly.  You send a block of data to the on-board controller,
it may or may not rewrite the block in the same space.  Depending on
the implementation, it might even be advantageous to write to a new
block every time.  This would spread out the cell wearing.
Unfortunately, writing a bit would cause an entire block of writing.

> >>
> >>>Thad Smith wrote:
> >>>
> >>>>"sailor.gu@gmail.com" wrote:
> >>>>
> >>>>>1. As you said, change 1s to 0s need not erase, so it is not a
> >>>>>write/erase cycle, right?
> >>>>
> >>>>Correct, it is only a write.  No erasure is done.

You can't control it with NAND flash.

> >>>
> >>>Flash memories are rated 100,000 write cycles, not just erase cycles.
> >>
> >>Interesting.  Does that mean that using page writes provides N times
> >>less wear than single byte writes, where both modes are available and N
> >>is the size of the page?
> >
> > No. The 100,000 cycles are per cell/bit. Since you can only change a 1 to 0
> > once and then erase it, that counts as one cycle. Filling a page byte by
> > byte, with separate write cycles, or doing a page write makes no difference
> > for each cell, they only get changed from 1 to 0 once. When you erase the
> > entire page, all cells change to 1 again so the write/erase cycle is
> > complete. So it's safe to say that 100,000 write cycles is the same as
> > 100,000 page erase cycles.
>
> That's what I thought, but linnix wrote:
> >
> > Depends on how the flash is built.  Rather than addressing individual
> > cells.  Flash controller addresses a block of cells.  There are much
> > less write amplifiers vs. cells.  You can think of DRAM's row & col
> > addressing.  Turning on a row will wear out all the cells sharing the
> > row.

By sharing addressing and refleshing logics, NAND are cheaper to build
than NOR.  Each cell is like a tiny battery.  Unfortunately, battery
don't last forever, since charging is also weakening the holding
capabiblity.

If I can borrow 5 billion yuan, I would do it differently.  I would
build separate batteries at the charger level.  This would shorten the
holding time between chargings, but also remove the write cycle
limitation.  The down size is that you have to power it up at least
once in a while.  The up size is that you can use it like a hard disk.

>
> That would argue for page writes, assuming that wrote a single "row" at
> once, as wearing less that individual byte writes.
>
> So the question becomes what is a write cycle for a single cell, as far
> as wearout goes: writing that particular cell or writing any cell on the
> same "row"?
> 
> Thad

Meindert Sprang wrote:
> "Thad Smith" <ThadSmith@acm.org> wrote in message
> news:4305dc6e$0$79779$892e0abb@auth.newsreader.octanews.com...
> 
>>linnix wrote:
>>
>>>Thad Smith wrote:
>>>
>>>>"sailor.gu@gmail.com" wrote:
>>>>
>>>>>1. As you said, change 1s to 0s need not erase, so it is not a
>>>>>write/erase cycle, right?
>>>>
>>>>Correct, it is only a write.  No erasure is done.
>>>
>>>Flash memories are rated 100,000 write cycles, not just erase cycles.
>>
>>Interesting.  Does that mean that using page writes provides N times
>>less wear than single byte writes, where both modes are available and N
>>is the size of the page?
> 
> No. The 100,000 cycles are per cell/bit. Since you can only change a 1 to 0
> once and then erase it, that counts as one cycle. Filling a page byte by
> byte, with separate write cycles, or doing a page write makes no difference
> for each cell, they only get changed from 1 to 0 once. When you erase the
> entire page, all cells change to 1 again so the write/erase cycle is
> complete. So it's safe to say that 100,000 write cycles is the same as
> 100,000 page erase cycles.

That's what I thought, but linnix wrote:
> 
> Depends on how the flash is built.  Rather than addressing individual
> cells.  Flash controller addresses a block of cells.  There are much
> less write amplifiers vs. cells.  You can think of DRAM's row & col
> addressing.  Turning on a row will wear out all the cells sharing the
> row.

That would argue for page writes, assuming that wrote a single "row" at 
once, as wearing less that individual byte writes.

So the question becomes what is a write cycle for a single cell, as far 
as wearout goes: writing that particular cell or writing any cell on the 
same "row"?

Thad

sailor.gu@gmail.com wrote:

> I will only account about three days time(4320 minutes).
> and I will use 4320bits to recoard the time.
> so the erase operation need not be done.
> when all bits is set,  no more account action will be done.

Sounds straight-forward.

Thad

"Thad Smith" <ThadSmith@acm.org> wrote in message
news:4305dc6e$0$79779$892e0abb@auth.newsreader.octanews.com...
> linnix wrote:
> > Thad Smith wrote:
> >
> >>"sailor.gu@gmail.com" wrote:
> >>
> >>
> >>>1. As you said, change 1s to 0s need not erase, so it is not a
> >>>write/erase cycle, right?
> >>
> >>Correct, it is only a write.  No erasure is done.
> >
> >
> > Flash memories are rated 100,000 write cycles, not just erase cycles.
>
> Interesting.  Does that mean that using page writes provides N times
> less wear than single byte writes, where both modes are available and N
> is the size of the page?

No. The 100,000 cycles are per cell/bit. Since you can only change a 1 to 0
once and then erase it, that counts as one cycle. Filling a page byte by
byte, with separate write cycles, or doing a page write makes no difference
for each cell, they only get changed from 1 to 0 once. When you erase the
entire page, all cells change to 1 again so the write/erase cycle is
complete. So it's safe to say that 100,000 write cycles is the same as
100,000 page erase cycles.

Meindert

linnix wrote:
> Thad Smith wrote:
> 
>>"sailor.gu@gmail.com" wrote:
>>
>>
>>>1. As you said, change 1s to 0s need not erase, so it is not a
>>>write/erase cycle, right?
>>
>>Correct, it is only a write.  No erasure is done.
> 
> 
> Flash memories are rated 100,000 write cycles, not just erase cycles.

Interesting.  Does that mean that using page writes provides N times 
less wear than single byte writes, where both modes are available and N 
is the size of the page?

Thad

I will only account about three days time(4320 minutes).
and I will use 4320bits to recoard the time.
so the erase operation need not be done.
when all bits is set,  no more account action will be done.

Thad Smith wrote:
> "sailor.gu@gmail.com" wrote:
>
> > 1. As you said, change 1s to 0s need not erase, so it is not a
> > write/erase cycle, right?
>
> Correct, it is only a write.  No erasure is done.

Flash memories are rated 100,000 write cycles, not just erase cycles.

>
> > 2. write a bit is much rapider than erase/write sector, right?
>
> Yes, it is faster.

Yes for EEPROM.  Not necessary true for Flash.

>
> >    so even  I do bit-write operation per one minute, its impact can be
> > ignored, right?

Depends on how the flash is built.  Rather than addressing individual
cells.  Flash controller addresses a block of cells.  There are much
less write amplifiers vs. cells.  You can think of DRAM's row & col
addressing.  Turning on a row will wear out all the cells sharing the
row.

>
> Practically speaking, no.  Yes, you can make multiple writes without
> an erase, but at some point you need to erase in order to store more
> information.  Here is a simple example:
>

For the followings, true for EEPROM, but unknown for Flash.

> Suppose you need to write a 16-bit value once per minute and further
> suppose that the all-ones value (0xffff) is not a valid value.  After
> erasing a sector, you can write the first value to the bottom 2 bytes
> (assuming 8-bit bytes).  For the next number, if all one bits of the
> new number are 1 bits in the previous number ((n1 & ~n0) == 0), you
> can overwrite the previous value (free update!).  If false, you can
> write the next higher location.  When the sector is full, you need to
> start writing a fresh sector, possibly the same one after erasure.
>
> To recover the last value following a power cycle, read the highest
> 16-bit word that is not 0xffff.
>
> This procedure assumes that you won't get stuck with a value half-way
> written.  If that is a possibility, the protocol can be extended to
> indicate that the update cycle is complete.  The easiest way is to set
> another byte to 0 when the value update is complete, resulting in an
> extra byte per value.  This could be optimized to reduce the overhead
> by packing bits or taking advantage of data value restrictions.
>
> This technique gives you SectorSize/DataSize writes per erasure,
> theoretically extending the number of updates by that factor.  I have
> used an enhancement of this technique to give incremental updates to a
> set of arrays with infrequent erasures.
> 
> Thad

"sailor.gu@gmail.com" wrote:

> 1. As you said, change 1s to 0s need not erase, so it is not a
> write/erase cycle, right?

Correct, it is only a write.  No erasure is done.

> 2. write a bit is much rapider than erase/write sector, right?

Yes, it is faster.

>    so even  I do bit-write operation per one minute, its impact can be
> ignored, right?

Practically speaking, no.  Yes, you can make multiple writes without
an erase, but at some point you need to erase in order to store more
information.  Here is a simple example:

Suppose you need to write a 16-bit value once per minute and further
suppose that the all-ones value (0xffff) is not a valid value.  After
erasing a sector, you can write the first value to the bottom 2 bytes
(assuming 8-bit bytes).  For the next number, if all one bits of the
new number are 1 bits in the previous number ((n1 & ~n0) == 0), you
can overwrite the previous value (free update!).  If false, you can
write the next higher location.  When the sector is full, you need to
start writing a fresh sector, possibly the same one after erasure.

To recover the last value following a power cycle, read the highest
16-bit word that is not 0xffff.

This procedure assumes that you won't get stuck with a value half-way
written.  If that is a possibility, the protocol can be extended to
indicate that the update cycle is complete.  The easiest way is to set
another byte to 0 when the value update is complete, resulting in an
extra byte per value.  This could be optimized to reduce the overhead
by packing bits or taking advantage of data value restrictions.

This technique gives you SectorSize/DataSize writes per erasure,
theoretically extending the number of updates by that factor.  I have
used an enhancement of this technique to give incremental updates to a
set of arrays with infrequent erasures.

Thad