[feature-request] pass SPIClass reference explicitly

[y-nk]

Hello,

I have looked at the source code of the one source i'm interested (AudioLibs/AudioSourceSD) and found that it's not possible to pass an already defined spi class to the source.

More practically speaking, I'd like to know if this:

arduino-audio-tools/src/AudioLibs/AudioSourceSD.h

Lines 44 to 55 in 2f35a96

	virtual void begin() override {
	TRACED();
	if (!is_sd_setup) {
	while (!SD.begin(cs)) {
	LOGE("SD.begin cs=%d failed",cs);
	delay(1000);
	}
	is_sd_setup = true;
	}
	idx.begin(start_path, exension, file_name_pattern);
	idx_pos = 0;
	}

could eventually become this instead:

  virtual void begin(SPIClass &spi /* = SPI */) override {
    TRACED();
    if (!is_sd_setup) {
      while (!SD.begin(spi->pinSS(), *spi)) {
        LOGE("SD.begin cs=%d failed", spi->pinSS());
        delay(1000);
      }
      is_sd_setup = true;
    }
    idx.begin(start_path, exension, file_name_pattern);
    idx_pos = 0;
  }

so that we can eventually override the SPI used.

I hope this makes sense, and sorry if there are typos in the proposed code (i'm not very advanced in cpp)

[y-nk]

This reflects from my previous post where i mentioned I'd like to use a dedicated SPI bus for a player instance, but the other lib i'm using (MFRC522) does not offer the possibility to pass an SPIClass instance either ; so i'm a bit stuck since both are using SPI.

(in the meantime i'm trying to find replacement libs for the rfid reader as well, but still i think this would be a nice - non breaking - addition to this library)

[pschatzmann]

I suggest that you do this instead. This will not break the parent API:

  virtual void begin(SPIClass &spi) override {
  }

  virtual void begin() override {
     return begin(SPI);
  }

Can you submit a pull request ?

[y-nk]

I'm willing to try. My level of C++ is quite low but I think i can manage it.

1. Would you expect it only on AudioSourceSD or also AudioSourceSDFat?
2. How about the cs property of the class?

[pschatzmann]

I suggest that you just do it for AudioSourceIdxSD and AudioSourceSD

The cs can already be redefined in the constructior. To be consistent maybe it would be better just to create an additional constructor which contains the SPIClass as well

[y-nk]

indeed it makes more sense to have a new constructor. as i understand, the player instance is triggering the source.begin() here so it would be impossible to pass new parameters anyway.