Add ability to detect if an SD card is present

[chipaudette]

It would be great if we could detect when an SD card was present.

Tag: @cab-creare-com , @eyuan-creare

[chipaudette]

My research has found:

• This Teensy forum post that reveals that the generic SD class has a method for detecting if an SD card is present.
• In the forum post, their code snippet shows SD.mediaPresent whereas it should actually be SD.mediaPresent().
• Also, their code snippet doesn't show that this only works if you have already done SD.begin(), or in our case SD.begin(BUILTIN_SDCARD);.

I prototyped this approach in AudioSdWriter_F32 and AudioSD_Player_F32, but got bad interactions:

• I found that it works well to detect whether the card is present, but it seems to interfere with our ability to actually do recordings to the SD card.
• Specifically, I had it check to see if the card was present before starting each recording. It would successfully record one WAV file, but it wouldn't record any additional WAVs unless I rebooted the system (it failed to open the file for recording).
• I suspect that the problem is multiple calls to SD.begin() after the SD / SdFs has already been begun.

More generally, I believe that this problem exposes a conflicted design within the Tympan_Library.

• The Tympan's AudioSdWriter_F32 and AudioSdReader_F32 actually call the SdFs class, not the generic SD class.
• The generic SD class is a wrapper around SdFs that the Teensy folks created to add a compatibility with the widely-familiar SD class from Arduino.
• Unfortunately, when the Teensy folks created the SD class as a wrapper, it isn't a pure wrapper -- they added capabilities that are only in SD. The mediaPresent() method is unique to SD and is not in SdFs (as far as I can tell).
• I believe that any system that sometimes calls SD and sometimes calls SdFS will have inherent conflicts as it's likely the two sets of code were designed assuming that you'd use one interface or the other interface, not both. Or, if you're going to use both interfaces, you'd better have a better understanding of how it works, which I don't have.

I looked at the Teensy implementation of the SD class (here) to see if there was an easy way to step around these problems:

• In SD, I do not see an easy way of making our own mediaPresent() that removes the need for begin() to have been called. So, I think that we're stuck with the requirement that begin() must be called if mediaPresent() is to work correctly.
• In SD, I do not see any public data members or public methods that expose whether begin() has already been called. So, I don't see how we check whether begin() needs to be called. If we can't safely call begin() automatically, I guess we'd be forced to require that the user call begin() themselves (just once)
• As an alternative to requiring that the user to call SD.begin(), I did consider having either AudioSdWriter or AudioSdPlayer keep track of whether it had called SD.begin(). So, for example, if AudioSdWriter were used to call SD.begin(), AudioSdWriter would know to not call SD.begin() again. Sounds good, right? Unfortunately, what happens if you use both AudioSdWriter and AudioSdPlayer in the same program? In my implementation, there is no state sharing between the two classes (can there be state sharing?). Without state sharing, each class ends up calling SD.begin() itself, which means begin() gets called more than once, which means that additional recordings might be blocked, which would be bad.

The case where we're both writing and playing...that's the case that best exposes our challenge.

Moving forward:

• If resources were not limited, the ideal solution would be to redesign/refactor how SdFs (or SD) is used throughout the Tympan_Library so that the design better acknowledges that the SD is a single resource that needs to be centrally managed...not handled pseudo-independently as currently seen in AudioSdPlayer and AudioSdWriter.

• Perhaps the simplest approach would be to define a Tympan-specific interface for the SD card that contains just those functions that we need (not the crazy large API of SdFs). This Tympan-specific interface would track its own state (for begin(), at least) and expose that information to avoid these kinds of problems.

[chipaudette]

Alternatively, perhaps you don't need a fully integrated solution.

If you're open to a less pretty solution, you simply need to:

• Call SD.begin(BUILTIN_SDCARD) yourself. Call it once near the beginning of your program. Make sure that it comes before AudioSDWriter or AudioSDPlayer init() or begin() their own SdFs.
• Call SD.mediaPresent() whenever you like after SD.begin()

Example below:

#include <SD.h>

void setup(void) {
    //your Arduino-style setup activities are here

   //Begin the generic SD subsystem (does not require that the SD card is present?)
   SD.begin(BUILTIN_SDCARD);  //should work for all Tympan revisions
}

void loop(void) {
  //Check to see if SD is present
  if (SD.mediaPresent()) {
      Serial.println("SD Card is Present");
  } else {
      Serial.println("SD Card is Missing");
  }
  delay(1000);  //not needed in your code...only here to make for a nicer example
}

In my modest amount of testing, I believe that I have shown that this approach does play nicely with the AudioSDPlayer and AudioSDWriter, though more testing is absolutely warranted.