[En-Nut-Discussion] Nut/OS and file in external EEPROM

[Dusan Ferbas]

Hi Hugo,

I will not controvert your arguments. We were just looking for any easy 
solution that allows us to upload web pages to a device which will be later 
able to offer them.

The reason why we did not implement some mechanism with bucket oriented 
file system (clearing of FF bits in some FAT like system) is because we 
used DataFlash. It is a paged device with buffers. This speeds up writing 
and device offers also ability to erase a single page. But Atmel do not 
recommend to write a page without previously clearing it. So the idea of 
reverting 1's to 0's is gone.

If you can use parallel Flash then you can access every byte and you can 
play with bits etc. I have experience with Am29F010-40 and AM41DL3238G. 
Here you have to erase device by sectors (various length according to 
device capacity).

Regarding contributed implementation: File table is stored in internal 
EEPROM, you can delete only last file and you can append only to last file. 
Starting files are expected to be static. Last one can be used for log etc. 
You can also add more log files sequentially.

For file API look into Project/SPI_Flash/file_sys.h.

You can find here some kind of flexibility. If you need to change files 
very often then you will probably look for some other solution. We are 
currently satisfied by uploading part of application logic in JavaScript or 
Macromedia Flash. Of course there is a security mechanism that you have to 
enable upload explicitly. But you can modify this behaviour in source code. 
You can also maintain multilingual versions with this pseudo file system.


-------------
>Hi Dusan,
>
>I am interested in your DF Filessystem and made a quick search for how it
>works. It seems that you build a directory structure somwhere in the Flash.
>That means that you have to alter that directory everytime you write any
>file to the flash. Since flash memories have a limited number of writes per
>lifecycle, I think this directory page will become the first area which
>fails because there are most of the write accesses.
>Anyway, can your filesystem delete any file at any time, or can you only
>delete from the end? Is it it sequentiell filesystem or a random access one?
>
>I thought (not realized yet) of building the files from a bunch of pages
>which are randomly scattered around in the dataflash. The first byte of each
>page signals if it is an empty page (0xff), a first page, or any other page.
>Following this indicator is the number of the next page of the file in the
>second byte and if it is the first page there will follow the filename and
>maybe some other file infos. This design will bring the following features:
>
>- you can delete/modify any file at any time
>- you dont have one central directory which is the first area that will fail
>
>But there is also a disadvantage: since you don't have a directory you have
>to look at every sector to find a file. Read the first byte, is it a first
>sector byte read the filename. Is it not the one that you are looking for
>get the next sector. I have no experience now how long that search will
>take. What do you think, is it too slow?
>
>The other thing I don't know, can I delete every single page of the
>dataflash? I read something about blocks containing more than one page.
>Maybe you only can erase a complete block. Then my design will get
>complicated with deleting files.
>
>What do you think of my idea?
>
>Thanks
>Thorsten

Dusan