Refactor AudioSDWriter and AudioSDPlayer to use SD not SdFS

[chipaudette]

Due to my inexperience at the time, our AudioSDWriter_F32 and AudioSDPlayer_F32 are not well designed. Among their many problems is that they access the SD card via the SdFs library instead of the Teensy/Arduino standard SD library. I think that we should move these two classes (and SDWriter underneath) to use the more-standard SD library.

Problems with the current SdFs-based implementation include:

• Confusion over how to best handle the fact that both AudioSDWriter and AudioSDPlayer want to access the SD card. I think that we've worked it out by using a pointer to the same underlying SdFs instance, but I'm not sure it's as good as using the singleton that is SD.

• By using SdFs directly, we can't use features that are written specifically at the level of SD. In this case, I 'm speaking mostly about the ability to see if an SD card is present. There may also be additional SD-only capabilities that I'm not familiar with.

The biggest argument to keep the SdFs-based implementation (besides the fact that it exists and that it seems to work) is that SdFs generally has lots more capabilities. Luckily, even if we move to SD, you can still ask SD for the SdFs underneath via SD.sdfs. So, we'd be good! Sadly, AFAIK you can't do the reverse; you can't ask for the singleton SD object from our SdFs instance.

Besides just being a more standard implementation, moving to SD provides these benefits:

• We can easily wrap SD so that we can be sure we only call SD.begin() once, which is the real problem with trying to detect the SD card.

• To learn how to use the SD subsystem better, we only have to read through the far-more-simple SD Library and not the crazy-complicated SdFs library (aka SdFat).

Our inability to make continuous improvements to Tympan's SD capability is in large part due to the difficulty of understanding SdFs. I think that moving to SD would make everything more clear and easier.

[chipaudette]

Tag: @eyuan-creare

Note, I'm placing this issue here so that I don't forget. Until there's a small budget offered to execute this task, it'll just sit here. I'm hopeful, though, I'm hopeful!

[chipaudette]

I looked through the Tympan code and identified all the methods from the SdFs and SdFile classes that I use from the SdFat library. These are the methods that, ideally, I'd replace with substitutes from the SD library (ie, the SDFile and SDClass classes).

To my eye, this looks pretty promising. There are a few that I don't see direct substitutes for, but I think that we can work around them pretty easily.

The only really missing item is the method createContinguous, which can be used to pre-allocate a large file space on the SD card to (hopefully) reduce hiccups during writing. I don't actually use it right now in the Tympan library because I didn't really see any improved performance during all of my write tests. Since it's not used by the Tympan library now, I guess that means it'd be easy to live without.

[chipaudette]

If this revision is ever done, here's the test to do:

SDWriter_wApp_wMTP_foo.zip

1. See the attached ZIP. Modify it to use the new AudioSDWriter. You can see whether an SD card is inserted by asking for the help menu via 'h' and looking at the top of the resulting printout.
2. Start the Tympan without an SD card. Confirm that it reports that it has no SD card (via 'h')
3. Insert an SD card and confirm that it reports that it does have an SD chard ('h')
4. Record a WAV file ('_Axr') and stop recording a WAV file ('_Axs')
5. Confirm that it still thinks that it has an SD card ('h')
6. Try recording a second WAV file ('_Axr') and stop ('_Axs')

If the revised firmware is successful, it will be able to complete this test. Earlier attempts at enabling SD card detection failed at step (6)...it would not start recording the second WAV file. Specifically, it seems to be unable to open a file for recording.

I believe that it failed because each check of the SD card in steps (2), (3), and (5) causes a hidden SD.begin() to be called. Also, the first recording of a WAV file in Step (4) causes a hidden SdFs.begin() to be called. I believe that the system cannot handle any SD.begin() being called after the first SdFs.begin(). Hence, the system fails at Step (6).