Hi Stefan
Before this get totally out of hand, let me just give you a quick rundown.
The basic Idea is not to tie a File Allocation table to a specific aria where it will wear out the flash. Rather to consider the file object as a piece of memory like you would in a linked list. This means you just have to find the first (indexed) peace and then you can access all the files header info?s sequentially. But let?s stick the name FAT for clarity.
The System starts by initializing the Flash, determining how big the Flash Page sizes are and then setting the appropriate offset addresses for wear level info, File info and data.
Once the flash type is determined and initialized it will allocate (malloc) ram for a ?FAT? page, A ?FATBAK? page and the amount of open files you want, let?s say 4. Then it scans the flash from start page (configurable) to end page, looking for a fat page and a fatback page. If not found, it?s clearly not formatted so it will be formatted with callbacks for the systems that has output and input. If found (the pages are indexed), the start page can be trace from there without the need to continue stepping through the flash.
Now that we have a fat start page and a backup start page we can load that page into RAM, read out file headers happily and find the file start addresses with an offset in the media.
To open a file with name ?FILE?, the fat entries will be stepped through until such a file is found, the Object will be loaded with start page, file number etc. the handle (pointer to object) will be returned.
So with a 2MB flash that generally uses 512 to 528 byte pages you roughly need 3K for the 2 fats and the 4 files you may want open at the same time. The SPI code for hardware, the wear leveling code, sector disturb/refresh code, the file systems and a multitude common file routines for text file manipulation all fit in 32K block on an 8051.
I have stored bitmaps and text files of up to 500K ? ¼ of the specific flash?s size without effort on this very small system. It is not intended for the larger Linux or ARM environment where as you mentioned, there are many available systems for.
Now I maintain my original point, this may be useful for some and it certainly works on the 8 different applications I rolled it out on of which there is about 3000 units in the field. If someone has a need to store and retrieve data on flash memory, this may work for them and for that reason I would like to put it out there, I am sure yours is much better and I?m really not trying to compete with you or anyone for that matter. So if you are not in favor of such, I take note, I apologize, hell ill even stand corrected, but it may just be suitable for one of the millions of people who were not going to buy you product anyway.
Please ? this intended to help, not for financial gain of any sort and I?m sure it will not affect your business in any way.
Still, I thank you for your input but I take exception to terms like ?Mickey mouse stuff? let part while things are still reasonably civil.
--------------------------------------- This message was sent using the comp.arch.embedded web interface on
formatting link