We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm posting this question here since Keil's support haven't answered my email so far: ---------------------------------------- I have the following piece of code:
fH = fopen(FILE_NAME_CLOCK, "a"); fseek(fH,20,SEEK_SET); fwrite(jbuf,1,sizeof(jbuf),fH); fclose(fH);
It is supposed to write to position 20 right, but if you look at the attached file it appends the data to the end of the file. What am I missing or doing wrong or is it a bug?
PS: Using Keil's RTK file system and µVision3 V3.80 on a ARM7 from NXP.
You are referring to how NAND flash works. That has nothing to do with the functionality a proper file system must provide.
Any proper file system must provide the programming with the standard file-handling API calls INCLUDING the functionality to modify the contents of a file. This is irrespective of weather the underlying storage medium is a harddisk, NAND flash, battery backed RAM, etc.
There are ways to modify the contents of a file that resides on NAND flash - the code must just be 'smart' enough.
For bigger flash file systems, you normally use some form of tree or list to describe the data blocks of the file.
Quite similar to how you store multiple small files in a larger flash sector, and later do a garbage-collect to reclaim the space from blocks that have been moved.
On the other hand - many flash file systems can't do atomic updates of file data, so a power loss when modifying a file may result in a garbled or totally lost file. Because of this, some flash file systems requires the user to create a new file, and then do an atomic rename to let the new file replace the old. A power loss at the wrong time will then either result in the new file being a lost block to be reclaimed on a later sector erase, or the new file having successfully replaced the old file.
The only problem here, is that this affects the code size for the implementation. It would be better if Keil could produce more information about their RT-LIB before people buy it - then it would be easier for customers to try to deduce if it is a good fit for the intended use.
I absolutely agree. I did development on a journalling file system for embedded linux and that's how I know it can (and should) be done on a file system and feel Keil's file system is incomplete in that respect.
Usually is a problem of RAM size (Data) not Code.