On Fri, 18 Aug 2006 14:20:00 GMT, "andrew queisser"
<andrewdotqueisser@hp.com> wrote:

>but then I might have to worry about having to erase the sector while I'm 
>doing a time-critical operation instead of waiting for the next power cycle 
>which would happen when the battery gets disconnected for recharge.


I think to be (power)fail-safe you'll need 3 sectors, two management
sectors and one data sector.

Only one data sector, as you are only flipping bits, you might store
the actual count in a management sector while erasing.

Two management sectors, since you sometimes have to erase one.
-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

"42Bastian Schick" <bastian42@yahoo.com> wrote in message 
news:44e5aaf9.367450565@news.individual.de...
>
> If count only [m/n] , can you live with the fault between successive
> runs ?
>
> E.g. a zero-bit means 8 runs, so
> 0xfe => 1..8 runs
> 0xfc => 8..16 etc.
>
> But the main problem stays, you have to erase the flash at a time in
> the future.
>
> But why not realy storing the 32bit value (btw. DWORD on an ARM CPU
> would mean 64bit :-)
>
> Assume an (flash) array of 128 elements, all initialized to 0xff,
> if an element is 0 => take next
> if an element is > 0 && < 0xffffffff => last count stored
> if an element is 0xffffffff => free
> (Note: count of 0xffffffff cannot be stored, special handling
> is needed.)
>
> If you no free element, erase all and start with first.
>
> After storing a new count, clear all bits of the last.
>
> Sound fairly easy to implement.

That's exactly what I had in mind. I would flip a bit every 10 cycles. If 
the power goes down between cycles I lose 10 events. My flash is good for 
about 1 million erase cycles so I really don't need to worry about erase 
cycles as much as the time hit to erase a sector. The events happen about 
every second so I could really afford to flip a bit after every single cycle 
but then I might have to worry about having to erase the sector while I'm 
doing a time-critical operation instead of waiting for the next power cycle 
which would happen when the battery gets disconnected for recharge.

Andrew

"Hershel Roberson" <hrjunk01@moment.net> wrote in message 
news:ec4fbt01hk9@enews1.newsguy.com...
>
> On 17-Aug-2006, "andrew queisser" <andrewdotqueisser@hp.com> wrote:
>
>> I'm thinking of ways to implement a nearly non-volatile counter using
>> flash
>> and RAM. Idea is to count events in a RAM counter and write the count to
>> flash every n times. At first I thought I'd just use successive locations
>> in
>> flash until I need to reformat the entire sector but I'm thinking it may
>> be
>> better to flip single bits from 1 to 0 with each bit indicating n events.
>> That way I don't waste an entire DWORD for each update.
>>
>> Does anybody know of a ready-made solution for this kind of thing?
>>
>> Thanks,
>> Andrew
>
> I use a "power going down" interrupt, and save off counters (and other
> things)
> as the power is going down.
>
> -Hershel

Hmm, I don't have one of those but maybe we should add something like that.

Thanks,
Andrew 

On 17-Aug-2006, "andrew queisser" <andrewdotqueisser@hp.com> wrote:

> I'm thinking of ways to implement a nearly non-volatile counter using
> flash
> and RAM. Idea is to count events in a RAM counter and write the count to
> flash every n times. At first I thought I'd just use successive locations
> in
> flash until I need to reformat the entire sector but I'm thinking it may
> be
> better to flip single bits from 1 to 0 with each bit indicating n events.
> That way I don't waste an entire DWORD for each update.
>
> Does anybody know of a ready-made solution for this kind of thing?
>
> Thanks,
> Andrew

I use a "power going down" interrupt, and save off counters (and other
things)
as the power is going down.

-Hershel

On Thu, 17 Aug 2006 20:20:42 GMT, "andrew queisser"
<andrewdotqueisser@hp.com> wrote:

>Hi all,
>
>I'm thinking of ways to implement a nearly non-volatile counter using flash 
>and RAM. Idea is to count events in a RAM counter and write the count to 
>flash every n times. At first I thought I'd just use successive locations in 
>flash until I need to reformat the entire sector but I'm thinking it may be 
>better to flip single bits from 1 to 0 with each bit indicating n events. 
>That way I don't waste an entire DWORD for each update.

If count only [m/n] , can you live with the fault between successive
runs ?

E.g. a zero-bit means 8 runs, so
0xfe => 1..8 runs
0xfc => 8..16 etc.

But the main problem stays, you have to erase the flash at a time in
the future.

But why not realy storing the 32bit value (btw. DWORD on an ARM CPU
would mean 64bit :-)

Assume an (flash) array of 128 elements, all initialized to 0xff,
if an element is 0 => take next
if an element is > 0 && < 0xffffffff => last count stored
if an element is 0xffffffff => free
(Note: count of 0xffffffff cannot be stored, special handling
is needed.)

If you no free element, erase all and start with first.

After storing a new count, clear all bits of the last.

Sound fairly easy to implement.

-- 
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !

Donald Harris wrote:
> "andrew queisser" <andrewdotqueisser@hp.com> wrote in message 
> news:uc4Fg.126$b75.121@news.cpqcorp.net...
>> Hi all,
>>
>> I'm thinking of ways to implement a nearly non-volatile counter using 
>> flash and RAM. Idea is to count events in a RAM counter and write the 
>> count to flash every n times. At first I thought I'd just use successive 
>> locations in flash until I need to reformat the entire sector but I'm 
>> thinking it may be better to flip single bits from 1 to 0 with each bit 
>> indicating n events. That way I don't waste an entire DWORD for each 
>> update.
>>
>> Does anybody know of a ready-made solution for this kind of thing?
>>
>> Thanks,
>> Andrew
>>
>>
> 
> Look into ferroelectric ram.  It is fast writing, reading and is 
> non-volatile.
> 
> Don
> 
> 
Yes  Look up FRAM from Ramtron.  8pin chips like EEprom. 10E14 writes, 
with no write delay.

On Thursday, in article <uc4Fg.126$b75.121@news.cpqcorp.net>
     andrewdotqueisser@hp.com "andrew queisser" wrote:

>Hi all,
>
>I'm thinking of ways to implement a nearly non-volatile counter using flash 
>and RAM. Idea is to count events in a RAM counter and write the count to 
>flash every n times. At first I thought I'd just use successive locations in 
>flash until I need to reformat the entire sector but I'm thinking it may be 
>better to flip single bits from 1 to 0 with each bit indicating n events. 
>That way I don't waste an entire DWORD for each update.
>
>Does anybody know of a ready-made solution for this kind of thing?

Depending on what your counting the best alternative would be good supply
supervision and one of the Ramtrom Ferroelectric RAM chips, minimal hassle
and very high write cycles.

If counting time you might be able to use some of their other chips.

Almost single chip solution, as power supply supervision to disable accesses
will be necessary on ANY solution.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

andrew queisser wrote:
> "Thomas Magma" <somewhere@overtherainbow.com> wrote in message 
> news:US5Fg.424407$IK3.93287@pd7tw1no...
> 
>>"andrew queisser" <andrewdotqueisser@hp.com> wrote in message 
>>news:uc4Fg.126$b75.121@news.cpqcorp.net...
>>
>>>Hi all,
>>>
>>>I'm thinking of ways to implement a nearly non-volatile counter using 
>>>flash and RAM. Idea is to count events in a RAM counter and write the 
>>>count to flash every n times. At first I thought I'd just use successive 
>>>locations in flash until I need to reformat the entire sector but I'm 
>>>thinking it may be better to flip single bits from 1 to 0 with each bit 
>>>indicating n events. That way I don't waste an entire DWORD for each 
>>>update.
>>>
>>>Does anybody know of a ready-made solution for this kind of thing?
>>>
>>>Thanks,
>>>Andrew
>>>
>>>
>>
>>I would use a small, low cost micro (PIC maybe) and save the count in the 
>>EEPROM. Single chip solution.
>>
>>Thomas
>>
> 
> Oh, I should have mentioned that we already have flash, RAM, etc. available 
> in our system so this is just a software question. Is there an advantage of 
> EEPROM over flash in terms of erase cycles?

Look at the data sheets, commonly EEPROM's are designed to be cycled, 
whilst FLASH, expecially uC flash, is not.
Often EEPROMs use hidden Error correction bits, to get the cycle counts up.

The best separate-chip technology for non volatile counters would be
Ramtron's FRAM devices. Zero write delays, and no life cycle limits

<paste>
> Are 
> you saying that degradation might not be localised to a single bit? In that 
> case I could save myself the trouble of separating out the bits.

My point is, you will need to test this, to be really sure.

>> I would use a small, low cost micro (PIC maybe) and save the count in the
>> EEPROM. Single chip solution.
>>
>> Thomas
>>
> Oh, I should have mentioned that we already have flash, RAM, etc. 
> available in our system so this is just a software question. Is there an 
> advantage of EEPROM over flash in terms of erase cycles?
>
> Andrew
>
>

Here is a quote from Wikipedia:

 "While RAM has no limitations on rewrites to memory, EEPROMs are limited in 
that repeated write and erase cycles eventually damage the thin insulating 
layer, a process called 'wear out'. Some early EEPROMs could only perform 
about 100 erase-write cycles but new models specify 100,000 erase-write 
cycles or more. Flash memory is cheaper than EEPROM but will wear out 
faster, typically after 10,000 erase-write cycles. Another reason why EEPROM 
is more effective for storing configuration data is that Flash memory has to 
erase multiple memory locations at a time. Changing a single byte is only 
possible by rewriting a whole block, which causes the flash memory to wear 
out more quickly than one might otherwise expect."

Thomas 

"andrew queisser" <andrewdotqueisser@hp.com> wrote in message 
news:uc4Fg.126$b75.121@news.cpqcorp.net...
> Hi all,
>
> I'm thinking of ways to implement a nearly non-volatile counter using 
> flash and RAM. Idea is to count events in a RAM counter and write the 
> count to flash every n times. At first I thought I'd just use successive 
> locations in flash until I need to reformat the entire sector but I'm 
> thinking it may be better to flip single bits from 1 to 0 with each bit 
> indicating n events. That way I don't waste an entire DWORD for each 
> update.
>
> Does anybody know of a ready-made solution for this kind of thing?
>
> Thanks,
> Andrew
>
>

Look into ferroelectric ram.  It is fast writing, reading and is 
non-volatile.

Don