Post by thread:Re: [EE] Flash and EEPROM based file systems

anyone have any code dealing with implementing a file system on either FLASH memory or any other type of memory.. I'd like to get a 1 MB flash chip and put a small filesystem on it but rather than try to design the thing myself I'd like to sample what's out there.. I haven't turned up much. I plan on using the Atmel SPI Flash memory chips and figure that with a 16 bit pointer I could have access to 4 MB I want to make a tiny file server :) Thanks, Damon Hopkins

<x-flowed>At 04:14 AM 5/28/00 -0400, you wrote: >anyone have any code dealing with implementing a file system on either >FLASH memory or any other type of memory.. I'd like to get a 1 MB flash >chip and put a small filesystem on it but rather than try to design the >thing myself I'd like to sample what's out there.. I haven't turned up >much. I plan on using the Atmel SPI Flash memory chips and figure that >with a 16 bit pointer I could have access to 4 MB I want to make a tiny >file server :) Because of the finite lifetime of eeprom, you might consider one of the systems used for CD-ROM or CD-RW. Or, a simple method is the use a linked list directory. When a file gets replaced more than N times, mark the entry as deleted and replace it with a new entry the first one is linked to. This results in slower directory accesses, but predictable write cycling of memory. Of course, if your data will be write-once and only appended to, you could use one of the classic simple file systems, such as the CP/M-DOS FAT16 method (well-documented in the IBM Technical Reference Manual for the PC, or in Dr. Dobbs). ================================================================ Robert A. LaBudde, PhD, PAS, Dpl. ACAFS e-mail: spam_OUTralTakeThisOuTlcfltd.com Least Cost Formulations, Ltd. URL: http://lcfltd.com/ 824 Timberlake Drive Tel: 757-467-0954 Virginia Beach, VA 23464-3239 Fax: 757-467-2947 "Vere scire est per causas scire" ================================================================ </x-flowed>

"Robert A. LaBudde" wrote: {Quote hidden}> > At 04:14 AM 5/28/00 -0400, you wrote: > >anyone have any code dealing with implementing a file system on either > >FLASH memory or any other type of memory.. I'd like to get a 1 MB flash > >chip and put a small filesystem on it but rather than try to design the > >thing myself I'd like to sample what's out there.. I haven't turned up > >much. I plan on using the Atmel SPI Flash memory chips and figure that > >with a 16 bit pointer I could have access to 4 MB I want to make a tiny > >file server :) > > Because of the finite lifetime of eeprom, you might consider one of the > systems used for CD-ROM or CD-RW. > > Or, a simple method is the use a linked list directory. When a file gets > replaced more than N times, mark the entry as deleted and replace it with a > new entry the first one is linked to. This results in slower directory > accesses, but predictable write cycling of memory. > > Of course, if your data will be write-once and only appended to, you could > use one of the classic simple file systems, such as the CP/M-DOS FAT16 > method (well-documented in the IBM Technical Reference Manual for the PC, > or in Dr. Dobbs). > > ================================================================ > Robert A. LaBudde, PhD, PAS, Dpl. ACAFS e-mail: .....ralKILLspam@spam@lcfltd.com > Least Cost Formulations, Ltd. URL: http://lcfltd.com/ > 824 Timberlake Drive Tel: 757-467-0954 > Virginia Beach, VA 23464-3239 Fax: 757-467-2947 > > "Vere scire est per causas scire" > ================================================================ I was thinking of a fat16 type of system I'll work of my hand scribbled notes into an HTML document if anyone would be willing to look at it and HOPEFULLY give me suggestions or ideas.. the main purpose of the file system would be to have multiple files that are mainly read. there should be very little writing.. I'm thinking about this as being used in a web server type application. maybe I should write it out in HTML anyway just to MAKE myself be more specific :) Damon Hopkins

> >I was thinking of a fat16 type of system I'll work of my hand scribbled >notes into an HTML document if anyone would be willing to look at it and >HOPEFULLY give me suggestions or ideas.. the main purpose of the file >system would be to have multiple files that are mainly read. there >should be very little writing.. I'm thinking about this as being used in >a web server type application. > > maybe I should write it out in HTML anyway just to MAKE myself be >more specific :) Maybe you have to go something like this: Go flash. Then, just make a sort of adapted FAT system. Loose all the data/time/atrrb information so that you only retain 8 byte namen 3 byte extention (no dot between them, it just takes up space), and a pointer to a particular memory space where the file is located. In the first 2 bytes or so the length is recorded for the file, so you know where the file ends. E Voila! But when you've got to alter the contents of your FLASH-DISK, just flush the whole thing and write a new adapted file- table. Ofcourse you will write a VB application or so for that task.... Jilles

> anyone have any code dealing with implementing a file system on either > FLASH memory or any other type of memory.. I'd like to get a 1 MB flash > chip and put a small filesystem on it but rather than try to design the > thing myself I'd like to sample what's out there.. I haven't turned up > much. I plan on using the Atmel SPI Flash memory chips and figure that > with a 16 bit pointer I could have access to 4 MB I want to make a tiny > file server :) I have plans for the same type of project. Maybe we (and/or some other members of the list) should join together and make this reality. The driver _I_ need has these properties: - written in ANSI C - offers ANSI C inspired functions for file access (fopen(), fread() etc) but does implement only the basic functionality, no need for 100% compatibility. - optimized for write-once-read-many files (data) and append-write (logfiles). With "optimized" I don't mean that other access profiles are forbidden, just that those might suffer an impact in speed. - data, once successfully written, is guaranteed to remain intact. only files currently written to might be lost on powerfail/crash. - as little traffic over the SPI as possible. - where possible, stick to 64bit boundaries for data fields (for example in directory or file list blocks) to support later addition of encryption. Most older crypto algorithms work on 64bit blocks. Do you see enough convergence for a co-development? Please send me email (list or private) when you're interested in working on such a file system. I'm quite experienced with the technology and limits of flash, and am convinced that my capabilities cover this project completely.. If only the day had 35 hours..