Go Down

Topic: Happiness is SdFat with DMA SPI (Read 6851 times) previous topic - next topic

fat16lib

#15
Dec 02, 2012, 01:45 am Last Edit: Dec 02, 2012, 01:50 am by fat16lib Reason: 1
I think a block transfer function could be added.  Maybe something like

Code: [Select]

 bool SPIClass::transfer(uint8_t* rxBuf, uint8_t* txBuf, uint16_t size);


You need to allow either rxBuf or txBuf to be null.  The transfer size is limited to a 16-bt field unless you use chained buffers.

The main problem is that SPI.h uses the variable chip select mode.  This mode can be used with DMA but doesn't seem like what users would want.

pico

#16
Dec 02, 2012, 03:19 am Last Edit: Dec 02, 2012, 03:25 am by pico Reason: 1
How would this be integrated into the standard SPI lib so that you could use multiple SPI devices at once without them all or none having to use DMA?

Strikes me as a pity that you need to go the DMA route to get performance that is equivalent to a simple FIFO buffer as found on the Teensy chip. Seems like _a lot_ of added complexity with all the attendent issues just to get to a baseline of a reasonably efficient SPI performance.

I gather from what you've written there would be little or no point in terms of a speed benefit in doing DMA SPI for the Teensy 3, for example?

Do you think there is really no hope to get the poor Due SPI performance improved to any significant degree without resorting to DMA?
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.)

fat16lib

You could use DMA or not on any device or any transfer to a given device.  SAM3X DMA is just an engine to move memory to/from a device register with the appropriate handshake/flow control.

I get twice the performance on SAM3X as on Teensy 3.0. I run SAM3X at 42 MHz and Teensy 3.0 at 24 Mhz.  I use a lot of tricks on Teensy so DMA on Due is simpler.

I suspect there would be a slight improvement on Teensy 3.0 with DMA.

DMA could be a real advantage with a RTOS.  If you run the SD task at low priority, more CPU would be available.  Even better a task could wait on a DMA done interrupt.

Finally, I have the option in my SPI layer of using optimized SPI without DMA.  It runs much faster than the standard SPI library but has none of the options.

I don't see what you have against SAM3X DMA.

pico


I don't see what you have against SAM3X DMA.


I have nothing against DMA per se, it's just that by your own account, it seems to be adding  a great deal of complexity to the SPI implementation. Of course, the simpler the solution the more robust, generally speaking.

But if you say the Teensy 3.0 FIFO code is even more complex, it's probably a better way of going -- and perhaps even means the Teensy would benefit from a DMA implementation after all, if only to make things less complex.
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.)

zachtos

So I'm planning to try out your improved DUE SPI / SD card library this weekend on my laser tag system.  I'll let you know how it goes.  I currently use the ATmega328P with your old SD library, but use file indexing to open files quickly.  Not very user friendly for coding, but it works.  Maybe I can retire the file indexing if this works much faster?

What is the status on this being implemented into the DUE library non beta?

http://code.google.com/p/beta-lib/downloads/list

IR Combat laser tag developer/inventor

kostbill

Hello.

I have a question regarding fat16lib's code.

You define the DMAC Channel HW Interface Number for SPI as
#define SPI_TX_IDX 1
#define SPI_RX_IDX 2

You are then using them to fill the field of the DMAC_CFG register in the DST_PER and RST_PER.

In the SAM3X datasheet, we have the following:

SRC_PER: Source with Peripheral identifier
Channel x Source Request is associated with peripheral identifier coded SRC_PER handshaking interface.
• DST_PER: Destination with Peripheral identifier
Channel x Destination Request is associated with peripheral identifier coded DST_PER handshaking interface.

And when searching for the peripheral identifers, we also see table 11-1, that lists all the peripherals with the Instance ID.

The SRC_PER and DST_PER are 4 bit values each. The peripherals are 45, thus they require 6 bits, so, we cannot add all the peripherals in the SRC_PER and DST_PER fields.

But then, how did you choose the values 1 and 2? Are these values random? What are they used for? How did you know what to do?

Thanks a lot!


johnnyo

Quick follow up question (and I know this thread is quite old...): I'm dusting off my Due from a project a year ago. I would like to know what components you used to interface with the SDCard. I'm thinking of using the Adafruit SDcard breakout board, but if your library won't work with it (or I won't get the same speed), I would definitely reconsider.

Go Up