unconnected SPI performance -- library vs DMA

Here are some measurements of unconnected SPI performance (guaranteed not to exceed) sending 1000 bytes at various SPI clock speeds. I utilized the DMA interface, spiSend(), from fat16lib's SdFat library and his interface to the Arduino SPI library, though I had to neuter his spiRate transformations in order to get the desired SPI clock speeds. There is no error checking in SPI hence these unconnected transfers "work" (observed with scope), but whether you could get a device to run at the high speeds without errors is an exercise left for the reader. On a breadboard, rates above 10Mhz will probably have errors. fat16lib reported SD data rates of 33mbs (million bits per second) runninng at 42 MHz. The DUE SPI hardware includes registers to adjust the delay after CS and the delay between transfers.

Included in the table below are rates for Maple (including DMA) and ye ol UNO. YMMV

              DUE spi          DUE spi/dma
SPI clock    write               write
1MHz          0.82                1.00    mbs (million bits/second)
2MHz          1.45                2.00
4MHz          2.35                3.99
7MHz          3.26                6.99
14MHz         4.25               13.94
21MHz         4.73               20.89
42MHz         5.33               41.45

              maple spi       maple spi/dma
SPI clock   read/write         read/write
1.125MHz     .85mbs               1.125mbs
2.25MHz     1.35mbs               2.25mbs
4.5MHz      1.8mbs                4.5mbs
9MHz        2.2mbs                8.9mbs
18MHz       2.2mbs               17.8mbs

           arduino  avr328p/16MHz      
SPI clock   read/write   
2MHz          1.57mbs  
4MHz          2.6 mbs    
8MHz          3.8mbs

fat16lib reported SD data rates of 33mbs (million bits per second) running at 42 MHz.

SD cards never approach bus speeds for average transfer rates. You can transfer 512 byte blocks at bus speed but SD cards go busy for substantial periods. There is a lot of overhead in sending commands for each block and waiting for status/ready from the card.

Random access to the FAT kills SD performance. For fastest performance you must do large contiguous transfers since flash is programmed in multiple 512 byte blocks.

In 4-bit mode SD version 3.0 cards have bus speeds of 50 MB/sec or 104 MB/sec. You don't get close to those speeds for typical file transfers.

I suspect that a few percent more SD performance could be achieved in SPI mode but the real advantage would be to use the built-in 4-bit controller. Unfortunately one I/O line on this controller is used to drive an LED and is not available on a pin.

I added performance results for the DUE's "extended" SPI mode. For the unconnected tests, the extended mode is faster than the older SPI API. See SPIperf.txt on the git site below

mantoui:
I added performance results for the DUE's "extended" SPI mode. For the unconnected tests, the extended mode is faster than the older SPI API. See SPIperf.txt on the git site below

GitHub - manitou48/DUEZoo: Some proof-of-concept sketches and results for Arduino DUE

Hi mantoui,

did you have an standalone version of the "extended" SPI-Lib as an replacement of the "regular" SPI-Lib as an 1 for 1 version to use all the benefits of the DMA support?

Would be very nice, thanks.

Markus