How to Reduce RAM and Flash Memory Usage in Embedded C

What Is Memory Optimization in Embedded C?

Memory optimization in Embedded C involves organizing data and instructions efficiently so that an application uses the available memory effectively.

Unlike desktop computers, which typically have gigabytes of RAM, microcontrollers operate within much smaller memory limits. A program that works correctly on a computer may not fit into the RAM or Flash memory of a resource-constrained embedded device.

Two major types of memory must be considered:

1. RAM (Random Access Memory)

RAM stores data that the processor needs while the application is running. It commonly holds global variables, static variables, stack data, dynamically allocated memory, and other runtime information.

For example, sensor readings, communication buffers, and temporary calculation results may occupy RAM.

2. Flash memory

Flash memory is non-volatile memory used to store firmware and other data that must remain available after power is removed. It commonly holds program instructions, constant data, lookup tables, and initialization values, depending on the microcontroller architecture and compiler.

For example, the compiled instructions for reading a sensor or controlling a motor usually occupy Flash memory.

Why Is Embedded C Memory Optimization Important?

Memory optimization is important for several practical reasons.

• Limited hardware resources: Small microcontrollers cannot accommodate unlimited program data or instructions.
• Improved reliability: Excessive stack usage, buffer overflow, or heap fragmentation can cause unexpected failures.
• Lower hardware cost: Efficient firmware may allow an application to run on a less expensive microcontroller.
• Room for new features: Reducing existing memory usage leaves space for additional functionality.
• Better resource management: Efficient buffers, data structures, and algorithms help applications operate within predictable memory limits.
• Easier debugging: Understanding memory allocation makes it easier to investigate crashes, corrupted variables, and hard faults.

For example, an STM32-based sensor monitoring device may need RAM for sensor buffers, communication stacks, control variables, and an RTOS. Optimizing one large buffer or eliminating unnecessary copies can make a meaningful difference when RAM is limited.

1. Choose the Correct Data Types

One of the simplest embedded C code optimization techniques is selecting appropriate data types.

C provides several data types, including char, short, int, long, and fixed-width integer types such as uint8_t, uint16_t, and uint32_t.

The actual size of some C data types depends on the implementation. Fixed-width types from are useful when the application requires a specific number of bits.

Consider the following example:

#include 

uint32_t sensor_count;
uint32_t error_code;
uint32_t device_state;

If the variables only need to store small non-negative values, a smaller type may be sufficient:

#include 

uint16_t sensor_count;
uint8_t error_code;
uint8_t device_state;

Here, uint16_t can represent values from 0 to 65,535, while uint8_t can represent values from 0 to 255.

However, choosing smaller types requires checking the full range of possible values.

For example, a counter that can exceed 255 cannot safely be converted to uint8_t without changing the program’s behavior.

2. Use const Correctly to Manage RAM and Flash

The const keyword indicates that an object must not be modified through that object’s declared type. It is especially useful for calibration values, lookup tables, fixed configuration parameters, and other read-only data.

Consider a lookup table used for a sensor conversion:

#include 

const uint16_t temperature_table[] = {
    100, 125, 150, 175, 200, 225
};

Compare it with:

#include 

uint16_t temperature_table[] = {
    100, 125, 150, 175, 200, 225
};

The first declaration communicates that the table is read-only. On many embedded toolchains, appropriately placed constant data can be stored directly in Flash rather than occupying writable RAM.

The second declaration creates a writable array, which may require RAM for its runtime copy.

However, const alone does not guarantee that data will be placed in Flash. The exact behavior depends on the target architecture, compiler, linker script, memory model, and startup code.

For example, on many Cortex-M microcontrollers, constant data is mapped into Flash, while initialized writable global variables are stored in RAM and initialized from values held in Flash at startup.

Use const for genuinely read-only data, and verify placement through the linker map file.

3. Avoid Unnecessary Global and Static Variables

Global and static variables generally have storage for the lifetime of the program. They can consume RAM even when the application does not actively use them.

Consider this example:

#include 

uint8_t sensor_buffer[256];
uint8_t communication_buffer[512];
uint32_t calculation_result;

These objects may occupy RAM throughout program execution.

If a buffer is needed only temporarily, consider whether a smaller buffer or a different processing approach can satisfy the requirement.

For example, instead of storing an entire data stream, process it in smaller chunks:

#include 

#define CHUNK_SIZE 32

void process_sensor_data(void)
{
    uint8_t buffer[CHUNK_SIZE];

    /* Read and process data in smaller chunks. */
}

This reduces the buffer’s size compared with a large persistent array, although the local buffer now consumes stack space while the function executes.

Do not simply move every global array to a local variable. On embedded systems, the stack is often limited, and large local arrays can cause stack overflow.

4. Reduce Large Arrays and Buffer Sizes

Arrays are a common source of excessive RAM usage in embedded applications.

Suppose a microcontroller stores 1,024 16-bit sensor samples:

#include 

uint16_t sensor_samples[1024];

The array requires:

That is 2 KiB of storage, assuming uint16_t is exactly 16 bits and no additional storage is counted.

If the application can process only 64 samples at a time, a smaller buffer may be sufficient:

#include 

uint16_t sensor_samples[64];

The buffer now requires:

This reduces the buffer’s storage requirement by 1,920 bytes.

However, the correct buffer size depends on the sampling rate, processing time, communication speed, and whether samples can arrive while processing is in progress.

For UART, SPI, I2C, DMA, or ADC applications, ensure that reducing the buffer does not cause lost data or timing problems.

Useful techniques include:

• Use circular buffers when continuous data streaming requires them.
• Process data incrementally instead of storing everything.
• Avoid allocating multiple buffers for the same purpose.
• Reuse memory only when object lifetimes do not overlap.
• Calculate the minimum buffer size from actual timing and throughput requirements.

5. Optimize Structures and Padding

Structures can consume more memory than the sum of their individual fields because compilers may insert padding to satisfy alignment requirements.

Consider:

#include 

struct DeviceInfo {
    uint8_t status;
    uint32_t timestamp;
    uint8_t mode;
};

Although the fields total six bytes, the structure may occupy 12 bytes on a common ABI because of alignment and padding.

Reordering the members may reduce padding:

#include 

struct DeviceInfo {
    uint32_t timestamp;
    uint8_t status;
    uint8_t mode;
};

On many common 32-bit ABIs, this arrangement occupies eight bytes, but the exact result depends on the target and compiler.

If an application stores hundreds of such structures, saving a few bytes per object can significantly reduce total RAM usage.

Use sizeof(struct DeviceInfo) to inspect the actual size on the target toolchain.

Avoid using packed structures indiscriminately. Packing may create unaligned fields, potentially causing slower access or hardware faults on some architectures. Also, structure layout used for communication protocols should be handled carefully because compiler padding and byte order can affect portability.

6. Reduce Stack Usage in Embedded C

The stack stores function-call information and commonly holds local variables, saved registers, and other execution state. Interrupt handling and nested function calls also contribute to stack requirements.

Large local arrays can consume substantial stack space.

For example:

void process_data(void)
{
    uint8_t buffer[1024];

    /* Process data */
}

This function reserves a 1 KiB local array, subject to the target’s implementation and stack allocation rules.

On a microcontroller with a small stack, this may be unsafe.

A better design may use a smaller buffer:

void process_data(void)
{
    uint8_t buffer[64];

    /* Process data in smaller chunks */
}

The smaller buffer reduces the local storage requirement by 960 bytes.

Other stack optimization techniques include:

• Avoid deeply nested function calls when unnecessary.
• Review recursive functions, especially when stack usage is difficult to bound.
• Avoid large local structures and arrays.
• Measure worst-case stack consumption, including interrupt nesting.
• Set appropriate stack sizes for tasks in RTOS-based applications.

Do not assume that moving a local variable to global storage is always a good solution. It may increase persistent RAM usage and introduce reentrancy or concurrency problems.

7. Minimize Dynamic Memory Allocation

Dynamic memory allocation uses functions such as malloc(), calloc(), realloc(), and free().

Although dynamic allocation can be useful, it introduces additional considerations in resource-constrained embedded systems. Heap fragmentation, allocation failures, unpredictable execution time, and lifetime-management errors can make a system harder to verify.

Example:

#include 

void process_message(void)
{
    char *message = malloc(256);

    if (message != NULL) {
        /* Process message */

        free(message);
    }
}

The allocation requests 256 bytes, but the allocator may consume additional heap space for metadata and alignment.

For small systems with predictable requirements, a fixed-size buffer can be easier to manage:

#include 

#define MESSAGE_SIZE 64

static uint8_t message_buffer[MESSAGE_SIZE];

void process_message(void)
{
    /* Use the fixed-size buffer */
}

This example reserves storage for a reusable buffer rather than requesting memory dynamically for each call. It is suitable only if the buffer’s lifetime, reentrancy, and concurrency requirements are satisfied.

For RTOS-based applications, separate tasks may need independent buffers, and shared buffers may require synchronization.

The goal is not to prohibit dynamic allocation in every embedded project. Instead, choose a memory allocation strategy that provides predictable behavior for the application’s requirements.

8. Reduce Flash Memory Usage by Optimizing Code

Flash memory stores firmware instructions and, depending on the linker configuration, constant data and other read-only sections.

Reducing RAM alone does not necessarily reduce firmware size. To reduce Flash memory usage, examine the compiled program and identify unnecessary code, duplicate logic, oversized lookup tables, and unused library functions.

Consider repeated code:

void control_motor(void)
{
    /* Repeated initialization logic */
}

void control_pump(void)
{
    /* Similar repeated initialization logic */
}

If the functions contain genuinely identical logic, a shared helper function may reduce duplication:

static void initialize_output(void)
{
    /* Shared initialization logic */
}

void control_motor(void)
{
    initialize_output();
}

void control_pump(void)
{
    initialize_output();
}

However, extracting a function does not always reduce Flash usage. Function-call overhead, compiler inlining, optimization settings, and the amount of duplicated code determine the final result.

Other useful techniques include:

• Remove unused functions and variables where possible.
• Enable appropriate compiler optimization settings.
• Use linker garbage collection for unused sections when supported.
• Avoid unnecessarily large libraries.
• Select suitable integer formats and algorithms.
• Reduce redundant logging and diagnostic strings in production builds.
• Measure code size after each meaningful change.

Do not sacrifice readability or reliability for a negligible reduction in firmware size.

9. Use Compiler Optimization Settings Carefully

Compilers can optimize generated machine code to improve execution speed, reduce code size, or balance both objectives.

For GCC-based embedded toolchains, common options include:

• -O0: Minimal optimization, often useful during early debugging.
• -O1: Basic optimization.
• -O2: Broader optimization intended to balance performance and code size.
• -Os: Optimize for code size.
• -Oz: Available in certain GCC versions and toolchains for stronger size-oriented optimization.

Exact support and behavior depend on the compiler version and target.

For example, a firmware project targeting an STM32 microcontroller may use a size-oriented optimization option to reduce Flash consumption.

A typical build configuration could include:

arm-none-eabi-gcc -Os -ffunction-sections -fdata-sections \
    -c application.c -o application.o

The options -ffunction-sections and -fdata-sections place functions and data into separate sections where supported. They can work with linker garbage collection options such as --gc-sections to discard unused sections.

These compiler options are not universal guarantees of a smaller final binary. Verify the final linked firmware and test the application’s timing, interrupt behavior, and functional correctness.

Optimization can also change debugging behavior and expose code that incorrectly relies on undefined behavior or improperly shared data.

10. Avoid Unnecessary String Usage

String literals can occupy Flash memory, while writable character arrays can consume RAM. String handling can therefore affect both memory budgets.

Consider:

char status_message[] = "System Ready";

This creates a writable character array initialized with the string. The array occupies storage for its characters and terminating null byte.

If the message never needs modification, use:

const char status_message[] = "System Ready";

On many embedded toolchains, the constant array can be stored in Flash, subject to the memory model and linker configuration.

Additional optimization techniques include:

• Avoid duplicating long diagnostic messages.
• Use compact binary representations for internal communication where appropriate.
• Disable verbose debug logs in production builds when they are not needed.
• Avoid formatting large strings when a simpler output method is sufficient.
• Ensure that string buffers are large enough to prevent overflow.

For formatted output, functions such as printf() can pull in substantial library code, depending on the toolchain and enabled features. A smaller logging implementation or a reduced-feature formatting library may lower Flash usage.

Always balance size reduction with maintainability and the diagnostic information required in the field.

11. Use Efficient Lookup Tables and Algorithms

Lookup tables can improve execution speed but may consume significant Flash memory.

For example, a large conversion table might store hundreds or thousands of values. Before including such a table, check whether a formula, smaller table, or interpolation method can provide adequate accuracy.

Consider these trade-offs:

• Large lookup table: Faster lookup in some applications, but more Flash usage.
• Smaller lookup table: Lower memory usage, potentially with interpolation or additional computation.
• Mathematical calculation: May save table storage but require more CPU time or code space.
• Fixed-point arithmetic: May avoid floating-point library overhead on certain targets, but requires careful scaling and range analysis.

Fixed-point arithmetic is not automatically smaller or faster on every microcontroller. Some processors include efficient floating-point hardware, while others do not.

Choose the approach based on accuracy, timing, memory limits, and the hardware’s capabilities.

12. Measure Memory Usage with the Linker Map File

Effective embedded systems memory optimization requires measurement. Source code alone cannot tell you exactly how much RAM or Flash the compiled application consumes.

A linker map file provides information about sections, symbols, addresses, and memory placement.

Common sections include:

The actual placement of sections depends on the linker script and target architecture.

With GNU embedded toolchains, you can inspect the compiled application using commands such as:

arm-none-eabi-size firmware.elf

To generate a linker map file, use an appropriate linker option:

-Wl,-Map=firmware.map

Review the map file to identify the largest arrays, unexpected library dependencies, and sections consuming the most memory.

Remember that a simple size report may not account for the full runtime stack and heap requirements. Estimate and test peak runtime RAM consumption separately.

13. Practical Example: Comparing Memory Usage

Consider a small sensor-monitoring application.

Before optimization

#include 

uint32_t readings[256];
uint32_t threshold = 500;
uint32_t sample_count = 0;

void collect_data(void)
{
    /* Collect sensor readings */
}

The array alone requires:

The three variables together require 1,032 bytes on a target where uint32_t is four bytes, excluding padding, other program variables, stack usage, and runtime overhead.

After optimization

Suppose the application only needs to process 32 samples at a time, and the threshold fits within a 16-bit unsigned integer.

#include 

static uint16_t readings[32];
static const uint16_t threshold = 500;
static uint16_t sample_count = 0;

void collect_data(void)
{
    /* Collect and process samples in smaller batches */
}

The sample array now requires:

The writable counter requires two bytes, and the threshold requires two bytes of logical data storage. If the compiler and linker place the threshold in Flash, it need not consume writable RAM as a runtime variable.

This example demonstrates the potential savings from reducing buffer size, selecting appropriate data types, and using read-only data correctly.

14. Common Memory Optimization Mistakes

While optimizing Embedded C, developers should avoid the following mistakes.

15. A Practical Memory Optimization Checklist

Before deploying embedded firmware, review these points:

• Check the RAM and Flash limits of the target microcontroller.
• Review the linker map file and memory section sizes.
• Choose suitable data types and validate numeric ranges.
• Mark genuinely read-only data as const.
• Reduce oversized arrays and communication buffers where safe.
• Review structure padding and alignment.
• Measure stack usage under worst-case conditions.
• Evaluate dynamic allocation and heap fragmentation risks.
• Remove unused code and unnecessary library features.
• Test compiler optimization settings.
• Run functional, timing, and stress tests after changes.
• Confirm that sufficient memory remains for future features and runtime overhead.

Conclusion

For students learning Embedded C, practicing these techniques on STM32, ARM Cortex-M, or other microcontroller platforms builds a strong foundation for firmware development, debugging, and embedded software engineering.