Keil C51微秒级延时实现：从编译器优化到精准时序控制

1. 项目概述：从汇编到C，追寻微秒级延时的精确实现

在嵌入式开发，尤其是51单片机这类资源受限的平台上，精确的短延时（几十到几百微秒）是一个高频且棘手的需求。驱动单总线器件如DS18B20温度传感器、处理红外遥控信号、或是实现简单的时序通信，都对延时的精度有着近乎苛刻的要求。误差超过十几个微秒，轻则通信失败，重则导致系统逻辑紊乱。早年用汇编语言，我们可以通过精确计算指令周期来“雕刻”时间，比如用DJNZ指令循环，在12MHz晶振下能轻松实现2微秒精度的延时。但如今，C语言因其开发效率高、可读性强已成为主流，随之而来的一个灵魂拷问是：用C语言写延时函数，还能达到汇编级别的精度吗？

很多工程师的第一反应是“不能”，或者认为需要嵌入汇编片段。网上充斥着各种用for循环或while循环实现的延时函数，但很少有人深究其编译后的机器码究竟执行了多久。我最初也抱有同样的怀疑，直到在一次驱动DS18B20的项目中，因延时不准导致数据读取持续失败，才下定决心彻底研究一下Keil C编译器（C51）在这方面的“底细”。经过一系列反汇编分析和对比测试，我发现了一个被多数人忽略的细节：同样是循环，while(i--)和while(--i)在Keil C51下生成的机器码效率天差地别，而后者竟能生成与手写汇编几乎同等高效的代码。这篇文章，就是这次“较真”过程的完整记录和总结，旨在为各位嵌入式同僚提供一个可靠、精确且纯C语言的微秒级延时实现方案，并深入剖析其背后的编译器行为逻辑。

2. 精度需求分析与常见误区

在深入代码之前，我们必须明确微秒级延时应用的典型场景及其精度要求。这并非纸上谈兵，而是决定我们方案选型的根本依据。

2.1 典型应用场景与精度要求

最常见的场景是驱动各类单总线或简单串行协议器件。以DS18B20为例，其读写时序对时间有严格规定。例如，主机发起复位脉冲需拉低总线至少480us，随后释放总线并进入接收模式，DS18B20会在15-60us内回应一个存在脉冲。又比如写时序，写“1”时需要主机拉低总线1-15us后释放，而写“0”则需要拉低至少60us。这些时间窗口，特别是写“1”的短时间窗口，要求延时函数的误差必须控制在十几微秒以内，否则极易导致位读写错误。

另一个场景是软件模拟通信协议，如I2C或SPI。虽然标准模式下速率不高（100kHz I2C的一个位周期为10us），但在高速模式或需要严格占空比的场合（如某些自定义协议），对短延时的精度和稳定性也有要求。此外，在按键消抖、简单的状态机切换或等待外部硬件响应（如ADC转换完成）时，一个稳定可靠的短延时也能让程序逻辑更清晰。

2.2 为何不总是使用定时器？

面对精确延时需求，很多工程师的第一选择是硬件定时器。这固然是最精准、最不占用CPU资源的方法。但在以下情况，硬件定时器可能并非最佳或可行选择：

1. 资源已耗尽：在复杂的应用中，51单片机的两个定时器可能已分别用于串口波特率生成、PWM输出或其他周期性中断任务，没有多余的定时器可供使用。
2. 小题大做与开销：对于一个只需要几十微秒的延时，配置定时器涉及初始化、设置中断、编写中断服务程序、处理全局变量等步骤。其代码复杂度和运行时开销（中断响应、现场保护等）远大于一个简单的延时循环。
3. 动态调整不灵活：虽然定时器可以通过重装初值来改变延时，但对于需要频繁变化、且延时值在编译时或运行时可预测的短延时，用循环实现反而更直观、更轻量。

因此，纯软件循环延时在嵌入式开发中依然是一个不可或缺的底层技能。关键在于，我们能否让C语言写出的循环，像汇编一样可预测、可计算。

2.3 网上常见C延时函数的陷阱

在开始我们的探索之前，先看看网络上流传最广的几种写法及其问题。假设单片机使用12MHz晶振（机器周期为1us）。

陷阱一：简单的for循环

void delay_for(unsigned char i) { for(; i != 0; i--); }

很多新手会这样写。通过Keil C51反汇编查看其生成的代码：

?C0007: MOV A, R7 ; 1周期 JZ ?C0010 ; 2周期（如果i为0则跳转） DEC R7 ; 1周期 SJMP ?C0007 ; 2周期 ?C0010: RET

分析循环体（i不为0时）：MOV A, R7(1周期) +JZ(2周期，条件不成立时) +DEC R7(1周期) +SJMP(2周期) =6个机器周期。这意味着，每循环一次，实际消耗6us（12MHz下）。此外，函数调用LCALL和返回RET各需要2个周期。因此，延时时间T ≈ 2 + 6*i + 2us。精度只有6us，且存在固定的函数调用开销。这对于需要10us、20us精度的场合是完全不可接受的。

陷阱二：使用局部变量做循环

void delay_for_var(unsigned char i) { unsigned char j; for(j = i; j != 0; j--); }

有人以为引入中间变量会让编译器优化出不同代码。但反汇编显示，编译器依然将变量分配给了寄存器（可能是R6或R7），生成的循环结构与陷阱一类似，效率同样低下，并没有任何改善。

陷阱三：使用长整型以求“更长”延时

void delay_long(unsigned long i) { for(; i != 0; i--); }

这是最糟糕的做法。由于51是8位机，对32位unsigned long类型的递减和比较操作，编译器会生成一长串复杂的库函数调用和循环代码（涉及多次内存存取和带借位减法），其执行周期数完全不可预测，且极其冗长。这彻底丧失了精度的可控性，仅适用于对精度毫无要求的秒级延时。

这些常见写法的问题根源在于，开发者默认C语句与机器指令之间存在简单的一对一映射，而忽略了编译器的优化策略和具体实现。Keil C51编译器在生成代码时，有它自己的“想法”。

3. 编译器行为深度解析与关键发现

要写出高效的C延时，必须理解Keil C51编译器如何处理循环和递减操作。我们的目标是引导编译器生成最接近汇编指令DJNZ（减1不为零跳转）的代码，因为这是实现紧凑循环的最优指令。

3.1 从while(i--)到while(--i)的质变

我们尝试将for循环改为while循环，这是第一步优化。

尝试一：后置递减while(i--)

void delay_while_post(unsigned char i) { while(i--); }

反汇编结果令人失望：

?C0004: MOV R6, AR7 ; 1周期：将i的当前值复制到R6 DEC R7 ; 1周期：执行i-- MOV A, R6 ; 1周期：将i的原值（递减前）放入A JNZ ?C0004 ; 2周期：判断原值是否为0

循环体需要5个机器周期。虽然比for循环的6周期少1个，但依然不够理想。编译器生成了额外的MOV指令来保存递减前的值用于条件判断，因为i--表达式的值是i递减之前的值。

尝试二：前置递减while(--i)

void delay_while_pre(unsigned char i) { while(--i); }

这次的反汇编带来了惊喜：

?C0004: DJNZ R7, ?C0004 ; 2周期

奇迹发生了！编译器识别出了这种“先减1，再判断结果是否为0”的模式，并完美地将其优化为一条DJNZ指令！这正是我们梦寐以求的、与手写汇编效率相当的代码。

3.2 核心原理：表达式求值顺序与编译器优化

为什么while(--i)能生成DJNZ，而while(i--)却不能？这涉及到C语言中前置递减与后置递减运算符的本质区别。

• --i（前置递减）：先对i执行减1操作，然后将减1后的新值作为整个表达式的值。
• i--（后置递减）：先将i的当前值作为整个表达式的值，然后再对i执行减1操作。

对于while(--i)，其逻辑是：“先让i减1，然后用这个新值判断是否为真（非零）”。这恰好与DJNZ指令的语义（“减1，结果不为零则跳转”）完全吻合。Keil C51的优化器能够识别这种特定的模式，并将其映射到最合适的单一指令上。

而对于while(i--)，其逻辑是：“先用i的旧值判断，然后再让i减1”。为了在判断后还能执行减1操作，编译器必须生成额外的指令来保存旧值，因此无法优化为DJNZ。

关键心得：在Keil C51环境下，追求极致的循环效率时，务必使用前置递减（--i）。这是引导编译器生成最优机器码的“咒语”。

3.3 精确延时时间的计算模型

现在我们得到了最优的代码结构。让我们建立一个精确的延时计算模型。函数原型为：

void delay_us(unsigned char n);

假设使用12MHz晶振（机器周期=1us），编译器生成的核心代码为DJNZ Rn, loop。

1. 指令周期分析：

   • DJNZ Rn, rel：这条指令本身执行需要2个机器周期。
   • 函数调用：LCALL delay_us需要2个周期。
   • 函数返回：RET需要2个周期。

2. 循环次数与参数n的关系： 在while(--i)中，循环会持续执行，直到i递减为0。当传入参数n时：

   • 如果n = 1：--i使i变为0，循环条件while(0)为假，因此循环体（DJNZ）一次都不会执行。
   • 如果n = 2：第一次--i后i=1，执行一次DJNZ；第二次--i后i=0，循环结束。共执行1次循环。
   • 以此类推，循环次数 = n - 1。

3. 总延时时间公式：总时间(us) = 调用开销(2) + 循环时间 + 返回开销(2)循环时间 = (n - 1) * 2（因为每次DJNZ耗时2周期） 所以，总时间 T = 2 + 2*(n - 1) + 2 = 2n + 2(us)。

   我们来验证一下：

   • 当n = 1：T = 2*1 + 2 = 4us（仅调用和返回，无循环）
   • 当n = 5：T = 2*5 + 2 = 12us
   • 当n = 100：T = 2*100 + 2 = 202us

4. 制作延时参数查询表： 为了方便使用，我们可以预先计算常用延时值对应的n值。公式逆推：n = (所需延时T - 2) / 2。

   所需延时 T (us)	计算参数 n = (T-2)/2	实际取整 n	实际产生延时 (us)	误差 (us)
   10	(10-2)/2 = 4	4	2*4+2=10	0
   20	(20-2)/2 = 9	9	2*9+2=20	0
   50	(50-2)/2 = 24	24	2*24+2=50	0
   100	(100-2)/2 = 49	49	2*49+2=100	0
   15	(15-2)/2 = 6.5	6 或 7	14 或 16	-1 或 +1

   可以看到，对于大多数(T-2)为偶数的延时，我们可以实现零误差。对于奇数微秒的延时，误差最大为±1us，这在绝大多数应用中是可接受的。如果需要精确的奇数微秒延时，可以额外插入一个NOP指令。

注意事项：这个计算模型基于两个重要前提：第一，编译器必须如我们所愿生成DJNZ指令；第二，必须关闭编译器的“循环优化”等可能干扰指令周期数的选项。在Keil中，确保优化级别不是“9: Common block subroutines”这类激进优化，通常选择“8: Reuse Common Entry Code”或更低级别，可以保证代码的确定性。

4. 可复用的精确延时函数库实现

基于以上研究，我们可以构建一个稳健、易用的微秒级延时函数库。这里不仅提供核心函数，还会考虑更多实际工程因素。

4.1 基础函数与宏定义

首先，定义一个基础函数，并利用宏来简化常用延时值的调用。

/** * @brief 基于DJNZ指令的精确微秒延时（12MHz晶振） * @param us: 需要延时的微秒数，理论范围 4 ~ 512 us。 * @note 对于12MHz晶振，最小延时为4us（n=1），最大延时受限于unsigned char的范围。 * 计算公式：实际延时 = 2 * us + 2 (us)。 * 传入的us参数应为 (目标延时 - 2) / 2 的计算结果。 * 例如：要延时10us，应传入 (10-2)/2 = 4。 */ void delay_us_basic(unsigned char us) { while(--us); // 核心语句，必须为前置递减 } /* 常用延时宏定义，方便直接调用 */ #define DELAY_10US() delay_us_basic(4) // (10-2)/2 = 4 #define DELAY_20US() delay_us_basic(9) // (20-2)/2 = 9 #define DELAY_50US() delay_us_basic(24) // (50-2)/2 = 24 #define DELAY_100US() delay_us_basic(49) // (100-2)/2 = 49 #define DELAY_200US() delay_us_basic(99) // (200-2)/2 = 99 #define DELAY_500US() delay_us_basic(249) // (500-2)/2 = 249 /* 示例：在代码中直接使用 */ void ds18b20_init_pulse(void) { DQ = 0; // 拉低总线产生复位脉冲 DELAY_480US(); // 延时480us，需要提前定义 DELAY_480US() 为 delay_us_basic(239) DQ = 1; // 释放总线 delay_us_basic(30); // 等待30us，参数为 (30-2)/2 = 14 }

4.2 适配不同晶振频率

上述函数和宏是基于12MHz晶振的。如果项目中使用的是11.0592MHz（常用于产生标准串口波特率）或其他频率的晶振，机器周期会发生变化，计算公式需要调整。

机器周期计算公式：对于标准51架构，机器周期 = 12 / 晶振频率。

• 12MHz：机器周期 = 12 / 12 = 1us
• 11.0592MHz：机器周期 ≈ 12 / 11.0592 ≈ 1.085us
• 24MHz：机器周期 = 12 / 24 = 0.5us

我们需要一个更通用的函数，通过宏来定义系统时钟。

/* 在项目全局配置头文件中定义 */ #define FOSC 12000000UL // 系统晶振频率，单位Hz #define MACHINE_CYCLE (12.0 / FOSC * 1000000.0) // 计算单个机器周期的微秒数 /** * @brief 通用微秒延时函数 * @param t_us: 需要延时的微秒数 * @note 此函数通过计算得到所需的循环次数，适用于不同晶振。 * 由于存在浮点计算和循环开销，精度略低于直接查表法，但通用性强。 * 注意：t_us 不宜过小，否则计算误差占比大。 */ void delay_us(unsigned int t_us) { /* 计算所需的总机器周期数（减去函数调用和返回的固定开销） */ /* 假设调用和返回共需约4个周期（根据实际反汇编调整） */ unsigned int total_cycles; unsigned int i; // 将微秒时间转换为机器周期数 total_cycles = (unsigned int)(t_us / MACHINE_CYCLE); // 减去固定的函数调用、返回和循环控制开销（此值需通过实测校准） // 对于 while(--i) 结构，每次循环2周期，外加一些固定开销。 // 简化处理：假设总周期数 = 2 * i + K。通过实测一点来推算K。 // 更实用的方法是：针对特定频率，通过示波器或逻辑分析仪校准一个参数。 if (total_cycles > 4) { // 确保总周期数大于基础开销 i = (total_cycles - 4) / 2; // 估算循环次数，4是估算的固定开销周期 while(--i); } }

重要提示：通用计算法会引入浮点运算和除法，在51上开销大且不精确。对于高精度要求，强烈推荐针对固定晶振频率，使用前述的查表法或宏定义法。通用函数更适合对精度要求不苛刻或频率可能变化的场景。

4.3 更长延时的实现：嵌套循环与组合

单个unsigned char参数最大为255，代入公式T=2n+2，最大延时约为512us。如果需要ms级别的延时，有几种方法：

方法一：多层嵌套循环

void delay_ms(unsigned char ms) { unsigned char i, j; // 注意：此处的内层循环参数需要根据实际时钟校准 // 以下是一个近似1ms延时的示例框架，参数需要实测调整 while(ms--) { i = 250; while(--i) { // 约 2*250+2 = 502us j = 4; while(--j); // 约 2*4+2 = 10us，用于微调 } // 总共约 502us * 2 ≈ 1004us = 1.004ms } }

多层嵌套的缺点是计算和校准复杂，且容易受编译器优化影响。

方法二：基于微秒延时函数循环这是更推荐的做法，结构清晰，易于维护和校准。

void delay_ms_simple(unsigned int ms) { while(ms--) { delay_us_basic(249); // 延时500us delay_us_basic(249); // 再延时500us，合计约1ms } }

你需要先用示波器精确校准delay_us_basic(249)产生的实际时间，然后组合成1ms。也可以直接写一个delay_1ms()的宏或函数。

方法三：与定时器中断结合（推荐用于长延时）对于几毫秒以上的延时，最可靠、最不占用CPU的方式仍然是使用定时器中断。可以设置一个1ms的定时器中断，在中断服务程序中递增一个全局变量volatile unsigned int sys_tick。然后实现一个阻塞式延时函数：

volatile unsigned int sys_tick_ms = 0; void timer0_isr(void) interrupt 1 { TH0 = 0xFC; // 重装初值，实现1ms中断（12MHz） TL0 = 0x66; sys_tick_ms++; } void delay_ms_blocking(unsigned int ms) { unsigned int start_tick = sys_tick_ms; while ((sys_tick_ms - start_tick) < ms) { // 空循环，等待时间到达。可以在此处加入低功耗指令（如_nop_()） } }

这种方法将短延时（us级）交给精确的软件循环，长延时（ms级）交给定时器，是资源利用和精度兼顾的最佳实践。

5. 实战校准、验证与高级技巧

理论计算和编译器行为分析是基础，但嵌入式开发离不开实测。再精确的模型，也需要用仪器来验证和校准。

5.1 使用IO口和示波器进行校准

这是最直接、最可靠的校准方法。

1. 编写测试代码：

   sbit TEST_PIN = P1^0; void main(void) { while(1) { TEST_PIN = 1; DELAY_10US(); // 或 delay_us_basic(4); TEST_PIN = 0; DELAY_10US(); } }

2. 连接示波器：将示波器探头连接到P1.0引脚。
3. 测量与调整：观察产生的方波周期。理论上，一个高电平加一个低电平的时间应为20us。如果示波器显示为20.4us，说明我们的延时函数实际慢了0.4us。这可能是因为我们之前假设的函数调用开销（2+2=4周期）不准确，或者编译器在函数入口/出口处生成了额外的指令。
4. 计算补偿值：假设目标延时为T，实测延时为T_measured，根据公式T = 2n + C（C为实际固定开销），我们可以代入两组数据解出C。例如，n=4时目标10us，实测10.2us；n=9时目标20us，实测20.4us。解方程可得C约为2.4us（即约2.4个周期）。然后我们修正公式：n = (T - C) / 2。在实际编程中，可以将这个微小的补偿值考虑到宏定义的参数里。

5.2 逻辑分析仪验证时序

对于驱动DS18B20这类复杂时序，逻辑分析仪比示波器更直观。可以抓取完整的复位、存在脉冲、读写位时序，与DS18B20数据手册中的时间参数进行对比，确保每个时间窗口（如写1的拉低时间、读数据的采样时间点）都满足要求。如果发现某个阶段时间超限，就针对性地调整该处的延时函数参数。

5.3 编译器优化等级的影响

Keil C51提供了多个优化等级（0-9）。高级别优化（如9级）可能会进行“循环展开”、“函数内联”等激进优化，这会彻底破坏我们精心设计的指令周期计算。对于这种对时序有严格要求的底层延时函数，建议将其放在独立的.c文件中，并针对该文件使用较低的优化等级（如0级或1级）。在Keil中，可以在项目窗口右键点击该源文件，选择“Options for File...”，在“C51”标签页下单独设置优化级别。

5.4 中断对延时的影响及应对策略

这是一个至关重要但常被忽略的问题。当延时函数正在执行循环时，如果发生中断，CPU会转去执行中断服务程序，这段时间对于延时函数来说是“丢失”的，会导致实际延时时间变长。

应对策略：

1. 关闭中断：在调用高精度延时函数前关闭全局中断，延时结束后再打开。这是最简单粗暴的方法，但会影响系统的实时性。

   void delay_us_precise(unsigned char n) { EA = 0; // 关闭总中断 while(--n); EA = 1; // 打开总中断 }

   注意：这种方法只适用于极短时间的延时（几个微秒到几十微秒），且要确保关闭中断不会导致其他严重问题（如丢失串口数据）。

2. 规避与补偿：对于无法关闭中断的场合，需要评估系统中最坏情况下的中断响应时间。如果最长中断服务程序执行时间为Xus，那么你的延时函数在最坏情况下会额外增加Xus。在设计时序容限时，需要将这个因素考虑进去。例如，DS18B20要求主机拉低总线至少480us，那么你的延时参数应该保证即使在最坏中断干扰下，拉低时间也不会少于480us。

3. 使用硬件定时器：这再次印证了，对于时间敏感且可能被中断打扰的关键长延时，硬件定时器（即使工作在查询模式而非中断模式）是更可靠的选择。

5.5 编写可移植且安全的延时模块

综合以上所有要点，一个健壮的延时模块头文件可能如下所示：

// delay.h #ifndef __DELAY_H__ #define __DELAY_H__ // 系统时钟定义，必须在用户配置中修改 #ifndef FOSC #warning "FOSC not defined, default to 12MHz" #define FOSC 12000000UL #endif // 基础微秒延时函数声明 void delay_us_basic(unsigned char us); // 经过校准的常用延时宏（12MHz示例） #if (FOSC == 12000000UL) #define DELAY_5US() do { /* 插入_NOP_()或特定代码 */ } while(0) #define DELAY_10US() delay_us_basic(4) #define DELAY_20US() delay_us_basic(9) #define DELAY_50US() delay_us_basic(24) #define DELAY_100US() delay_us_basic(49) #define DELAY_200US() delay_us_basic(99) #define DELAY_500US() delay_us_basic(249) #define DELAY_1MS() delay_ms_blocking(1) #elif (FOSC == 11059200UL) // 针对11.0592MHz的校准值 #define DELAY_10US() delay_us_basic(5) // 需要重新校准 // ... #else #error "Please calibrate delay macros for your crystal frequency!" #endif // 毫秒级延时函数声明（基于系统滴答或软件循环） void delay_ms(unsigned int ms); #endif

在对应的delay.c文件中，使用#pragma指令限制该文件的优化级别，并实现函数。

6. 常见问题排查与经验实录

在实际项目中应用这些延时技巧时，我踩过不少坑。这里把典型问题和解决方案记录下来，希望能帮你节省时间。

问题一：延时函数在不同优化等级下时间差异巨大。

• 现象：代码在调试阶段（优化等级低）工作正常，一旦发布（优化等级提高），时序就全乱了。
• 原因：高级别优化可能将小函数内联、移除未使用的变量、改变循环结构，彻底打破了我们依赖的指令周期模型。
• 解决：
  1. 如前所述，将延时函数单独放在一个源文件，并固定其优化等级（如#pragma OPTIMIZE(0)）。
  2. 将延时函数声明为static，防止编译器跨文件优化时做出意外决策。
  3. 使用volatile关键字修饰循环变量（如volatile unsigned char i），强制编译器每次从内存读取变量值，阻止某些优化。但注意，这可能会降低效率。

问题二：使用while(--i)实现的延时，当i初始值为0时行为异常。

• 现象：传入参数0，期望不延时，但可能产生一个很长的延时（因为unsigned char递减到0再减1会变成255）。
• 分析：while(--i)中，如果i是unsigned char且初始为0，--i的结果是255，循环会执行255次，导致一个长达数百微秒的意外延时。
• 解决：在函数入口处增加判断。如果期望i=0时无延时，可以这样写：

  void delay_us_safe(unsigned char n) { if (n == 0) return; n = n * 2; // 假设我们期望的n是计算好的参数，这里需要转换 while(--n); }

  或者，在调用层面保证不传入0值。务必在数据手册或函数注释中明确说明输入参数的有效范围。

问题三：在高速单片机（如1T的51内核单片机）上，同样的代码延时时间极短。

• 现象：代码从标准12T的51单片机移植到1T的STC15系列后，所有延时都缩短为原来的1/12左右。
• 原因：1T单片机每个机器周期只需要1个时钟周期，而标准51需要12个。指令执行速度大大加快。
• 解决：重新校准所有延时参数。核心公式中的机器周期需要重新计算。对于1T单片机，DJNZ指令可能只需要2个时钟周期（而不是2个机器周期）。需要查阅具体芯片的数据手册，并重新用示波器测量校准。

问题四：延时函数被意外内联到不同的调用上下文，导致时间不准。

• 现象：同一个delay_us_basic(10)，在函数A中调用和函数B中调用，产生的延时略有不同。
• 原因：如果延时函数是简单的static inline函数，或者编译器开启了内联优化，函数体可能会被直接插入到调用处。如果调用处的寄存器使用情况不同，可能会影响编译器为循环变量分配的寄存器，从而轻微影响代码生成（虽然概率较小，但确实存在）。
• 解决：对于要求极高的场景，可以将延时函数定义为noinline（如果编译器支持），或者将其放在单独的、不会被内联的编译单元中。更稳妥的方法是，在最终产品中，用示波器在真实的调用环境下进行最终验证。

最后一条，也是最重要的经验：永远不要完全相信计算和软件模拟。对于嵌入式系统中的时序问题，示波器、逻辑分析仪和硬件仿真器才是你最可靠的朋友。在代码编写、模型计算之后，一定要在真实硬件上，在真实的系统环境（中断开启、外设工作）下，进行最终的测试和校准。把关键时序节点的理论值、实测值记录下来，形成你自己的“延时校准表”，这将成为你项目中最宝贵的财富之一。