I have a working project (works on ATXmega) where a 2Mbit data stream is read from SPI (via DMA) and is written to data storage.
I'd like to port it for Arduino board. As i see none support DMA.
The question is if it is possible to read 2Mbit/s stream of data and write it to SD card on any of Arduino boards ?
Correct, no DMA on Arduino's Atmega328.
So, hardware SPI on the Arduino can be clocked to 8MHz, but that does not include overhead. Overhead means that you can only send one byte at 8MHz, then there is a pause as the CPU performs instructions to loop and load another byte before you can start sending at 8MHz again. So average throughput is considerably less than 8Mbps.
How much data do you need to transfer in a burst? If it's enough to fit into RAM (not much over 1KB), you can probably read it at 2Mbps into internal RAM, then turn around and write it to SD at leisure before the next burst arrives.
If this is a continuous 2Mbps stream, it's real iffy. That's effectively 4Mbps (2Mbps in + 2Mbps out). At that speed you only get a handful of clock cycles to execute CPU instructions per byte (and one of those is spent on the loop jump, and another is spent toggling SS from input to SD card). That means no data processing, no error checking, no status LEDs, no nothing, just a bytestream. You'd also have to use direct AVR PORT calls and/or inline assembly instructions to reduce the overhead inherent in the built-in Arduino functions (dozens on CPU instructions per call).
Others here with more in-depth knowledge of the Atmega inner workings (how many clock cycles it takes to execute each instruction) could probably do the math to give you a better answer.
.. 2Mbit/sec is >200kB/sec. Such a speedy stream to write to an SDcard, with enough buffering (Sdcard's have latencies up to 250ms), you need something like teensy 3.0 (arm @48MHz, 24MHz SPI clock), chipkit Max32 (pic32 @80MHz, 20MHz SPI clock), Uno32 (pic32), or maybe Due (sam3).. All claim to be arduino compatible..
The bit stream is indeed much larger than available RAM.
Found a benchmark here : http://www.roland-riegel.de/sd-reader/benchmarks/ of 195kbyte/sec that is not so far from the 256kb/sec i need.
Another one here : http://arduino.cc/forum/index.php/topic,118529.0.html states "256000 bytes per second" in RAW mode.
Sounds pretty on the limit.... but may be possible ?
Maybe it is possible to write in 4bit mode ? Do you think it will be any faster ? is there any ready library for this ?
You cannot design such stuff "on the limit". Mind the write latency of an sdcard as well.
4bit/SDIO mode - I did some testing with stm32f4discovery as it possess an SDIO interface. The r/w speed to an SDHC 4GB card (average one) was 4-5MBytes/sec when using 16-32kBytes blocks (mind that STM32F407 is an mcu with 168MHz clock, CortexM4, 192kB ram).
Probably i'll have to use an external parallel SRAM to buffer the whole data (lets say 128kb) and then dump it slowly to SD.
Do you think the SRAM interface should withstand such rate together with SPI read ?
Currently on XMGEA @ 12Mhz i can write to NAND IC (parralel) over 7 Mbit/sec
..with chipkit Max32 and proper sdlibrary(!!) you can write ~400-500kBytes/sec to an sdcard (via SPI) and you have got a lot of ram on the chip as well.
The max SPI transfer speed you may achieve on the Max32 is 2.2MBytes/sec read/write with 20MHz SPI clock (this is not the sdcard fat write speed!).
With Teensy 3.0 - fat16lib has measured ~700kBytes/sec write at 48MHz mcu clock, and ~1800kBytes/sec write at o'clocked to 96MHz mcu clock.
No no no... i am limited to official arduino boards only :(
I have this work on XMEGA + NAND and need to port in some way to Arduino + SD. So maybe SRAM will help in the middle ?
..simply write a read/write routine for a bitbanged access to an external SRAM and do measure read/write access speed to a random byte (or you may do an autoincrement when the SRAM will be used for block transfers). You do not need the SRAM connected for such a measurement.
Just asked if anyone has experience. I don't even have any Arduino boards yet. Just needed a proof of concept.
..you better need a feasibility study :)
I would not mess with 8bit arduinos with that kind of application..