Hello!
If you mean Chan's FatFs yes, it works even with 32Gb by SPI and SDIO perfect, but by SPI much slower.
SPI is indeed slower. As for "much" slower, it depends on what you mean by "much" and with what kind of hardware.
Physically, SDIO has 4 bits, so there is no magic, "much" is at most 4 times.
BUT: SDIO sends data 4bits by 4 bits which is somewhat inconvenient unless you have a hardware way to
do it. If you do everything in software, then you have to split every byte before feeding it into your
SD card. I agree that a simple shift can be fast, but if you do this: (in pseudo-code)
while(count < buf_size) {
SetSDIO((data[count]>>4) & 0x0F);
SetSDOP(data[count] & 0x0F);
count++;
}
Then the while loop will eat a few cycles, the count++ maybe 1 or 2 cycles, the shift action maybe 1 or 2
cycles as well. That may indeed be faster than waiting for each byte to be sent by SPI, but definitely not
as fast as you coulde expect. Of course, if your µC processes SDIO in hardware (i.e. takes care of data shifting
and feeds the 4 bits properly), then yes, it
may be faster. I say
may because there is another aspect:
All the processors I know allow to feed SPI with DMA, which means that while you are transferring data to the
SD card, the processor can do something else, therefore the whole action of sending a buffer will consist in just
setting the DMA start point and length. So in order to decide whether you implement SDIO or SPI, you have
to know:
- If your processor handles SDIO by hardware;
- If you can DMA to the SDIO engine.
If any of these conditions is missing, then you should use SPI.
As for the original question, yes, you can use FATFS and SPI. The initialization of SD cards above 2 GB is slightly
different, so in case you want to be compatible with both, then you have to read the SD card characteristics first
and initialize accordingly.
Dora.