当前位置：首页 > news >正文

单片机中断实验一键复现包：Keil C51源码+Proteus仿真图+完整实验报告

news 2026/6/9 11:22:09

本文还有配套的精品资源，点击获取

简介：直接导入Keil uVision就能编译运行的51单片机中断实验工程，含核心中断处理代码zhongduan.c，编译生成zhongduan.hex可执行文件；配套Proteus仿真电路图（仿真图.DSN）和运行状态快照（仿真图.DBK），可实时观察外部中断触发、现场保护、服务程序执行与返回全过程；工程包含标准启动文件STARTUP.A51、项目配置zhongduan.uvproj、各类编译中间文件（.OBJ/.LST/.M51）及调试日志zhongduan.plg；附带规范实验报告（实验四.docx），涵盖实验目的、中断原理说明、接线与按键操作步骤、LED响应现象记录、时序分析及思考题参考答案；所有文件按标准Keil+Proteus协作流程组织，无需修改路径或重配环境，打开即仿、编译即跑。

1. 项目概述：为什么这个中断实验包值得你花十分钟打开它

如果你正在上《计算机组成原理》或者《单片机原理与接口技术》这类课，大概率已经经历过这样的场景：老师讲完中断向量表、IE寄存器、TCON寄存器、堆栈自动压入/弹出这些概念，你点头说“懂了”，结果回到宿舍打开Keil，新建工程、配置晶振、选芯片型号、写个INT0中断服务函数——编译没报错，烧进仿真器却毫无反应；改了三次EX0=1，又查了五遍IT0=1，LED还是不闪；最后发现是启动文件里没关看门狗，或者Proteus里按键接地方式错了，又或者根本没把P3.2引脚连到按钮上……这种“理论全对、实操全崩”的挫败感，我带过七届学生实训，几乎人人都踩过。

这个“单片机中断实验一键复现包”，不是网上那种只丢一个.c文件加一句“自己配环境”的半成品，而是一套经过三轮真实课堂验证、四次Proteus版本兼容性测试、六次Keil uVision不同小版本（v4.74 ~ v5.38）交叉编译确认的闭环工程。它包含的不只是代码和图，而是把“中断响应全过程”拆解成可观察、可测量、可回溯的五个物理阶段：按键按下→电平变化→硬件采样→CPU暂停主程序→跳转ISR→执行现场保护→运行用户代码→恢复现场→返回断点。每一个环节，在Keil里能看到汇编级堆栈操作，在Proteus里能用逻辑分析仪测出INT0引脚下降沿与LED点亮之间的精确延时（实测为3.2μs），在.LST文件里能逐行对照C语句与生成的MOV SP, #07H、PUSH ACC这类指令——这才是组成原理该有的“看得见摸得着”的教学载体。

关键词里的“51单片机”不是泛指，它特指标准8051内核、12T模式、11.0592MHz晶振下的行为；“中断实验”聚焦外部中断0（INT0/P3.2）的边沿触发机制，不掺杂定时器中断或串口中断干扰主线；“Keil C51”强调使用的是经典C51编译器而非ARM版uVision；“Proteus仿真”采用的是ISIS 8.13及以上版本兼容电路，所有元件均来自官方库（无第三方模型风险）；“实验报告”不是模板套话，而是按高校实验报告评分标准逐项撰写：目的明确指向“理解中断响应时序与现场保护机制”，原理部分手绘了IE寄存器位定义表并标注各位置1含义，现象分析中附了三组不同按键速度下的LED闪烁波形截图对比，思考题答案直接引用《Intel MCS-51 User’s Manual》第4章原文编号。它解决的不是一个“能不能跑”的问题，而是“能不能讲清楚每一拍发生了什么”的教学刚需。

我把它放在实验室U盘里三年，学生拷走后基本不用再问“为什么没反应”，因为整个链路——从C源码变量声明、编译器如何把while(1)编译成SJMP $、Proteus如何模拟CPU取指周期、到示波器探针该接哪根线——全部预置妥当。你不需要成为Keil专家，也不必熟读Proteus手册，只要按文档双击打开两个软件，就能亲眼看到：当按下那个虚拟按键的瞬间，主循环里的计数器真的停住了，堆栈指针SP从07H跳到09H，ACC和PSW被压入，然后LED亮起，再然后一切恢复如初。这种确定性，对初学者建立底层信心的价值，远超十页PPT。

2. 整体设计思路与方案选型解析：为什么是这套组合，而不是别的

2.1 为什么坚持用传统8051+Keil C51，而不是STM32+HAL库？

现在教单片机，很多老师直接上STM32，理由很充分：资料多、生态好、性能强。但这就绕开了一个本质问题：《计算机组成原理》这门课的核心目标，从来不是让你学会用某个芯片，而是理解“CPU如何响应异步事件”这一计算机构建基石。STM32的NVIC中断控制器封装太深，HAL库甚至把EXTI_Init()都抽象掉了，学生调用完函数，既看不到向量表地址，也看不到PSP/MSP切换过程，更无法观察到“压栈-跳转-执行-弹栈-返回”这五步原子操作的机器周期消耗。而8051的中断机制足够裸露：IE寄存器只有8位，EX0、ET0、ES这些位一一对应硬件模块；中断入口地址固定（INT0是0003H），你甚至可以在STARTUP.A51里直接看到LJMP 0003H这条跳转；堆栈操作由硬件自动完成，但压入顺序（PC低字节→PC高字节→PSW→ACC…）在.M51文件里清清楚楚。用它做实验，就像用透明玻璃缸养鱼——所有动作都暴露在视野下。

更重要的是，Keil C51编译器生成的汇编极其规整。比如void INT0_ISR() interrupt 0这个声明，编译后必然生成以PUSH ACC开头、POP ACC结尾的标准中断序言/尾声，中间夹着你的C代码。而STM32的GCC编译器会插入大量优化指令，新手根本分不清哪些是编译器加的，哪些是自己写的。我们选8051，不是守旧，是精准匹配教学目标——要让学生亲手“触摸”中断的骨骼，而不是隔着一层脂肪看轮廓。

2.2 为什么Proteus仿真图只用最简电路：一个按键+两个LED？

翻看目录里的仿真图.DSN，你会发现电路简洁得近乎“寒酸”：AT89C51最小系统（晶振+复位）、P3.2接独立按键（上拉到VCC）、P1.0和P1.1各接一个LED（共阳极，低电平点亮）。没有数码管，没有蜂鸣器，没有ADC采样电路。这不是偷懒，而是刻意为之的教学设计。

中断的本质是“打断当前任务去处理紧急事件”，那么实验电路就必须让“打断”与“被打断”形成强烈对比。这里，主程序是一个无限循环：while(1) { P1 = ~P1; delay_ms(500); }，让P1.0和P1.1交替闪烁，周期1秒。而中断服务程序只做一件事：P1_0 = 0; delay_us(100); P1_0 = 1;——点亮P1.0 100微秒。当按键按下，你肉眼可见主循环的1秒闪烁被强行插入一个极短的“刺眼亮光”。这个视觉反差，比任何波形图都直观地说明了“中断优先级高于主程序”。

如果加入数码管动态扫描，主程序时间片会被切割得支离破碎，LED的“被中断”现象就模糊了；如果加ADC读取电位器，每次中断都要等转换完成，反而掩盖了“响应延迟”这个关键指标。我们用最简电路，就是为了把“中断响应”这个单一变量，从所有噪声中彻底剥离出来。就像物理实验要用斜面测重力加速度，必须先消除摩擦——这里的“摩擦”，就是一切非核心的外设干扰。

2.3 为什么实验报告强调“时序分析”，而不是只写现象？

打开实验四.docx，你会看到第3.4节标题是“中断响应时序实测与分析”，下面不是简单写“LED亮了”，而是列了一张表格：

测量点	信号来源	实测值	理论值	偏差原因
T1	INT0引脚下降沿	t=0μs	—	触发基准
T2	LED点亮（P1.0变低）	t=3.2μs	3μs（3个机器周期）	IO口驱动延迟
T3	主循环LED状态冻结	t=3.5μs	—	CPU暂停取指

这个表格的数据，来自Proteus自带的“Digital Oscilloscope”工具，将通道A接P3.2，通道B接P1.0，用上升沿触发，捕获完整过程。为什么执着于测这3.2μs？因为这是检验学生是否真正理解“中断响应时间”定义的关键——它指从硬件检测到有效中断请求，到执行中断服务程序第一条指令之间的时间，包含：① CPU完成当前指令（最长1个机器周期）、② 执行硬件LCALL指令（2个机器周期）、③ 保存PC（2个机器周期）、④ 保存PSW（1个机器周期），共6个机器周期。在12T模式、11.0592MHz下，1个机器周期=1.085μs，6×1.085≈6.51μs——但实测只有3.2μs？因为当前指令恰好是单周期指令（如INC A），且LCALL前无需等待，实际只消耗了3个机器周期。这个“理论vs实测”的碰撞，才是组成原理实验的灵魂：它逼着学生回头翻手册，查指令周期表，理解“为什么不是固定值”。如果报告只写“现象正常”，那就失去了实验的意义。

3. 核心细节解析与实操要点：从源码到仿真的每一处设计意图

3.1`zhongduan.c`：一行代码背后的硬件映射逻辑

打开zhongduan.c，核心代码不过20行，但每行都是精心设计：

#include <reg51.h> sbit LED0 = P1^0; sbit LED1 = P1^1; sbit KEY = P3^2; void delay_us(unsigned int us) { while(us--); } void main() { IT0 = 1; // 设置INT0为下降沿触发 EX0 = 1; // 允许外部中断0 EA = 1; // 开总中断 while(1) { LED0 = ~LED0; LED1 = ~LED1; delay_ms(500); } } void INT0_ISR() interrupt 0 { LED0 = 0; // 立即点亮LED0 delay_us(100); // 保持100μs LED0 = 1; // 熄灭 }

表面看很简单，但藏着三个极易被忽略的细节：

第一，IT0 = 1必须在EX0 = 1之前设置。很多学生习惯把所有初始化写在一起，顺序随意。但8051手册明确指出：IT0位控制的是“中断请求锁存器”的触发方式，它必须在中断使能前配置完毕，否则可能因电平抖动产生误触发。我们在实验报告里专门用红框标出这行顺序，并附了Proteus中故意颠倒顺序后的错误波形图——LED会随机闪烁，证明硬件锁存器未正确初始化。

第二，delay_us(100)函数没有用定时器，而是纯软件循环。这是因为中断服务程序要求“快进快出”，用定时器会再次开启中断嵌套，破坏实验单纯性。而100μs足够短（约100个NOP指令），又足够长到肉眼可辨，且其执行时间稳定（Keil C51在O0优化下，while(us--)生成的DJNZ指令周期恒定）。我们在.LST文件里截取了这段汇编：

C:0x003F 757D64 MOV 7DH,#0x64 ; us = 100 C:0x0042 D57DFF DJNZ 7DH,C:0042 ; 循环100次

清晰显示为100次减法跳转，每周期2μs，总耗时200μs——等等，为什么代码写100却耗时200μs？因为delay_us(100)中的参数是近似值，实际需根据晶振和编译器优化等级微调，这正是实验报告思考题第2问的来源：“若要求精确100μs，应将参数改为多少？请结合.LST文件中DJNZ指令周期计算”。

第三，LED0 = 0和LED0 = 1之间没有加_nop_()或空指令。有学生觉得“应该加个延时防抖”，这是混淆了硬件消抖与软件消抖。按键消抖应在主程序中处理（如检测到下降沿后延时10ms再确认），而中断服务程序里必须保证原子性——一旦进入ISR，就要立即响应，不能因延时错过下一个中断。Proteus中我们特意用了理想开关模型（无抖动），就是为了聚焦“中断本身”，把消抖作为后续实验的独立课题。

提示：在Keil中编译后，务必打开zhongduan.LST文件，找到INT0_ISR函数对应的汇编段。你会看到编译器自动生成的PUSH ACC、PUSH PSW、POP PSW、POP ACC，以及最后的RETI指令。这是理解“现场保护”最直观的证据——不需要背诵，亲眼所见即真理。

3.2`STARTUP.A51`：被忽视的“中断第一行代码”

很多人以为中断从main()开始，其实不然。当你按下“编译”按钮，Keil首先链接STARTUP.A51这个启动文件。打开它，关键段落如下：

ORG 0000H LJMP START ; 复位向量 ORG 0003H LJMP INT0_ISR ; INT0中断向量 ORG 000BH LJMP TIMER0_ISR ; 定时器0中断向量（本实验未用） ... START: MOV SP,#07H ; 初始化堆栈指针 ACALL MAIN SJMP $

这里有两个决定性设计：第一，ORG 0003H强制将INT0_ISR的入口地址定位到内存0003H，这是8051硬件规定的。如果这里写错，CPU检测到中断后会跳到错误地址，轻则死机，重则跑飞。我们的工程里，zhongduan.c中void INT0_ISR() interrupt 0的interrupt 0关键字，就是告诉C51编译器：“请把这段代码放到0003H开始的区域”，它与启动文件中的LJMP INT0_ISR形成硬链接。第二，MOV SP,#07H将堆栈指针初始化为07H，意味着堆栈从内部RAM的08H单元开始向上生长。为什么是07H？因为8051的00H~07H是工作寄存器R0~R7区，08H~1FH是可位寻址区，必须避开。如果SP设为00H，压栈时会覆盖R0，导致主程序崩溃。这个细节，在实验报告的“原理”部分用一张RAM内存分布图详细标注，避免学生盲目修改。

注意：不要试图删除或修改STARTUP.A51！曾有学生觉得“C语言不用汇编”，直接删掉它，结果编译通过但仿真完全不响应中断——因为中断向量表消失了。启动文件不是可选项，它是CPU认知世界的“宪法”。

3.3`仿真图.DSN`：Proteus里那些“看不见”的连接玄机

双击打开仿真图.DSN，表面看就是AT89C51、按键、LED。但有三处Proteus特有的“隐形配置”，决定了实验成败：

按键属性设置：右键点击按键→Properties→“Logic level”必须设为“Active Low”，且“Debounce time”设为0。这是模拟理想机械开关，确保按下瞬间P3.2从高电平（1）跳变到低电平（0），触发下降沿中断。如果设为“Active High”，则按键按下时输出高电平，INT0永远收不到下降沿。
AT89C51晶振配置：双击单片机→Edit Properties→“Clock Frequency”必须填11.0592MHz，且“Program File”指向zhongduan.hex。这里有个坑：Proteus默认晶振是1MHz，如果不改，所有延时都会错乱（delay_ms(500)会变成5ms），主循环快得看不见，中断响应时间测量也失效。我们在实验报告里用红色加粗标出此步骤，并附了错误配置下的波形对比图。
LED驱动方式：两个LED均采用“共阳极接法”，阳极接VCC，阴极通过220Ω电阻接P1.0/P1.1。这意味着P1_0 = 0时LED点亮，P1_0 = 1时熄灭。这种接法的好处是：IO口灌电流能力（20mA）远大于拉电流能力（60μA），能保证LED亮度充足。如果接成共阴极，P1_0 = 1点亮，但单片机IO口拉高时驱动不足，LED会很暗甚至不亮，导致现象观察失败。

实操心得：第一次运行前，务必在Proteus中点击“Debug”→“Digital Oscilloscope”，将Channel A接P3.2，Channel B接P1.0，设置触发源为Channel A下降沿。这样，每次按键，你都能看到一条完整的时序波形：A通道下降沿（T1），B通道随后出现一个方波（T2-T3），主循环波形在此期间暂停。这是验证整个链路正确的黄金标准。

4. 实操过程与核心环节实现：从零开始的完整复现指南

4.1 Keil环境准备与工程导入（5分钟搞定）

虽然号称“开箱即用”，但Keil版本差异仍需确认。本工程经测试兼容Keil uVision4（v4.74）和uVision5（v5.38），不支持v5.40以上（因C51编译器被移除）。操作步骤如下：

确认Keil版本：打开Keil → Help → About uVision，查看版本号。若为v5.40+，请下载v5.38安装包（官网可搜到历史版本）。
导入工程：双击zhongduan.uvproj（注意不是.uvproj.bak）。Keil会自动加载所有文件：zhongduan.c、STARTUP.A51、zhongduan.uvopt等。
检查芯片型号：Project → Options for Target → Device，确认选择的是AT89C51。若显示其他型号（如STC89C52），需手动更正，否则生成的hex文件地址空间错乱。
配置输出路径：Project → Options for Target → Output，勾选“Create HEX File”，并确认“Name of Executable”为zhongduan.hex，路径与仿真图.DSN同目录（默认即如此）。
编译工程：点击“Build”按钮（或Ctrl+F7）。成功时底部Build窗口显示：
*** Build completed successfully *** Program Size: data=9.0 xdata=0 code=246

此时，目录下会生成新的zhongduan.hex（覆盖旧文件）。注意：.bak文件是备份，勿双击打开；.uvopt和.uvproj是工程配置，修改后记得保存。

关键验证点：编译成功后，立即打开zhongduan.M51文件（用记事本即可），搜索INT0_ISR，你会看到类似内容：
CODE 0003H 0003H INT0_ISR 0003H 0003H PUSH ACC 0005H 0005H PUSH PSW 0007H 0007H CLR P1.0 0009H 0009H MOV R7,#64H 000BH 000BH DJNZ R7,$ 000DH 000DH SETB P1.0 000FH 000FH POP PSW 0011H 0011H POP ACC 0013H 0013H RETI
这证明中断服务程序确实被链接到了0003H，并包含了完整的现场保护指令。如果此处地址不是0003H，说明启动文件未生效，需检查工程是否正确加载了STARTUP.A51。

4.2 Proteus仿真运行与现象观测（10分钟沉浸式体验）

Proteus版本需为8.13或更高（ISIS 8.x系列）。操作流程：

打开仿真图：双击仿真图.DSN，Proteus自动加载电路。
关联HEX文件：双击AT89C51芯片 → “Program File”栏，点击文件夹图标，选择当前目录下的zhongduan.hex。此步绝不可省略！否则单片机运行的是空程序。
启动仿真：点击左下角“Play”按钮（绿色三角）。此时，你会看到两个LED以约1秒周期交替闪烁（P1.0亮→P1.1亮→P1.0亮…），这是主程序while(1)的效果。
触发中断：点击画面中的按键（Key），按住不放。瞬间，P1.0会额外点亮一次，持续约100μs（肉眼表现为一次快速“闪亮”），之后主循环继续。这就是中断服务程序在执行。
高级观测：点击菜单“Debug”→“Digital Oscilloscope”，添加两个通道：Channel A接P3.2（按键端），Channel B接P1.0（LED端）。点击“Auto Scale”，然后按按键。你会看到清晰的时序图：A通道下降沿（T1），B通道在3.2μs后出现一个100μs宽的低电平脉冲（T2-T3），同时主循环的方波在此期间暂停。

实操心得：如果按下按键后LED无反应，请按以下顺序排查：
- 检查Keil中是否已生成最新zhongduan.hex（时间戳是否更新）；
- 检查Proteus中芯片的“Program File”是否指向正确的hex文件（路径不能有中文或空格）；
- 右键按键→Properties→确认“Logic level”为“Active Low”；
- 双击单片机→确认“Clock Frequency”为11.0592MHz；
- 在Keil中打开zhongduan.plg文件，搜索“error”或“warning”，常见错误如“undefined symbol ‘INT0_ISR’”说明启动文件未链接。

4.3 实验报告撰写要点：如何把“抄作业”变成“真理解”

实验四.docx不是模板，而是按高校实验报告规范撰写的范本。学生提交时，只需替换其中的“实测截图”和“思考题手写答案”即可。关键填写指南：

实验目的：不要照抄。应结合自身理解重写，例如：“通过观测INT0中断触发前后主程序计数器的变化，理解CPU暂停当前任务、转向中断服务程序的硬件机制；通过测量P3.2下降沿到P1.0变低的时间差，掌握中断响应时间的构成要素。”
实验原理：重点画两张图。第一张是IE寄存器位定义表（EA、EX0、ET0等），标注每位功能；第二张是中断响应流程图，从“检测到下降沿”开始，分步写出“锁存请求→查询IE→压栈PC→压栈PSW→跳转0003H→执行ISR→弹栈PSW→弹栈PC→返回”。这两张图比文字描述有力十倍。
实验步骤：必须写明Keil和Proteus的具体操作，例如：“在Keil中，Project → Options for Target → Output，勾选‘Create HEX File’；在Proteus中，双击单片机，将‘Clock Frequency’设为11.0592MHz”。避免“配置环境”“运行仿真”这类模糊表述。
现象分析：这是得分关键。不仅要写“LED闪烁”，更要解释“为什么主循环闪烁被中断插入了一个短脉冲”。引用实测数据：“使用逻辑分析仪测得T1-T2=3.2μs，符合8051中断响应时间理论值（3个机器周期）”，并分析偏差原因（如IO驱动延迟）。
思考题解答：第1题“为何要先设置IT0再置位EX0？”答案必须引用手册原文：“IT0位必须在中断请求发生前配置，否则锁存器可能无法正确采样边沿”。第2题“如何精确实现100μs延时？”答案需基于.LST文件计算：DJNZ R7,$指令周期为2μs，故R7初值应为50（50×2μs=100μs），即MOV R7,#50H。

提示：报告中所有截图，必须来自你自己的Proteus运行界面。用Windows自带的“截图工具”截取，确保显示完整的Proteus窗口标题栏（含版本号）和逻辑分析仪波形。这既是学术诚信要求，也是验证你确实完成了实验的铁证。

5. 常见问题与排查技巧实录：那些年我们踩过的坑

5.1 编译通过但Proteus中无任何反应——最经典的“静默失败”

现象：Keil编译显示“Build completed successfully”，Proteus点击“Play”后LED完全不亮，按键无效。

排查路径：
1.检查HEX文件关联：这是90%问题的根源。双击Proteus中的AT89C51，看“Program File”栏是否为空或指向错误路径。常见错误：路径中有中文（如“桌面”）、空格（如“My Documents”）、或指向了.bak文件。
2.验证HEX文件有效性：用记事本打开zhongduan.hex，正常文件以:10000000开头，末尾有校验和。如果打开是乱码或显示“无法读取”，说明Keil编译未生成hex（检查Output选项是否勾选）。
3.确认晶振频率：双击单片机→“Clock Frequency”，必须为11.0592MHz。若为1MHz，主程序延时会快500倍，LED闪烁快到看不见，你以为“没反应”，其实是太快了。
4.检查启动文件加载：在Keil中，Project → Files，确认STARTUP.A51文件存在且图标为汇编文件（蓝色A）。若图标是灰色，说明未被工程识别，需右键“Add Group”→“Add Existing Files”重新添加。

独家技巧：在Proteus中，点击“Debug”→“Serial Monitor”，如果单片机运行正常，此处会显示串口输出（本实验未用串口，但可验证CPU是否在跑）。若此处空白，基本确定HEX未加载或芯片未启动。

5.2 中断响应但LED不亮，或亮度极暗——IO驱动能力陷阱

现象：按键按下时，逻辑分析仪显示P1.0有电平变化，但LED肉眼不可见，或非常暗。

根本原因：LED接法错误或限流电阻过大。

解决方案：
-确认接法：必须是“共阳极”——LED阳极接VCC，阴极通过电阻接P1.0。若接成共阴极（LED阴极接地，阳极接P1.0），则P1_0 = 1才能点亮，但8051 IO口拉高能力仅60μA，不足以驱动LED。
-调整电阻：当前使用220Ω电阻，提供约15mA电流（(5V-1.8V)/220Ω≈15mA），亮度适中。若LED仍暗，可尝试150Ω；若过亮发热，换330Ω。切勿低于100Ω，以防烧毁IO口。
-万用表验证：用万用表二极管档测LED，确认其正向压降为1.8~2.2V（红光LED），排除LED损坏。

经验之谈：在Proteus中，右键LED→Properties→“Color”可设为“Red”或“Green”，但亮度由电流决定。若仿真中LED不亮，优先检查电路连接线是否连到P1.0引脚（常有人连到P1.1或P2.0）。

5.3 主程序闪烁正常，但中断时LED不闪——中断服务程序未执行

现象：LED按1秒周期稳定闪烁，按键按下后主循环无暂停，P1.0无额外点亮。

核心排查点：
-检查中断使能顺序：打开zhongduan.c，确认IT0 = 1; EX0 = 1; EA = 1;三行顺序正确，且都在while(1)之前。若EA = 1写在最后，前面两行无效。
-验证INT0引脚电平：在Proteus中，将鼠标悬停在P3.2线上，会显示实时电平。正常时为高电平（1），按键按下时应变为低电平（0）。若始终为1，检查按键是否接错（如接到P3.3）或上拉电阻缺失。
-查看IE寄存器：在Keil调试模式下（Proteus运行时点击Keil的“Debug”→“Start/Stop Debug Session”），打开“Peripherals”→“Interrupt”窗口，观察IE寄存器各位：EA（Bit7）、EX0（Bit0）必须为1，IT0（Bit1）必须为1。若为0，说明初始化代码未执行或被覆盖。

高级技巧：在INT0_ISR函数第一行加LED1 = 0;，第二行加LED1 = 1;，这样中断时P1.1会闪一次。若P1.1闪而P1.0不闪，说明中断服务程序执行了，问题出在LED0控制逻辑，而非中断本身。

5.4 逻辑分析仪波形异常：T1-T2时间远大于3μs——时序测量误区

现象：用Proteus逻辑分析仪测得P3.2下降沿到P1.0变低的时间为10μs甚至更长。

真相：你测的是“按键按下到LED点亮”，但按键本身有机械抖动（10~20ms），Proteus默认模拟了抖动。而中断响应时间是指“硬件检测到有效下降沿”到“执行第一条ISR指令”的时间，抖动属于前端噪声，不应计入。

正确测法：
1. 在Proteus中，右键按键→Properties→将“Debounce time”设为0，关闭抖动模拟。
2. 使用“Digital Oscilloscope”而非“Logic Analyzer”，因示波器触发更精准。
3. 设置触发源为Channel A（P3.2）的“Falling Edge”，触发电平设为2.5V。
4. 按下按键后，观察Channel B（P1.0）首次变低的时间点，此即T2。T1为触发点（自动标记）。

实测数据表（供参考）：
| 条件 | T1-T2 (μs) | 原因分析 |
|------|-------------|-----------|
| Debounce=0, Clock=11.0592MHz | 3.2 | 符合理论（3个机器周期） |
| Debounce=10ms, Clock=11.0592MHz | 10,200+ | 测量了抖动时间，非中断响应 |
| Clock=1MHz | 36.5 | 机器周期变长（1μs→12μs），6周期=72μs，但因指令优化实际为36.5μs |

5.5 思考题不会答——回归手册的笨办法

学生常卡在思考题，如：“若要实现中断嵌套，需满足什么条件？”

标准答案：必须同时满足三点：① CPU已响应低优先级中断；② 正在执行的中断服务程序中，再次开总中断（EA=1）；③ 新中断请求的优先级高于当前正在服务的中断。

但如何让学生真正懂？我们的做法是：在实验报告附录中，附上《AT89C51 Data Sheet》第12页“Interrupt Structure”图，并用红圈标出IP（中断优先级）寄存器。然后布置一个延伸实验：修改代码，在INT0_ISR中加入EA=1;，再用另一个按键触发INT1（P3.3），观察两个LED是否能嵌套闪烁。只有亲手试过，才明白“开总中断”不是一句空话，而是实实在在的寄存器操作。