There was discussions prior to the release of the initial Photon regarding application/user available Flash and RAM. But this was only a wild guess since the firmware was still in development. But with production releases, can engineering report how much user available Flash memory is available for applications code and how much RAM space is available.
Regarding RAM space, can I assume that the stack will be at the high end of available RAM space and working its way down toward the applications variable data? We’re porting an Arduino application in which we have a background stack monitor that operates to let us know how deep the stack might get so we can determine how much RAM we can really use in the application. Is the stack pointer variable and top of RAM location available to the application so we can determine what is available? In one of our applications we use the area above the top of allocated RAM and the bottom most location of the stack as heap space to allocate to the application.
Also, in the Arduino, in order to conserve RAM space you had the option of specifying that constants, such as strings, would be stored along with the code in Flash memory instead of taking up RAM space. Is this implemented in the Photon? A statement such as
const char dbg_message1[] PROGMEM = “\nYou are at step 1 of your application\n”;
would not take up RAM space with the text of the message. It would be stored in Flash instead.
See this thread for partial answers on heap and stack, but the bottom line is that heap is difficult.
The answer to your other question about the progmem equivalent is to use the const keyword:
const char[] bigArray = "This is test of the emergency broadcasting system. This is only a test. If this was an actual emergency you would have been directed to ..."; //lives only in flash
I was not aware that there was an out of memory SOS blink built into the firmware. On our Arduino app we built such a function into our application by initializing the free memory area to a known bit pattern and checking in the background where that pattern remains intact from the top of memory down. Is this being done in the firmware itself?
In 0.4.4.rc.3 (available in the github repo), we have System.freeMemory() which shows the minimum available heap (the actual amount of free memory can be more, but not less.) I saw figures in the region of 68kBytes before connecting to the cloud, and 60kBytes after connecting to the cloud.
For program memory, there is a maximum of 128K. Now that the system firmware is separate, your program can be as small as a few hundred bytes.