SD Card Datalogger - how to delete a file?

[HummingbirdElec]

Hi - I'm using a JM128 interfaced to an micro SD Card.  My software is based on the Freescale FAT16 lite driver.  After a little pain, I can create files and log data to them.  Now I would like to be able to delete a file.  I can'f find a function to do this.  Am I missing something?  How can i delete a file?

[guille]

Hi there, I just published a revised version of FAT Lite. Some improvements were taken from this thread (Re: Problems porting SD FAT to MCF51 JM Badge Board - Datalogger application),  the others were the result of the efforts of me and my team.

http://code.google.com/p/sdfatlite/

Cheers!

https://community.nxp.com/message/310772/edit" style="font-style: inherit; font-family: inherit; col...

[farhud]

Can you tell me how you are connecting the SD card to JM128? I am thinking of doing the samething. I have the EVB51JM128 board and it has a USB jack. I'd like to connect a USB memory card to this board and create some file with data on the USB memory card.

[HummingbirdElec]

Are you wanting to write to a USB memory device or a SD card?  Have you looked at the USD datalogger examples from Freescale?

[farhud]

Well, my board has USB input and I was wondering if I can insert my memory USB stick to it and be able to create files on it using my EVB51JM128 board. If there is a way to connect an SD card and do that task, it will be beneficial. Have tried a USB memory stick? I will take a look the document you suggested also.

[mjbcswitzerland]

Hi

Since I use utFAT on the Coldifre V2 and not the V1 I can't offer a direct solution, but you can get a good reference in the FATFS code too. Deleting a file is quite easy to add if there is not yet code available to do it.

For files with short file names you need to locate the file entry (other functions will do this) and then write the first letter of its name to 0xe5 (free directory name). This will mean that the file no longer appears, but its content is still there occupying space.

To delete the content it must be located (the file entry has a reference to the first cluster that it is occupying via the FAT) and then each cluster in the cluster chain freed by marking it either as empty or as dead (the exact method is implementation dependent and can aid in undeletes if not totally removed). This is a modification in the FAT and the data is still there in the clusters (unless it is desired to also delete the cluster content for some security purposes).

Additional details which are probably not directly relevant for a small FAT16 implementation:

• If FAT32 you would need up update the info sector accordingly and, depending on implementation, you may have two coipes of the FAT to keep in sync.

• Deleting long file named files is a bit complicated since also the name is linked in a directory object list and the complete list needs to be deleted, which means running backward through the list (extremely inefficient on a large card...and I believe that Windows will keep a copy of the FAT in RAM so that it can do this without needing to access the card itself - not really practical in embedded systems).

• Deleting a directory means deleting all files in it (one at a time) and then finally deleting the directory. A directory is pretty much a file without any content so the method is practically identical.

For details of FAT in general and utFAT in particular there is a comprehensive guide here: http://www.utasker.com/docs/uTasker/uTasker_utFAT.PDF

This may be available for the V1 in the future but nothing concrete at the moment.

Regards

Mark

www.uTasker.com

[HummingbirdElec]

Hi

Thanks for your help on the delete feature.  A further question.  I notice that as my file gets larger and larger, the time taken to open the file "u8Error=FAT_FileOpen(FILE_NAME,MODIFY); " takes longer and longer.  I imagine it is becuase it has to look at each entry and find the last one.

Is there a way to speed up the file open utility?

Best regards, Norman

[mjbcswitzerland]

Hi

The time to open a file doesn't depend on its size because only the file object has to be found to locate its position. This will always be at the same location and a search for it will always require the same time if the location of the file is not changed to different directories.

Before writing new data to the file it is however necessary to search through its clusters to find the last one. This is dependent on its length.

Therefore it depends what the open does. If the open just locates the file (effectively to the start of the file) it should always take the same time. If it perfoms also a "seek" to the end of the file so that new data can immediately be appended to it, it will take longer as the file grows in size. I don't expect that it does this since it means that a read will not return anything since the file pointer is already at the end of the file and to read the start of content the user would first have to command a "seek" to the start again. But, not all FAT implementations implement seek so perhaps it uses a read pointer (always at the start) and a write pointer (always at the end and requiring additional time when opening) and doesn't allow changes to already existing content(?)

Regards

Mark

[HummingbirdElec]

Hi

You are correct, my FAT16 finds the last cluster.  It can take up to 30 seconds to open a 10MB file!!  Since I need to keep eriting data to the file and can't wait 30 seconds, I see two options:

1) I could just leave the file open and keep adding data.  I see this as risky as the file may become corrupt.

2)  Could I store the location of the last cluster in in non-volatile before closing the file and then speed up the process of finding it when I next open and modify the file?

What do you think?

Thanks, Norman

[mjbcswitzerland]

Hi Norman

I don't think that there is any risk involved in keeping a file open. The open has nothing to do with the SD card - it simply means that the software knows details about the file (where its information is, where it starts and where its present read/write pointer is). If you are presently at the end of a file it means that data can be written without needing to seek to the end again, which is obviously faster than when the seek still has to be performed.

Theoretically one could save the present file position to non-volatile memory and reload it rather than having to perform the seek. This would be (much) faster.

The 10MByte seek time does however seem rather slow but this is implementation dependent, SPI speed dependent and also cluster size dependent. Formatting with larger cluster sizes will mean that a search through a cluster list will be faster since there are less invividual clusters to be searched through.

Regards

Mark