Skip to content
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

Add a way to control the type of the SdFat file being used #87

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mkende
Copy link

@mkende mkende commented Apr 28, 2023

This change introduce a new USE_SDFAT_FAT32 preprocessor variable that can be set to control the compilation of the library. When set, the library will use the File32 and SdFat32 types from the SdFat library rather than the default File and SdFat whose meaning is context dependant.

This serves two purposes:

  • when an Arduino core has an FS.h header then the current code will not compile because the SdFat and File are not defined.
  • the default SdFat File type on modern core is a typedef for SdFat FsFile type, which has a subset of the interface of the File32 one, which also prevent some existing code from compiling.

This change is a no-op for people who don’t define the new variable, so it should not break any existing code.

@johnwargo
Copy link
Contributor

@ladyada can you have someone look at these pull requests? Many of them are years old.

@caternuson
Copy link
Contributor

What's an example sketch that can be used for testing?

Unfortunately, the current file player examples in the library have hard coded #include <SD.h>, so will generally not work as is.

@mkende
Copy link
Author

mkende commented Mar 10, 2024

I don’t have a small working example ready that can be used, but just an empty sketch that import the VS1053 library will fail to compile using the rp2040 core:

#include <Adafruit_VS1053.h>

The compilation will succeeds with the new USE_SDFAT_FAT32 constant set (and it will work correctly in more complex sketch using SdFat.h instead of SD.h).

@mkende
Copy link
Author

mkende commented Apr 29, 2024

Any chance this can be merged?

@mkende mkende force-pushed the patch-2 branch 2 times, most recently from 0efc525 to 2aa84fb Compare July 15, 2024 21:39
@mkende
Copy link
Author

mkende commented Jul 15, 2024

Any chance this can be merged some day? This has been open for more than a year (and, to confirm, a no would be a valid answer too, if there is a reason why this change cannot be merged).

If the new USE_SDFAT_FAT32 macro is not set, this change is a no-op to all existing users, so it’s fairly low risk (and I can give a longer name to the macro if needed).

This change introduce a new USE_SDFAT_FAT32 preprocessor variable that can be set to control the compilation of the library. When set, the library will use the File32 and SdFat32 types from the SdFat library rather than the default File and SdFat whose meaning is context dependant.

This serves two purposes:
- when an Arduino core has an FS.h header then currently the code will not compile because the SdFat and File classes are not defined.
- the default SdFat File type on modern core is a typedef for SdFat FsFile type, which has a subset of the interface of the File32 one, which also prevent some existing code from compiling.

This change is a no-op for people who don’t define the new variable, so it should not break any existing code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants