ESP8266 Community Forum

I would have expected that global and static variables would be located at the bottom of RAM, the heap would grow upwards from there. The stack would begin at the top of RAM and would grow downwards from there.
This is without knowing anything about the architecture, registers or instruction set of the ESP8266 CPU.

I have written this little routine based on the above assumptions and it gives the amount of memory free as a negative number, so obviously the assumptions are wrong. Can someone correct me please?

long RAMfree(void) {
long free_memory;
uint8_t stackObject, *heapObjPtr, *stackObjPtr = &stackObject;
heapObjPtr = new uint8_t;
free_memory = (uint32_t)stackObjPtr - (uint32_t)heapObjPtr;
Serial.printf("\nIn RAMfree(): stackPtr = \'%lX\', heapPtr = \'%lX\', free memory = \'%ld\'\n", stackObjPtr, heapObjPtr, free_memory);
delete heapObjPtr;

return free_memory;
}


Thanks,
Peter.

After much trolling through the SDK documentation and code, I wrote the following. It suits my needs and I hope it helps someone else.

#include <cont.h>
extern cont_t g_cont;
#include <user_interface.h>
// ######################################################################################
long RAMfree(void)
{
long s, h;

Serial.printf("\n Heap free = \'%d\', Stack free = \'%d\', Stack guard bytes were ", (h=system_get_free_heap_size()), (s=cont_get_free_stack(&g_cont)));
if( ! cont_check(&g_cont)) {
Serial.printf("NOT ");
}
Serial.println("overwritten");

return (s+h);
}

I needed to find out if I had used all the available RAM after pulling many libraries into the sketch I am writing.
I found out that I had only used 6k out of 39k of heap and less than 2k out of the default 4k of stack.

I've got a WeMOS D1 mini to which is attached a WeMOS SD shield.

Before I go further and everybody leaps on my back, I've tried the latest R2.3.0 distribution and it compiles OK, once I've set the IDE to report ALL compiler messages and fixed all its complaints BUT the downloaded (the IDE says it's uploading but my convention is different - transfer from a big computer to a little computer is DOWNloading!) program doesn't run at all, at all. Debugging output is all garbage.

I'm using R2.2.0 and as I've added features to the sketch I'm writing, correct functionality from the SD library has decreased and become sporadic.
Now, the filesystem is on a 512Mb card which has had the file system checked, it's been reformatted, the files written back to it and deleted individually before being written back to the card by WIN7.
Initially, everything worked, but when I added some functionality in a totally unrelated part of the sketch:

First, the library refused to remove a file unless I tickled it just right as follows.

String myFileName = "MYFILENA.ME1"
SD.remove(myFileName); // DOESN'T WORK

SD.remove(myFileName.c_str()); // DOESN'T WORK

SD.remove("MYFILENA.ME1"); // WORKS???? but compiler complains.

I was happy with that for a while but it got worse as the sketch grew. Now, some files can be opened and read in one part of the sketch but refuse to open at all in a different part of the sketch. Now no files can be removed by the WeMOS D1 mini, no matter what calling convention I use.

I'm trying to trace the problems by adding debugging output to SerialHardware in an increasing number of places in the SD and SdFat libraries but this is driving me not-so-slowly CRAZY.

Is there anybody already familiar with the SdFat library who can assist with this problem?

Peter.

OldBikerPete wrote:(the IDE says it's uploading but my convention is different - transfer from a big computer to a little computer is DOWNloading!)

Unfortunately, your convention is not right !
it is not the size of the computer that matter, but the direction of the transfer :
Pull = Download
Push = Upload
So, when pushing new firmware to ESP is an Upload !

For your issues about SD.remove(), I don't understand why it doesn't work since the following methods are defined in SD.h :



EDIT : Ok ! I gave it a try, and I've faced some hardware watchdog issue. I'm now looking into it to get a fix.
Ok ! I found the reason here and it is hiding probably a compiler issue, but there is a workaround.
The diagnostic reveal that "boolean remove(const String &filepath) { return remove(filepath.c_str()); }" is calling itself in an infinite recursion. It have been seen also by someone else in this thread viewtopic.php?f=32&t=10755&start=12
Two solutions are possible, one is to add "char *" casting in "remove((char *)filepath.c_str());", but I think it would be better to change the other method to be "boolean remove(const char *filepath);", but that would mean adding "const" in many places.