嵌入式C优化：资源受限环境下的优化策略、ROM/RAM权衡

做嵌入式开发的朋友都知道，资源受限这四个字意味着什么。说白了，就是你的芯片就那么点ROM和RAM，代码要跑得稳，还得跑得快。我这些年经手的项目，从8位MCU到ARM Cortex-M系列，几乎每天都在跟这两个资源较劲。

今天咱们聊聊嵌入式C优化的核心——ROM和RAM的权衡。这不是什么高深理论，而是实打实的生存技能。

一、ROM与RAM：一对天生的冤家

ROM（Flash）存代码和常量，RAM存变量和堆栈。你想想看，ROM大了代码能塞更多功能，RAM大了能处理更复杂的数据。但芯片就这么大，你得做取舍。

我个人习惯，拿到一个新项目，先看三样东西：Flash容量、RAM容量、CPU主频。这三样决定了你的优化策略往哪个方向走。

资源类型	典型容量范围	主要用途	优化方向
ROM (Flash)	4KB ~ 2MB	代码、常量、查表数据	代码压缩、查表替代计算
RAM	256B ~ 512KB	变量、堆栈、缓冲区	变量复用、静态分配

二、用ROM换RAM：查表法的妙用

我在项目中遇到过这样一个场景：一个温度传感器需要做非线性校正，计算量很大。如果用实时计算，得占用不少RAM来存中间变量，而且CPU还得忙活半天。

后来怎么解决的？查表法。

// 方案A：实时计算（RAM消耗大）
float temperature_correction(float raw_value) {
    // 复杂的多项式计算
    float a = 0.0012f;
    float b = -0.0345f;
    float c = 1.234f;
    float d = -5.678f;
    return a * raw_value * raw_value * raw_value +
           b * raw_value * raw_value +
           c * raw_value + d;
}

// 方案B：查表法（ROM换RAM）
// 预计算好的校正表，存在ROM里
const float correction_table[256] = {
    -5.678f, -5.643f, -5.608f, /* ... 256个预计算值 */
};

float temperature_correction_fast(uint8_t raw_value) {
    return correction_table[raw_value];  // 一次查表搞定
}

你看，方案B把计算量从几十条指令降到了1条查表指令。代价是什么？ROM多了1KB的表（256个float，每个4字节）。但RAM几乎没增加。对于大多数嵌入式芯片来说，这笔买卖太划算了。

三、用RAM换ROM：代码复用的艺术

反过来，有时候RAM比较充裕，ROM却快塞满了。这时候就得想办法压缩代码体积。

我记得有个项目，Flash只剩2KB了，但还得加一个新功能。怎么办？把几个相似的函数合并成一个。

// 优化前：三个独立函数，代码重复
void set_led_red() {
    GPIOA->ODR |= (1 << 0);  // 红灯亮
    GPIOA->ODR &= ~(1 << 1); // 绿灯灭
    GPIOA->ODR &= ~(1 << 2); // 蓝灯灭
}

void set_led_green() {
    GPIOA->ODR &= ~(1 << 0);
    GPIOA->ODR |= (1 << 1);
    GPIOA->ODR &= ~(1 << 2);
}

void set_led_blue() {
    GPIOA->ODR &= ~(1 << 0);
    GPIOA->ODR &= ~(1 << 1);
    GPIOA->ODR |= (1 << 2);
}

// 优化后：一个函数搞定，用参数控制
void set_led_color(uint8_t color) {
    // 先全部熄灭
    GPIOA->ODR &= ~(0x07 << 0);
    // 再点亮目标颜色
    GPIOA->ODR |= (color & 0x07) << 0;
}

三个函数变成了一个，代码量减少了60%左右。代价是什么？每次调用多了一个参数传递，RAM里多了一个临时变量。但这点RAM开销，跟省下来的ROM比，不值一提。

四、常量与变量的抉择

这是嵌入式C里最常见的陷阱之一。很多人写代码，习惯把常量定义成变量，结果RAM白白浪费了。

// 错误示范：常量占用了RAM
int buffer_size = 256;  // 这个值不会变，却占了4字节RAM

// 正确做法：用宏或const
#define BUFFER_SIZE 256  // 编译期替换，不占RAM
// 或者
const int buffer_size = 256;  // 编译器可能优化到ROM里

你想想看，一个项目里这种"假变量"可能有几十上百个。每个省4字节，加起来就是几百字节的RAM。对于只有1KB RAM的芯片来说，这就是救命的空间。

五、结构体布局：别小看对齐

结构体的成员顺序，直接影响RAM占用。我见过太多人随便写结构体，结果编译器为了对齐，白白浪费了空间。

// 糟糕的布局：浪费了6字节
struct sensor_data {
    uint8_t  id;       // 1字节
    uint32_t value;    // 4字节，需要4字节对齐
    uint8_t  status;   // 1字节
};
// 实际占用：1 + 3(填充) + 4 + 1 + 3(填充) = 12字节

// 优化的布局：按大小排序
struct sensor_data_optimized {
    uint32_t value;    // 4字节
    uint8_t  id;       // 1字节
    uint8_t  status;   // 1字节
};
// 实际占用：4 + 1 + 1 + 2(填充) = 8字节

省了4字节，比例33%。如果结构体数组有100个元素，那就是400字节的差距。我曾经在一个数据采集项目里，靠调整结构体布局，硬生生省出了2KB的RAM。

六、堆栈优化：小心隐形杀手

堆栈溢出是嵌入式开发里最头疼的问题之一。它不像数组越界那样容易定位，往往是跑着跑着就莫名其妙复位了。

我建议的做法：

• 减少函数嵌套深度：每层函数调用至少消耗几十字节的堆栈
• 避免大局部变量：比如不要在函数里定义512字节的数组，用静态或全局替代
• 中断服务程序要精简：中断里调用的函数越少越好

// 危险：中断里用大数组
void TIM2_IRQHandler(void) {
    uint8_t temp_buffer[512];  // 这512字节从堆栈里分配
    // 如果主程序堆栈已经用了不少，这里很可能溢出
    process_data(temp_buffer);
}

// 安全：用静态缓冲区
static uint8_t temp_buffer[512];  // 在RAM的BSS段分配
void TIM2_IRQHandler(void) {
    process_data(temp_buffer);  // 不消耗堆栈空间
}

七、知识体系总览

下面这张图，是我这些年做嵌入式优化总结出来的核心思路。你可以把它当作一个检查清单，每次做优化时对照着看。

八、写在最后

嵌入式C优化，说白了就是一场资源博弈。ROM多了用ROM，RAM多了用RAM。没有银弹，只有权衡。

我个人的经验是：先测量，再优化。别凭感觉猜哪里是瓶颈，用工具看看ROM和RAM的实际使用情况。很多IDE都自带这个功能，比如IAR的map文件、Keil的编译报告。

最后送大家一句话：优化不是炫技，而是让代码在有限的资源里，跑出最好的效果。