Go Down

Topic: Disappointing SPI performance with SdFat (Read 1 time) previous topic - next topic

fat16lib

Nov 24, 2012, 06:47 pm Last Edit: Nov 24, 2012, 09:31 pm by fat16lib Reason: 1
My Arduino Due finally arrived and I started testing SdFat.

The results are disappointing since the standard SPI library is slow.  I used an SPI clock of 42 MHz.

When I run the SdFat bench example with large 4096 byte reads and writes, the results are just a little slower than the same test on an AVR Mega with an 8 MHz clock.  The Mega is fast since I wrote optimized SPI functions for AVR.  The maximum read/write rates are about 600 KB/sec for a high quality industrial SD.

I checked with a scope on the Due's SCK and the result is that a byte is transferred in about 200 ns then there is a gap of about 1250 ns until the next byte.

The Due SPI library needs optimized block read/write functions.

On Teensy 3.0 I get over three times the performance of Due.  This is with an 24 MHz SPI clock on Teensy 3.0.

The maximum read/write rate is over 2 MB/sec on Teensy 3.0.  Due should be faster with a 42 MHz clock.



pico

How does your Maple version compare to the above?
WiFi shields/Yun too expensive? Embeddedcoolness.com is now selling the RFXduino nRF24L01+ <-> TCP/IP Linux gateway: Simpler, more affordable, and even more powerful wireless Internet connectivity for *all* your Arduino projects! (nRF24L01+ shield and dev board kits available too.)

stimmer

#2
Nov 24, 2012, 07:59 pm Last Edit: Nov 24, 2012, 08:01 pm by stimmer Reason: 1
Be assured that it is just the library code that is slow, not the underlying hardware. I've been hitting the hardware directly at 28Mbps and 42Mbps rates and it is running at full speed, no gaps between bytes. Even better, it works with DMA too. :D (I have only been testing output however, I have not tried input yet.)
Due VGA library - http://arduino.cc/forum/index.php/topic,150517.0.html

fat16lib

#3
Nov 24, 2012, 09:30 pm Last Edit: Nov 24, 2012, 09:31 pm by fat16lib Reason: 1
stimmer,

I understand the problem is with the library.  I want to use the standard SPI library since it's a pain to maintain my own SPI layer for every chip that runs SdFat.  Also, my SPI functions may not play well with the standard SPI library.

I would like to see optimized functions in the SPI library for sending and receiving blocks of data.

Pico,

I don't have a Maple version of SdFat with the new caching improvements for large memory chips.  Others have ported old versions of SdFat to Maple but these are slow.

Go Up