If you reduce cabling, you might get close to 14Mhz. But with that resistors, you'll not move further then that.
I've used the sdcard in my tft also, and I've managed to get up to 28Mhz by removing the resistors and just put a shunt in their place.
The only way I've got 42Mhz, was with one sdcard reader like that with wires directly attached to the sdcard reader socket bypassing all the electronics there. Those electronics are for voltage translation and are very slow. Since Due is already 3.3V, you can safely bypass it.
I can place a picture here later for your reference.
Thanks for the work on the library! Here's first results from bench for an 8 GB PNY micro class 4 in the Adafruit micro SD breakout:
Type any character to start
Free RAM: 95415
Type is FAT32
File size 5MB
Buffer size 100 bytes
Starting write test. Please wait up to a minute
Write 85.27 KB/sec
Maximum latency: 159470 usec, Minimum Latency: 15 usec, Avg Latency: 1171 usec
Starting read test. Please wait up to a minute
Read 1208.31 KB/sec
Maximum latency: 865 usec, Minimum Latency: 15 usec, Avg Latency: 81 usec
What were they thinking when they put the pins in the middle, right under the edge of the shield footprint? (I guess they were thinking minimum conductor length, and matching the original layout but not to accommodate existing shields that ignored the ICSP header...)
Here's the same card with 20 MB and 32768 Buffer at full speed.
Free RAM: 62747
Type is FAT32
File size 20MB
Buffer size 32768 bytes
Starting write test. Please wait up to a minute
Write 2074.35 KB/sec
Maximum latency: 452410 usec, Minimum Latency: 7830 usec, Avg Latency: 15788 usec
Starting read test. Please wait up to a minute
Read 4381.52 KB/sec
Maximum latency: 12166 usec, Minimum Latency: 7413 usec, Avg Latency: 7476 usec
Well, if that is some kind of conflict between DMA and I2C, you can try the Henning Karlsen RTC library. I think it uses some kind of softI2C, it might work for you.
Nice library - I've combined it and RTClib, as I think RTClib was better expect it was using Wire.h and I'd rather go without..
Anyway, my bad and my apologies - it seems after all not to be SdFat that causes this, it's UTFT which makes sure RTC is in accessible.. Investigating further..
I can't test unless I have a board and it's a lot of labor for a few users.
I understand, maybe I can bribe you with some hardware when the time comes
As for the number of users, that's in the lap of the Gods.
SDIO provides super performance but you need large transfers with a lot of buffer.
External RAM is supported, so buffer space should not be a problem.
I would be interested to know what Arduino applications would require more than a few MB/sec of I/O to an SD card.
That's probably the $64 question. I'm hoping to also have I2S support so maybe audio apps that analyse sound, a DSO that saves the waveform, logic analyser.
I guess I'm working on the "if you build it they will come" model, but they may not.
I would like to experiment with the new system. But I am in the dark how you hook up an Arduino Due with an Sd card shield (I have a SEEED Studio SD card shield v 3.1). Could you please give me some details on how you do that?
The web site with only a description (no schematic) is http://www.seeedstudio.com/depot/sd-card-shield-p-492.html
There is no description of the connectors to this SD shield. It seems to me that a 6 pin connector on the arduino due (next to the processor chip) needs to be connected to the connectors on the SD shield. I don't know the name of these and at the store they couldn't help. The 5V vs 3.3 V problem you mention could be solved with a jumper from the Due to the SD shield. Any ideas on the connectors and how to connect them?
Arduino and Seeeduino compatible ( Do not compatible with Mega)
That might be a problem
But without a schematic or some real information I don't know what to suggest except map out the schematic yourself from the PCB or buy a board from someone who does provide proper documentation.
I've been looking into this and the problem seems to be down to an SPI overrun. The VGA library is quite a DMA hog, and what appears to happen is that in spiRec() the TX DMA sends data faster than the RX DMA can write it to memory due to the bus contention.
Looking at the data sheet, the SPI_MR register has a flag SPI_MR_WDRBT which should hold up the TX DMA until the RX DMA has read the SPI_RDR register. I'm experimenting with the following fix:
in Sd2Card.cpp, in spiRec() around line 234
after this line: #if USE_SAM3X_DMAC
add this line: pSpi->SPI_MR |= SPI_MR_WDRBT;
in spiSend() around line 268
after this line: #if USE_SAM3X_DMAC
add this line: pSpi->SPI_MR &=~ SPI_MR_WDRBT;
The idea is that in spiRec() the SPI_MR_WDRBT flag helps keep the two DMA channels in sync, but spiSend needs the flag turned off again otherwise it will hang.
I have not given this fix much testing other than running bench and QuickStart, and a modified QuickStart which outputs to VGA, which all work correctly.