51单片机+Proteus交通灯仿真：状态机设计与定时器中断实战

简介这份资源面向51单片机初学者与电子工程相关专业学生提供一套可直接运行的交通灯控制系统仿真方案用于解决无硬件条件下学习定时器、中断与I/O端口编程的实践需求。压缩包共14个文件、约37KB包含C语言源程序、编译生成的hex文件、Keil工程配置与备份文件以及Proteus仿真工程文件覆盖从代码编写到电路仿真的完整链路。已有891人学习下载说明其在入门实践项目中具有一定参考价值。读者可据此观察红灯30秒、绿灯20秒、黄灯5秒的灯光切换逻辑理解定时器计数与中断服务程序的配合方式并借助仿真环境快速验证代码、排查计数误差与中断处理问题从而在低成本条件下完成一次较完整的嵌入式控制实践。1. 从一次答辩现场说起为什么交通灯仿真值得认真做一遍答辩季我见过太多这样的场面同学打开 Proteus点下运行红绿灯开始循环闪烁然后说“我的设计完成了”。导师随口问一句“东西向绿灯还剩 3 秒时南北向有人按了紧急按钮你的状态机怎么走”屏幕前的鼠标就停住了。交通灯这个题目看起来是 51 单片机入门里最“没技术含量”的一个但它恰恰是能把定时器中断、状态机设计、端口驱动、仿真联调串成一条完整链路的最小闭环项目。51 单片机 Proteus 仿真交通灯程序 仿真这套组合的价值不在于灯会不会亮而在于你能不能拿出一份状态迁移说得清、时序参数改得动、异常情况兜得住的完整方案。这篇内容面向正在做单片机课程设计、毕设预研或者想补一个可演示项目的读者把需求、架构、代码结构、仿真搭建和验收口径一次讲透你照着改参数就能变成自己的东西。2. 需求与总体设计一个十字路口的四相位状态机2.1 先把需求钉死别急着画原理图交通灯项目的翻车点十有八九不是代码写错而是需求一开始就没定清楚。我一般会先逼着自己回答四个问题路口是十字还是丁字、有没有人行横道、有没有紧急按钮、夜间要不要黄闪。这四个问题直接决定状态机的状态数量和 IO 分配。以最常见的十字路口双向直行为例合理的需求边界是这样的需求项具体口径对应设计影响相位数量四相位东西直行、东西左转、南北直行、南北左转状态机至少 4 个主状态配时方式每相位绿灯时长可独立配置用常量表而非硬编码延时黄灯过渡绿转红前固定 3 秒黄灯每个主状态带一个过渡子状态紧急优先按键触发后 2 秒内全红持续 10 秒需要中断 状态抢占逻辑夜间模式22:00 后黄灯闪烁一个独立低优先级状态把这张表定下来后面所有代码和仿真接线都是它的投影。很多同学上来就抄一份“红绿黄循环”的代码跑通了却发现加不了左转、加不了按键只能推倒重来这就是需求没立住的代价。2.2 总体架构三层职责划分这套方案我习惯拆成三层层与层之间只通过明确的变量和函数接口通信仿真里出问题时能快速定位是哪一层的事。第一层是硬件抽象层负责端口定义和灯组驱动。51 的 IO 口驱动能力有限Proteus 里可以直接驱动 LED但真实电路通常要加三极管或 ULN2003所以这一层要把“点亮某方向某颜色”封装成一个函数而不是在业务代码里到处写P1 0xXX。第二层是定时与调度层用 Timer0 做 50ms 基准节拍所有秒级计时都由节拍计数派生绝不用delay()硬等。第三层是状态机业务层只关心“当前处于哪个相位、还剩多少节拍、下一个相位是谁”不碰任何端口。这样分层的好处很直接导师让你把绿灯从 30 秒改成 45 秒你只改常量表让你加一个行人按钮你只在状态机层加一个抢占分支让你换到另一款 51 兼容芯片你只改硬件抽象层的端口宏。血泪经验是凡是把延时和端口操作混在main里平铺直叙的代码第二次修改必然出玄学问题。2.3 状态迁移设计把时序画成表状态机的核心不是代码是那张迁移表。四相位加黄灯过渡实际是 8 个状态在循环紧急和夜间模式作为抢占态插入。我一般会先写这样一张表再动手当前状态持续节拍50ms/拍下一状态灯组输出东西/南北S0 东西绿60030sS1东绿西绿 / 南北红S1 东西黄603sS2东黄西黄 / 南北红S2 东西左转绿30015sS3东左绿 / 南北红S3 东西左转黄603sS4东左黄 / 南北红S4 南北绿60030sS5东西红 / 南北绿S5 南北黄603sS6东西红 / 南北黄S6 南北左转绿30015sS7东西红 / 南北左绿S7 南北左转黄603sS0东西红 / 南北左黄这张表就是整个项目的“黑匣子记录”答辩时导师问任何一个时刻的灯态你都能从表里查出来。表里的节拍数全部来自 2.1 的需求口径改配时就是改这一列数字逻辑一行不用动。3. 程序实现定时器节拍 查表状态机3.1 定时器基准节拍50ms 从哪来51 单片机常用 12MHz 晶振机器周期 1μs。Timer0 工作在模式 116 位定时要产生 50ms 中断初值计算是65536 - 50000 15536 0x3CB0。这个数字建议写成宏并注明推导过程否则过两个月你自己都忘了为什么是 0x3CB0。#include reg52.h #define FOSC 12000000UL /* 晶振频率改板子时只改这里 */ #define TICK_MS 50 /* 基准节拍 50ms */ #define T0_RELOAD (65536 - (FOSC/12/1000*TICK_MS)) volatile unsigned int g_tick_cnt 0; /* 全局节拍计数状态机消费 */ void Timer0_Init(void) { TMOD 0xF0; /* 清 Timer0 模式位 */ TMOD | 0x01; /* Timer0 模式116位定时 */ TH0 (unsigned char)(T0_RELOAD 8); TL0 (unsigned char)(T0_RELOAD 0xFF); ET0 1; /* 开 Timer0 中断 */ EA 1; /* 开总中断 */ TR0 1; /* 启动计时 */ } void Timer0_ISR(void) interrupt 1 { TH0 (unsigned char)(T0_RELOAD 8); /* 重装初值必须放最前 */ TL0 (unsigned char)(T0_RELOAD 0xFF); g_tick_cnt; /* 只做计数业务逻辑一律不放中断里 */ }这段代码有两个设计取舍要说清。第一中断服务函数里只做重装和计数不点灯、不判断状态。中断里干活越多主循环被拖慢的概率越大仿真里表现为灯闪得“发飘”实物上就是时序漂移。第二g_tick_cnt用volatile修饰因为它在中断和主循环之间共享不加这个关键字编译器优化后可能读到寄存器里的旧值这是 51 项目里最典型的玄学 bug 之一。节拍定为 50ms 而不是 1s是为了让黄灯 3 秒、紧急响应 2 秒这类非整秒需求也能用整数节拍表达精度够用且不引入浮点。3.2 状态机主循环查表驱动拒绝 if 嵌套地狱有了节拍主循环要做的事就三件算当前状态该持续多少拍、判断是否该迁移、把灯态刷到端口。我一般用结构体数组把 2.3 那张表直接翻译成代码迁移逻辑就变成一个减法。typedef struct { unsigned int duration; /* 本状态持续节拍数 */ unsigned char ew_lamp; /* 东西向灯组编码 */ unsigned char ns_lamp; /* 南北向灯组编码 */ } PhaseDef; /* 灯组编码bit0 红 bit1 黄 bit2 绿 bit3 左转绿1 为亮 */ #define EW_RED 0x01 #define EW_YEL 0x02 #define EW_GRN 0x04 #define EW_LGRN 0x08 #define NS_RED 0x01 #define NS_YEL 0x02 #define NS_GRN 0x04 #define NS_LGRN 0x08 static const PhaseDef g_phase_tbl[8] { {600, EW_GRN, NS_RED}, /* S0 */ { 60, EW_YEL, NS_RED}, /* S1 */ {300, EW_LGRN, NS_RED}, /* S2 */ { 60, EW_YEL, NS_RED}, /* S3 */ {600, EW_RED, NS_GRN}, /* S4 */ { 60, EW_RED, NS_YEL}, /* S5 */ {300, EW_RED, NS_LGRN}, /* S6 */ { 60, EW_RED, NS_YEL} /* S7 */ }; static unsigned char g_phase 0; static unsigned int g_remain 0; static unsigned int g_last_tick 0; void FSM_Run(void) { unsigned int now g_tick_cnt; if (now g_last_tick) return; /* 没有新节拍直接返回 */ g_last_tick now; if (g_remain 0) { /* 当前状态走完迁移 */ g_phase (g_phase 1) 0x07; /* 8 状态循环 */ g_remain g_phase_tbl[g_phase].duration; } else { g_remain--; } Lamp_Output(g_phase_tbl[g_phase].ew_lamp, g_phase_tbl[g_phase].ns_lamp); }这里的关键设计点有三个。其一用g_last_tick做节拍去重保证每个 50ms 节拍只推进一次状态主循环跑多快都不影响时序这是把“时间”和“执行速度”解耦的标准做法。其二g_phase 1 0x07用位与实现 8 状态回绕比if (g_phase 8) g_phase 0少一个分支也顺手把状态数锁死在 8 个加状态时你会被迫先想清楚表怎么改。其三灯态输出统一走Lamp_Output端口映射只在这一处出现Proteus 里改接线、实物上换驱动芯片都只动这一个函数。3.3 紧急按键与夜间模式抢占逻辑怎么插紧急按键最容易写崩。常见错误是在主循环里if (key 0) { 全红; delay(10000); }一按下去整个状态机停摆松手后相位错乱。正确做法是把紧急模式做成抢占态按键中断里只置一个标志主循环检测到标志后保存当前相位和剩余节拍切到全红状态倒计时结束后恢复现场。volatile bit g_emergency 0; /* 按键中断置位 */ static unsigned char g_saved_phase; static unsigned int g_saved_remain; void EXTI0_ISR(void) interrupt 0 { g_emergency 1; /* 中断里只置标志不做业务 */ } void FSM_EmergencyCheck(void) { static unsigned int emg_cnt 0; if (g_emergency emg_cnt 0) { g_saved_phase g_phase; /* 保存现场 */ g_saved_remain g_remain; emg_cnt 200; /* 10s / 50ms 200 拍 */ g_emergency 0; } if (emg_cnt 0) { Lamp_AllRed(); /* 全红输出 */ emg_cnt--; if (emg_cnt 0) { /* 恢复现场从断点继续 */ g_phase g_saved_phase; g_remain g_saved_remain; } } }夜间黄闪同理只是它不抢占而是降级检测到一个模式标志后状态机不再推进直接让黄灯按 1Hz 翻转。这里有个细节黄闪的翻转也要挂在 50ms 节拍上每 10 拍翻一次不要另开一个定时器否则两个时间源迟早打架。紧急响应“2 秒内全红”的口径靠的是按键中断即时置位、主循环下一轮就处理实际响应时间远小于 2 秒这个余量是留给实物按键消抖的。4. Proteus 仿真搭建从元件清单到联调4.1 元件清单与最小系统接线仿真能不能跑起来一半取决于最小系统接得对不对。51 在 Proteus 里必须接复位电路和晶振否则程序不跑很多同学以为是 hex 没加载其实是 RST 脚悬空。我一般按这张清单备料元件型号/参数数量作用单片机AT89C51/AT89C521主控晶振12MHz1时钟源瓷片电容30pF2晶振负载电解电容10μF1上电复位电阻10kΩ1复位下拉LED红/黄/绿12四相位灯组限流电阻330Ω12LED 限流按键轻触开关1紧急触发接线要点晶振两脚各接一个 30pF 到地复位脚经 10μF 电容接 VCC、经 10kΩ 电阻接地EA 脚接 VCC用内部程序存储器。LED 按 2.3 的灯组编码接到 P1 和 P2共阴接法时端口输出高电平点亮代码里的编码就是按这个极性写的如果你改成共阳Lamp_Output里要整体取反这是仿真里灯“全亮”或“全灭”的第一排查点。4.2 hex 加载与仿真参数设置程序在 Keil 里编译出 hex 后双击 Proteus 里的单片机在 Program File 栏选中 hexClock Frequency 填 12MHz必须和代码里的FOSC一致。这一步翻车的典型现象是灯循环速度明显偏快或偏慢原因就是仿真时钟和代码假设的晶振对不上。另外建议在 Proteus 的 System 设置里把“动画选项”的帧率调低一点仿真跑长时序时能省不少 CPU否则 30 秒绿灯在仿真里可能卡成幻灯片。联调顺序我一般固定为先只加载最小系统看复位是否正常用一个 P1 口翻转的小程序验证再接入单组 LED 验证端口极性最后接全 12 个灯跑完整状态机。这个顺序看着笨但能把“程序问题”和“接线问题”彻底分开比一上来全接好然后对着不亮的灯猜要快得多。4.3 用虚拟终端和探针做时序验证Proteus 里有个很多人不用的功能在端口上挂电压探针配合虚拟示波器看波形。验证黄灯是不是真的 3 秒不用掐表把黄灯对应端口接示波器一个高电平脉冲的宽度就是实际时长和 2.3 表里的 60 拍 × 50ms 3s 对一下差得离谱就说明节拍去重或重装初值有问题。我还会在状态迁移处加一个调试端口输出用虚拟终端打印当前相位号答辩演示时这个终端就是你的“黑匣子”导师问哪一秒是什么状态直接翻记录。5. 避坑与排查五个最容易翻车的点5.1 灯全亮或全灭端口极性与驱动方式不匹配现象是仿真一运行12 个灯要么全亮要么全灭状态机怎么改都没反应。原因通常是 LED 接法共阴/共阳和代码里的编码极性相反或者限流电阻漏接导致 Proteus 判定为短路。解决办法是先单独写一个只点亮一个灯的最小测试确认极性后再套用完整编码表Lamp_Output里加一行注释写明“本工程为共阴高电平点亮”换接法时改这一处即可。5.2 时序整体偏快或偏慢晶振频率两处不一致现象是绿灯明显不到 30 秒就跳了或者慢得让人怀疑人生。原因基本是 Keil 工程里的晶振设置、Proteus 单片机属性里的 Clock Frequency、代码里的FOSC宏三者不一致最常见的是代码按 12MHz 算初值、仿真却填了 11.0592MHz。解决办法是把这三个值统一成一个宏管理仿真属性里照抄改板子时三处一起改别只改一处。5.3 紧急按键按了没反应或相位错乱现象是按下按键灯不变或者变完全红后恢复时相位跳到了别处。原因是按键中断没开EX0/IT0 没配、或者中断里直接做了延时和点灯导致主循环被卡。解决办法是中断只置标志业务全放主循环恢复现场时严格用保存的g_saved_phase和g_saved_remain不要图省事从 S0 重新开始否则演示时会被追问“为什么紧急结束后要重新等一个完整绿灯”。5.4 状态机卡死在某一个相位现象是灯停在某个状态不再迁移。原因多半是g_remain的类型或初值问题如果duration写成有符号数又减到负数或者g_last_tick去重逻辑写反导致节拍永远不推进。排查方法是把g_phase和g_remain打到虚拟终端上看节拍计数是否在涨、g_remain是否在减两个数有一个不动就能定位到是定时器没进中断还是去重条件写错。5.5 仿真能跑、实物不跑复位与 EA 脚现象是 Proteus 里一切正常焊到板子上程序不执行。原因是实物最小系统的复位电容、EA 脚接法或晶振负载电容和仿真假设不同仿真对复位电路是“宽容”的实物不宽容。解决办法是实物调试时先用万用表量 RST 脚上电瞬间是否有高电平、EA 是否稳定接 VCC再怀疑程序。这条是我踩过最深的坑仿真通过不等于硬件通过验收前一定留出实物联调时间。6. 验收与答辩用一张时序表把问题问死验收这件事我建议你主动出击别等导师问。准备一张“任意时刻灯态查询表”就是把 2.3 的迁移表加上累计时间轴标出每个相位的起止秒数答辩时往投影上一放导师指哪一秒你答哪一秒主动权就在你手里。具体做法是以 S0 起点为 0 秒S0 占 0–30sS1 占 30–33sS2 占 33–48s依此类推算出 8 个状态的完整时间窗再标出紧急模式插入后的时间偏移规则。这张表同时就是你的验收标准——仿真跑一遍用示波器量每个黄灯脉冲宽度和表里对误差在 ±1 个节拍50ms内算合格。答辩时高频被问的三个问题提前准备好答案第一“你的定时精度受什么影响”答晶振误差加中断响应延迟50ms 节拍下累计误差可接受且所有时长都是节拍整数倍不存在浮点累积误差第二“紧急按钮和正常相位冲突怎么办”答抢占态保存现场、结束后恢复断点并现场演示一次第三“怎么扩展到丁字路口或加人行道”答改状态迁移表和灯组编码业务层不动这正好呼应第 2 章的分层设计。演示顺序也有讲究先跑完整循环让导师看全貌再定点触发紧急模式展示异常处理最后打开虚拟终端展示状态日志三步下来方案的可信度就立住了。从那以后我每次带人做这类仿真项目都强制先写迁移表再写一行代码表对不上就不许开 Keil。这个习惯救过我不止一次也让我明白交通灯这种“简单题”真正考的是把需求、时序、异常三件事说圆的能力。希望帮到你。本文还有配套的精品资源点击获取