Petit FAT file system with a MSP430

Question

Is there a way of clearing a file in the petitFAT format? What I came up with is this:

void SDerase(void)
{
    for(;;){
        res = pf_write("\0", 1, &bw);
        if(res || !bw) break;
    }
}

So this basically writes NULL characters to the files until it reaches the end. It works fine, but it's a bit slow. Erasing a 100 kb file takes roughly 1.5 seconds. I will be using bigger files later, possibly a few megabytes, so this method would take ages. Is there another method of erasing a file (.csv or .txt) with the petitFAT file system?

Answer 1

I'm trying to log some data, so if I don't clear it, it is sometimes hard to tell where the new data ends.

If you are logging ASCII data, this is not a problem. Simply reserve special characters for 'data begins here' and 'data ends here'. Even if you are logging binary data, it may be worth changing the encoding to something like base64 ( http://en.wikipedia.org/wiki/Base64 ) to net you special characters for controlling your data sequence (GB memory cards are cheap, and base64 only introduces 33% data overhead).

Alternatively, you could have an extra file that contains the data boundaries for your log files as a number of bytes. This is going to be a hassle with an interface as limited as petitFAT though, as you can only open a single file at a time. Depending on how much RAM and program memory you can spare on your MSP430, you may consider moving to a more feature-rich FAT implementation.

If I call the pf_write function by timer interrupt, how do I actually write it to MMC? From what I've read, it seems like I have to terminate write and reinitiate it again? e.g., this line pf_write(0, 0, &bw);

In a simple logger that does nothing but write sequentially to a single file you shouldn't need to call pf_write(0,0,&bw) until you shut down your device entirely. (It may or may not be necessary to do so before seeking to another position.)

If you absolutely want to stick with your 'overwrite entire file' idea, you could try whether first getting the file size and then writing larger blocks of \0s instead of single bytes gives you a significant speedup.