OK so without having to delve into the depths of the linker etc. Is there a ‘simple’ way to interpret the CLI compiler output.
text data bss dec hex filename
13868 176 19800 33844 8434 /spark/com
This doesn’t really tell me how much code space and/or RAM my app is currently using - OR what is left still available ???.
Basically I can’t find anywhere which tells me how much space I have available OR used ???. Need to know this so I can plan developments please :-).
NB Apologies if I’ve missed something in the existing docs.
I see this from the Web IDE for a test app
Output of arm-none-eabi-size:
text data bss dec hex
5372 172 396 5940 1734
In a nutshell:
Flash used 5544 / 110592 5.0 %
RAM used 568 / 20480 2.8 %
Does this really mean that I have 110592 bytes of FLASH for my app ?? and 20480 bytes of RAM ??.
Doesn’t stack up with my (different) app reporting freeMem as more than 39k…
Sorry if I am being a noob here :-O. Always did find C linker output to be a ‘black art’ ;-)).
Here you can find a nice brief info how to read the figures you are seeing.
Let's get (non)volatile
And a bit more elaborate
For the time being the problem with Web IDE is, that the relative numbers are still refering to the Particle Core which only had about 20KB of SRAM, but the Photon has got 128KB of which some is used for the system and leaves you about 60K to start with.
The figure you get from
System.freeMemory() should give you a “good” idea how much you have free at least, but the number can change while your program is running due to dynamic RAM allocation (e.g. by use of
String objects or explicit
malloc() or such).
Again you are the man with answers - MANY thanks ;-)).
Yes I already use freeMemory - in fact I set this up as a variable (during development) so that I can keep an eye on it…
Suggestion for Particle - can the Dev and/or CLI environments be set up to show this automatically after a compile ???. I regularly used Forth compilers back in the 1980’s which clearly told me how much RAM and EEPROM (yes I do pre-date FLASH by that many years!! and it was WAY more critical back then) was used and how much left free = seemples
Of course this will then get more complex when we need to know how much stack is allocated (per thread or task - as per freeRTOS), and how much HEAP has been allocated/is available etc.
We’ll get there - I’m sure !!.
AFAIK the CLI does give you the TEXT/DATA/BSS output by default (roughly 55K - (DATA + BSS) should give you something near the initial reading of
System.freeMemory() on a Photon).
And for Dev it’s on the ToDo list.