On an Arduino with 2048 bytes of SRAM, how many 512 byte buffers are you going to create? The SD class already has one per file.
I don't see how this will help, since the File::print() methods block when the SD class buffer gets full, until the transfer to the card is complete.
The File::print() method is interruptible. If the Sample routine is 'fast' enough (low overhead), the impact sampling will have on the File object is minimal. The OP never defined which Arduino he was using. If he is using one of the smaller memory size MCU's he could use multiple smaller buffers, (i.e. 128byte). As long as the maximum FILE blockage is less than his total buffer size it will work.
Let's say he wants 200 samples/second, and each sample is eight bytes (x,y,z + tick) so a 128 byte buffer will hold 16 samples. Or 0.080 seconds. If he has four 128byte buffers (0.320 seconds). His worst case was 0.150 seconds. I expect that using four buffers would usually have three buffers empty most of the time. If his main loop was posting each buffer, the FILE object would add the first three 128bytes to it's sector buffer and quickly return. The Fourth buffer write would block until the actual write is completed. Meanwhile, the other three buffers are empty, giving a 0.240 second period for the write to complete.
This is of course a simplistic example, we do not know how he is obtaining his samples, how big each sample is, and what hardware is being used to sample.
My assumption (ass, u, me) is that the accelerometer is NOT a SPI device. If it is a SPI device, the SPI.beginTransaction() locking of the SD library will inhibit sampling sometimes. Will these dropped samples be acceptable? That is for the OP to answer.
The code would need some statics:
- buffer overflow (no empty buffers)
- Maximum number of dirty buffers (main loop generated)
- number of missed samples (if exclusive hardware interference exists)
- Maximum duration of missed samples (Sample code increments counter until successful sample)