Making a copy of UTFILE .

[neil]

Hi Mark,
  After a write to the SD card, I want to read the block back in to verify the data has correctly been written. Is it possible to take a copy of the UTFILE handle before the write, and then use the copy to read in the block just written to verify? Or am I best using another UTFILE variable? I am trying to avoid using useek as you mentioned this can take a bit of time to execute.

Thanks
Neil

[mark]

Hi Neil

If you keep a file open and its UTFILE struct valid it means that you can write (add more data) more efficiently. This because an open doesn't need to be performed and the internal file pointer is alread at the end of the file.

Reading doesn't however have such great benefits. By keeping the file open you don't need to open it again but the internal pointer is still at the end of the file. To read the data that has just been written it is still necessary to "seek" to the location. The seek backwards always needs to seek from the start of the file in the forward direction and so is less efficient than a seek forward from a location already close to the search part of the data (the reason being that clusters are linked only in one direction and so backward searching is not really possible).

If you make a backup of the UTFILE before the write it is correct that it contains the location of the data before the write was performed. After the write is executed it will however be necessary to sets its entry ulFileSize to match the new file size otherwise a read will not work since it will think that it is already at the end of the file. Then a read with the backup copy of the UTFILE will indeed allow a faster read (no open and no seek to the last location).

There is however a potential problem (although I don't think that it will ever be a difficulty with a read following a write) and that is due to the fact that the utFAT interface uses a backup buffer of the last sector read or written to the card. If a read of the same sector is made that has been written it may not actually read form the card since the local data copy is still valid (this is like a small cache). Since there will have been a write to the FAT at the end of the previosu write an immediate read would in fact always cause a read form the physical card, but it is worth bearing in mind that this may not always take place in every situation.

Therefore such a trick would in fact work reliably in this particular case and would result in a faster operation.

Regards

Mark

[neil]

Hi Mark,
  Thanks for the reply.  After the application writes the data to the SD card, straight away it writes 1k buffer to a dummy file ensuring that any backup buffer on the card is flushed to file. I do this incase of a power cut and lose the data. So am I right in thinking that if I do the read as previously described, after this dummy write then it will read from the card and not buffer?

Many Thanks
Neil

[mark]

Neil

Since the data write is always followed by a FAT area write, following read data is guarantied to be from the card rather than the buffer without doing anything special.

Regards

Mark

[neil]

I have created UTFILE on the stack, and works fine as discussed. Before the UTFILE variable goes out of scope, do I have to do anything with it (for example close)?

In my application I send data through GPRS, and if I dont get an ack. from the server I do a seek to go back to the posiotn before sending (so can resend). If I take a copy of the position as above, would this be faster than doing a seek command?

Thanks
Neil

[mark]

Hi Neil

When you call utCloseFile(&utFile) it does two things.
- it will set the contents of utFile all to zero
- if the file is opened in "managed mode" it will free its entry.

The managed mode allows blocking other users from editing, deleting etc. when it is used. If you don't open the file in managed mode a close is in fact not needed at all, but, if the file is blocked by using managed mode a close should may be required to ensure that it is freed.

I think that it is a valid method to keep a backup of the file reference using this technique to save having to seek to the position again. It will certainly be faster. The only potential difficulty is when another user edits the file because this can cause content to be overwritten and so also be at different cluster locations on the disk (the backup UTFILE struct will get synchronised when using managed files which are not blocking other users from doing this but this is only in respect to the file position and file size) so the location information may not remain accurate - in this case a seek is the only solution, but in simple systems where there is only one user of a file (or other users are blocked) it will be OK.

Regards

Mark