3x to 8x faster SD-Cards

[LinusHeu]

https://github.com/carlk3/no-OS-FatFS-SD-SPI-RPi-Pico/tree/sdio

I think it should be possible to integrate this into this core and add wrappers to allow usage of Arduino Streams, Files, etc.
Benefits would be (if I understand correctly):

• ~3x speed using 4-bit SD Bus (commonly called SDIO) instead of SPI
• DMA (even when using SPI) (not sure)
• Multiple cards (even on one port) in one file system
• FatFs offers more features than this core's current sdfat like exFat, volumes, disk labels, partitions, renaming

I don't have the time to do that now. And I'm not sure if you would be open to completely replacing the FS or adding a second FS. So I'm just putting the idea out there for now.

[earlephilhower]

No problem adding a FatFS filesystem if someone really needs the speed of SDIO. FWIW the SDFat library from grieman can do most of what you mention, I believe, but right now it's not implemented. ExFat, for example, is just a #define somewhere to enable it (but with an increase in RAM usage, etc.).

[greiman]

I am interested in RP2040 SDIO for SdFat.

SdFat has support for SDIO. I implemented a Teensy driver. There apparently is a SdFat SDIO driver for some STM32 chip.

Here is the performance for Teensy 4.1:

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
21834.06,4600,22,23
22123.89,53,22,22

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
22624.43,133,22,22
22624.43,746,22,22

Here is the performance for SDIO with FatFS on RP2040 from the above site:

FILE_SIZE_MB = 5
BUF_SIZE = 20480
...
write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
6378.2,13172,2588,3194
6488.7,6725,2597,3145
...
read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
11915.6,2340,1577,1718
11915.6,2172,1579,1716

This is great performance but it requires huge writes and reads with FatFS.

I modified SdFat so the SDIO driver is put in infinite multi-block read or write mode and kept in that mode as long as possible. This means all file I/O is fast with only the standard 512 byte internal sector buffer.

Here is the result on Teensy 4.1 for 20 byte reads and writes.

FILE_SIZE_MB = 5
BUF_SIZE = 20 bytes

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
22222.22,44,0,0
22123.89,44,0,0

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
16447.37,531,0,1
16501.65,107,0,1

I don't know if the implementation for RP2040 allows the infinite multi block mode. I will start looking at the versions of the RP2040 driver.

I may need help if the driver's PIO needs to be modified. I have only played with the simplest PIO examples.

Here is the current state of SdFat SPI on RP2040:

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2268.60,249,222,225
2265.52,248,222,225

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2273.76,237,221,224
2275.83,264,221,224

This result takes advantage of the SPI transfer(txBuf, rxBuf, size) API.

[greiman]

@LinusHeu

FatFs offers more features than this core's current sdfat like exFat, volumes, disk labels, partitions, renaming

SdFat supports exFAT, FAT32/FAT16/FAT12 and file rename with move.

UTF-8 is supported for filenames.

I have not implemented disk labels since there have been no requests.

The base classes for the file system support the four MBR partition. I don't use it for SD cards since modern SD cards only guarantee high performance if you use the SD standard single partition layout. The hardware SD caching and RAM buffering is optimized for this layout.

New cards will even optimize flash for this layout. Modern flash devices use pseudo SCL for some areas.

SdFat has features for very fast data-logging, I have logged ADC data on Teensy at over a million samples per second with no missed points due to write latency.

I pre-allocate a file and write 512 byte sectors using a circular buffer as a queue. SD cards have a not busy functions that guarantees you can send 512 bytes at full SDIO speed.

[LinusHeu]

Thank you so much for your detailed post
I didn't know all that was possible with sdfat as well. (And I totally missed the renaming in the docs. I should have looked closer.) Looks great!

As far as I know, two SDIO implementations exist for RP2040:
The one from ZuluSCSI https://github.com/ZuluSCSI/ZuluSCSI-firmware which was adapted and used by https://github.com/carlk3/no-OS-FatFS-SD-SPI-RPi-Pico/tree/sdio I linked initially.
And an AFAIK more limited one from pico-extras https://github.com/raspberrypi/pico-extras

At Adafruit CircuitPython, someone is working on SDIO for RP2040 as well. They want to use one of these two SDIO PIO implementations. I would love to have that on Arduino. But I think implementing it into SdFat is a bit out of my league :D

[greiman]

@LinusHeu

I looked at all the Rp2040 SDIO versions. I almost missed the best version for SdFat. I looked at the ZuluSCSI version and saw they were porting to a version for their boards. Then I decided to look at the wrapper for their boards.

It was for SdFat. They use a port of SdFat on their boards. That's the good news, almost certainly I can have 4-bit SDIO working.

The less good news is that I have two modes for SDIO. A mode that works with almost all MCU SDIO controllers but doesn't allow the infinite transfer mode and one for more flexible controllers with infinite transfers. They have only implemented the former.

On other boards the simple SDIO runs slower than my SPI implementation until you do about 8 KB writes and 4KB reads aligned on 32-bit boundaries and only read or write multiples of 4-bytes. I didn't include SDIO for ESP32 since I couldn't get performance.

The problem is SD cards now have huge flash pages, multiples of 16 KB. the 512 byte sectors are emulated. When you end a write, an entire flash page is programmed. The next 512 byte write causes the just programmed page to be copied to a RAM buffer, 512 bytes added and a new page programmed. I estimate data rates in a high end card reach 200 MB/sec with lots of flash wear.

I have some hope since RP2040 is flexible. I have never done anything beyond looking at examples of PIO programs for RP2040 so this may be a learning opportunity.

This is how ZuluSCSI handled the infinite transfer API which is now my todo list:

bool SdioCard::erase(uint32_t firstSector, uint32_t lastSector)
{
    logmsg("SdioCard::erase() not implemented");
    return false;
}

bool SdioCard::readData(uint8_t* dst)
{
    logmsg("SdioCard::readData() called but not implemented!");
    return false;
}

bool SdioCard::readStart(uint32_t sector)
{
    logmsg("SdioCard::readStart() called but not implemented!");
    return false;
}

bool SdioCard::readStop()
{
    logmsg("SdioCard::readStop() called but not implemented!");
    return false;
}
bool SdioCard::writeData(const uint8_t* src)
{
    logmsg("SdioCard::writeData() called but not implemented!");
    return false;
}
bool SdioCard::writeStart(uint32_t sector)
{
    logmsg("SdioCard::writeStart() called but not implemented!");
    return false;
}

bool SdioCard::writeStop()
{
    logmsg("SdioCard::writeStop() called but not implemented!");
    return false;
}

bool SdioCard::cardCMD6(uint32_t arg, uint8_t* status) {
    logmsg("SdioCard::cardCMD6() not implemented");
    return false;
}

[greiman]

@LinusHeu

I see that there is continued development of SDIO for RP2040 so I have done this post to see if people with experience are interested in an implementation that provides fast performance for all read/write sizes.

Seems like a common effort is the best answer.

[greiman]

@LinusHeu

I am making progress. I have a version of SDIO working with this board support package. I will be able to get good performance for large transfers but there will be restrictions.

One of the biggest problems is 32-bit alignment for DMA and PIO. This means the best performance is only obtained if a file is read/written with transfers that are multiples of four bytes. The optimal size is multiples of 512 bytes. This eliminates memcpy to/from tmp buffers.

The other problem is being able to put the SD in infinite read or write mode like I do for optimized SPI mode or SDIO on Teensy. It requires SD clock control that not in the current PIO code. Also the small PIO FIFOs may be a problem. Teensy has full sector FIFOs.

PIO requires four contiguous GPIOs. The PIO programs need to be modified and re-assembled to change this. I need to select several choices for pre-assembled configurations and provide instructions for custom configurations.

[LinusHeu]

One of the biggest problems is 32-bit alignment for DMA and PIO. This means the best performance is only obtained if a file is read/written with transfers that are multiples of four bytes. The optimal size is multiples of 512 bytes. This eliminates memcpy to/from tmp buffers.

Sounds like a reasonable and easy to work with limitation to me. The Arduino-Audio-Tools library is reading in 1024 blocks anyway (except at the end of the file, if it's shorter). And other applications should be able to optimize for that as well, I think.

PIO requires four contiguous GPIOs.

I don't think that's an issue at all because it's also in the "Hardware design with RP2040" pdf from Raspberry Pi:

The constraints our SD PIO software puts upon us is that the four data signals must be connected to
contiguous GPIOs. The CLK and CMD signals can go anywhere.

Many PIO implementations have similar contiguous GPIO requirements. E.g. this core's I2S library.

Thank you so much for your work. Sorry, I can't help with it, but I'm really excited to try it out! :D

RP2040 boards I could find with the SD-card wired for SDIO:
https://www.adafruit.com/product/5786 (files here https://github.com/adafruit/Adafruit-Metro-RP2040-PCB)
https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-base?variant=32369520672851 (pinout at bottom of product description)
https://www.adafruit.com/product/5160 (schematic at bottom of product description)
https://www.sparkfun.com/products/17718 with https://www.sparkfun.com/products/17720 (schematic under "documents")

[LinusHeu]

From following that other issue in ZuluSCSI I have two questions I'm curious about:

I am also considering PIO SPI. There is a hard limit of 24 MHz with the board support package, since SPI is shared.

Why does sharing SPI limit it to 24MHz?
Shouldn't it be possible to use one of the two hardware SPI as dedicated SD-SPI? That would require no change in your library but just in earlephilhowers 8266sdfat and/or this core, right?
If I understand it correctly, even on a Pico W both hardware SPI controllers are free to be used. (The wifi module is connected using pio.)

[greiman]

Why does sharing SPI limit it to 24MHz?

I believe the problem is that SPI uses the 48 MHz clock and is limited to 24 MHz.

I tried this PIO SPI example but it is very slow. You need two state machines to get high speed. One for clock/send and one for receive.

I have have written a PIO SPI that can be used on any three GPIO pins. It was an exercise to learn PIO before modifying SDIO PIO.

I can get 50 MHz for full duplex send/receive if I overclock to a system clock of 200 MHz. If I do send only, it is easy to get 66.5 MHz for 133 MHz. Modern SD cards will run with 66.5 MHz SPI.

I should have some test results soon. I hope to get 5MB/sec for read/write for 50 MHz. I have done write at100 MHz but don't know if it would work with an SD. It looks good on my scope and logic analyzer.

Most SD cards will run at 100 MHz on Teensy. I get 40 MB/sec read/write even for small transfers.

I need to package the the code as a class with the standard SPI API. Then I won't need to modify the SdFat code.

I am looking at the versions of SDIO. Any mods will be very difficult since they use 31 PIO instructions which leave one more.

SDIO may be limited to large transfers for high speed.

[LinusHeu]

I believe the problem is that SPI uses the 48 MHz clock and is limited to 24 MHz.

There's a way around that. 🥳
Using Hardware-SPI, I was able to increase the write speed and got limited by the SD-card and not the SPI-Hardware.
(Sadly, I don't have an oscilloscope to verify if the RP2040 SPI hardware works correctly at those higher speeds. I assume that the SD-Card was the limit. 62,5MHz baudrate is still within spec. 66,5MHz would be a tiny overclock.)

TL;DR: Switch clk_peri (back) to clk_sys to run clk_peri at 125MHz (within spec) and above (overclocking), which allows faster bauds for hardware SPI.

This post (and my comment there) explains this issue and the 2 solutions I tried: #415

Today I ran the bench example in https://github.com/earlephilhower/ESP8266SdFat/blob/master/examples/bench/bench.ino (SdFat 2.1.1 with I don't know what changes) :

1. At this core's default settings. That is clk_sys==133MHz and therefore the "clk_peri gets switched to 48MHz" issue happens:
   Maximum possible SPI bauds = 24MHz
   What my SD-card could handle and was used for this benchmark = 24MHz

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
1901.14,2357,257,267
1900.42,1633,257,267

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2041.65,346,244,249
2041.65,355,244,249

2. My workaround (from Over-clocking and SPI maximum frequency #415) Change "CPU Speed" to 125MHz / board_build.f_cpu = 125000000L. clk_sys==125MHz and clk_peri stays at that. Slower CPU is a good tradeoff for faster SPI for this benchmark.
   Maximum possible SPI bauds = 62,5MHz
   What my SD-card could handle and was used for this benchmark = 31,25Mhz
   Nothing between 62,5 and 31,25 is possible due to the clock dividers in the SPI hardware.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2199.74,13137,215,231
2212.39,1573,215,229

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2320.19,319,216,219
2321.26,327,216,218

The following benchmarks were run with Bodmers code (from #415) added to the top of void setup().
It allows faster SPI bauds. Theoretically, over 100Mhz should be possible (out of spec).
But I used this trick to reach baudrates between 31,25Mhz and 62,5Mhz, to get closer to the maximum that my SD-Card can handle.

3. clk_sys == clk_peri == 133MHz
   Maximum possible SPI bauds = 66,5MHz
   What my SD-card could handle and was used for this benchmark = 33,25Mhz
   (again, of course, nothing possible between 66,5 and 33,25)

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2424.83,13779,199,209
2439.02,1556,199,208

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2453.39,296,203,207
2454.59,280,203,206

4. clk_sys == clk_peri == 150Mhz
   Fastest possible SPI bauds = 75Mhz
   2nd fastest possible bauds = 37,5Mhz (SD-Card didn't initialize)
   What my SD-card could run at: (3rd fastest) = 18,75MHz or 25Mhz, I'm not sure right now.
   not worth it to benchmark.

5. clk_sys == clk_peri == 140Mhz
   Fastest possible SPI bauds = 70Mhz
   What my SD-card could run at and used for this benchmark: 35Mhz

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2587.99,1650,189,196
2585.32,3058,189,196

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
2602.81,276,193,195
2602.81,276,193,195

Header of all bench outputs:

FreeStack: 196464
Type is FAT32
Card size: 31.91 GB (GB = 1E9 bytes)
Manufacturer ID: 0X3
OEM ID: SD
Product: SP32G
Version: 8.0
Serial number: 0X2E242BCB
Manufacturing date: 7/2012

Card used: SanDisk Extreme Pro 32GB (sorry, it had some files on it and wasn't freshly formatted. 28,9GB were free.)
Adafruit Micro SD Breakout connected using jumper wires (no breadboard).

I don't think these 2 workarounds are 100% perfect. Because to hit that fastest baudrate that my SD-card can handle, I had to change clk_sys to a specific frequency and run both clk_sys and clk_peri out of spec.
A bunch of stuff overclocks RP2040 way more, so I'm not worried about killing it. I'm just slightly annoyed because other things (e.g. one form of I2S, DVI, USB-PIO-host) also require specific clk_sys. So you can't hit the perfect SPI-SD-speed while using those things. But the alternative PIO-SPI requires valuable PIO resources.
I think adding an external clock-generator (as input to clk_peri), might allow using both a very specific clk_sys (e.g. for DVI) while still hitting the perfect SPI bauds for the SD-card. (I don't think that's worth it, but might be a fun experiment.) I haven't fully understood all the possibilities yet.

If you use the current master branch of this core, a bug with the SPI-debugging output was just fixed. Now, in the debug output, it will tell you which SPI baudrate was requested and what was actually reached.
Here's how to enable SPI debugging. I recommend to user Serial (USB) as debug port and not a UART, because the UARTs also get affected by playing around with clk_peri.

These functions were helpful for me:
spi_get_baudrate(spi0)
clock_get_hz(clk_peri)

I hope this post is helpful to you, even though it's so long, and I used this older fork of sdfat and old SD-card . :D

[greiman]

I don't want users to need to change clocks.

Also you aren't getting much improvement. Part of the problem is that the SPI controller seems to get bigger gaps between bytes at higher speeds.

Here is at 24 MHz with 200 MHz system clock. The rate is 2.3 MB/sec because of gaps. It should be 3 MB/sec.

Here is my PIO SPI at 50 MHz using 200MHz system clock. It gets the true 6.25 MB/sec rate - no gaps.

I used different pins on my test to verify that any pins work.

133 MHz should have 4.15 MB/sec raw rate. The SPI SCK would be 33.25 MHz.

[LinusHeu]

Very interesting! I wonder what causes these gaps.
Maybe such a faster and more flexible PIO SPI would also be nice for displays and other things. This core already includes PIO-based UART so PIO-SPI would fit great as well imo.

[greiman]

PIO-SPI would fit great as well imo.

I agree but I have too many things to maintain. I am only doing functionality needed for SdFat, MSBFIRST, SPI_MODE0 Maybe someone will make a real library.

Here are the first SdFat results with a very rough version of PIO SPI. Of course I don't get the raw SPI speed due to overhead of file system and SD protocol.

Here is what I did to get it to work with SdFat:

Edit: No changes to the SdFat library, only the these changes to the app.

Added PioSpi and modified config:

#include "PioSpi.h"
PioSpi spi;
...
//#define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SPI_CLOCK)
#define SD_CONFIG SdSpiConfig(SD_CS_PIN, DEDICATED_SPI, SPI_CLOCK, &spi)

This is for 512 byte transfers. You can get a tiny bit more for large transfers. I get 7,112 KB/sec with 8,192 byte writes at 250 MHz CPU speed.

Results:
CPU Speed: 133 MHz

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
3594.54,3661,137,141
3607.50,167,137,141

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
3728.56,146,135,136
3736.92,168,135,136

CPU Speed: 200 MHz

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
5428.88,114,91,93
5428.88,115,91,93

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
5617.98,97,89,90
5630.63,119,89,90

CPU Speed: 250 MHz

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
6784.26,95,73,75
6775.07,94,73,75

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7012.62,100,71,72
7032.35,100,71,72

[LinusHeu]

Oh wow! Now I fully understand why you said "you aren't getting much improvement"!
And I might need to buy a faster SD-card. :D
What are the baud rates for that? Maximum possible baudrate = clk_sys / 4?

I think that maybe your minimal PIO-SPI could already be added to this core as a library, and then other people can add those features when they need them.

[greiman]

@LinusHeu

Here is a snapshot of my PIO SPI library. I included a version that works with the current release of SdFat. The zip file contains readme.txt and the PioSpi folder needed to try it with SdFat.

I started to add all SPI modes for MSBFIRST but first I want to experiment with ideas for a full rewrite SDIO PIO while my memory of PIO is fresh.

If you try it, let me know if it works for you.

Here are the results I get with an old SD card that has SLC flash and is very good for SPI.

At 250 MHz system clock:

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7173.60,91,70,71
7173.60,91,70,71

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7142.86,108,70,71
7173.60,94,70,71

PioSpiTest.zip

[LinusHeu]

Thank you. :D I will definitely try that!
Btw, do you have a recommendation for a better SD-Card, a list of SD-Cards that work well with fast SPI, or anything like that?
My old SanDisk Extreme Pro 32GB seems to top out at about 35MHz baud rate SPI.

[greiman]

Btw, do you have a recommendation for a better SD-Card

I have had good luck with most cards I have tried with the above PioSpi library. I have not tuned the library yet for these GPIO options.

• Output drive strength can be set to 2mA, 4mA, 8mA or 12mA
• Output slew rate can be set to slow or fast
• Input hysteresis (schmitt trigger mode) can be enabled

The above card is:
Samsung Pro Plus 32GB
Manufacturing date: 10/2015

New versions don't perform well on MCUs. They are best on phones with huge read ahead/ write behind buffers.

Here are a few bench results for newer cards. Notice max write latency is often high for new cards. They are optimized for phones with huge buffers.

If you buy one of these cards today they many perform well on MCUs. Phone are the market.

All Tests:

FILE_SIZE_MB = 5
BUF_SIZE = 512 bytes

I like this card for consistent write latency. Fairly low cost for 128GB.

PNY 128GB Elite-X
Manufacturing date: 10/2020

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7091.74,80,71,71
7061.69,80,71,71
7091.74,80,71,71
7051.73,81,71,71
7101.82,81,71,71

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7183.45,76,69,70
7277.55,82,69,69
7277.55,94,69,69
7277.55,93,69,69
7277.55,93,69,69

A high end Samsung card - disappointing.

Samsung Pro Plus 128 GB
Manufacturing date: 9/2021

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
6944.00,2048,72,73
6982.79,1116,72,72
6839.51,7055,72,73
6953.66,2646,72,72
6963.34,319,72,72

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7256.43,76,69,70
7277.55,98,69,69
7266.98,90,69,69
7277.55,93,69,69
7266.98,93,69,69

A few SanDisk cards:

SanDisk Extreme 32GB
Manufacturing date: 7/2021

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7173.60,1547,70,71
7215.01,828,70,70
7204.61,818,70,70
7132.67,6137,70,71
7215.01,1351,70,70

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7246.38,80,69,70
7256.89,82,69,70
7256.89,86,69,70
7246.38,86,69,70
7256.89,99,69,70

SanDisk High Endurance 32GB
Manufacturing date: 7/2021

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7132.67,2753,70,71
7092.20,5395,70,71
7032.35,8278,70,72
7142.86,2842,70,71
7132.67,2852,70,71

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7235.89,96,69,70
7256.89,88,69,70
7246.38,81,69,70
7256.89,98,69,70
7246.38,101,69,70

SanDisk Ultra 32GB
Manufacturing date: 10/2021

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7072.14,13219,70,72
6954.10,23401,70,73
7062.15,13776,70,72
7062.15,13790,70,72
7032.35,12930,70,72

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7225.43,80,69,70
7256.89,100,69,70
7256.89,98,69,70
7246.38,104,69,70
7256.89,86,69,70

SanDisk Extreme 64GB
Manufacturing date: 11/2020

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7002.35,3419,70,71
7031.90,2215,70,71
6915.19,11790,70,72
7041.80,1717,70,71
7041.80,2204,70,71

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
7266.98,83,69,70
7277.55,88,69,69
7266.98,82,69,69
7277.55,96,69,69
7266.98,93,69,69

[LinusHeu]

Thank you very much

[DatanoiseTV]

I am interested in porting SDIO support to a custom board. Was there some progress on RP2350 yet?

[greiman]

You might try this version of SdFat with a development version of SDIO for RP2040.

I have also tested on Pico 2 here.

Edit: Looks like your pin-out would work. CMD and CLK can be on any pins and DAT on any four consecutive pins.

[DatanoiseTV]

Will check it out tomorrow. Happy to send you a PicoADK v2 if you like.

[DatanoiseTV]

@greiman Great results with my boards at 250 MHz. 270 MHz overclocking breaks USB and at 300 MHz I am currently
getting:

begin() failed
Do not reformat the SD.
SdError: 0X1A,0X0

FreeStack: 511880
Type is exFAT
Card size: 127.93 GB (GB = 1E9 bytes)

Manufacturer ID: 0X3
OEM ID: SD
Product: SD128
Revision: 8.5
Serial number: 0XFEB5BF29
Manufacturing date: 10/2023

FILE_SIZE_MB = 15
BUF_SIZE = 4096 bytes
Starting write test, please wait.

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
26547.88,10218,148,151
9517.48,31343,148,428
26547.88,10313,148,151
25861.30,13172,148,155
26547.88,10397,148,151
26315.00,13322,148,152
19379.27,24630,148,184
13966.06,63496,148,289
26547.88,10451,148,151
25861.30,13159,148,155
26594.95,10432,148,151
26315.00,13234,148,152
15495.41,24712,148,237
17064.34,63550,148,236
26086.18,10658,148,154
26315.00,13322,148,152

Starting read test, please wait.

read speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
27123.96,167,150,150
27173.10,169,150,150
27173.10,156,150,150
27173.10,162,150,150
27173.10,164,150,150
27173.10,157,150,150
27173.10,168,150,150
27173.10,169,150,150
27173.10,155,150,150
27173.10,163,150,150
27173.10,165,150,150
27173.10,156,150,150
27123.96,170,150,150
27173.10,168,150,150
27173.10,155,150,150
27123.96,166,150,150

Done

[greiman]

Your variation in write speed is interesting. What SD card are you using?

It appears some modern SD cards use pSLC caching.

This causes large variations in write speed similar to low cost SSD drives.

This also could be due to a small erased flash list in the SD due to limited spare flash size.

[DatanoiseTV]

SanDisk Ultra 128GB

[greiman]

SanDisk Ultra probably explains the uneven write performance. Ultra will have occasional long latency for write.

[DatanoiseTV]

Thanks a lot! Is there any chance this gets merged into the arduino pico core?

[greiman]

It would be OK to merge this but I should finish modifying it.

The next version will have better support for adding SDIO drivers for any board.

I will also modify the RP2040/RP2350 version to use the RP-series SDK to get the number of PIOs.

I will post a first version on SdFat-beta. I hope to soon find time to finish and test these and other mods for the next version.

Edit: I planed on looking at all new PIO features on the RP2350 but I think I will concentrate on finishing a release that only uses the additional PIO on RP2350.

I did a search on PIO version zero vs one and get this:

Search "PICO_PIO_VERSION" (24 hits in 2 files of 570 searched) [Normal: Case]
C:\Users\Bill\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\4.1.1\pico-sdk\src\rp2_common\hardware_pio\include\hardware\pio.h (17 hits)
Line 26: // PICO_CONFIG: PICO_PIO_VERSION, The PIO hardware version, type=int, default=0 on RP2040 and 1 on RP2350, group=hardware_pio
Line 27: #ifndef PICO_PIO_VERSION
Line 29: #define PICO_PIO_VERSION 1
Line 31: #define PICO_PIO_VERSION 0
Line 81: #if PICO_PIO_VERSION > 0
Line 94: #if PICO_PIO_VERSION > 0
Line 127: #if PICO_PIO_VERSION > 0
Line 386: #if PICO_PIO_VERSION == 0
Line 578: #if PICO_PIO_VERSION > 0
Line 582: #if PICO_PIO_VERSION == 0
Line 620: #if PICO_PIO_VERSION > 0
Line 672: #if PICO_PIO_VERSION > 0
Line 783: #if PICO_PIO_VERSION > 0
Line 913: #if PICO_PIO_VERSION > 0
Line 1033: #if PICO_PIO_VERSION > 0
Line 1094: #if PICO_PIO_VERSION > 0
Line 1129: #if PICO_PIO_VERSION > 0
C:\Users\Bill\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\4.1.1\pico-sdk\src\rp2_common\hardware_pio\pio.c (7 hits)
Line 28: #if PICO_PIO_VERSION > 0
Line 85: invalid_params_if_and_return(PIO, gpio_base != 0 && (!PICO_PIO_VERSION || gpio_base != 16), PICO_ERROR_BAD_ALIGNMENT);
Line 86: #if PICO_PIO_VERSION > 0
Line 99: #if PICO_PIO_VERSION > 0
Line 111: #if PICO_PIO_VERSION > 0
Line 123: #if PICO_PIO_VERSION > 0
Line 135: #if PICO_PIO_VERSION == 0

[DatanoiseTV]

Sounds great to me, let me know if there is something to test on my HW. I am just finishing the PicoADK v2.0 Pro, which will have SDIO 1.8 and 3.3V with a spec-compliant power switching and level shifter made for SDIO. This way we could possibly go into higher clock speeds and therefore more bandwidth.

[greiman]

Sounds great to me, let me know if there is something to test on my HW.

Please try this new beta.

It has a huge number of internal changes/bug fixes. I restructured the way SPI/SDIO drivers are added.

Here is the Github diff summary:

97 files changed
+4279
-1471
lines changed

It will be a while before I move it to release. Some changes may break apps.

[DatanoiseTV]

Success - will run some tests next. The 1.8/3.3V version of the board will arrive in a couple of weeks.