Flash file system for NOR flash

Here is a recent set of discussions - may be of some help:

http://e2e.ti.com/support/microcontrollers/msp430/f/166/t/348490.aspx

Have you considered FatFs http://elm-chan.org/fsw/ff/00index_e.html ?

It is quite lightweight.

Yeh, I went through it. I found a elm chan fatfs porting guide for spi flash. 

http://www.actel.com/documents/A2F_AC360_AN.pdf

Do you think this should be sufficient in order to make it work on NOR flash?

The FatFs module needs some low-level functions to operate the physical media, that is the NOR FLASH as a block device. You can have an idea about using FatFs with external NOR flash at

http://www.stf12.org/developers/FatFS.html

Also FatFs allows to set sector size = 4KB, which is minimal erasable amount on your NOR flash. If you select this option, the low-level driver becomes even simpler, no intermediate copy-modify-write back RAM buffers needed.

But you still have to provide some sort of wear levelling if you plan to do frequent files updates on your flash.

I am working on the application note that i gave link earlier. I will update once its done.

It depends on what you expect to store; The maximum file size, the number of files, can you use file numbers rather than file names, the structure of the files data split up in little blocks where only one block needs to be updated or whole file must be rewritten, etc.

In my application I am going to use max 40KB size file which is bmp image. All other data is less than even 4KB which is some sort user data. The file system I wrote before considering these things. In that  I kept some part of memory for indexing purpose. where FileName, starting address of data to be stored in memory, size of file, and a flag for marking file as deleted when user wants to delete it. The updated of files will not be frequent.

In the very past I wrote a RAM-drive similar to what you described here, just file numbers (1-255), a flag for compressed and, while the files are mostly needs partly update, fragmented, but RAM is easy to change.

In your case with fixed 40K bmp and not much updates I would use (maybe) continuous files.

For Flash I split it into sectors with size equal to Flash segment and divide the sectors into 8/16 or whatever smaller blocks, each block has a bit in a control bit-string per sector indicating if block is dirty and if all bits ‘0’ the segment can be erased. And using dynamic cluster size.

Before write I compare the data (if needed to write), AND the data maybe needs only to change bits from ‘1’ to ‘0’, if these are not possible mark block as dirty and create a new one.

When you write pointers inversed (0=FF and FF=0) you can simply overwrite a pointer to a new (higher) location. So reducing the need of Flash erase.

Well, if vast majority of your files is less than 4K in size why bother using any file system at all? It matches perfectly your physical device block size. Big part of the code for FAT-like systems is for managing clusters, which are building blocks of files. In your case most of the files arbitrary consist of only one cluster...

May be the code you wrote before is the better choice then.