hello! I need to write data on an SD card, but writing has to be small - less than 1 ms/datum, which may be 150 bits, 40 if I try with a more ompact format. does anybody know how long it takes to write data on an SD card?
does anybody know how long it takes to write data on an SD card?
That would depend on how much data you are writing, whether you are buffering the data to write large chunks, whether or not you open and close the file for each write, and exactly which library/what methods you use to write to the file.
There is no easy "x microseconds per byte" answer.
yes, I mean the maximum rate achievable; say I want to write some some 20 characters (which are 8 bits each) at a time on a txt file, and I only open the file once and close it when I'm finished; how fast could I go?
As PaulS said there is no simple answer to this question. It depends on how you write the 20 bytes. The most efficient way to write 20 bytes is to make a call like this which will work with both the Arduino SD.h library and the SdFat library.
file.write(array, 20);
I ran my benchmark program which timed 250,000 writes of 20 bytes each. I ran the test on two SD cards. The results are.
SanDisk 2GB Extreme:
Maximum latency: 81960 usec, Min Latency: 44 usec, Avg Latency: 128 usec
Write rate 148.34 KB/sec
SanDisk 2GB standard:
Maximum latency: 66660 usec, Min Latency: 44 usec, Avg Latency: 197 usec
Write write rate 98.01 KB/sec
So the time for the above write to complete varies from 44 microseconds to 81960 microseconds.
The maximum time occurs because the card occasionally blocks operations while it erases a region of flash memory.
So the answer is the time to do a write has a huge range.
thanks, fat16lib, you've been very helpful! what about using an external eeprom instead? the built-in one isn't big enough for my needs. can you (or anybody else) help me?
no, I've just read in the EEPROM library reference that an eeprom write takes 3.3 ms, which sounds like a lot! do you know if it's possible to add SRAM, DRAM or something?
You may use FRAM or MRAM devices (google for FM25H20 or MR25H40) - those are 8pin SPI (up to 40MHz) chips with 256kx8 or 512kx8 capacity. Full speed read and write, nonvolatile, unlimited number of writes (it works like a SRAM).
p.
It is possible to log data to an SD at 20 bytes every millisecond if you use special techniques.
I recently wrote a program to log one byte samples at 100,000 samples per second http://forums.adafruit.com/viewtopic.php?f=31&t=30557&p=153175&hilit=100+ksps#p153175.
I have not posted this program but it is a modification of the binaryLogger example in fastLoggerBeta20110802.zip here Google Code Archive - Long-term storage for Google Code Project Hosting..
These programs use SD streaming write commands to write data to a pre-allocated contiguous file. the data is captured in an interrupt routine.
20 byte samples at 1000 samples per second should be easily possible.
I've got some timings for writing to an EEPROM chip using SPI here:
That doesn't have any file-system overheads. Assuming the chip starts erased, you could just do the writing part.
The figures there suggest that writing small amounts "seems" faster, perhaps because the chip hasn't actually committed the write yet. Writing 256 bytes took just under 2 mS.
Assuming the chip starts erased, you could just do the writing part.
The same thing could be done with SD, I think.
the SD lib has an erase fn so erasing all blocks before starting sampling should avoid the long delay fatlib noted above.
There's no reason why SD cannot be used as a single block device without the fs overhead as well.
(just be careful not to let it near a windows machine and say yes to the obligatory "reformat" offering).
PS am I correct in thinking that modern SD devices will have built-in load spreading, so that sequential writing will not burn out the first physical blocks on the device ?
Much of what ardnut says doesn't help. The item that is correct is SD controllers do load leveling so you won't damage a block by writing it repeatedly.
It is not using the SD as a block device that produces low latency writes. Single block writes are very unpredictable in terms of latency.
Erasing all blocks doesn't help much in single block write mode. I erase all blocks in my SdFat formatting sketch but single block mode still has long latencies on a freshly formatted SD.
To write with low latency, you must use multi-block streaming commands. There is a streaming command with pre-erase.
I just posted a sketch that logs data from an analog pin at up to 100,000 samples per second without losing data. This sketch uses streaming writes to a preallocated contiguous file.
This logger has very low time jitter in the interval between samples, a few ns at most. It uses a timer compare event to trigger the ADC which is much better than using a timer interrupt.
The sketch is in AnalogIsrLogger20120810.zip Google Code Archive - Long-term storage for Google Code Project Hosting..
There is 23K256 SPI serial sram (I've seen a pcb with it at sparkfun) - 20MHz clock, so with 16MHz uno you can write 32kBytes at ~1MByte/sec (not considering the data processing), no latencies, the same with much bigger fram or mram devices..
32 KB and even FRAM/MRAM is really limiting for many fast logging apps.
I log 16 bit data at 120 KB/sec so it eats storage.
Some time back I created a ramdisk, with xilinx cpld and single 4MByte sram chip - it works like a serial sram, but with 8bit data bus. You can write/read up to 15MBytes/sec with a fast MCU and you need just 11 signal wires to connect it to any mcu. It costs and you have to mess with cpld and a lot of very fine pins, however 
pito,
The fast external RAM is an old idea and won't help much for fast data acquisition.
Here is a more interesting use for a large RAM. Use the RAM as a FIFO for a really fast ADC. You could clock data into the RAM from the ADC at 15 MB/sec or faster and read it out over SPI at Arduino speeds. Even 4 MB at several million samples per second would be interesting.
Interfacing several ADC to the RAM FIFO would be even more interesting. Then you would have parallel channels.
Adding a fast external ADC to an Arduino doesn't work very well since it's hard to avoid excessive jitter in the sample interval.
Some internal clocked ADC have been used with an Arduino and triggered by a timer compare signal on a pin but these are not really fast.
In many application, jitter is as important as ADC accuracy. If you don't know when a measurement was taken you haven't captured the signal wave form.
Edit: Reading the FIFO in parallel with about 11 pins would be fine.
yes - that is a ramdisk/fifo, you may clock in what you want (any data width), the max writing speed is ~50MSamples/sec with that CPLD provided you will use 10ns sram. Reading speed with an MCU depends on how fast you can bitbang the pins 
pito,
No A RAM disk is not what I want.
I want the ADCs (multiple ADCs) integrated with the FIFO and controlled by a CPLD or FPGA.
I want to be able to program the sample rate so samples are taken at precise intervals and clocked into the FIFO without intervention by the MCU. This would allow very low sample interval jitter.
The MCU reads from the FIFO, maybe does some processing, and writes the data to storage.
Analog Devices makes a board with this functionality for high speed ADC testing and evaluation but it is very high cost. The Analog board can do 133 million samples per second.