-
Notifications
You must be signed in to change notification settings - Fork 13.3k
SDFS/SD make F() strings appear in RODATA, not flash #6767
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
Comments
However it is unusable, see esp8266/Arduino#6767
Just an update. |
Can you provide a simple MCVE, @TD-er , which shows this? That would let me reproduce it locally and make fixing things much faster. |
OK, took a while to come up with a proper MCVE. #include <Arduino.h>
#include <SD.h>
void setup() {
// String foo = F("Lorem ipsum ...., euismod tortor.");
}
void loop() {
} I used 5 paragraphs of Lorum Ipsum as one-liner in the flash string. (3229 characters, used 2 spaces between the paragraphs) What happens is this: (core 2.6.0)
It looks like all flash strings are now in memory, as soon as you include |
Cool. That's very weird and I'll definitely look into it! |
I just updated the order of the outputs, to make it more logical. |
Just one thing that looks strange while browsing through the includes from SDFS.h. The file Probably nothing to do with this, but it also doesn't help compilation either I guess. (although it does include |
Ah, able to repro and narrow it down. The issue is actually caused by including the real <SdFat.h> file from SdFat library! For some reason he has this snippet in src/syscall.h
I'll pull it out (we already have some local changes for SPI compat) and do some testing... |
Updated the title, @TD-er , just to make it clear when the PR comes in what the root issue was. |
Also, about assert.h: That's coming from the GCC toolchain, basically, and I only added the pgmspace.h include and did minor tweaks to the #define. I think it's fine as-is, because that's what all other OSes and chips are doing (well, anything using GCC...) |
When SdFat.h is included it was undefining the F() (flash string) macro. This causes all strings to go into RAM, as seen in this issue: esp8266/Arduino#6767 Remove this undef. The F() is only used in a few print statements which are F()-safe on the 8266 now, and in the SD.h and SDFS.h libs the function that actually calls print(F(xxxx)) is never used.
Fixes esp8266#6767 . Remove the `undef F` from SysCall.h as it is not needed nor used in the SD or SDFS libraries. This puts F() strings back in flash when using the SD/SDFS libs.
Fixes #6767 . Remove the `undef F` from SysCall.h as it is not needed nor used in the SD or SDFS libraries. This puts F() strings back in flash when using the SD/SDFS libs.
Basic Infos
Platform
Settings in IDE
Problem Description
In my project, we have had log to SD present, but since it was disabled for a long time, I now made it compile again.
At first there is this strange thing when including SD.h, a lot of
__FlashStringHelper
related code would no longer compile.For example I could not compile code like this anymore:
Had to change it into separate functions with a switch statement returning F() macro defined strings.
After changing all of these, I ended up with this error:
Only when throwing out almost all code from my sketch, I was able to compile it wilt SD support enabled.
But I doubt it is useful, since you don't have any memory left.
Without SD support:
With SD support:
That's an increase of over 26 kByte RAM usage.
I'm not entirely sure the issue with the
__FlashStringHelper
related code has anything to do with this, but maybe it does somehow prevent strings to be stored in flash?The text was updated successfully, but these errors were encountered: