SD Card, do I need to close after each write?

Other Hardware Storage
1

I'm building (yet another) data logger.

Looking at the Arduino Reference it seems each example closed the SD card file after each write.

My question is, is closing the SD card after each write something unique to the SD Card memory or is it just how the example was written (to show all the functions).

I understand the risk of leaving a file open that might be corrupted on a power glitch.
Also as the reference stated you have to close one file in order to read another.

I guess I'm thinking there might be a wear issue with doing more than is necessary with the SD Card.

Am I on the wrong though path?

Thanks

John

1 Like
2

JohnRob:
My question is, is closing the SD card after each write something unique to the SD Card memory or is it just how the example was written (to show all the functions).

No need to close. However, data is written to a 512 byte buffer which is only saved when filled, so you may lose some data on power loss. You can use flush to force a save.

Also as the reference stated you have to close one file in order to read another.

Once true perhaps. I don't think it is any longer. Of course in practical terms, each open file will need a buffer, so on something like an Uno, you won't be able to have very many open at the same time.

3

wildbill:
each open file will need a buffer, so on something like an Uno, you won't be able to have very many open at the same time.

Nope, the buffer (actually a "cache") is shared between all File instances. Each of them actually takes 38 bytes of RAM.

What you MUST NOT DO is to create more than one (opened) instance on the same file; otherwise inconsistencies might occur and so data corruption/loss.

4

Lucario448:
Nope, the buffer (actually a "cache") is shared between all File instances. Each of them actually takes 38 bytes of RAM.

And because it's shared, if you have two open files and write to them alternately, then the cache has to be flushed to the SD card every time you switch from one file to the other. The flush is terribly expensive (because the SD card is cluster oriented, flushing the cache writes at least 2048 bytes to the SD card no matter how much new data has been written), so arranging to have as few cache switches as possible can really speed things up.

5

If you never close() the file then the file shows as zero size when you open it on your PC. The directory entry never gets updated.

sync() will update the directory without closing, so it is a little more efficient than close+open.

6

MHotchin:
And because it's shared, if you have two open files and write to them alternately, then the cache has to be flushed to the SD card every time you switch from one file to the other. The flush is terribly expensive (because the SD card is cluster oriented, flushing the cache writes at least 2048 bytes to the SD card no matter how much new data has been written), so arranging to have as few cache switches as possible can really speed things up.

Correct. That's because the ATmega328P barely has enough RAM to handle mass storage devices; so multi file instancing has to have its drawbacks.

MorganS:
sync() will update the directory without closing, so it is a little more efficient than close+open.

sync() is for the underlying SdFile instance; for the File "wrapper" its name is flush().

7

Lucario448:
sync() is for the underlying SdFile instance; for the File "wrapper" its name is flush().

Thanks for the correction.

1 Like