简介：这是一套面向嵌入式初学者与课程设计学生的智能交通灯控制器完整方案，基于Keil与Proteus联合开发，解决从程序编写到电路仿真验证的全流程需求。压缩包共17个文件，约86KB，包含C语言源码、Keil工程文件、Proteus仿真图、编译生成的hex与lst等中间文件，以及使用说明和成果问题记录等txt文档，覆盖代码、仿真与文档三类核心内容。系统支持正常、紧急与智能三种工作模式，通过按键切换，智能模式可依据车流量动态调整红绿灯时序，涉及嵌入式设计、C语言编程、交通流检测与实时控制等知识点。已有4701人学习下载，读者可据此完成程序编译、仿真运行与模式切换验证，并借助说明文档快速上手，适合作为课程设计或入门嵌入式项目的参考范例。
1. 从路口配时说起：这套智能交通灯控制器方案到底解决什么问题
做过路口信号配时的人都知道，十字路口最怕的不是车多，而是四个方向永远按固定秒数轮转——主干道空着绿灯还在亮，支路排到路口外却只能干等。这套智能交通灯控制器方案要解决的，就是让信号灯从“死循环”变成“按需分配”。它面向两类人：一类是要交单片机课程设计、嵌入式毕设的学生，需要一套能跑通、能仿真、能讲清楚原理的完整工程；另一类是做小型路口控制 Demo 的从业者，想拿一套现成的 Keil 工程加 Proteus 仿真图快速验证逻辑。方案的核心是一颗单片机做主控，配合车流检测输入、倒计时显示和信号灯输出，在 Proteus 里完成从电路到程序的联合调试，最后用 Keil 编译出可烧录的固件。整套东西不依赖真实路口，一台电脑就能把“感知—决策—执行”这条链路走完，这也是它适合拿来当课设和毕设的根本原因。
2. 需求拆解与技术选型：为什么是单片机加 Proteus 这条路
2.1 功能需求先立住，别急着画电路
拿到题目先别打开 Proteus 拖元件，先把需求写成能验收的条目。这套控制器的功能需求通常拆成四块：第一，四方向红黄绿三色灯按交通规则互锁，绝不允许出现东西绿灯和南北绿灯同时亮的“撞车相位”；第二，带倒计时数码管显示，让驾驶员知道还要等多久；第三，支持车流检测输入，用按键或传感器模拟车辆到达，实现“有车延长、无车跳转”的感应控制；第四，具备紧急模式，按下急停键后所有方向转红，给特种车辆让行。把这四条写进设计文档，后面电路和代码才有对照物。我一般会把这四条再细化成一张状态表，明确每个相位下六个灯（东西红黄绿、南北红黄绿）的电平，这张表就是后面写代码的唯一依据，也是答辩时最能说明问题的东西。
2.2 主控与外围器件的选型逻辑
主控选型上，这类题目最稳妥的是 51 系列单片机，原因很实在：I/O 口够用、资料多、Keil 支持成熟、Proteus 元件库里有现成模型，仿真不会因为找不到器件卡住。如果题目要求更高，可以换 STM32，但代价是 Proteus 仿真配置更麻烦，对初次做课设的人不友好。外围器件按功能配：信号灯用红黄绿 LED 各两组共六路，串限流电阻接 I/O；倒计时用两位共阴或共阳数码管，段选接一个端口、位选接另外两个 I/O；车流检测用按键模拟，一端接地一端接 I/O，配合内部或外部上拉；紧急按键单独占一个 I/O，最好接外部中断引脚，保证响应及时。选型时有个血泪经验：数码管共阴共阳一定要和代码里的段码表对上，否则仿真里显示的是乱码，很多人卡在这里以为是程序错了，其实是硬件属性选反了。
2.3 Proteus 仿真与 Keil 工程的配合方式
这套方案的工作流是 Keil 写代码、编译出 hex 文件，Proteus 里加载 hex 跑仿真。两者配合的关键是时钟频率要一致——Keil 工程里设的晶振频率必须和 Proteus 单片机属性里的频率相同，否则倒计时会快得离谱或慢得看不见。通常的做法是统一用 12MHz，定时器初值按这个频率算。仿真图里还要注意电源和地的连接，Proteus 不像实物板会自动共地，每个器件的 VCC 和 GND 都得显式接上，否则仿真跑起来灯不亮、数码管不显示，排查半天发现是没接地。下面这段是定时器初始化的核心代码，负责产生 1 秒的计时基准：
// 12MHz 晶振下，定时器0 产生 50ms 中断，20 次中断为 1 秒 void Timer0_Init(void) { TMOD &= 0xF0; // 清除定时器0的控制位 TMOD |= 0x01; // 定时器0 工作在模式1（16位定时） TH0 = 0x3C; // 50ms 初值高8位 TL0 = 0xB0; // 50ms 初值低8位 ET0 = 1; // 使能定时器0中断 EA = 1; // 开总中断 TR0 = 1; // 启动定时器0 }这段代码里 TH0、TL0 的初值是按 12MHz 晶振、50ms 定时算出来的，改晶振频率就必须重算这两个值，否则计时全乱。中断服务函数里用一个计数变量累加到 20 就置一秒标志位，主循环检测这个标志再递减倒计时。把计时和显示解耦，是这类程序不卡顿的关键，很多人把延时函数直接塞进主循环，结果按键响应迟钝、数码管闪烁，就是没做中断分层。
3. 总体架构设计：状态机、定时与显示三条主线
3.1 用有限状态机描述信号相位
信号灯控制最忌讳用一堆 if-else 堆出来，改一个相位要动全身。正确的做法是把它抽象成有限状态机：每个相位是一个状态，状态里定义六个灯的输出电平和持续时间，状态之间按固定顺序迁移，遇到紧急信号则强制跳到全红状态。下面是一个简化的状态定义：
// 相位枚举：东西绿、东西黄、南北绿、南北黄、全红 typedef enum { EW_GREEN, EW_YELLOW, NS_GREEN, NS_YELLOW, ALL_RED } PhaseState; // 每个相位对应的灯输出，位定义：bit0东西红 bit1东西黄 bit2东西绿 // bit3南北红 bit4南北黄 bit5南北绿 const unsigned char PhaseOutput[5] = { 0x24, // 东西绿(bit2) + 南北红(bit3) 0x14, // 东西黄(bit1) + 南北红(bit3) 0x21, // 南北绿(bit5) + 东西红(bit0) 0x11, // 南北黄(bit4) + 东西红(bit0) 0x09 // 全红(bit0 + bit3) };用查表法输出灯态，好处是相位逻辑集中在一张表里，改配时或加相位只动表不动流程。每个状态配一个持续时间变量，主循环里倒计时减到零就迁移到下一个状态。这种写法在答辩时特别好讲，评委一看就知道你懂状态机，而不是只会写流水账。
3.2 定时器中断与倒计时的分层
定时和显示必须分层，这是让仿真跑得稳的核心。定时器中断只做一件事：每 50ms 把计数变量加一，满 20 次置一秒标志。主循环负责读标志、减倒计时、切相位、刷新数码管。这样中断里代码极短，不会因为数码管刷新耗时导致计时不准。倒计时变量按相位独立维护，切换相位时重新赋初值。如果做感应控制，车流检测按键在中断或主循环里置一个“有车”标志，主循环判断当前是绿灯且该方向有车，就延长绿灯时间，延长上限设一个阈值防止一直延长。这套分层结构在 Proteus 里跑起来，数码管跳秒均匀、按键响应及时，不会出现仿真卡死。
3.3 数码管动态扫描与信号灯输出
数码管用动态扫描，两位分别显示当前相位剩余秒数。扫描频率要够高，通常 5ms 切换一位，人眼就看不到闪烁。段码表按共阴或共阳写好，位选用两个 I/O 轮流拉低。信号灯输出直接按 PhaseOutput 表把对应位置一或置零，注意 LED 是共阳接法还是共阴接法，决定输出高电平亮还是低电平亮。下面这段是动态扫描的骨架：
// 数码管动态扫描，seg_code 为段码表，digit 为位选 void Display_Scan(unsigned char tens, unsigned char units) { P2 = 0x00; // 消隐，防止拖影 P0 = seg_code[tens]; // 送十位段码 P2 = 0x01; // 选通十位 Delay_ms(5); // 保持5ms P2 = 0x00; // 消隐 P0 = seg_code[units]; // 送个位段码 P2 = 0x02; // 选通个位 Delay_ms(5); }消隐这一步不能省，否则两位数字会互相串扰，看起来像鬼影。段码表要和数码管共阴共阳属性匹配，这是前面提到的翻车高发区。信号灯输出和数码管扫描放在主循环不同分支，互不阻塞。
4. 关键模块实现：从车流检测到紧急优先的代码落地
4.1 车流检测与感应配时逻辑
车流检测用按键模拟，按下代表该方向有车到达。主循环里轮询按键状态，置对应方向的有车标志。感应配时的逻辑是：当前方向绿灯且检测到有车，就把该相位剩余时间重置为一个延长值，但总延长次数设上限，比如最多延长两次，防止一个方向车流不断导致另一方向饿死。这个上限值就是配时的公平性参数，通常设成基础绿灯时间的一半比较合理。代码上用一个延长计数变量控制：
// 感应延长：绿灯期间有车且未超延长上限，则重置倒计时 if (current_phase == EW_GREEN && ew_car_flag && extend_cnt < 2) { countdown = GREEN_EXTEND; // 重置为延长时长 extend_cnt++; // 延长次数累加 ew_car_flag = 0; // 清除本次车流标志 }延长上限这个参数是这套方案里最值得在文档里说明的设计点，它体现了“感应”和“公平”的权衡，答辩时能讲出这一层，分数不会低。
4.2 紧急模式的中断响应
紧急模式要求响应快，最好走外部中断。紧急按键接 INT0 或 INT1，下降沿触发，中断服务函数里直接把相位强制设为 ALL_RED，并置一个紧急标志，主循环检测到标志就暂停正常倒计时，只维持全红。紧急解除后再从全红状态按正常顺序恢复。这里有个坑：中断里不要做数码管刷新这类耗时操作，只置标志，刷新交给主循环。下面是对应的中断骨架：
// 外部中断0服务函数，紧急按键触发 void EX0_ISR(void) interrupt 0 { emergency_flag = 1; // 只置标志，不做耗时操作 current_phase = ALL_RED; // 强制全红 countdown = 0; // 倒计时清零 }中断里代码越短越好，这是嵌入式的基本纪律。紧急标志在主循环里被检测后，决定是否恢复自动配时。
4.3 相位切换与黄灯过渡处理
相位切换不能从绿灯直接跳红灯，中间必须有黄灯过渡，这是交通规则也是安全要求。实现上，绿灯倒计时结束后先切到黄灯状态，黄灯固定 3 秒，再切到下一方向的绿灯。黄灯时间在代码里做成常量，方便按路口实际情况调整。切换时要注意先关当前方向绿灯再开黄灯，避免瞬间两个灯同时亮。状态迁移的顺序写成固定序列，用状态变量驱动，不要用嵌套判断。这套过渡逻辑在 Proteus 里能清楚看到灯色变化，也是仿真验收时最直观的观察点。
5. 避坑与常见问题排查：仿真跑不通时先看这几条
5.1 数码管显示乱码或全亮
现象是数码管显示的不是预期数字，或者所有段全亮。原因通常是共阴共阳属性选反，或者段码表与硬件不匹配。解决方法是先确认 Proteus 里数码管型号的共阴共阳属性，再对照段码表逐位核对，必要时用单个数码管测试一位显示，确认段码正确后再做动态扫描。
5.2 倒计时速度明显不对
现象是倒计时跳秒太快或太慢。原因基本是 Keil 工程晶振频率和 Proteus 单片机属性频率不一致，或者定时器初值算错。解决方法是统一两边频率，重新按公式算 TH0、TL0 初值，并在中断里用示波器或计数变量验证 50ms 是否准确。
5.3 仿真运行后灯不亮
现象是加载 hex 后信号灯和数码管都没反应。原因多半是电源和地没接，或者单片机没有加载 hex 文件。解决方法是检查每个器件的 VCC、GND 是否显式连接，确认单片机属性里 Program File 指向了正确的 hex，必要时重新编译一次 Keil 工程。
5.4 按键无响应或响应迟钝
现象是按下车流检测或紧急按键没反应。原因是按键没加上拉、主循环被延时函数阻塞，或者中断没使能。解决方法是给按键加外部上拉电阻，把长延时改成定时器中断分层，检查 EA 和对应中断使能位是否打开。
5.5 相位切换时两个方向绿灯同时亮
现象是切换瞬间出现冲突相位。原因是切换代码里先开新灯后关旧灯，或者状态表输出有误。解决方法是严格按“先关后开”的顺序写切换逻辑，并逐条核对 PhaseOutput 表，确保任何状态下不会出现两个绿灯位同时为 1。
6. 验收与答辩：怎么证明这套控制器真的能用
验收这套方案，我一般分三步走。第一步是静态检查，把相位状态表和代码里的 PhaseOutput 数组逐条对照，确认六个灯在任何状态下都满足互锁，这一步不用跑仿真就能查出大部分逻辑错误。第二步是 Proteus 动态验收，按场景跑：正常配时看四方向轮转是否顺畅、倒计时是否均匀；感应场景按车流键看绿灯是否延长、延长是否封顶；紧急场景按急停键看是否立即全红、解除后是否正常恢复。每个场景记录观察结果，形成一张验收表：
| 验收项 | 操作 | 预期结果 | 实际结果 |
|---|---|---|---|
| 正常轮转 | 上电运行 | 四相位顺序切换，黄灯过渡 3 秒 | 待填 |
| 倒计时显示 | 观察数码管 | 秒数均匀递减，无闪烁 | 待填 |
| 感应延长 | 绿灯时按车流键 | 绿灯延长，最多两次 | 待填 |
| 紧急优先 | 任意时刻按急停 | 立即全红，解除后恢复 | 待填 |
| 互锁检查 | 全程观察 | 无冲突相位 | 待填 |
第三步是答辩准备，重点讲三件事：为什么用状态机而不是 if-else，感应延长的上限是怎么定的，紧急模式为什么走中断。这三个问题答清楚，基本能说明你理解了设计而不只是抄了代码。答辩时如果评委问“如果两个方向同时有车怎么办”，就答按相位顺序轮转加延长上限保证公平，这是配时的基本思路。
从那以后我每次做这类控制器方案，都强制先把相位状态表写出来再动代码，因为血泪经验告诉我，跳过这张表直接写程序，最后一定会在某个切换瞬间翻车。希望这套从需求到验收的完整思路，能帮你把课程设计或毕设稳稳落地，需要工程文件和仿真图的话，按资源里的说明获取即可。
本文还有配套的精品资源，点击获取
