简介：这份智能交通灯控制器资源面向嵌入式初学者、课程设计学生及参加电子竞赛的开发者，提供从程序编写到电路仿真的完整实践方案。包内共17个文件，约86KB，以Keil工程文件（uvproj、uvopt）、C语言源码（main.c）、编译产物（hex、M51、LST）以及Proteus仿真文件（DSN、DBK）为主，另附使用说明与成果问题记录等txt文档，覆盖代码编译、电路搭建与联合仿真的全流程。资源实现正常、紧急、智能三种工作模式，可通过按键切换，并依据车流量动态调整红绿灯时序，涉及嵌入式系统设计、C语言编程、交通流检测与实时控制等知识点。已有4701人学习下载，适合作为课程设计或自学参考，帮助读者在无实物硬件条件下完成程序验证与功能调试，快速掌握Keil与Proteus联合仿真的开发方法。
1. 从一次路口配时翻车说起：这套智能交通灯控制器到底能干什么
去年帮一个做嵌入式实训的朋友调一套交通灯控制器，路口四个方向，早晚高峰配时完全不对，绿灯空放、红灯排长队。他手里只有一份 Keil 工程和一张 Proteus 仿真图，代码能编译、仿真能跑，但没人讲得清状态机怎么切、配时怎么改。我花了两个晚上把源码从头到尾捋了一遍，才发现问题出在状态迁移的边界条件上——这类项目看着简单，真正上手改的时候，坑全藏在定时器中断和状态枚举里。
这套智能交通灯控制器就是干这个的：用单片机做主控，通过 Keil 写 C 程序，在 Proteus 里搭出完整的路口仿真电路，实现红绿灯的自动切换、倒计时显示、紧急模式切换。它适合三类人——正在做嵌入式课程设计的学生、想练手状态机编程的初学者、需要快速搭一个交通灯 Demo 做二次开发的工程师。你拿到的不只是代码，还有能直接跑的仿真图和一份使用说明，省去了从零画电路、配寄存器的功夫。
2. 技术选型与整体架构：为什么是 51 单片机 + Keil + Proteus 这套组合
2.1 主控与开发环境的选择逻辑
这套项目的主控用的是经典 8051 内核单片机（常见型号如 AT89C51/AT89C52），开发环境是 Keil μVision，仿真平台是 Proteus。这个组合在嵌入式教学和快速验证场景里几乎是标配，原因很实际：51 单片机的寄存器结构简单、资料多，Keil C51 编译器成熟稳定，Proteus 能直接加载 Keil 生成的 HEX 文件做软硬件联合仿真，不需要真实硬件就能看到灯亮灯灭、数码管跳数。
从工程角度看，交通灯控制器的核心逻辑并不复杂，本质是一个带定时约束的状态机。用 51 单片机完全够用，I/O 口直接驱动 LED 和数码管，定时器产生秒级时基，中断服务程序里做倒计时递减。如果换成 STM32 当然性能更强，但对于一个教学级 Demo 来说属于杀鸡用牛刀，反而增加了初学者的上手门槛。
常见做法是：系统时钟用 12MHz 晶振，定时器 T0 工作在模式 1（16 位定时），每 50ms 产生一次中断，中断里对一个计数变量累加，满 20 次就是 1 秒。这样做的目的是把秒级时基和状态切换解耦，主循环只负责状态判断和 I/O 输出，时间精度交给中断保证。
2.2 仿真电路的模块划分
Proteus 仿真图里通常包含这几个功能块：
| 模块 | 器件 | 作用 |
|---|---|---|
| 主控 | AT89C51/52 | 运行程序，输出控制信号 |
| 交通灯 | 红黄绿 LED 各两组 | 模拟东西、南北方向信号灯 |
| 倒计时显示 | 两位共阳/共阴数码管 | 显示当前方向剩余秒数 |
| 时钟电路 | 12MHz 晶振 + 两个 30pF 电容 | 提供系统时钟 |
| 复位电路 | 10μF 电容 + 10kΩ 电阻 | 上电复位 |
| 紧急按键 | 轻触开关 | 触发紧急模式 |
电路连接上，P1 口一般分配给 LED 灯组，P0 或 P2 口驱动数码管段选和位选。数码管如果直接用 I/O 口驱动，需要加限流电阻，否则仿真里可能出现亮度异常或电流过大警告。Proteus 的好处是这些细节都能在仿真里直观看到，改一个电阻值立刻能看到效果。
2.3 软件架构：状态机 + 定时中断的双层结构
程序整体分两层：底层是定时器中断，负责产生精确的秒级时基；上层是主循环里的状态机，负责根据当前状态和剩余时间决定下一步动作。状态定义通常用枚举：
// 交通灯状态枚举 typedef enum { EW_GREEN, // 东西绿灯，南北红灯 EW_YELLOW, // 东西黄灯，南北红灯 NS_GREEN, // 南北绿灯，东西红灯 NS_YELLOW, // 南北黄灯，东西红灯 EMERGENCY // 紧急模式，全红或黄闪 } TrafficState;每个状态对应一组固定的 I/O 输出和持续时间。主循环里不断检查当前状态的剩余时间，减到 0 就切换到下一个状态。这种写法逻辑清晰，改配时只需要改每个状态的初始时间常量，不用动状态迁移的代码。
注意：状态枚举的顺序要和切换逻辑严格对应，否则会出现黄灯直接跳绿灯这种不符合交规的情况。我见过有人把 EW_YELLOW 和 NS_GREEN 的顺序写反，仿真里看着灯在闪，实际逻辑是错的。
3. 核心代码逐段拆解：定时器、状态机与数码管驱动
3.1 定时器初始化与秒级时基生成
定时器是整个系统的心跳。下面这段代码用 T0 产生 50ms 中断，累计 20 次得到 1 秒：
#include <reg52.h> unsigned char tick_count = 0; // 50ms 中断计数 unsigned char seconds = 0; // 秒级时基 // 定时器0初始化，50ms@12MHz void Timer0_Init(void) { TMOD &= 0xF0; // 清除T0控制位 TMOD |= 0x01; // T0工作模式1，16位定时 TH0 = (65536 - 50000) / 256; // 高8位初值 TL0 = (65536 - 50000) % 256; // 低8位初值 ET0 = 1; // 使能T0中断 EA = 1; // 开总中断 TR0 = 1; // 启动T0 } // T0中断服务程序 void Timer0_ISR(void) interrupt 1 { TH0 = (65536 - 50000) / 256; // 重装初值 TL0 = (65536 - 50000) % 256; tick_count++; if (tick_count >= 20) { // 50ms * 20 = 1s tick_count = 0; seconds++; // 秒计数递增 } }这段代码的关键参数是定时初值。12MHz 晶振下，一个机器周期是 1μs，16 位定时器最大计数值 65536，要产生 50ms 定时就需要装入 65536 - 50000 = 15536。TH0 和 TL0 分别装高 8 位和低 8 位。中断里必须重新装初值，因为模式 1 不是自动重载的。tick_count累加到 20 就代表过了 1 秒，seconds变量供主循环读取。
常见错误是忘记重装初值，结果中断只触发一次就再也不进了。还有一种情况是晶振频率设错，比如 Proteus 里默认是 12MHz 但代码按 11.0592MHz 算，倒计时会明显偏快或偏慢。
3.2 状态机主循环与配时切换
主循环负责读取seconds，判断当前状态是否该切换：
#define EW_GREEN_TIME 30 // 东西绿灯30秒 #define EW_YELLOW_TIME 3 // 东西黄灯3秒 #define NS_GREEN_TIME 25 // 南北绿灯25秒 #define NS_YELLOW_TIME 3 // 南北黄灯3秒 TrafficState state = EW_GREEN; unsigned char remain = EW_GREEN_TIME; void main(void) { Timer0_Init(); while (1) { if (seconds > 0) { // 每秒处理一次 seconds = 0; if (remain > 0) { remain--; // 倒计时递减 } if (remain == 0) { state = NextState(state); // 切换状态 remain = StateDuration(state); } UpdateOutput(state, remain); // 刷新I/O } } } // 状态迁移函数 TrafficState NextState(TrafficState cur) { switch (cur) { case EW_GREEN: return EW_YELLOW; case EW_YELLOW: return NS_GREEN; case NS_GREEN: return NS_YELLOW; case NS_YELLOW: return EW_GREEN; default: return EW_GREEN; } }这里把配时参数抽成宏定义，改时间只需要改这几个常量。NextState函数用 switch 实现环形迁移，逻辑一目了然。remain变量记录当前状态剩余秒数，减到 0 就切换。UpdateOutput负责根据状态和剩余时间刷新 LED 和数码管。
提示：
seconds变量在中断里递增、在主循环里清零，存在竞态风险。51 单片机是 8 位机，对unsigned char的读写是原子的，所以这里不会出问题。但如果换成 16 位的int，就需要在读写时关中断保护。
3.3 数码管动态扫描与倒计时显示
数码管显示用动态扫描，两位分别显示十位和个位：
// 共阳数码管段码表，0-9 unsigned char code seg_code[] = { 0xC0, 0xF9, 0xA4, 0xB0, 0x99, 0x92, 0x82, 0xF8, 0x80, 0x90 }; // 动态扫描显示倒计时 void DisplayNumber(unsigned char num) { unsigned char tens = num / 10; unsigned char ones = num % 10; // 显示十位 P2 = 0xFE; // 位选：选中第一位 P0 = seg_code[tens]; // 段选：输出十位段码 DelayMs(2); // 保持2ms // 显示个位 P2 = 0xFD; // 位选：选中第二位 P0 = seg_code[ones]; // 段选：输出个位段码 DelayMs(2); // 保持2ms }动态扫描的原理是利用人眼视觉暂留，两位数码管轮流点亮，每位的点亮时间约 2ms，刷新频率足够高就不会看到闪烁。seg_code数组存的是共阳数码管的段码，如果要换成共阴数码管，需要把数组值按位取反。位选通过 P2 口控制，段选通过 P0 口输出。
常见问题是扫描频率太低导致闪烁，或者段码表搞错导致显示乱码。Proteus 仿真里数码管有共阳和共阴两种型号，选错了显示效果完全不对。我一般会在代码里留一个宏开关，方便切换。
4. 从 Keil 到 Proteus：完整跑通流程与避坑记录
4.1 Keil 工程编译与 HEX 文件生成
拿到源码后，第一步是在 Keil 里打开工程文件（.uvproj 或 .uvprojx），确认目标器件型号和实际使用的一致。然后检查晶振频率设置，在 Options for Target → Target 标签页里，Xtal 频率要填 12MHz，和 Proteus 仿真图里的晶振保持一致。
编译前确认输出 HEX 文件已勾选：Options for Target → Output → Create HEX File。点击 Build 后，如果代码没有语法错误，会在工程目录下生成 .hex 文件。常见的编译错误包括头文件路径不对、寄存器名拼写错误、中断号写错。比如interrupt 1对应定时器 0，写成interrupt 0就是外部中断 0，程序行为完全不对。
编译通过后，记下 HEX 文件的路径，下一步在 Proteus 里加载。
4.2 Proteus 仿真图加载与运行
打开 Proteus 仿真图（.dsn 文件），双击单片机元件，在 Program File 栏里选择刚才生成的 HEX 文件，Clock Frequency 填 12MHz。确认后点击左下角的运行按钮，仿真开始。
如果灯不亮或者数码管不显示，按这个顺序排查：先看电源和地有没有接、再看晶振和复位电路、最后检查 I/O 口连接。Proteus 里元件引脚是灰色表示未连接，蓝色表示低电平，红色表示高电平，通过颜色能快速定位问题。
仿真运行后，观察交通灯切换是否符合预期。如果切换太快或太慢，检查定时器初值和晶振频率是否匹配。如果某个方向灯一直不亮，检查对应的 I/O 口是否被其他功能占用。
4.3 避坑记录：5 个我踩过的坑
现象一：仿真里灯全亮或全灭，不受程序控制。原因：单片机没有正确加载 HEX 文件，或者复位电路一直处于复位状态。 解决：双击单片机确认 Program File 路径正确，检查复位电路电容和电阻值，确保上电后复位引脚能回到高电平。
现象二：倒计时数码管显示乱码或缺段。原因：段码表和数码管类型不匹配，共阳代码用在共阴数码管上。 解决：确认 Proteus 里数码管型号，共阳用 0xC0 开头，共阴用按位取反后的值。也可以直接在仿真里换一个数码管型号试。
现象三：交通灯切换时间明显偏快或偏慢。原因：Keil 工程里设置的晶振频率和 Proteus 里不一致，或者定时器初值算错。 解决：两边都设为 12MHz，重新计算定时初值。50ms 对应 50000 个机器周期，初值 65536 - 50000 = 15536。
现象四：编译通过但仿真没反应，程序像卡死。原因：主循环里某个 while 等待没有退出条件，或者中断没有正确使能。 解决：检查EA和ET0是否置 1，检查主循环里有没有死循环。可以在关键位置加 I/O 翻转语句，用示波器或 LED 观察程序是否在跑。
现象五：紧急按键按下后无法恢复。原因：紧急模式的状态迁移没有写回正常状态的路径。 解决：在紧急模式里检测按键释放，释放后根据当前时间重新进入对应的正常状态，而不是直接跳回固定状态。
5. 二次开发改造：从固定配时到感应控制的升级思路
这套项目的默认版本是固定配时，每个方向的绿灯时间写死在宏定义里。实际路口更常见的是感应控制——根据车流量动态调整配时。如果你要在这个基础上做二次开发，最值得改的就是配时策略。
改造思路是引入一个简单的车流量检测接口。可以用两个按键模拟东西、南北方向的车检信号，在定时器中断里对按键状态采样，统计单位时间内的脉冲数作为车流量指标。然后修改StateDuration函数，让绿灯时间根据车流量在最小值和最大值之间浮动：
#define MIN_GREEN 15 // 最小绿灯时间 #define MAX_GREEN 45 // 最大绿灯时间 // 根据车流量计算绿灯时长 unsigned char CalcGreenTime(unsigned char flow) { unsigned char t = MIN_GREEN + flow * 3; if (t > MAX_GREEN) t = MAX_GREEN; return t; }flow变量由车检中断累加，主循环切换状态时读取。这样车多的方向绿灯自动延长，车少的方向缩短，比固定配时更贴近真实场景。
另一个改造方向是加入夜间模式。用定时器记录运行时长，或者加一个光敏电阻接口，当环境光低于阈值时切换到黄闪模式，只保留黄灯闪烁提醒。这个改动涉及 I/O 扩展和状态机新增分支，适合练手。
验证改造效果时，我习惯在 Proteus 里加一个虚拟示波器，观察状态切换的时序波形。把每个状态的持续时间用 I/O 口翻转表示，示波器上能直观看到配时变化。改完配时逻辑后，先跑一遍完整周期，确认没有状态卡死或跳变异常，再测边界条件——比如车流量突然增大到超过最大值时，绿灯时间是否被正确限制在 MAX_GREEN。
从那以后我每次改状态机代码，都强制走一遍「全状态遍历 + 边界值测试」，不管项目多小。交通灯这种逻辑看着简单，但状态迁移的边界条件最容易翻车，少测一个分支就可能出现两个方向同时绿灯的致命 bug。希望这套代码和仿真图能帮你少走点弯路，把时间花在真正值得琢磨的配时策略上。
本文还有配套的精品资源，点击获取
