-
Notifications
You must be signed in to change notification settings - Fork 518
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pico-sdk only rp2040 implementation #472
Comments
I have no interest in supporting SdFat on new platforms. I will not being doing much much new development of SdFat. A file system should be integrated into the operating system not a library like SdFat. When I started SdFat in 2008 for an Arduino with 1 KB of RAM, I assumed it would be replaced with a proper filesystem. The pico-sdk should have an integrated file system with SD being one of the file devices. It would be fairly easy to port SdFat to pico-sdk. I use SdFat on the ChibiOS/RT RTOS. You need to replace a couple of calls to millis(), digitalWrite(), and pinMode(). You need a wrapper for SPI like in this example. I have a very fast pio SDIO driver for rp2040 that can do over 20 MB/sec. I will post it as an example eventually. |
Thanks a lot for your quick reply!
In this case I'll not waste time to try to isolate the Arduino stuff and I'll just remove it or replace it with pico-sdk.
It should, but ... Right now I'm using https://github.com/carlk3/no-OS-FatFS-SD-SDIO-SPI-RPi-Pico but is buggy. Thanks a lot for the link. Regarding PIO SDIO implementation, how big is it? I'm asking as I might not be able to use it as I'm a bit short on PIO space (on both of PIOs :) ). |
@greiman did you manage to post the pio SDIO driver? |
I looked at the SDIO driver but became busy with other things. You probably can't use it since it uses almost all memory in one PIO. I implemented it to be fast for small transfers like the SdFat dedicated SPI mode but that takes more memory. I also need to decide whether to do more development. There are lots of possible configuration options so I need to make it easy to choose the pins and speed options. This can't be done at run time since it must be compiled into the PIO code. I also need to decide whether to develop a second mode. SD cards start in the very old "Standard mode" which was limited to 25 MHz. Modern cards can run much faster in that mode. I find all cards I have tested can run at 62.6 MHz with 250 MHz CPU speed. Implementing "High Speed" mode is a big job since it has totally different bus timing but the SD start in "Standard" mode. So a reload of the PIO code is required during the initialization process. 25 years ago 50 MHz bus speed required an unusual timing. I also don't want to increase the amount time I spend on maintenance of SdFat. I don't enjoy development on the Arduino platform. I had high hope for Arduino15 years ago when I released the first version of SdFat. I now don't use Adruino for my projects. |
First and foremost, I'd like to say thanks a lot Bill for all your effort on this project. As a FOSS contributor myself, I know it is hard to maintain a project that is used by so many people even if we like it or not ;-). I managed to free one of the PIOs, next I'll try to see if I can adapt ZuluSCSI's SDIO implementation. Is your implementation much different? |
My implementation is very different. I started from scratch, I didn't copy any existing code. Modern SD cards require vary large transfers for maximum speed. I do this for both read and write by keeping the SD in read or write mode as long as possible. To do this I stop the SDIO clock between 512 byte transfers. Here is a typical result of the bench example for 512 byte reads and writes. This is overclocked at 250 MHz CPU. This is on an Adafruit Metro RP2040. I also test on a Pico.
It is slower for smaller transfers. In this case I can't transfer directly to the user buffer and must cache the 512 byte block and do an extra copy using the CPU and memcpy.
|
I looked at the current state of my RP2040 SDIO. The source needs to be cleaned up since I was still playing with different approaches. I looked at the High Speed mode again. Card output valid timing has a long delay from the rising edge of clock. I might try it again at some point. Here is High Speed mode timing: I have a 350 MHz mixed signal scope and a fast logic analyzer so I can debug the PIO. |
Existing RP2040 SDIO systems like the aforementioned https://github.com/carlk3/no-OS-FatFS-SD-SDIO-SPI-RPi-Pico already use most (or all) of the instruction memory in one of the PIO units. It's not a downside for yours to use most of the instruction memory, rather it seems to be the status quo. :) |
I had hoped to post a version of SdFat with RP2040 SDIO some time ago but have been very busy and away from home so not had time to finish testing all the mods in the new version. |
@greiman |
Here is a test version of SdFat with RP2040 SDIO. Try it and let me know the result. It is setup with two examples, Rp2040SdioSetup and bench. I test with an Adafruit RP2040 Metro and a Pi Pico. I use the AdaFruit PiCowBell on Pico. The blue proto board has pins for a logic analyzer. I tested at 133 MHz and 250 MHz. Here is my results for the bench example: At 133MHz:
At 250 MHz:
|
@greiman |
Got things set up this morning for building the RP2040 library, here are the first results (no clock speed changes yet, just compiled as-is and run).
edit: Results at a 500MB file are nearly the same
edit the 2nd (son of edit):
edit the third (son of edit returns!): |
Edited: had ms where μs should have been. Write is often slower for big writes since there will be occasional large latencies while the card programs flash. Your card has max latencies of about 50 ms. For 133 MHz the average latency was 3-4 μs greater than the min latency. For the card I used with a 500 MB file, the max latency is 8-10 ms and average latency is one μs greater than the min.
For some apps occasion large write latency is very undesirable. Here is my card for 500 MB at 250 MHz. Max of 8 ms write latency.
|
I did first tests with a Pico 2. I need to do some mods so the third PIO can be used and there are problems with some cards at 250 MHz. Here are two tests with a Lexar Silver Plus at 250 MHz. 512 byte buffer with a 5 MB file:
32,768 byte buffer with a 50 MB file.
|
Does it mean it would use all 3 PIOs or 3rd PIO? I am using 1 PIO for I2S Audio on the PicoADK v2, so it would be good to have 1-2 spare PIOs. In the best case, I would like to stream samples from SDXC while using I2S for audio output. |
It uses one PIO. It looks for a PIO with almost all memory available. Then it claims two state machines. See Currently 27 of 32 memory location are used in the PIO. I may need some of the free 5 locations. |
Hello there,
I'd like to add support for rp2040 but based only on pico-sdk, I'd love to upstream it, so I'd like to ask if such a contribution is something that the maintainer(s) will accept.
Why pico-sdk only? Mostly because the arduino-pico can't be used with cmake projects .
The text was updated successfully, but these errors were encountered: