一句话: 用 GPIO 软件模拟 SPI 时序，加一个无关函数进去，延时就变了。同样一段 C 代码，编译器优化等级没改，只是同一个 .c 文件里多了个函数，bit-bang 的 SCK 脉宽就不准了。解决方法是把时序敏感的 bit-bang 代码拆到独立编译单元。

适合谁读：写 bit-bang 时序代码，时序不稳定、加一行代码就变一次的嵌入式开发者。

现象

用四个 GPIO 模拟 SPI 读 ADC：

void BB_Delay(void) { for(volatile int i=0; i<10; i++); } uint16_t Read_Channel(uint8_t cfg) { CNV_LOW(); BB_Delay(); for(int i=15; i>=0; i--) { SCK_HIGH(); // 发 SCK MOSI_SET((cfg >> i) & 1); // 发数据 BB_Delay(); SCK_LOW(); BB_Delay(); } // 读 MISO ... CNV_HIGH(); }

时序调好了，示波器量 SCK 脉宽稳定。然后在这个 .c 文件里加一个无关函数——不调用它，只是加进来——重新编译。SCK 脉宽变了。

改一句代码 → 重测一遍时序。永远调不稳。

为什么

编译器优化是全文件级别的。同一个编译单元（.c 文件）里函数多了、变量多了、调用关系变了，编译器给每个函数分配的寄存器、栈布局、指令顺序都可能不一样。

bit-bang 依靠for(volatile int i=0; i<N; i++)做延时。volatile保证循环不会被优化掉，但它不保证循环迭代之间指令周期数固定。函数被其他代码"包围"的方式变了——函数入口/出口的寄存器保存恢复变了——整个时序就偏移了。

解决：拆独立编译单元

把 bit-bang 四个函数单独放一个 .c 文件：

Drv_AD7689.c ← 只有 bit-bang 四个函数，不依赖其他模块 Drv_SPI.C ← 硬件 SPI 和其他驱动

Drv_AD7689.c内容极其纯粹——没有外部依赖，没有任何其他模块的数据结构。编译器看到的是一个小而干净的编译单元，优化结果稳定。

不管Drv_SPI.C里加了什么函数、改了什么逻辑，Drv_AD7689.c的编译结果完全不受影响。时序调好一次就永久稳定。

什么该拆

不只是 bit-bang。以下情况值得拆独立编译单元：

编译单元是最强的隔离边界——比#pragma和volatile都可靠。函数放在同一个文件里，编译器就有权在它们之间做任何优化。拆到不同文件，编译器管不到。

经验

bit-bang 不是一个延时循环的问题，是一个时序工程。时序稳定性取决于三个变量——编译器版本、优化等级、编译单元边界。前两个很难控制（换 IDE 版本就变了），第三个是你能百分之百控制的。

写 bit-bang 的第一条规则：放到独立 .c 文件。少一个函数也不行，多一个函数就多了变数。

有用的话点个收藏，下次调试直接用。有问题欢迎评论区交流，看到了都会回。