Stack vs heap in embedded context - Visual Side-by-Side Comparison

Concept Flow - Stack vs heap in embedded context

Start Program

↓

Initialize Stack

↓

Function Calls & Local Variables

↓

Push/Pop on Stack

↓

Initialize Heap

↓

Dynamic Memory Allocation

↓

Allocate/Free on Heap

↓

Program Ends

Program starts with stack setup for function calls and local variables, and heap setup for dynamic memory; stack grows/shrinks with calls, heap allocates/frees memory dynamically.

Execution Sample

Embedded C

void func() {
  int a = 10;
  int *p = malloc(sizeof(int));
  *p = 20;
  free(p);
}

This code shows local variable 'a' on stack and dynamic allocation of 'p' on heap, then freeing heap memory.

Execution Table

Step	Action	Stack State	Heap State	Notes
1	Enter func(), allocate 'a'	a=10 (top of stack)	empty	Local variable 'a' stored on stack
2	Call malloc(sizeof(int))	a=10	Allocated 4 bytes at addr X	Heap allocates memory for '*p'
3	Assign *p = 20	a=10	Memory at addr X = 20	Heap memory content updated
4	Call free(p)	a=10	Memory at addr X freed	Heap memory released
5	Exit func(), pop 'a'	stack empty	heap empty	Stack frame removed, heap memory freed

💡 Function ends, stack frame popped, heap memory freed

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
a	undefined	10	10	10	10	undefined
p	undefined	undefined	addr X	addr X	addr X	undefined
Heap Memory at addr X	empty	empty	allocated	20	freed	empty
Stack	empty	a=10	a=10	a=10	a=10	empty

Key Moments - 3 Insights

Why is the local variable 'a' stored on the stack and not on the heap?

Local variables like 'a' are stored on the stack because they have fixed size and lifetime tied to function calls, as shown in execution_table step 1 where 'a' is allocated on stack when func() starts.

What happens if we forget to free the heap memory allocated by malloc?

If we don't free heap memory (step 4), it remains allocated causing memory leaks, which is critical in embedded systems with limited memory.

Why does the stack grow and shrink automatically but heap requires manual management?

Stack grows/shrinks with function calls automatically (push/pop), but heap memory must be allocated and freed manually (steps 2 and 4), as heap is managed by programmer.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what happens to the heap?

A Stack allocates 4 bytes

B Heap memory is freed

C Heap allocates 4 bytes of memory

D Stack memory is freed

💡 Hint

Check the 'Heap State' column at step 2 in execution_table

At which step does the stack frame for 'a' get removed?

A Step 3

B Step 5

C Step 2

D Step 4

💡 Hint

Look at the 'Stack State' column and notes in execution_table

If we remove the free(p) call, what changes in the variable_tracker for heap memory?

A Heap memory remains allocated after final step

B Heap memory is freed as usual

C Stack memory increases

D Variable 'a' is stored on heap

💡 Hint

Refer to 'Heap Memory at addr X' row in variable_tracker after step 4

Concept Snapshot

Stack vs Heap in Embedded C:
- Stack stores local variables and function calls
- Stack grows/shrinks automatically with calls
- Heap stores dynamic memory allocated with malloc
- Heap requires manual allocation and free
- Embedded systems have limited memory, careful management needed

Full Transcript

In embedded C, the stack is used for local variables and function calls, growing and shrinking automatically as functions start and end. The heap is used for dynamic memory allocation with malloc and free, which must be managed manually. For example, in the code, variable 'a' is stored on the stack when func() is called, while memory for pointer 'p' is allocated on the heap. The heap memory must be freed to avoid leaks. The stack frame is removed when the function ends. This distinction is important in embedded systems where memory is limited and must be carefully managed.

Practice

1. In embedded C, where are local variables inside functions typically stored?

easy

A. On the stack

B. On the heap

C. In flash memory

D. In CPU registers only

Solution

1. Step 1: Understand local variable storage

   Local variables inside functions are temporary and exist only during function execution.

2. Step 2: Identify stack usage in embedded C

   The stack is used to store temporary data like local variables and return addresses.

3. Final Answer:

   On the stack -> Option A

4. Quick Check:

   Local variables = stack [OK]

Hint: Local variables go on stack, dynamic memory on heap [OK]

Common Mistakes:

• Confusing heap with stack for local variables
• Thinking local variables are stored in flash
• Assuming all variables are in CPU registers

2. Which of the following is the correct way to allocate memory dynamically in embedded C?

easy

A. int p = malloc(sizeof(int));

B. int *p = sizeof(int);

C. int *p = malloc(sizeof(int));

D. malloc(int p);

Solution

1. Step 1: Recall malloc syntax

   malloc returns a pointer to allocated memory, so pointer variable is needed.

2. Step 2: Check each option

   int *p = malloc(sizeof(int)); correctly assigns malloc's return to an int pointer. Others misuse types or syntax.

3. Final Answer:

   int *p = malloc(sizeof(int)); -> Option C

4. Quick Check:

   malloc returns pointer, assign to pointer [OK]

Hint: malloc returns pointer, assign to pointer variable [OK]

Common Mistakes:

• Assigning malloc result to non-pointer variable
• Using sizeof without malloc
• Incorrect function call syntax

3. What will happen if you declare a large array inside a function in embedded C on a system with limited stack size?

medium

A. Stack overflow may occur causing a crash

B. Heap memory will be used automatically

C. The array will be stored in flash memory

D. The compiler will convert it to a global variable

Solution

1. Step 1: Understand stack size limits

   Stack size is limited in embedded systems; large local arrays consume stack space.

2. Step 2: Consequence of large stack allocation

   Allocating large arrays locally can exceed stack size, causing overflow and crash.

3. Final Answer:

   Stack overflow may occur causing a crash -> Option A

4. Quick Check:

   Large local arrays risk stack overflow [OK]

Hint: Large local arrays risk stack overflow in embedded [OK]

Common Mistakes:

• Assuming heap is used automatically
• Thinking large arrays go to flash
• Believing compiler auto-converts locals to globals

4. Consider this code snippet in embedded C:

void func() {
  int *p = malloc(10 * sizeof(int));
  // ... use p ...
  // missing free(p);
}

What is the main problem here?

medium

A. Pointer p is not initialized

B. Stack overflow due to large local array

C. Syntax error in malloc usage

D. Memory leak because allocated heap memory is not freed

Solution

1. Step 1: Analyze malloc usage

   Memory is allocated on the heap with malloc but never freed.

2. Step 2: Identify consequences of missing free

   Not freeing heap memory causes memory leak, wasting limited embedded memory.

3. Final Answer:

   Memory leak because allocated heap memory is not freed -> Option D

4. Quick Check:

   Missing free causes memory leak [OK]

Hint: Always free malloc memory to avoid leaks [OK]

Common Mistakes:

• Confusing stack overflow with memory leak
• Thinking malloc syntax is wrong
• Assuming pointer is uninitialized

5. In an embedded system with 2KB stack and 4KB heap, which approach is best to safely allocate a 1KB buffer for temporary data?

hard

A. Declare a local array of 1KB inside a function

B. Use malloc to allocate 1KB on the heap and free after use

C. Declare a global 1KB array to avoid stack and heap

D. Use a static local array inside the function

Solution

1. Step 1: Evaluate stack usage for large buffer

   1KB local array uses half the stack, risking overflow in embedded systems.

2. Step 2: Consider heap allocation safety

   Allocating 1KB on heap with malloc is safer; heap is larger and managed manually.

3. Step 3: Compare global and static arrays

   Global/static arrays use fixed memory but reduce flexibility and increase RAM usage always.

4. Final Answer:

   Use malloc to allocate 1KB on the heap and free after use -> Option B

5. Quick Check:

   Heap allocation safer for large temporary buffers [OK]

Hint: Use heap malloc for large temporary buffers in embedded [OK]

Common Mistakes:

• Using large local arrays risking stack overflow
• Ignoring freeing heap memory
• Assuming global arrays are always best