# Elapsed time between writes to SD card

In a 512 byte block write to an SD card, how much delay time between successive single or double byte writes is allowable? Is the total time it takes to write the entire block the limiting factor? How would too much of a delay time to complete the writes manifest itself?

Why would you use a delay() between writes? Does your application need it? Why does it need it?

I meant delay, as in elapsed time, not delay().

jboyton: I meant delay, as in elapsed time, not delay().

In which case it will have no effect at all.

In a 512 byte block write to an SD card, how much delay time between successive single or double byte writes is allowable?

This question does not make sense. When a block write occurs, the whole block is written at once. The bytes in the block are not written one by one.

What, EXACTLY, is it you are trying to learn?

Grumpy_Mike:

jboyton: I meant delay, as in elapsed time, not delay().

In which case it will have no effect at all.

Are you saying it doesn't matter to the SD card how long it takes to write a block?

PaulS:

In a 512 byte block write to an SD card, how much delay time between successive single or double byte writes is allowable?

This question does not make sense. When a block write occurs, the whole block is written at once. The bytes in the block are not written one by one.

I think they are written one at a time, at least in the library I’m using (Sdfat). Here is the code that writes the block:

``````inline void SdSpi::send(const uint8_t* buf , size_t n) {
if (n == 0) return;
SPDR = buf[0];
if (n > 1) {
uint8_t b = buf[1];
size_t i = 2;
while (1) {
while (!(SPSR & (1 << SPIF))) {}
SPDR = b;
if (i == n) break;
b = buf[i++];
}
}
while (!(SPSR & (1 << SPIF))) {}
}
``````

PaulS:
What, EXACTLY, is it you are trying to learn?

What I want to learn is what the timing requirements are for writing a block. Can I take as long as I want or is there some timeout that occurs if it proceeds too slowly.

The reason I’m interested is that I’m trying to scavange ram and I’d like to do away with the 512 byte buffer. If I could build the output stream on the fly it would require about half as much ram as the buffer. But I’d need some processing time in between writes.

You can take a long time to write a block if you keep chip select low. The card should not time out so just stream the 512 bytes of data to the card as you acquire it. Most cards should tolerate this.

Another method is to only write a little data to each block and fill the rest of the 512 byte block with dummy data. Cards have a huge number of blocks so wasting space is not a problem.

See this link. Petit FAT File System Module http://elm-chan.org/fsw/ff/00index_p.html

Thanks, I was hoping you'd chime in. That's good news that the timing isn't an issue. I had tried inserting short delays and the card seemed okay, but I wasn't confident in this evidence as my understanding of SD cards is almost nil.

It may be easiest and most efficient to simply fill out 90% of each sector with zeros. Even wasting so much space I won't fill the card. I wish my text editors would properly display lines greater than 256 characters though.

Petit FAT -- I hadn't seen that before. It appears to require pre-allocated files, like uFAT. I may end up having to accept that limitation if I can't fully solve my memory issues by trimming the fat, so to speak, elsewhere.

if I can't fully solve my memory issues

An idea I've been rolling around in my head as a way to reduce RAM requirements: why not use 512 bytes of EEPROM as the write buffer? EEPROM has a write life of 100,000* cycles, but if you only write to SD 100 times a day, the EEPROM will still last for almost 3 years.

• Anecdotal evidence suggests that 100,000 is very conservative and more than double that life may be attained.

Of course, another option is an I2C SRAM chip...

Another option is a microcontroller with more memory.

I suppose EEPROM could be used in some project but it wouldn't work for me. It's really slow to access. That by itself is a non-starter. And even at a modest data rate it would burn out pretty quickly. In my intended use it would only last a few hundred hours.