Optimizing Memory Footprint in Ultra-Low Resource Embedded Systems

General
1

Hello

I am currently working on a project for an ultra-constrained embedded system & I’m encountering challenges with optimizing the memory footprint. :innocent:

Despite careful planning; the limited RAM and flash memory available often force me to make tough decisions on resource allocation. I am interested in learning how others have tackled similar constraints and what strategies have proven most effective. :thinking:

The main issue lies in balancing dynamic memory allocation with deterministic behavior, especially in real-time applications. :thinking: Traditional allocation techniques sometimes introduce unpredictable latency or fragmentation issues that can compromise system reliability.

I’m curious about innovative practices, such as static allocation patterns, memory pooling / custom allocators; that help maintain both efficiency and real-time performance in these environments. :thinking: Checked Understanding Memory Management in Embedded Systems Microsoft SQL Server Training guide related to this and found it quite informative.

I’m reaching out to the community to share insights, best practices, and practical experiences regarding memory optimization in such systems. If anyone has encountered and overcome similar challenges, your detailed examples would be greatly appreciated.

Thank you!! :slightly_smiling_face:

2

Hi @derektheler ! Personally I’ve found these strategies to pay off the most, in order of biggest payoff to least:

  1. Make sure you have high quality visibility into your application’s memory usage: tools like puncover, zephyr’s memory reporting tools (if on zephyr), using binutils size/nm and other static analysis tools; instrumenting heap and statck utilization (minimum free space, max free block, etc). For example, usage can accidentally sneak in if you happen to use double computation. Using these tools will help you eliminate waste quickly.
  2. Be sure you’ve exhausted all the available memory on your device- often there are spare bytes here and there, in backup memories, USB peripheral controllers, EEPROM banks, etc.
  3. Consider carefully the purpose of your device- are there features that can be eliminated or simplified? if it’s a connected device, can you offload functionality to a server? Do you have a secondary bootloader when you could instead use the built-in ROM bootloader, and regain the flash space? Can you use compression (or trade off accuracy) to reduce runtime memory consumption when processing data?
  4. Sometimes the last resort, but should always be seriously considered- can you upgrade your hardware to save development time? often it’s far cheaper to switch to a larger capacity device instead of burning weeks trying to fit into the smaller part.

Finally, have you considered eliminating the operating system entirely? there are trade offs, but on some very constrained systems, having dedicated stacks for multiple tasks is not possible. You might consider modern cooperative schedulers like:

And the classic:

This is likely a drastic change to make, though!

Good luck!