Finally got a bit of time to fiddle with DMA using the DUE on SPI.
The code was derived from DUEZoo/dmaspi.ino at master 路 manitou48/DUEZoo 路 GitHub and there is other code there to do mem2mem transfers using the DMA.
Findings :-
SPEED, lots of speed improvements. 128*64 1 BPP OLED complete refresh in 230uS instead of ... like 2mS.
I got the SDFAT to run with DMA settings fine and a 1306 OLED to work fine, however running both together resulted in system hang after mixed periods of time. (anywhere from 30 seconds to 30+ minutes)
Both devices used different sck settings so I modified the code on SDFAT to check the settings before doing any transfers as each one finishes to completion before anything else gets to run.
The code I'm testing is reading audio from SD, doing a FFT128, displaying the real-time spectrum and sending the sound to a DAC (MCP49212).
I suspect the problem is something to do with the DMA sck switching and the continuous interrupts used for synchronising the DAC samples.
If I remove the screen updates it seems not to hang and I have had software SPI refreshing the screen previously without problems.
At the moment I'm testing where I have set the sck for both as "5" which is a lowest common setting where they both seem happy and still get very fast transfers.
Think it was stated somewhere getting DMA to work is easy... getting it to play nicely with other libraries or devices that use DMA or hw SPI is another thing.
Another thing I would like to get working with DMA is writing to the buffer in reverse order. I thought this would be simple as a destination address and increment direction can be defined... but got unexpected results.