1. Home
  2. Embedded Programming
  3. Re: Large storage options for embedded systems

Re: Large storage options for embedded systems

To make a small computer that runs say Linux and needs at least 100MB

> non-volatile memory, I suppose most people would use one of the > following: > > microdrive 512mb - 1GB > compactflash 32mb - 512mb > flash sims 4mb - 128mb > small ide drive 4gb - 60gb > > Does anyone know of anything else out there? For my project of > building a small linux-running computer, I'm contemplating the > compactflash solution but I feel constant writing to one section of it > would yield lesser life than a microdrive. Is this the cheapest > solution? > > And how about storing most of Linux on a ROM that might be cheaper, > and letting a small flash be the read-write (/var, /tmp, /etc).

CF 'generally' does sector remapping so that even if you write one sector again and again you will evenly wear the whole flash. You can also get 1gb (and I think 2gb CF now).

Why would be constantly writing one sector?

Ralph

Reply to
Ralph Mason
Loading thread data ...

log files, wtmp etc are constantly written to in unix in small increments. I suppose that problem is rerouted by turning off all logs and the likes, and I believe one filesystem type in Linux distributes small writes across sectors somehow.

Do you think CF or other flash chips are reasonably priced at 1GB, to beat say the microdrive? And the approximate cost of just ROM chips of the same size?

Reply to
Ghazan Haider

I think you may be thinking of JFS.

Because of the automatic remapping I spoke about with CF, JFS isn't a good choice for that.

There have been plenty of threads on this lately in here.

Ralph

Reply to
Ralph Mason

Perhaps a ram drive for logs would work as well.

Reply to
Brett

I think you misunderstand the limits of flash. The life problem is due to the erase cycle. A block can only be erased a limited number of times, estimated at 100,000 to 1,000,000 in modern chips. Once erased, you can append as many pieces into the block as you wish until it is full. Then, until you move or delete it, the content is static. Wear leveling simply uses a different block each time it needs a new sector to write, so that it isn't erasing the same block all the time.

Someone else mentioned JFFS, which is optimised for flash. I believe it operates without i-nodes or a true directory, to minimize the erase cycles related to those clusters. The disadvantage is that it has to build the directory in RAM from the journal entries each time the system boots up.

Bob McConnell N2SPP

Reply to
Bob McConnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.