For example, the voltage on an analog pin. I'd like it to be able to log in millisecond time (or nano second, considering how fast one can read/write with the ports with port registers), and then save it to an SD card.
I'm thinking the best way to do it is to save the data to the arduino's internal memory, for the sake of speed, and once that is filled, write it to the SD card. However, I think the limit is the size of the arduino's internal memory; how much data can an UNO really handle?
Whoa there, let's make sure we're on the same page. Millisecond log times are entirely doable with an SD card, nanoseconds are entirely impossible. On a good day SD cards can write a few hundred kB per second (my experience...others on this forum are more expert and can probably quote more concrete numbers).
It definitely makes sense to write data in 512-byte chunks, and using interrupts to log the data to 1 buffer while writing a 2nd buffer to SD is a good approach. Setting aside two 512-byte buffers uses up half of the UNO's 2kB of RAM. So it's doable, but leaving some room for stack space means you only have about 500-700 bytes of RAM left to play with. That might be enough, depending on your application.
You can't store into flash so that's out.
http://arduino.cc/en/Reference/PROGMEM:Store data in flash (program) memory instead of SRAM.
It may be an option not to write all data.
The dual buffering system mentioned seems the best idea but if the data is constant you won't have time to save it somewhere. And yes interrupts will introduce some jitter, better off without them.Exactly what sample rate do you need and for how long? (Hint, you can have fast and you can have long but not both).
I don't think that's true. What about with the prgspace library?
Quote from: Graynomad on Mar 29, 2012, 01:03 pmYou can't store into flash so that's out.I don't think that's true. What about with the prgspace library?
Quote from: Jantje on Mar 29, 2012, 01:49 pmIt may be an option not to write all data.Unfortunately, not this time; I'm trying to do time measurements of microsecond pulses; essentially the times between pulses, so I can't omit much of the data.
But, there's another way using the i2c, increasing the read/write speed to 400KHz:
at least in the single digit milli second time.
That's for storing read only data that you set at compile time - you can't write on progmem at runtime.
QuoteBut, there's another way using the i2c, increasing the read/write speed to 400KHz:But where will you move it to?
1-9mS, that's heaps of time for the processor to read and store data in general, but I don't know much about SD card timing.If you can save say 512 bytes to the SD in < 512 x sample-rate then the above-mentioned dual buffer idea should work. And despite my reluctance to use interrupts they may be required in this case.You set a timer up to interrupt every (say) 5mS, the ISR does a reading and stores in buffer A. If the buffer is full it sets a flag.The main code waits for the flag, when it is set it swaps a pointer to the buffer B and proceeds to save buffer A. 512 samples later the procedure is repeated with the pointer being swapped back to buffer A.
Or am I really misunderstanding everything, in blind hope?
I think I'm unclear on the benefit of an interrupt..
simply write buffer A to the card in that same if block?
You may be using the wrong microcontroller for the task.My suggestion would be to graduate to a Maple, ChipKit, or similar board that offers oodles of RAM, high clock speeds, etc.
Yep, I2C can't talk to an SD card. Normally you use SPI.If you use interrupts it's like having two separate jobs running so as long as the SD code doesn't disable the interrupts you will have a small amount of jitter but overall it should run smoothly.Bottom line, we need to know more about writing to SD cards on the Arduino.
I've heard there's a faster alternative to the standard arduino library that I can use; is this true?
On a good day SD cards can write a few hundred kB per second