STM32嵌入式开发中的Flash空间优化实战

1. 项目概述：嵌入式开发中的"肥胖症"难题

在STM32F103这类资源受限的MCU上开发时，我们经常会遇到这样的场景：当功能越加越多，突然某次编译后IDE弹出了"Region 'FLASH' overflowed"的红色警告。这就像给MCU穿了一件越来越小的衣服，直到某天完全穿不下了。我最近接手的一个工业控制器项目就面临这个问题——原本128KB的Flash在添加了日志模块和协议栈后，利用率直接飙到了110%。

传统解决方法往往是粗暴的：换更大Flash的芯片（硬件成本↑）、砍功能（产品竞争力↓）、或者开启-Os优化（可能引入不稳定因素）。但这些都只是治标不治本。真正要解决这个问题，需要像外科手术一样精准地分析固件体积组成，理解编译器和链接器如何生成最终二进制文件。

2. 编译体积优化的底层逻辑

2.1 从源码到二进制的旅程

当我们在CLion或VSCode里点击编译按钮时，其实触发了以下关键流程：

1. 预处理阶段：gcc -E展开所有宏和#include，此时生成的.i文件可能比源码大数倍
2. 编译阶段：gcc -S将预处理后的代码转换为汇编.s文件
3. 汇编阶段：as将汇编代码转为.o目标文件
4. 链接阶段：ld将所有.o和库文件合并成最终.elf

体积膨胀往往发生在最后两个阶段。我曾遇到一个案例：某GPIO驱动模块的.o文件只有2KB，但链接后整个固件因此增加了8KB。这是因为静态库的链接是"全有或全无"的——即使只用了库中的一个函数，链接器也会把整个模块都包含进来。

2.2 ELF文件结构解析

通过arm-none-eabi-size工具查看编译产物时，我们会看到这样的输出：

code复制   text    data     bss     dec     hex filename
  79256    2156    6016   87428   15584 build/firmware.elf

这三大区块的实际含义：

• text段：代码和常量（Flash存储）
• data段：已初始化的全局变量（Flash+RAM各存一份）
• bss段：未初始化的全局变量（仅RAM占用）

在Keil工程中，我们常看到map文件里这样的内存分布：

code复制Execution Region RW_IRAM1 (Base: 0x20000000, Size: 0x00005000)
Execution Region ER_IROM1 (Base: 0x08000000, Size: 0x00020000) 

2.3 链接脚本的魔法

链接器根据.ld脚本决定如何排布这些段。以STM32F103的典型链接脚本为例：

code复制MEMORY
{
  RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 20K
  FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 128K
}

SECTIONS
{
  .isr_vector : { *(.isr_vector) } >FLASH
  .text : { *(.text*) } >FLASH
  .rodata : { *(.rodata*) } >FLASH
  .data : { 
    _sdata = .;
    *(.data*)
    _edata = .;
  } >RAM AT>FLASH
  .bss : {
    _sbss = .;