我先把话说在前头：无论你是做毕业设计、课程设计，还是单纯想拿一块STM32开发板练手做点带传感器、带按键、带显示的完整小系统，“基于STM32的智能交通灯管理系统”这个题目都是性价比极高的选择。它不像纯点灯那样无聊，又比做四轴飞控、织网机器人那种动不动就翻车的项目友好得多——麻雀虽小，五脏俱全，做完之后你对GPIO控制、定时器中断、外部中断、数字逻辑状态机、传感器信号处理这些嵌入式基本功都会有一个非常扎实的掌握。

平时开车等红灯的时候，你会发现路口的红绿灯有两种：一种是傻乎乎固定配时，高峰期照样让你空等；另一种是“聪明”灯，车多方向绿灯时间自动拉长，没有车的方向能快速放行。咱们这次要做的，就是把后面这套逻辑在STM32上完整落地。文章会从需求拆解开始，把硬件选型、电路设计、软件状态机、常见坑点全部过一遍，即使你手里的板子是几十块钱的STM32F103C8T6最小系统板，也能照着重现。

1. 系统需求拆解与总体设计思路

1.1 智能交通灯到底“智能”在哪里

最简单的红绿灯控制逻辑，一个51单片机、三组LED、写死几个delay就搞定了，为什么要专门做一套带“STM32”、“管理”、“系统”字眼的设计？因为真实路口的交通灯控制系统，至少要处理下面几类需求：

• 基础倒计时显示：南北、东西两个方向的红绿灯按设定配时交替切换，同时用数码管或OLED显示剩余秒数。
• 紧急车辆优先：当救护车、消防车需要通过时，按下紧急按钮，系统强制把当前放行方向切到绿灯，让特种车辆快速通过，疏散后恢复原有配时。
• 车流量感应：在支路安置红外对射或地磁传感器，检测支路是否有车等待。主路有车、支路没车时，主路保持绿灯；支路来车达到一定数量或等待时间后，支路切换为绿灯。
• 夜间模式：深夜车流稀少，不需要完整的红绿灯周期，可以进入黄灯闪烁状态或缩短各相位时间。
• 参数可调：不同路口车流量差异很大，红绿灯时长不应该写死在代码里，而是可以通过按键调整并存储。

把这些需求写成一个功能清单，就非常清晰了：

也就是说，“智能”的核心在于系统必须有多输入（传感器、按键）、多输出（红绿灯、显示）和可切换运行策略，而不是一条路走到死的固定时序。

1.2 为什么选择STM32F103C8T6作为主控

很多人在选题时会纠结：用51单片机不行吗？用Arduino不行吗？我认真说一句：51能跑，但跑得很吃力；Arduino能跑，但做完之后你对底层的理解非常浅；而STM32正好卡在“性能充裕”和“资料丰富”的黄金交叉点上。

• 性能充裕：STM32F103C8T6是Cortex-M3内核，72MHz主频、64KB Flash、20KB RAM。跑一个交通灯状态机加上数码管刷新，CPU占用率不到5%，剩下的资源足够你折腾RTOS、加OLED动画、做串口上位机监控。
• 外设匹配：这个题目需要定时器做精准计时（TIM定时器）、外部中断处理紧急按键（EXTI）、PWM模拟或GPIO直控灯组、I2C/SPI驱动OLED、ADC读取传感器或电位器。STM32F103这些外设全都标配，每个都能踩到点子上。
• 生态成熟：学习资料铺天盖地，无论是标准外设库、HAL库还是LL库，网上都有完整例程。真遇到问题，搜个报错信息都比冷门单片机容易十倍。

这里再补充一句选型细节：F103C8T6是LQFP48封装，RAM/Flash在同系列里属于“低配”，但对交通灯这种应用绰绰有余。如果你后续想加GUI（比如用LVGL跑一块屏幕），建议直接上F103RCT6（256KB Flash）或者F407系列。不过作为课程设计/毕设，C8T6能吃得很饱。

1.3 系统整体架构与信息流

做嵌入式项目，写代码之前先在脑子里把“数据从哪来、往哪去、怎么处理”这一条链路理清楚，比直接打开Keil堆代码重要得多。这个系统的信息流其实很直接：

输入部分：

• 4个按键：模式切换、紧急优先、参数增加、参数减少
• 红外传感器（可扩展2~3路）：检测特定方向是否来车
• 调试串口：接收上位机指令，或向上位机发送状态信息

核心处理：

• 状态机调度：维护当前路口放行相位、剩余时间、下一相位切换
• 运行模式切换：普通模式、紧急模式、夜间模式、参数设置模式
• 计时与延时：所有状态切换必须由定时器中断驱动，不允许用阻塞式delay

输出部分：

• 南北方向3组LED（红黄绿） + 东西方向3组LED（红黄绿）
• 数码管倒计时显示（或OLED）
• 蜂鸣器提示（紧急模式切换时发声）
• 串口日志输出

我把这部门放到后面软件部分细说，这里先让你有个概念：这个项目的复杂度不在某一个点上，而在于各个模块之间怎么协同工作。比如你在主循环里用delay延时，紧急模式按键来了根本响应不了，这就是典型的协同失败。正确姿势是把时间基准交给定时器中断，主循环只负责“决策”，不负责“数数”。

2. 硬件电路设计与关键元器件计算

2.1 GPIO口分配原则与LED驱动电路

STM32F103C8T6虽然有37个GPIO，但不是每个都能随便用。有些引脚默认功能会干扰调试下载（比如PA13/PA14/PA15、PB3/PB4这5个脚是JTAG/SWD复用引脚），所以分配引脚时第一时间把这些排除掉。以下是常见的可用引脚分配表，供参考：

如果你没有用数码管而是用OLED显示倒计时，那么PB口只占用两个I2C引脚就够了，富余的GPIO可以接蜂鸣器、传感器电源控制等。

LED驱动的电路设计值得多说两句。STM32 GPIO在推挽输出模式下，单脚最大输出电流大约±25mA，但芯片整体功耗有限，直接从引脚灌电流点亮LED虽然能亮，却不专业——尤其是灯组变为“控制外部灯板”时，GPIO直接驱动继电器或大功率LED完全带不动。

推荐的做法是GPIO接三极管（S8050）或MOS管做开关驱动，示例如下：

// LED驱动管脚初始化（标准外设库写法） GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; // 推挽输出 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; // LED属于低频器件，2MHz足够 GPIO_Init(GPIOA, &GPIO_InitStructure);

电机驱动方面，如果只是演示用5V小灯珠，一根导线串个220Ω限流电阻接到GPIO也行。但做管理系统的实物演示时，建议还是用ULN2003达林顿管阵列来驱动220V交流信号灯——GPIO输出高电平给ULN2003输入端，输出端接继电器线圈或双向可控硅，实现弱电控制强电的隔离效果。安全第一，220V部分一定要隔离，实验时优先用LED灯板做模拟。

2.2 电源电路与复位/启动配置

STM32F103C8T6最小系统板一般自带USB转串口和AMS1117-3.3V稳压，供电用USB 5V就行。但完整的管理系统设计中，如果加入了多个传感器、数码管、蜂鸣器、继电器，5V外设和3.3V系统必须分开供电，并在电源入口做好滤波。

这里给出一个稳妥的电源方案：

• 输入：DC 5V / 2A适配器或USB供电
• 3.3V：AMS1117-3.3线性稳压，输入输出各接10μF+100nF电容滤波
• 5V外设：直接从输入5V取电，LED灯板、蜂鸣器、红外传感器电源统一从这里拉
• 关键点：STM32的VDD每个引脚旁边加100nF去耦电容，VCAP引脚接2.2μF钽电容

如果你用的是带板载稳压的最小系统板，这步可以跳读，但外设供电不能偷懒，否则数码管刷新时电压一跌，RGB灯就开始乱跳、红外误触发，排查起来比改代码还痛苦。

2.3 传感器与按键输入电路

红外对射传感器模块是交通灯车流量检测中最常见的选型。它的原理很简单：发射管持续发射红外光，接收管一直导通，输出低电平；当车辆挡住光线时，接收管截止，输出高电平。模块自带LM393比较器调阈值，直接输出TTL电平给STM32的GPIO读取即可。接线就三根：VCC、GND、OUT。

按键部分有两种接法：外部中断触发和GPIO轮询扫描。紧急优先按键必须用外部中断（EXTI），因为它在理论上随时可能被按下，如果主循环刚好在数码管刷新、串口打印，轮询就会错过毫秒级的按键时间；普通模式切换和参数加减按键放在主循环里扫描就够了，没必要浪费中断资源。

按键硬件上一定要做消抖，可别指望软件delay(10)能包治百病。推荐的做法是RC硬件消抖（10kΩ上拉电阻+100nF电容到地），再配合软件10ms稳定判断。如果只用软件消抖，在按键触点氧化后还是会偶发抖动漏判。

3. 系统软件核心逻辑与实现步骤

3.1 状态机建模：交通灯逻辑的灵魂

智能交通灯控制逻辑，本质就是一个有限状态机（FSM）。这一点我会不厌其烦地强调，因为这是整套软件最值得学习的地方。

先定义相位状态：

typedef enum { STATE_NORTH_GREEN, // 南北绿灯，东西红灯 STATE_NORTH_YELLOW, // 南北黄灯，东西红灯 STATE_EAST_GREEN, // 东西绿灯，南北红灯 STATE_EAST_YELLOW, // 东西黄灯，南北红灯 STATE_ALL_YELLOW_BLINK, // 夜间黄闪模式 STATE_EMERGENCY_CLEAR // 紧急模式专用状态 } TrafficState;

普通白天模式下，状态流转是：

南北绿灯(30s) → 南北黄灯(3s) → 东西绿灯(30s) → 东西黄灯(3s) → 回到南北绿灯

看起来非常简单，但这里藏着第一个大坑：绿灯和黄灯之间，必须存在一个所有方向都为红灯的间隔时间。真实路口在绿灯切换红绿之前会有“全红时间”，确保交叉路口的车辆和行人清空，这个时间通常1~3秒。很多课程设计的交通灯都没有做这个，从美观上没问题，从合理性上一眼就会被答辩老师问倒。

为此，状态机里需要加入过渡状态，我建议这样设计：

南北绿灯 → 南北绿灯闪3秒（提示即将变灯） → 南北黄灯(3s) → 全红(2s) → 东西绿灯 → ...

如果觉得状态太多不好管理，也可以在状态结构体里面通过事件驱动完成。核心思路是：每个状态有进入时要执行的GPIO输出动作、有持续的时间、到了时间就跳到下一个状态。

典型的实现方式：

#define T_GREEN_N_S 30 // 南北绿灯时间，可按键调整 #define T_YELLOW 3 // 黄灯时间 #define T_ALL_RED 2 // 全红时间 typedef struct { TrafficState state; uint16_t counter; // 剩余时间计数 } TrafficFSM;

在定时器中断中每秒减1，减到0就触发状态切换；在主循环中检测切换标志并执行输出更新。

3.2 精准计时：用定时器中断替代delay

很多新手习惯这样写：GPIO拉高→delay(30000)→GPIO拉低→delay(20000)，最后做出来的系统一旦有按键或传感器介入就全线崩溃。智能交通灯管理系统里，我不会让任何核心逻辑跑在阻塞式delay上。

用SysTick或者TIM2作为时间基准，每1ms进入一次中断，软件计数器累加：

volatile uint32_t tick_ms = 0; void SysTick_Handler(void) { tick_ms++; }

然后代码里需要一个非阻塞延时判断工具函数：

uint8_t WaitMs(uint32_t *last_tick, uint32_t interval) { if (tick_ms - *last_tick >= interval) { *last_tick = tick_ms; return 1; // 时间到了，返回1 } return 0; }

这里千万不要用if (tick_ms == target)这种写法，因为中断和主循环并不同步，极易漏掉跳变。用“差值>=目标”的方式，只要tick_ms是单调递增的，就算偶尔被其他中断卡住，也不会丢时间。这种思路在RTOS的vTaskDelay底层也是这么实现的。

另外提示一下，STM32F103的SysTick在标准外设库中是SysTick_Config(SystemCoreClock / 1000)，在HAL库里是HAL_SYSTICK_Config()，它本身就是为操作系统时钟节拍设计的，拿来做毫秒基准再合适不过。

3.3 车流量感应与自适应配时逻辑

传感器检测部分其实不复杂，复杂的是“检测到信号之后，系统要怎么决策”。这里我分享一套比较实用的方案，不用上什么复杂AI算法，纯逻辑就能在答辩时讲清楚。

在支路上放两路红外传感器：一路靠近路口（停止线前），一路再往后几米（停车排队区）。当主路绿灯放行时，如果支路停止线前有车（第一路传感器持续被挡住超过2秒），说明这位车主等了一个周期，系统应该在下一轮把支路放行时间延长。如果两路都被占满，说明车流量很大，支路绿灯时间直接拉满到最大值。

实现逻辑可以这样写：

typedef struct { uint8_t sensor_stopline; // 停止线前传感器状态 uint8_t sensor_queue; // 排队区传感器状态 uint16_t waiting_seconds; // 支路等待时间计数 } BranchDetector;

主循环里每秒更新一次等待计数，如果支路检测到车而本方向是红灯，waiting_seconds++。当主路绿灯周期结束时，检查这个值：

• waiting_seconds >= 15或者sensor_queue为高 → 支路绿灯时间设为基础时间的1.5倍
• 否则 → 支路绿灯按基础时间执行

这玩意儿叫“基于车辆到达检测的感应控制”，专业上属于自适应交通控制里最朴素的实现。但你别小看它，运到现场，它的效率就已经能比固定配时提升不少了。

3.4 紧急模式与夜间模式切换细节

紧急车辆优先功能在嵌入式实现上最需要照顾的是“模式恢复”逻辑。按下紧急按键后，系统要尽快让当前路口变成放行状态，但不能直接一步跳绿——如果当前方向正好是绿灯，没问题；如果当前方向是红灯，直接切绿就会造成交叉方向刚起步的车和紧急车辆相撞。

我的实现办法是设置一个紧急模式标志，然后让状态机在到达安全切换点时再强制跳转：

void Emergency_Trigger(void) { emergency_flag = 1; } void Traffic_FSM_Tick(void) { if (emergency_flag) { // 等当前周期到达全红间隔状态后，直接进入南北绿灯放行 if (fsm.state == STATE_ALL_RED) { fsm.state = STATE_NORTH_GREEN; fsm.counter = T_EMERGENCY_GREEN; // 比如30秒 emergency_flag = 0; } } }

夜间模式的切换就更直白了：按键或者定时判断（比如晚上22点到早上6点）把状态机切到黄闪状态。黄闪的准确含义是“该方向允许通过但需观察”——通常主干道保持黄闪或者支路红闪，具体规则各路口不同，代码里只需要让两组黄灯以1Hz频率交替闪烁即可。

3.5 OLED倒计时显示驱动

用OLED来显示倒计时，图形比数码管灵活得多，而且接线比数码管省脚位。SSD1306驱动的0.96寸OLED，I2C接口只要两个引脚。

初始化部分用标准库操作是这样的：

I2C_InitTypeDef I2C_InitStructure; RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // I2C必须开漏 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure);

显示刷新时注意，不要把整个屏幕全部重绘。倒计时数字每秒变化，只需将上一秒数字所在的区域清掉，用DrawRectangle填充背景色，再在新位置画当前数字。否则每秒钟全屏刷新会占用大量CPU时间，导致其他逻辑调度被卡顿。

4. 调试记录与常见问题排查

调试过程是整个项目里最“养人”的阶段。我把自己在实际做这套系统时踩过的几个典型坑拿出来分享，这些问题你在做的时候很可能也会遇到。

4.1 定时器中断里别做“重活”

刚写完系统时，我把数码管刷新函数直接放在了定时器中断服务函数里，结果主循环里的按键扫描经常失灵。查了很久，用示波器测量发现中断执行时间已经超过了1ms的周期，中断没退出，主循环根本没机会跑。

解决办法很简单：中断里只做标记和计数，把耗时操作（比如OLED刷屏、状态机切换）全部放到主循环中执行：

volatile uint8_t fsm_tick_flag = 0; void SysTick_Handler(void) { tick_ms++; if (tick_ms % 1000 == 0) { fsm_tick_flag = 1; // 每秒置位一次，主循环处理 } } int main(void) { while (1) { if (fsm_tick_flag) { fsm_tick_flag = 0; Traffic_FSM_Tick(); // 状态机切换 OLED_DisplayTime(remain_sec); } Key_Scan(); Sensor_Update(); } }

4.2 红外传感器误触发与供电噪声

第一次接入红外模块时，发现它在数码管切换的瞬间频繁误触发。用万用表一量，5V电源在数码管段选跳变的瞬间有接近0.5V的跌落噪声，红外模块供电被污染了。

解决办法做了三层：一是红外模块的电源和数码管电源分开走线，物理隔离；二是在模块VCC-GND之间并一个100μF电解电容+104陶瓷电容；三是软件上增加连续有效性判断，传感器信号需要连续保持20ms以上才确认有效，有效后还需要“去抖锁定”100ms，防止同一辆车被重复计数。

4.3 GPIO引脚复用冲突

这是一个典型的入门级翻车现场。我用PA9和PA10做串口，同时又把按键接在PA10上，结果焊好板子发现按键按下时串口会乱码——因为PA10默认是USART1_RX，你灌信号进去，串口接收缓冲区全是垃圾。

所以分配引脚时，如果你要用串口调试，就优先避开USART引脚；如果必须复用，需要在代码初始化时先GPIO_PinRemapConfig或明确切换复用功能。做硬件前，先画一张引脚分配表，把每个GPIO的功能、默认复用、占用情况列清楚，能省很多事。

4.4 Keil工程配置与下载问题

接着说说开发环境。无论你用标准外设库还是CubeMX+HAL库，Keil MDK里都容易踩几个坑：

芯片型号选错：新建工程时如果没选对STM32F103C8，编译链接时会出现Flash Download Failed或烧录成功后不运行。C8T6的RAM是20KB，Flash是64KB，在Target选项卡里要对应设置，否则编译器按大容量芯片分配内存，越界了也不知道。

下载器识别不到：用ST-LINK下载时要确保驱动安装正确；如果用的是“ST-Link V2”山寨版，连接时降低速度到1MHz，稳定很多。

头文件路径缺失：标准外设库移植到新工程时，最容易报一堆error: #5: cannot open source input file "stm32f10x.h"，就是没把Libraries/CMSIS/CM3/DeviceSupport/ST/STM32F10x和Libraries/STM32F10x_StdPeriph_Driver/inc加入Include Paths。这个错误我见过无数人问，包括我自己当年也卡过。

4.5 参数掉电保存的坑

系统里的绿灯时长参数修改后，如果直接断电，重启又要重新设置。要把参数保存到EEPROM里，STM32F103C8T6内部没有真正的EEPROM，但在Flash最后几页预留了模拟EEPROM空间。也可以外挂AT24C02，但这样硬件多一块芯片。

我这里推荐一个更轻量的办法：使用内部Flash最后一个扇区存储参数，注意擦除时应先备份当前扇区未修改的数据，防止整片擦掉后参数丢失。精简版的保存代码如下：

// 假设把参数存在Flash最后一页, 先擦除再写入 uint32_t addr = 0x0800FC00; // 根据Flash大小调整 FLASH_Unlock(); FLASH_ErasePage(addr); FLASH_ProgramWord(addr, (uint32_t)config_data); FLASH_Lock();

如果不想碰Flash操作，至少要加一段参数RAM保护，开机时检测按键，只有按下“设置键”时允许修改，防止误触导致配置漂移。

4.6 常见问题速查表

5. 扩展思考：这套系统还能怎么升级

到这里，基于STM32的智能交通灯管理系统主体部分就算做完了。不过它只是起点。做完这个项目之后，如果把底层逻辑吃透了，往上叠加的东西其实非常多：

• 通信组网：用ESP8266或SIM800模块，把路口各方向的车流量及当前灯态上报到MQTT服务器，就能做成“城市路口云监控系统”——在Web端画一个大屏，每一路口的红绿灯状态实时显示。这个扩展方向很受毕业设计、物联网竞赛欢迎。
• 多路口协调：主干道上连续三四个路口，如果每个路口独立运行，车速稍微快点就会连续吃红灯。如果让相邻路口通过LoRa或RS485通信共享配时信息，实现“绿波带”协调控制，那技术含量直接上了一个台阶。
• AI流量预测：把过去的车流量数据存下来，用简单的时间序列预测算法（比如移动平均、最小二乘拟合法）预测下一个小时的车流量，动态调节配时。这个不是嘴上说说，用STM32跑个简单线性回归模型完全可行，RAM和Flash都够用。
• 可视化上位机：用Qt或Python写一个串口上位机，实时展示路口状态。这样调试时不需要一直盯着OLED或开发板看，电脑屏幕上直接数红灯秒数，效率会高出不少。

不过要提醒一句：扩展的每一步都会引入新的复杂度，如果时间紧、又是第一次做STM32项目，先老老实实把红绿灯状态机跑顺，把掉电存储、紧急模式这些基础功能做扎实，再谈扩展。项目做出来的高度，不在于功能数量多，而在于每一个功能都能说得清原理、禁得住追问。

我做这个项目的核心体会是：所谓“智能”并不玄乎，它就是“感知 → 决策 → 执行 → 反馈”这个闭环在嵌入式系统上的落地。交通灯管理是这样，其他所有智能硬件项目也都是这样。你把这个环的每一环都亲自实现了一遍，以后再面对任何单片机项目，心里就有底了。