C语言基于函数指针可变参数的远程MCU单元测试方案可行性问询

核心结论 #

这个方案思路在特定约束下有落地先例，但存在多处原理性设计硬伤，不做修改的话根本做不到“一次编写适配所有测试场景”的设计目标，甚至大概率连稳定跑通都难。

现有思路可跑通的边界 #

如果你的测试目标全是参数个数不超过4个、全是32位整型值传递、无副作用、返回值也是32位整型的纯函数，同时MCU架构是ARM Cortex-M、固件固定链接地址不开位置无关编译、不开最高等级优化，那你举的两数求和demo是可以跑通的，不少嵌入式产线的简易功能测试也用过类似的极简实现。

无法绕开的原理性缺陷 #

• 最核心的硬伤：C语言不存在运行时通用的任意参数函数调用能力。你想靠可变参数机制适配任意被测函数是完全不成立的——C语言的函数传参规则是编译阶段就根据函数签名固定死的：不同架构的参数传递寄存器、栈对齐规则、浮点参数传递路径完全不同，比如Cortex-M前4个参数走R0-R3寄存器，多出来的参数压栈，float/double可能走FPU专用寄存器；8位AVR、RISC-V的传参逻辑又完全不一样。你在通用的unitTestFcn里写的函数调用代码，编译时就已经固定了传参的汇编逻辑，根本不可能运行时动态根据收到的参数个数、类型把数据塞到正确的寄存器/栈位置，但凡参数个数、类型和编译时假设的不一样，要么参数值传错，要么直接栈溢出跑飞进HardFault。
• 裸函数地址的可靠性完全没有保障。你靠PC端解析链接器拿函数地址的做法，在开了位置无关编译、MPU地址隔离、链接时优化(LTO)、函数内联/重排的场景下完全失效：要么运行时函数实际地址和链接地址不匹配，跳转直接跑飞；要么static函数被优化内联后根本不存在独立的函数地址，连目标都找不到。
• 复杂参数、返回值和副作用场景完全hold不住。嵌入式代码里的函数很少是全int值传递的：有传结构体、联合体的，有传指针指向内存/外设寄存器的，有返回大结构体需要隐式传输出缓冲区地址的，这些场景你的通用调用逻辑根本处理不了——你从串口收个4字节地址当指针传进去，大概率指向非法内存区，一访问就直接死机。更别说操作外设、修改全局状态、开关中断的带副作用函数，你随便在测试任务上下文里调用，直接把整个系统的运行状态打崩，连结果都回传不了。
• 测试结果可信度不足。你把测试逻辑全放PC端，但是函数真实运行的上下文（中断优先级、任务栈大小、外设初始状态、并发竞态条件）根本还原不了：你在测试函数里调用的时候是跑在测试任务的低优先级上下文，和真实业务场景下的运行环境完全不一样，测出来的结果不代表实际运行的表现，也覆盖不到栈溢出、竞态、时序错误这类嵌入式最常见的问题。

可落地的修改方向 #

• 放弃“运行时动态传参调用任意函数”的想法，在固件编译阶段用脚本扫描所有被测函数的签名，自动生成对应的参数解析、调用、返回值打包的桩函数，通用测试逻辑只负责通信和按测试ID分发到对应桩函数，不要碰动态构造调用帧的逻辑。
• 不要直接传裸函数地址，给每个被测函数分配全局唯一的测试ID，固件里维护ID到对应桩函数的固定映射表，避开地址偏移、函数优化带来的地址失效问题。
• 测试模式下配置MPU做内存访问隔离，加上HardFault捕获机制，测试用例跑飞的时候能把错误信息回传给PC，不会整板锁死。

内容的提问来源于stack exchange，提问作者lgz