EEPROM File System
Dave Hein
Posts: 6,347
I want to begin working with file system code, such as fsrw.· However, I want to use an EEPROM instead of an SD card.· Does fsrw support EEPROMs, or does anybody have spin code that implements a file system on EEPROM?
Dave
Dave
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In the end it depends on the usecase. If you change content very often FAT is fine, because it allows files to be split if continuous free clusters are not big enough to store the file. But using clusters also means to waste storage area, as it's moste likely that the last cluter is not completely filled. For a 32k EEPROM I'D suggest a cluster size of 128 bytes, so the cluster address range is 0-255, which can be stored in one byte.
An easy solution would be a linked list. You simply store the filename and the size of the file followed by the file itself. When you add file-position with filesize you'll find the next filename/size .... You don't waste bytes, your filename can be as long as you want ... But deleting/creating files is a bit of work.
The first time the program runs it will recognize that the EEPROM doesn't contain a file system and it will tell you to run the "format" command.· The "create" commmand will create a zero-length file.· The "dir" command will show a directory listing.· The "append" command will append a line of text to an existing file.· Enter a blank line to exit the append mode.· The "type" command will print out the contents of a file.
My orignal idea was to treat the EEPROM as an array of longs, with a file header that contained a blocksize, pointer to the next block and pointer to the next file.· A file consists of a chain of blocks of varying size.· Unused disk space initially consists of a large block that is as large as the EEPROM minus a few bytes for the disk header.· The unused disk space block is whittled down every time a new block is allocated for a file.
disk3.spin still contains the block headers for this method, but I am converging on a fixed-block size scheme, which will eliminate the need· for the block size parameter in the header.· My plan is to use block sizes, which match the size of the EEPROM page.· This is 64 bytes for the 24LC256.· This will allow me to easily take advantage of page-mode writes.· The header overhead will only be 3 or 4 bytes per 64-byte block.
disk3.spin used the clib and Basic_I2C_Driver object from the OBEX library.
Regards,
T o n y
Tony, I wrote the original code in C so I could develop it on various platforms.· This way I can tinker with it during my lunch hour at work, and then copy it to one of my PCs at home.· Once I get it working in C I convert it to Spin and run it on the Prop.
Dave