Go Down

Topic: Problem with SD Library and long strings (Read 2 times) previous topic - next topic

PaulS

Quote
I'm afraid you are not understanding me.

On the contrary, I do understand you.

Quote
Now add those two really long strings from my original post as global variables at the top of the file

Now, use up all available SRAM.

Quote
then something is wrong with the library and it needs to be fixed

The problem is that you are running out of SRAM. Changing the library so that it doesn't work won't help. Rather, it won't be useful.

Quote
or at least noted that the library needs a certain amount of memory free before it can be used.

More likely for this to happen, but the question is how much? And how/when do you measure that? SRAM usage is not static. What might be just barely enough in one sketch will not be enough in another sketch.

Oily The Otter

Quote
Quote
or at least noted that the library needs a certain amount of memory free before it can be used.

More likely for this to happen, but the question is how much? And how/when do you measure that? SRAM usage is not static. What might be just barely enough in one sketch will not be enough in another sketch.


Although SRAM usage is dynamic, I think my problem is too much static usage because my program barely gets off the ground before it crashes.
It looks like the SD library needs at least 25% of your SRAM to function based on it's cache:
Code: [Select]
// SdVolume class
/**
* \brief Cache for an SD data block
*/
union cache_t {
           /** Used to access cached file data blocks. */
  uint8_t  data[512];
           /** Used to access cached FAT16 entries. */
  uint16_t fat16[256];
           /** Used to access cached FAT32 entries. */
  uint32_t fat32[128];
           /** Used to access cached directory entries. */
  dir_t    dir[16];
           /** Used to access a cached MasterBoot Record. */
  mbr_t    mbr;
           /** Used to access to a cached FAT boot sector. */
  fbs_t    fbs;
};


I think the library reference page should note that it takes a good chunk of your resources to run. Especially considering the consequences of going over the limit.

The sketch I am having a problem with is a web server, which has a bunch of static strings that make up the webpage I am trying to serve. These strings are probably taking up more than half of my SRAM and trying to add SD Library to the mix is causing the crash. I already have a bunch of strings in program memory, but I will try to move more of them there. I will also try to reduce the number of static arrays I am using.

Any other tips for reducing my SRAM usage?
Can I measure the amount of SRAM I am using at compile time?

Thanks for your help, PaulS. I really appreciate it.

jcarrr

I fought almost this same problem for a long time.  Because the problem would come and go, and because  it seemed to respond to the order and when variables, and particularly char arrays were declared, It only dawned slowly that it was a memory problem.  Considering the time spent chasing the problem, the move to a megaArduino was a cheap fix.  I

I now declare the char array buffers globally so they don't impact ram in unexpected ways.

I use one of the RAM reporting functions and stick a Serial.print in here and there while debugging to see how RAM is coming.  I see lots of discussion about the relative merits of the RAM programs, but if it continues to report 3000 bytes available in the Mega implementation, who cares about precision.

Go Up