Why not use SDIO instead of SPI?

[CodeKill3r]

I'm pretty sure the integrated SPI interface is not the bottleneck of faster transfer but the SPI communication itself.
For faster communication could you implement/include the 4bit SDIO interface (like this: https://github.com/carlk3/no-OS-FatFS-SD-SDIO-SPI-RPi-Pico or https://github.com/democloid/pico-sdio-example )?

[elehobica]

Hello @CodeKill3r

Thanks for sharing your thoughts.
You're right that SDIO is definitely superior from the aspect of access speed.

On the other hand, SPI interface has following benefits.

• Not consuming PIO state machine resource (as long as the pin assignment is compliant with SPI master pin assignment manner)
• Less number of pin counts

IMHO, there are many applications which don't require high data bandwidth, but require PIO state machine or more pin counts for other purpose than microsd card interface. Therefore, this library is going to keep using SPI interface. For the applications where the access speed really matters, user can choose the SDIO dedicated libraries as you listed up.

Best regards
Elehobica

[CodeKill3r]

The reasoning was that you already tried PIO-ing the SPI, so why not SDIO then.
On personal note: I had troubles with the SPDIF recorder with 96K/24b getting buffer overruns and then stopping. (to be fair it is 4608kbps ~570KB/s -- higher than any of your write test results)

(what is weird that the carlk3 in SPI claims ~3MB/s write, which is 1 bit for roughly every 2 clk while your best results only shows 1 bit around every 10 clk -- there may be some other bottleneck: maybe optimize access to AU size?)

Best regards,
ck

[elehobica]

Hi @CodeKill3r

Okay, you have an actual trouble with S/PDIF recorder project.
For the project, the important factor is rather worst write latency than average data rate.
Could you please let me know which micorsd card you're using?
If you have already tested the pico_fatfs benchmark, could you share it? The result will help to tell why.

Best regards
Elehobica

[CodeKill3r]

Hi @elehobica

First I had to change this repo's test COM from UART to USB_CDC as i don't want to connect another gizmo to do the same as it can/should do by itself.... (maybe PR later).

Now I got ~800KB/s writing speed with Kingston Canvas Select Plus 256GB card -- but the potential dropouts/buffer overruns are not known -- which is more important for me when I try to record a long session.
You have buffer, you use SPI --- what do you mean the latency is important?? Even the card uses wear leveling and shuffling the blocks/AUs. -- I mean the latency interesting up to a point -- until the write buffer overflows. Too bad this test is unable to plot these through a long write/read.
What i would be interested in is can the card's pipieline be saturated, and how bad it would be for the performance.
(I used Sandisk Ultra 32GB card before that worked with 96k24 sometimes up to 4GB until overheat or whatever reason caused "ERROR: _spdif_queue is full ", other times it was just a few 100Megs or even less)

Kingston Canvas Select Plus 256GB
benchmark_pico_SPI.log

benchmark_pico_SPI_PIO.log

Best regards,
ck

[elehobica]

Hello @CodeKill3r

Thanks for log files.
As the log files indicate, the microsd which you're using shows quite excellent read performance, on the other hand, it sometimes shows illegally long write latency. (42202us, 80617us shown as below)

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
794.3565, 42202, 461, 643
797.9062, 28878, 460, 640

write speed and latency
speed,max,min,avg
KB/Sec,usec,usec,usec
727.0147, 29366, 524, 703
394.5454, 80617, 524, 1296

Once the long latency such as 60~ times longer than the average happens, the buffer in the application will be easily run out. That is the reason the buffer overruns in your case. The easiest solution (with keeping to use this library) would be to replace the microsd with other one like Samsung PRO Plus or Xioxia Exceria G2, which show more moderate worst write latency.

Returning back to your first post, it looks your main focus is more dedicated to S/PDIF recorder project, let's talk at pico_spdif_recorder. then we can discuss about switching the library to SDIO one to have more margin for continuous write access.

Again, I'm going to keep this repository as SPI access library. I'll appreciate if you understand this point.

Best regards
Elehobica

[CodeKill3r]

Hi @elehobica

It looks like that slow write and big latency maybe an outlier -- 1 out of 12 seems a bit weird. (a more detailed test would be nice, like have these stats for every 5Megs, then if I set like 2GB test, it would show how consistent/reliable those values are -- maybe a direct csv formatted data output?)
I think the initial processing/preparing takes the longest for the card but then if it can keep up the 800KB/s write -- what seems so as i've done a few 500MB tests resulting similar values -- it can overtake the input data and keep the buffer low.

The easiest solution (with keeping to use this library) would be to replace the microsd with other one like Samsung PRO Plus or Xioxia Exceria G2, which show more moderate worst write latency.

Except none of those (actually any card in the chart) can even keep up with the input (again: 4608Kbps !! ~570kBytes/s) let alone have some margin to recover after a speed-bump.

Again, I'm going to keep this repository as SPI access library. I'll appreciate if you understand this point.

Okay, no problem, just asked as it does not explicitly have SPI in the name.

Best regards,
ck