简介：这份智能交通灯控制器资源面向嵌入式初学者、课程设计学生及参加电子竞赛的开发者，提供从程序编写到电路仿真的完整方案。包内共17个文件，以Keil工程文件（uvproj、uvopt）、C语言源码（main.c）、编译产物（hex、M51、LST）以及Proteus仿真文件（DSN、DBK）为主，另附使用说明与成果问题记录等txt文档，压缩包约86KB。资源核心在于三种工作模式的实现：正常模式按预设时序切换红绿灯，紧急模式可立即放行特殊车辆，智能模式则依据车流量动态调整信号灯时长，并通过按键完成模式切换。借助Keil与Proteus联合仿真，读者可在无实物硬件的情况下验证控制逻辑，掌握传感器数据处理、实时控制算法与用户交互设计等关键技能。目前已有4701人学习下载，适合作为嵌入式系统设计与交通流检测技术的实践参考。
1. 从一次路口配时翻车说起：这个智能交通灯控制器到底能干什么
去年帮一个做嵌入式实训的朋友看他的课程设计，题目就是智能交通灯控制器。他拿来的东西很典型：Keil 工程能编译，Proteus 仿真图也能打开，但一跑起来东西向绿灯常亮，南北向红灯永远不切，数码管倒计时停在 30 不动。他以为是代码逻辑写错了，我让他先别动 C 文件，把 Proteus 里那根从 P3.2 引出来的线看了一眼——接错了口，中断根本没进来。这个场景基本能说明这份资源的价值：它不是一段孤立的红绿灯代码，而是一套「Keil 程序代码 + Proteus 仿真图 + 使用说明」的完整闭环，代码、电路、说明三者对得上，你才能把现象和原因对上号。
这份资源适合三类人：正在做单片机课程设计、需要交一个能演示的交通灯系统的学生；想练手 51 单片机定时器、中断、数码管动态扫描的初学者；以及需要拿一个现成仿真工程做二次开发、改配时逻辑或加车流量检测的开发者。它的核心不是「红绿灯」这三个字，而是把定时器中断、状态机切换、倒计时显示、紧急按键这几件事在一个可仿真的环境里串起来。下面按「先看清结构、再跑起来、最后动手改」的顺序拆。
2. 工程结构拆解：Keil 工程、Proteus 仿真图和使用说明怎么对应
2.1 三份文件各自管什么
拿到一个「代码 + 仿真 + 说明」的组合包，第一件事不是急着编译，而是先搞清楚三份东西的边界。Keil 工程负责逻辑，Proteus 仿真图负责电气连接和器件模型，使用说明负责把前两者的对应关系讲清楚。很多人翻车就翻在把这三者当成独立的文件，改代码的时候不看仿真图，改电路的时候不看代码里用的是哪个口。
常见的目录组织是这样：
智能交通灯控制器/ ├── code/ # Keil 工程目录 │ ├── traffic_light.uvproj # Keil 工程文件 │ ├── main.c # 主逻辑：状态机 + 定时器 │ ├── display.c # 数码管动态扫描 │ ├── display.h │ ├── timer.c # 定时器初始化与中断服务 │ └── timer.h ├── sim/ # Proteus 仿真目录 │ ├── traffic_light.dsn # 仿真工程 │ └── traffic_light.hex # 编译产物，供仿真加载 └── 使用说明.txt / .pdf # 端口对应、编译步骤、常见问题这个结构里最关键的一条线是：Keil 编译出来的.hex文件要被 Proteus 加载进去，仿真才会按你的代码跑。如果仿真里跑的还是旧行为，八成是.hex没重新生成或者加载路径没更新。使用说明里通常会写明「先编译、再在 Proteus 双击单片机、把 Program File 指向新的 hex」，这一步漏了，改多少代码都白搭。
2.2 端口分配：代码和仿真图必须对齐
交通灯系统的端口分配是代码和电路之间的契约。常见做法是 P1 口驱动东西南北四个方向的红黄绿 LED，P0 口驱动数码管段选，P2 口做数码管位选和按键输入。下面是一份典型的端口定义，你拿到手的工程大概率长这样：
// port.h —— 端口定义，必须和 Proteus 仿真图一致 sbit EW_RED = P1^0; // 东西向红灯 sbit EW_YELLOW = P1^1; // 东西向黄灯 sbit EW_GREEN = P1^2; // 东西向绿灯 sbit NS_RED = P1^3; // 南北向红灯 sbit NS_YELLOW = P1^4; // 南北向黄灯 sbit NS_GREEN = P1^5; // 南北向绿灯 sbit KEY_EMERGENCY = P3^2; // 紧急按键，接外部中断0这里有个血泪经验：sbit定义的口必须和 Proteus 里 LED 接的口一一对应，差一位就是「灯亮错方向」。我见过有人代码里写P1^0是东西红灯，仿真图里却把东西红灯接到了 P1^1，结果现象是「红灯和黄灯一起亮」，查了半天代码没毛病，问题在图上。所以拿到工程后，第一件事是打开使用说明里的端口对应表，或者直接对着仿真图数一遍，确认代码和电路说的是同一件事。
2.3 使用说明里真正该看的三件事
使用说明不是摆设，但也不用逐字读。我一般只看三处：一是端口对应表，确认代码和仿真图对齐；二是编译与加载步骤，确认用哪个版本的 Keil、hex 输出路径在哪、Proteus 里怎么加载；三是常见现象对照，比如「上电后全灭」通常是晶振或复位问题，「倒计时不动」通常是定时器没进中断。这三处看完，基本就能判断这个工程是不是「开箱能跑」。
提示：如果使用说明里写了晶振频率（常见 11.0592MHz 或 12MHz），一定要和 Proteus 里单片机属性中的时钟频率对上。频率不一致，倒计时会明显偏快或偏慢，这种问题最容易被误判成代码 bug。
3. 跑起来：从 Keil 编译到 Proteus 仿真的完整链路
3.1 Keil 侧：编译配置和 hex 输出
先确认 Keil 工程能干净编译。打开.uvproj后，重点看两个地方：Target 里选的单片机型号（常见 AT89C51、AT89C52 或 STC89C52），以及 Output 选项卡里有没有勾选「Create HEX File」。型号选错会导致寄存器定义对不上，hex 不生成则 Proteus 没东西可加载。
# Keil 命令行编译（可选，用于批量验证） UV4 -b traffic_light.uvproj -o build_log.txt # -b 表示 batch 模式编译 # -o 把编译日志输出到文件，方便看 warning 和 error如果你用命令行编译，build_log.txt里出现0 Error(s)才算过。有 warning 不一定要命，但像「未使用的变量」「隐式声明函数」这类 warning 最好清掉，它们往往对应着没接上的逻辑。编译通过后，hex 文件默认在工程目录的Objects/或Output/下，具体看 Output 选项卡里的路径设置。
3.2 Proteus 侧：加载 hex 和时钟设置
Proteus 这边要做三件事。第一，双击仿真图里的单片机，在 Program File 里指向刚编译出来的 hex；第二，确认 Clock Frequency 和代码里定时器计算用的晶振一致；第三，检查电源和地有没有接好，尤其是数码管的共阴共阳属性。
Proteus 操作路径： 1. 双击 U1（单片机）→ Edit Component 2. Program File: 选择 code/Objects/traffic_light.hex 3. Clock Frequency: 12MHz（与代码一致） 4. 点击 OK，然后点左下角运行按钮运行后正常现象是：一个方向绿灯亮、另一个方向红灯亮，数码管显示剩余秒数并逐秒递减，绿变黄再变红，两个方向交替。如果数码管显示乱码或闪烁，先查位选和段选的驱动方式，共阴和共阳接反是最常见的原因。
3.3 定时器与状态机：让灯真正「动」起来的核心
交通灯能切换，靠的是定时器中断驱动的状态机。定时器每隔固定时间产生一次中断，中断里累加计数，计到阈值就切换状态。下面是一段典型实现：
// timer.c —— 定时器0初始化，50ms 中断一次 void Timer0_Init(void) { TMOD &= 0xF0; // 清除定时器0的控制位 TMOD |= 0x01; // 定时器0工作在模式1（16位定时） TH0 = (65536 - 50000) / 256; // 50ms 初值，12MHz 晶振 TL0 = (65536 - 50000) % 256; ET0 = 1; // 使能定时器0中断 EA = 1; // 开总中断 TR0 = 1; // 启动定时器0 } // 中断服务：每 50ms 进一次，20 次就是 1 秒 void Timer0_ISR(void) interrupt 1 { static unsigned char tick = 0; TH0 = (65536 - 50000) / 256; // 重装初值 TL0 = (65536 - 50000) % 256; tick++; if (tick >= 20) { // 累计 1 秒 tick = 0; if (countdown > 0) countdown--; } }这段代码的关键参数是50000和20。50000对应 50ms，是在 12MHz 晶振下算出来的：一个机器周期 1us，50000 个机器周期就是 50ms。20是把 50ms 累加成 1 秒。如果你把晶振改成 11.0592MHz，这两个数都要重算，否则倒计时会偏。状态切换则放在主循环里根据countdown判断：
// main.c —— 主循环里的状态机 while (1) { switch (state) { case EW_GREEN_NS_RED: EW_GREEN = 0; NS_RED = 0; // 低电平点亮 if (countdown == 0) { state = EW_YELLOW_NS_RED; countdown = YELLOW_TIME; // 黄灯 3 秒 } break; case EW_YELLOW_NS_RED: EW_GREEN = 1; EW_YELLOW = 0; if (countdown == 0) { state = EW_RED_NS_GREEN; countdown = GREEN_TIME; } break; // ... 其余状态 } Display(countdown); // 动态扫描数码管 }状态机的写法决定了代码好不好改。把每个状态和对应的灯、倒计时初值写清楚，后面加「夜间黄灯闪烁」或者「紧急全红」就是加一个 case 的事。如果原工程把状态切换写成了一堆 if-else 嵌套，二次开发时会很痛苦，这也是判断一份代码质量的小技巧。
3.4 数码管动态扫描：倒计时怎么显示出来
倒计时显示靠动态扫描，本质是用人眼视觉暂留，快速轮流点亮每一位。常见是两位数码管显示秒数，P0 给段码，P2 给位选：
// display.c —— 两位数码管动态扫描 void Display(unsigned char num) { unsigned char tens = num / 10; unsigned char ones = num % 10; P0 = seg_code[tens]; // 段码表，共阴 P2 = 0xFE; // 选中十位（位选低有效） Delay_ms(2); // 保持 2ms P0 = 0x00; // 消影，防止重影 P0 = seg_code[ones]; P2 = 0xFD; // 选中个位 Delay_ms(2); P0 = 0x00; }seg_code是段码表，共阴和共阳的码表是反的，用错就是乱码。Delay_ms(2)的 2ms 是经验值，太短亮度不够，太长会闪。消影那一步很多人会漏，漏了就会出现「十位和个位叠在一起」的重影。这些细节在使用说明里不一定写全，但仿真跑起来一眼就能看出来。
4. 避坑与排查：仿真跑不起来时先看这几处
4.1 现象：上电后所有灯全灭，数码管也不亮
原因通常是电源或复位没接好，或者单片机根本没加载 hex。先确认 Proteus 里单片机的 VCC 和 GND 都接了，再看 Program File 是不是空的。还有一种情况是晶振没接，仿真里单片机没有时钟源，自然不跑。解决方式是补上电源、地和晶振，重新加载 hex 后运行。
4.2 现象：倒计时数字不动，但灯会切换
原因多半是定时器中断没进来，或者中断里没做倒计时递减。先查ET0和EA有没有置 1，再查中断服务函数里的重装初值有没有写。如果灯会切换说明主循环在跑，问题就锁定在中断这条线上。解决方式是单步调试或加一个 LED 翻转来确认中断是否触发。
4.3 现象：数码管显示乱码或重影
原因是段码表共阴共阳用反，或者动态扫描没消影。先确认仿真里数码管是共阴还是共阳，再对照代码里的seg_code表。重影则是扫描切换时没把段选清零。解决方式是统一共阴共阳属性，并在每次切换位选前加一句P0 = 0x00。
4.4 现象：紧急按键按下没反应
原因是按键接的口和代码里定义的不一致，或者中断优先级没配。紧急按键通常接外部中断，要确认IT0（触发方式）和EX0（使能）都设对了。还有一种情况是按键抖动导致误触发，需要加消抖。解决方式是对照仿真图确认端口，并在中断里加简单延时消抖。
4.5 现象：改了代码但仿真行为没变
原因是 hex 没重新编译或 Proteus 没重新加载。这是最高频的「假 bug」。解决方式是每次改完代码先重新编译，确认 hex 时间戳更新，再在 Proteus 里重新指向该文件。养成「改代码 → 编译 → 重载 hex → 运行」的固定顺序，能省掉大量无效排查。
5. 二次开发：改配时、加功能、做验证的几条实操思路
拿到这个工程后，真正有价值的是把它当成一个可改的底座。最常见的改造是调配时。原工程里绿灯、黄灯、红灯的时长通常是宏定义，比如#define GREEN_TIME 30。改这个值就能改配时，但要注意倒计时的显示位数——如果数码管只有两位，配时超过 99 就显示不下，得改成三位或者用其他方式表示。
加功能方面，比较实用的是「夜间模式」和「紧急全红」。夜间模式可以在主循环里加一个判断，到了某个时间段就让黄灯闪烁，其他灯灭。紧急全红则是把紧急按键接到外部中断，中断里直接把四个方向的红灯点亮、绿灯黄灯灭掉，退出中断后再恢复。这里有个坑：中断里改状态变量时要注意和主循环的竞争，简单做法是在中断里只置一个标志位，让主循环去处理。
// 紧急模式：中断里只置标志，主循环处理 volatile bit emergency_flag = 0; void EX0_ISR(void) interrupt 0 { Delay_ms(10); // 消抖 if (KEY_EMERGENCY == 0) { emergency_flag = 1; // 只置标志，不直接改灯 } } // 主循环里 if (emergency_flag) { EW_GREEN = 1; EW_YELLOW = 1; EW_RED = 0; NS_GREEN = 1; NS_YELLOW = 1; NS_RED = 0; // 等待再次按键或超时后清除标志 }验证改造是否成功，我一般用「现象对照法」：先列出预期现象，再逐条对照仿真。比如改了绿灯时长，预期是绿灯倒计时从新值开始递减，那就盯着数码管看第一秒是不是新值。改紧急模式，预期是按下后四向全红，那就按一下看是不是立刻全红、松开后能不能恢复。这种笨办法比盯着代码看有效得多。
还有一个容易被忽略的点是代码的可移植性。如果原工程把端口定义、定时参数、状态逻辑全塞在main.c里，改造时会很乱。我一般会先把端口定义抽到port.h，把定时参数抽到config.h，把状态机单独放一个文件。这样下次换一个单片机或者换一套仿真图，只需要改port.h和config.h，逻辑不用动。这个习惯是从一次「换个板子重写一遍代码」的教训里养成的，从那以后我每次拿到这类工程，第一件事就是看它的端口和参数有没有集中管理，没有就先抽出来再改。
希望这份拆解能帮你把这个交通灯控制器真正跑起来、改起来。
本文还有配套的精品资源，点击获取
