SdFat V2.0b with multiple SD cards?

[CraigF]

I use SdFat v2.0b ("SdFat-Beta") for a Teensy 3.6 project that also uses the Audio board & library and a number of other bus-based sensors and libraries. The SdFat configuration documentation is confusing but it's actually very simple to install and use -- everything I've used works perfectly, and I am happy with it.

Today I decided it would be useful to instantiate two instances of SdFat for two different SD adaptors: the built-in SD on the Teensy 3.6 and the SD on the Audio board.

However, SdFat *appears* to be set up so that a single set of #defines in SdFatConfig.h control which of the four modes is used (FIFO_SDIO, DMA_SDIO, SPI_Dedicated, SPI_Shared). This config file also sets which pins are used for SPI, so it appears I'd have to modify the library to support instantiating multiple instances to handle multiple SD cards.

For my purposes it's probably fine to branch SdFat just for this project, but I'm wondering if anybody has already encountered or addressed this issue, and if so, how. My first thought is to pass the desired configuration file (or perhaps just a struct containing the necessary data elements) as a parameter.

P.S.
I love SdFat v2.0b (SdFat-Beta) with its ExFat support because it solved all my "episodic latency" problems, speeded up SD writes amazingly, and solved my licensing problems. I have been using it for some time and have found it compatible with every teensy library I've tried. If properly configured it typically doesn't even require any modifications. If mods are needed it's usually just a single line. If anybody else has been struggling with speed or write latency issues in SD, this is the solution.

Huge thanks to Bill Greiman for this and for the original code underlying the old SD library.

 

[mborgerson]

I use SdFat v2.0b ("SdFat-Beta") for a Teensy 3.6 project that also uses the Audio board & library and a number of other bus-based sensors and libraries. The SdFat configuration documentation is confusing but it's actually very simple to install and use -- everything I've used works perfectly, and I am happy with it.

Today I decided it would be useful to instantiate two instances of SdFat for two different SD adaptors: the built-in SD on the Teensy 3.6 and the SD on the Audio board.

However, SdFat *appears* to be set up so that a single set of #defines in SdFatConfig.h control which of the four modes is used (FIFO_SDIO, DMA_SDIO, SPI_Dedicated, SPI_Shared). This config file also sets which pins are used for SPI, so it appears I'd have to modify the library to support instantiating multiple instances to handle multiple SD cards.

In my SD card startup routine, I have the following:

if (!sdf.cardBegin(SD_CONFIG)) {
Serial.println("cardBegin failed");
}
if (!sdf.volumeBegin()) {
Serial.println("volumeBegin failed");
}
if (!sdf.begin(SdioConfig(FIFO_SDIO))) {
Serial.println("\nSD File initialization failed.\n");
return false;
} else Serial.println("initialization done.");

I suspect that it would work if I substituted "SdioConfig(FIFO_SDIO)" for "SD_CONFIG".

If that is true, perhaps you could do

sdf1.cardBbegin(SdioConfig(FIFO_SDIO)); // init the SDIO SD Card
sdf2.cardBbegin(SdioConfig(WHATEVER_FOR_SPI); // init the SPI SD Card

That should set up two separate file systems, one for SDIO, the other for spi.

IIRC the SdioConfig function just turns the input parameter into whatever SDFS needs
to get started.

I'm in the middle of cooking dinner and don't want to let the magic smoke out of my
scalloped potatoes, so I won't be able to test anything until tomorrow.

 

[CraigF]

Thanks for that response! Basically what you wrote worked, except that begin() is called on each instance of SdFs rather than on the cards directly.

I had some issues at first and was worried that all the autodetection and defaults that are set up in the configuration file #define macros were interfering, but I got a response from Bill Greiman assuring me that anything specified will overrule anything that was automatically set. So long as I initialize the default SPI instance to use the correct remapped MOSI pin and then call SdFs.begin() with a CS pin, SdFat will not subsequently change them. Anyway, it works perfectly now!!

 

[WMXZ]

when I asked this question on Bill's GitHub in form of an 'issue', He pointed me to a example that does access two uDS cards.