avoiding flash memory writes as much as possible

10K writes to a given memory cell or 10K cumulative writes to the flash, regardless of location? *Generally* the flash vendor implements a decent leveling algorithm that spreads the "damage" out over the entire array.

Cache data to scratchpad RAM and do One Big Write to flash.

There's rarely a single best approach, especially when significant details (O/S, available RAM, types of RAM, ...) are missing.

In general (so this may not apply in a particular situation) use short-life flash as read-only media, e.g., only to boot and to load executables. Use "regular" RAM (probably SDRAM, given the presumed architecture) as a write cache. Use replaceable flash (such as an SD card or a USB stick) for data logging.

Try not to get into this situation in the first place? Sounds like some upstream design decisions weren't optimal.

--
Rich Webb     Norfolk, VA

Use RAMDISK. Or, better, use a sensible way of communication between the processes. There are many depending on the OS that you use.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

h.

As it turns out the Flash does do write leveling. Im working for the guy who does the hardware, but this is his first embedded device also. We are using a Linux kernel 2.4.36 (because for now we are stuck at that revision level for a while).

Ive only done desktop systems so Ill have to look into RAMDISK.

What form of communication would you suggest knowing its a linux kernel? Im very familiar with writing tcp/ip client/servers, but if another IPC is much smaller (code wise) Id have to figure it out since Ive never done an IPC.

On Sat, 4 Apr 2009 17:42:05 -0700 (PDT), Bob wrote in comp.arch.embedded:

My first suggestion would be to tell your hardware guy to find a flash with a much larger write allowance. 100K to 300K is easily available now. Is this flash soldered to the board?

If you can put in a socket for SD cards, the flash can be easily replaced when it wears out, and longer-lasting cards are appearing constantly. The same is true of compact flash cards, but they are more expensive now and are going to stay that way. SD has won the flash card wars.

There are two other bits of advice I can offer for using Linux with flash.

First to make sure you built the kernel so that it will run with a swap partition, or make sure that you do set up a ram disk for the swap partition to live on.

Second, for any file systems on flash, you want to mount them with "noatime", and possibly "nodiratime". Otherwise, any time you even read a file from flash through the file system, the file system will rewrite the directory entry for that file to update the last accessed time. Consult your system's documentation for the best way to do this.

But 10K write cycles is certainly way too small for a flash used in an embedded system, especially if it is soldered and not easily replaced.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Bob schrieb:

You may have a look at

These devices are like RAM - fast and with unlimited write cycles, but nonvolatile like eeproms.

--
Mit freundlichen Grüßen

Frank-Christian Krügel

the

e

Be sure to build your root file system on ramdisk. Otherwise, you will write to flash periodically even if you don't do anything.

You take care of the root file system and it will take care of system buffers and IPCs.

Yes, even old CF can write 100K cycles or more.

But small CFs are much cheaper and easier to run as IDE. We run small disposal CFs as primary file system and larger read only CF as data storage. We replace the $1 CF every few months, just in case. The larger 1G,2G,4G CF lasts for years.

They don't.

This would normally be done using either shared memory or Unix-domain sockets.

But if you want to retain your existing design, you can just create a RAM disk and store the file there.

Hi Bob.

If you want to leave it as a file exchange: mount -t tmpfs -o size=3D10M none /mnt

You may already find that /tmp is created as a tmpfs file system.

Steve Schefter