ESP32 Forum

I'm a dummy in this area but keen to learn. I hear phrases like IRAM, cache and heap and am trying to build a mental picture.

I think of the heap as a chunk of memory (RAM) from which data can be carved. In simple terms, this is where malloc() storage comes from.

The program stack is where local variables are pushed. For example:
both the variable "a" and "b" are local to "myFunc" and placed on the stack to be automatically deleted as the stack unwinds from the function return. I also believe that the "size" of the stack is specified in the FreeRTOS stack size parameter when one creates a task. I also believe that the memory for THAT stack is carved from the heap.

Now, and assuming the above is correct ... I wondered where "global" data is stored? What follows are two program fragments that are nearly identical with the distinction of the storage classifier.
and
In the first program, the size of the free heap did *NOT* decrease. While in the second program the size of the free heap decreased by the expected 10K. I would have naively expected that in both cases, the "buffer" variable of size 10K would have been carved from RAM (heap) ... while in the first case, it would have been initialized from its initial value (which I would assume is stored in flash). However, in my test, the first program did NOT decrease heap size ... but yet (unless I am horribly mistaken) is still writable. So where then is the RAM storage for the first buffer coming from?

Again ... I'm a dummy here ... so if we have explanation to share, please don't assume anything and if there are assumptions being made on interpreting an answer, ideally lets try and call those out.

In theory, both examples should get the memory statically allocated. Do you actually use buffer in myFunc in an useful way (that is, one that cannot be optimized away by the compiler)? If you do not, the 'static' can actually make a difference. Without the static, the array can be used by any source file that's linked into the program; the compiler is forced to include it because at compile time it does not know if another part of the program may use it. If you declare it statically, you're saying it will only be available within the scope of that specific C file. Now, if the compiler sees that the array isn't used anywhere in that C file (or used in a way that can be optimized away, e.g. when you only fill it but never read it back), it will be smart enough to optimize away the entire array and the memory for it won't be allocated at all.

Mr Sprite_TM ... I bow low to you sir. Your thinking was perfect and the explanation first class. I changed my logic to include:
To force utilization of all the data in the buffer variable. Once done, the amount of free heap for BOTH a static and non-static qualifier were exactly the same (10K carved from the heap). I hadn't realized that the compiler would be smart enough to optimize out with that kind of intelligence. Color me impressed with the compiler.

Mr WiFive,
Thank you sir. I'll study that article and try and add it to my repertoire of background knowledge so that questions I may ask in future will take that goodness into account.

Variables allocated on the stack are stored directly to the memory and access to this memory is very fast, and it's allocation is dealt with when the program is compiled. When a function or a method calls another function which in turns calls another function etc., the execution of all those functions remains suspended until the very last function returns its value. The stack is always reserved in a LIFO order, the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack, freeing a block from the stack is nothing more than adjusting one pointer. More about....Stack and Heap

John