嵌入式C代码优化：工业控制场景下函数重入性与栈溢出防护

工业控制器（PLC、运动控制、RTU）的软件通常在裸机中断+主循环或RTOS多任务环境下运行。两个隐蔽的致命陷阱是函数重入和栈溢出——前者导致全局变量被破坏，后者让系统静默死机。本文分享实用的编码防护技巧。

一、函数重入性：中断与多任务的雷区

可重入函数是指能被多个任务或中断同时调用而不破坏数据的函数。不可重入的典型特征是使用了全局或静态变量。例如一个简单的计数器：

// 不可重入版本

static int counter = 0;

void inc_counter(void) {

   counter++;  // 中断来了再次调用，counter值错乱

}

如果主循环调用inc_counter()时，中断服务程序也调用了它，counter的读取-修改-写入三步可能被中断打断，导致更新丢失。工业控制中，这种问题会导致脉冲计数错误、PWM占空比突变。

改造为可重入的方法：去掉静态变量，改用参数传递，或者用局部变量+返回值：

// 可重入版本

int inc_counter(int *counter) {

   (*counter)++;

   return *counter;

}

如果必须使用全局资源，则需要加互斥保护（关中断或信号量）。在RTOS中，可以使用互斥锁，但中断中只能用关中断的方式：

// 临界区保护（裸机中断场景）

volatile int shared_data;

void safe_update(void) {

   __disable_irq();

   shared_data++;

   __enable_irq();

}

注意：标准库中的许多函数（如strtok、rand）是不可重入的，在中断或多任务中应使用它们的可重入版本（如strtok_r、rand_r）。

二、栈溢出防护：看不见的内存杀手

栈空间在MCU中通常只有几KB到几十KB。深层函数调用、递归、大局部数组都可能导致栈溢出，覆写相邻的全局变量或堆区，造成随机死机。检测方法主要有两种：

1. 栈填充模式（Watermark）

在系统初始化时将栈区域全部填充为特定模式（如0xDEADBEEF），定期检查边界是否被改写。

// 栈填充与检查（适用于裸机）

#define STACK_SIZE 2048

uint32_t stack_area[STACK_SIZE / 4];

void stack_init(void) {

   for (int i = 0; i < STACK_SIZE / 4; i++)

       stack_area[i] = 0xDEADBEEF;

}

void stack_check(void) {

   int i;

   for (i = 0; i < 32; i++) {  // 检查栈顶32个字

       if (stack_area[i] != 0xDEADBEEF) {

           // 栈溢出！记录错误或复位

           system_error_handler();

       }

   }

}

在主循环或空闲任务中周期性调用stack_check()，可及时发现溢出。

2. 编译器栈保护选项

GCC提供了-fstack-protector和-fstack-protector-strong，会在函数入口和出口插入栈金丝雀（canary）检测。在CMake或Makefile中添加：

CFLAGS += -fstack-protector-strong -Wstack-usage=256

-Wstack-usage=256会警告每个函数栈使用超过256字节的情况，帮助开发者优化局部变量。

3. 静态分析栈需求

使用avr-size、arm-none-eabi-objdump或IDE的栈分析工具，查看每个函数的栈帧大小。对于递归函数，必须限制递归深度或改用迭代。工业控制中应尽量避免递归。

三、实战建议

编码规范：中断服务程序只调用可重入函数；全局变量加volatile并保护；避免大局部数组（改用动态分配或静态缓冲区池）。

工具链：开启-fstack-protector-strong和-Wstack-usage；使用静态分析工具（如PC-Lint、Coverity）检测不可重入函数。

测试：压力测试时故意制造最深调用路径，观察栈水位。

函数重入和栈溢出是嵌入式软件“慢性病”，靠后期调试很难复现。从编码阶段养成可重入意识和栈防护习惯，配合编译器检查和运行时监测，才能让工业控制软件在恶劣环境中稳定运行。