So, with the Core, it was pretty easy to interpret the output of arm-non-eabi-size to determine the amount of space left on the device (108 kB > text+data size). However, with the new Photon splitting up the System and User space, I’m not sure what the best way to accomplish this task is. Does anyone have any insight into this? Thanks!
@mumblepins, with the Photon firmware still under development, it’s really hard to peg how much user space there will be. My understanding is that there is 128KB available for user programs. Some code that normally went in the user space like sprintf is now in the system space! With multi-threading around the corner, I am not sure what the effective user code space will be but assume it is larger than what the Core has. The tougher bit is how much RAM is available. Again, I would say you can count on 80KB or so but that is an educated guess. 
With building locally, is there a way to tell what the current system+user+whatnot space is used,?
@mumblepins, not in a nice “packaged” way. For now, you’ll have to use the old trial and error method 
the flag MODULAR=n will build a combined system + user app .bin file.
3 Likes
You can use the output from the compiler as before to know the static program size and also the amount of static memory allocated. As you mentioned, the tricky part is knowing what the upper limit is. 
The maximum size of the whole image (program code + non-zero initialized variables) is 128K.
The maximum size of statically allocated ram is presently
0x20000 - 0x300 - 40K
Which is 79K. (This is from the file modules/photon/user-part/linker.ld)
This value may change over time, hopefully increasing as we optimize the system code/WICED libraries to use less static RAM.