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.
Just for the sake of people who might experience this problem in future: First I must admit that my understanding of opening it with the "a" option was that you could then do a fseek() and then write to the middle of a file.
I received an email from Keil USA, basically stating that their file system does not support writing to a position in the middle of a file.
This in my opinion is a SERIOUS shortcoming for any file system as you can now only append to the end of a file or rewrite the file from scratch. How many times is it required to modify data inside a file - my guess is the most of all! I certainly didn't expect Keil to sell such incomplete software to their clients.
Thanks for all the replies.
just as the manual states clearly: "Seeking within a file opened for "w" mode is currently unsupported." if you have a file system that runs in RAM, maybe you can maintain your files there until it is required to update the non-volatile memory. this has obvious shortcomings, of course.
=>How many times is it required to modify data inside a file - my guess is the most of all!<=
For RL-FlashFS/Flash-Memory:
http://www.keil.com/support/man/docs/rlarm/rlarm_fs_mem_org.htm
When you want to erase the flash data, you need to erase the whole flash sector at once.
When the content of the file is modified, the old file content is invalidated and the new memory block is allocated. The Flash Block is erased when all the data stored in the Flash Block is invalidated.
fseek is not supported for SPI chip memories, e.g. dataflash, but is supported for MMC/SD cards.
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.