企业官网建设流程全解析

做课设、毕设或者嵌入式练手项目，“基于STM32的智能停车场管理系统”算是一个非常经典的选题。这套系统听起来像个小型工程项目，拆开看其实就几个很典型的嵌入式模块：车辆检测、道闸控制、车位计数、信息显示，额外再挂一个通信模块就能升级成联网管理。对刚学STM32的人来说，它能把你学过的GPIO、定时器、中断、串口、I2C这些外设整个串起来；对想进阶的人来说，也可以往里面加摄像头识别、云端管理这些内容，做成一个比较完整的作品。

这个管理系统的核心诉求其实很朴素：解决停车场的入口拥堵和车位不明问题。车辆进来自动感应、道闸自动抬起、联动扣减剩余车位并显示在屏上，出口车辆出去自动加回剩余车位。整套流程用STM32F103系列跑裸机就足够顺畅，资源也不紧张。我把实际做下来的一些方案选择和调试经验整理在后面，尤其是几个平时文档里不会写、但真机会出问题的地方，希望能帮你少走点弯路。

1. 方案选型：四大部分怎么定

这项目第一步最容易被忽略，有人上来就画原理图，结果做到一半发现舵机电流把单片机拉复位了，或者红外对射在大太阳底下乱触发。先花半天把方案定清楚，后面能省很多事。

1.1 主控选型：为什么大家都用STM32F103C8T6

主控我选的是STM32F103C8T6，蓝板最小系统板那种，二十多块钱，网上资料和示例代码一抓一大把。它的配置对停车管理系统来说是绰绰有余的：72MHz主频、64KB Flash、20KB SRAM，跑一个事件驱动逻辑加显示刷新完全没压力，后面就算想上FreeRTOS也带得动。

有人会问选F103还是F407，或者用国产的GD32替代行不行。我的看法是：如果主要目的是学习或交项目，F103C8T6是性价比最高的选择，因为教程、调试经验、案例源码最全，你卡住了随便搜都能找到参考。GD32的软件基本兼容，烧录时选择对应芯片型号就行，但遇到问题参考资料相对少一点。F407性能更强、带硬件MAC和DMA更丰富，但做停车场管理这些算力用不上，有点浪费。

另一个需要考虑的点是芯片封装。C8T6是LQFP48封装，手工焊接也不难，如果你有画板打样的计划，这个封装比BGA之类的好伺候太多。建议直接用带板载ST-LINK接口的F103C8T6最小系统板做原型，等逻辑调通后再自己画底板，风险更低。

1.2 车辆检测方案：红外、超声波和地磁怎么选

车辆检测是整个系统中最容易出幺蛾子的部分，几种常见方案的对比我直接列在下面。

我做这套系统时，出入口用的是红外对射，车位占用检测用的是超声波。原因是模拟场景下这两种模块最好买也好接线。红外模块选带调制的型号，比如E18-D80NK，自带调制频率能滤掉一部分环境光干扰，比用单个红外二极管加接收管的方式稳定得多。普通的光电开关在阳光直射时接收管容易饱和，会频繁误触发，这一点在后面调试部分我详细说。

1.3 道闸和显示模块的搭配

道闸执行机构上，常见选择是舵机或步进电机。舵机的优点是控制简单，给一路50Hz的PWM就能直接转角度，SG90扭力小了点但模拟用足够，MG996R的扭力更足，适合带动有一定阻力的道闸杆。步进电机的优点是可以精确控制角度和力矩，但要加驱动芯片和限位逻辑，控制代码更复杂。我自己用的MG996R加一根轻质塑料杆，抬杆速度和力道都很合适。

显示模块我选了0.96寸OLED（SSD1306），I2C接口只占两根线，程序里刷屏也简单。如果你手头有LCD1602或LCD12864也可以用，只是1602显示内容少一点，12864占用的IO多一些。OLED屏在室内环境显示效果很好，不过在阳光直射下看不太清楚，如果要做户外演示，建议用LCD/LED数码管，或者给OLED加个遮光罩。

另外还可以加一个蜂鸣器或语音播报模块。无源蜂鸣器用定时器PWM驱动，能发出不同音调，用于“欢迎光临”“车位已满”这类提示；要更高级一点可以接JQ8900-TTS之类的语音模块，串口发指令播报，但这不是核心功能，可选。

2. 硬件电路设计与搭建

硬件是整个项目中坑最多的部分，尤其是供电和信号处理。很多新手把模块一股脑接上去，能跑起来就以为OK了，结果一到现场就各种重启和误触发，这基本都是硬件细节没处理好。

2.1 电源架构：别让舵机拖垮单片机

这个系统的用电设备分三档：MCU和传感器工作在3.3V/5V，蜂鸣器用5V也凑合，舵机则需要6V左右的电压。我见过不少人用USB线给单片机供电，然后舵机的正负极也接在5V引脚上，一旦舵机启动，电流猛增，单片机电压被拉低，表现就是屏幕闪一下然后系统重启。

建议的电源架构是用一个12V/1A以上的电源适配器进板，先用LM2596降压模块调到6V，给舵机单独供电；再从5V或者6V处接一个AMS1117-3.3稳压到3.3V给MCU和传感器供电。舵机的地线和MCU地线在电源入口处单点汇合，不要形成环路。每个芯片电源引脚旁都放一个100nF退耦电容，舵机电源输入端并联一个470uF到1000uF的电解电容，吸收舵机启动时的大电流冲击。我做的时候在舵机供电线上还串了一个共模电感，效果不错，但不是必需品。

还要注意一点，MG996R堵转电流可以到2A以上，如果用的LM2596输出能力不够，抬杆中途卡住就可能造成电压跌落。条件允许的话，舵机用独立5V/2A的电源适配器更省心。

2.2 检测信号进GPIO之前的处理

红外对射模块的输出通常是开关量信号，有的模块输出是NPN开集电极，有的是TTL电平。直接接到STM32的GPIO前，要搞清楚输出类型。开集电极输出需要外部上拉电阻，STM32内部有上拉电阻可以启用，但我建议外部加一个10K上拉到3.3V，信号更稳定。

为了防止信号抖动和电磁干扰，我在每个检测信号线上加了一个100nF的电容到地，形成低通滤波，然后在GPIO配置里把输入模式设置为上拉输入。软件层面再做消抖处理，这部分我放到第3章详细讲。

这里还有一个小技巧，检测信号线尽量短，双绞线或者屏蔽线更好，不要和舵机电源线、PWM线扎在一起走，否则舵机启动时的电磁干扰会耦合到检测线上，造成误触发。

2.3 舵机PWM驱动的关键参数

舵机控制是STM32定时器PWM输出的典型应用。舵机的控制信号是周期20ms（50Hz）的PWM波，高电平脉宽决定转角：0.5ms对应0度，1.5ms对应90度，2.5ms对应180度。实际舵机线性区间可能略有偏差，可以通过调试微调脉宽。

以STM32F103的TIM2为例，假设定时器时钟是72MHz，想得到50Hz的PWM，可以这样设置：预分频PSC=71，则计数频率为72MHz/72=1MHz，也就是1个计数1微秒；自动重载值ARR=19999，则PWM周期为20000微秒，正好20ms。脉宽就是比较值CCR：0.5ms对应CCR=500，2.5ms对应CCR=2500。

注意不能用系统滴答定时器的HAL_Delay去模拟舵机PWM，因为Delay期间CPU被阻塞，系统其他任务全停了。正确做法是把PWM交给定时器硬件输出，CPU只管修改CCR寄存器来改变角度。

2.4 显示、按键和小零件的接线

OLED接I2C时需要注意地址问题，SSD1306默认7位地址一般是0x3C，个别模块是0x3D。I2C引脚在F103上可以复用为PB6（SCL）和PB7（SDA），也可以用软件模拟I2C挂到任意GPIO上。软件模拟的好处是引脚随便选，缺点是比较浪费CPU时间，但如果显示刷新频率不高，也看不出差别。

按键电路很简单，每个按键接一个GPIO到地，配置为内部上拉输入，平时读到高电平，按下读到低电平。每个按键并联一个100nF电容去抖，然后在软件里做20ms到50ms的消抖延时。蜂鸣器建议用NPN三极管或MOS管驱动，不要直接接在GPIO上，无源蜂鸣器接PWM输出到三极管基极，通过定时器输出不同频率的方波就能发声。

3. 软件架构与核心逻辑

硬件搭好之后，软件设计思路比具体代码更重要。这个项目的逻辑不算复杂，但如果一开始就用轮询加Delay硬扛，后面加功能时会很痛苦。我的做法是从一开始就把主逻辑做成状态机，让系统在任意时刻都能响应检测、刷新显示、处理通信。

3.1 从初始化开始：GPIO、定时器、I2C

初始化阶段要做的事情包括：时钟树配置、GPIO模式设置、定时器PWM配置、I2C初始化、串口初始化。用HAL库的话，STM32CubeMX点点点就能生成工程，省很多事；用标准库的话，代码看起来更简洁，适合喜欢控制每一个细节的人。两种我都试过，最终项目里用了HAL库加CubeMX，因为这个系统涉及多个外设，CubeMX生成的初始化代码不容易漏。

GPIO配置上，几个关键点：红外检测输入引脚配置为上拉输入，按键也是上拉输入，蜂鸣器PWM引脚配置为复用推挽输出，LED指示引脚配置为推挽输出。I2C在CubeMX里选择I2C1，速率选100KHz标准模式，OLED这种显示器件不需要高速。

定时器PWM配置我在2.3节已经算过参数，在CubeMX里把TIM2的Channel设为PWM Generation CH1，PSC填71，ARR填19999，初始CCR填1500（对应90度，道闸复位位置）。串口用USART1，波特率115200，8位数据、无校验、1位停止位，这是最常用的配置。

3.2 车位计数逻辑与边界条件

车位计数是整个系统的核心数据。我定义了一个结构体来保存管理系统的全局状态，大致是总车位、剩余车位、入口状态、出口状态、道闸状态、当前事件标志。每次检测到入口红外被遮挡且确认是车辆进入后，剩余车位减一；每次检测到出口方向有车辆出去后，剩余车位加一。

边界条件要重点考虑，否则会出现负数或者超过总量的情况：剩余车位已经为0时，入口道闸不允许抬起，同时显示“车位已满”；计数结果必须限制在0到总车位之间，任何情况下不能越界；同一个触发源在短时间内连续触发时，要加锁定时间窗口，防止同一辆车在入口区域缓慢移动时产生多次计数。

更稳一点的做法是做成“车辆进入动作完成”后再计数，而不是遮挡瞬间就计数。比如检测到车辆进入后，先抬起道闸，车辆继续前进通过第二个检测点时，才真正完成扣减动作。这样即使车辆在入口处来回移动，也不会错误计数。

3.3 道闸控制状态机的实现思路

道闸不能简单用“检测到车辆就抬杆、延时3秒就落杆”的阻塞写法，因为阻塞期间系统无法响应新的事件。我用的状态机方法大致是这样的：

typedef enum { GATE_IDLE, GATE_OPENING, GATE_OPEN, GATE_CLOSING } GateState; void gate_process(void) { switch (gate_state) { case GATE_IDLE: if (entry_car_detected && remain_slots > 0) { servo_set_angle(170); // 抬杆角度 gate_state = GATE_OPENING; gate_timer_start(1000); // 1秒内完成抬杆 } break; case GATE_OPENING: if (gate_timer_expired()) { gate_state = GATE_OPEN; gate_timer_start(3000); // 保持抬起3秒 } break; case GATE_OPEN: if (gate_timer_expired() || car_passed_through) { servo_set_angle(90); // 落杆复位 gate_state = GATE_CLOSING; gate_timer_start(1000); } break; case GATE_CLOSING: if (gate_timer_expired()) { gate_state = GATE_IDLE; } break; } }

关键点是状态切换的时间基准来自定时器，而不是Delay，这样整个系统在道闸运行过程中依然能扫描红外检测、刷新显示、处理串口数据。如果后面模块多到忙不过来，再上FreeRTOS，用消息队列把检测事件、显示任务、通信任务分开，状态机这个底层逻辑也不用推翻重写。

3.4 车位超声波的轮询检测逻辑

如果做了车位级别的占用检测，比如超声波传感器负责判断车位上有没有车，那软件上就不能只看入口红外了。我用的方法是定时轮询：每200ms触发一次HC-SR04超声波模块，测量距离，连续测得距离小于设定阈值（例如50cm）就判定该车位有车，大于阈值就判定无车。

实时刷新所有车位状态会牵扯到每个车位的去抖，不能测到一次小于阈值立刻改状态，应该连续三次都小于阈值才更新为“占用”，连续三次都大于阈值才更新为“空闲”。测试下来这个策略能有效避免车辆经过临时遮挡造成的误判。

显示部分保持一个固定的刷新节奏即可，我用的是每300ms刷新一次OLED：第一行显示“剩余车位: N/T”，第二行显示最近一条事件信息。OLED全屏重绘一次大概是几十毫秒，但如果整个系统同时在做舵机控制和串口接收，300ms的刷新间隔完全够用，而且人眼看不出延迟。

4. 上位机通信和远程管理

真正意义上的停车场管理系统肯定需要和管理终端联动。这个项目里通信模块可以做成两种形态：一种是本地用串口连接PC上位机，另一种是通过ESP8266等模块把数据送到局域网或者云端。两种我都试过，各有适用场景。

4.1 串口协议：自己定一套轻量帧

STM32和上位机之间的数据传输，最好不要直接用printf发纯文本，因为上位机解析困难，数据多了还会粘包。我自定义了一个简单的帧协议，有帧头、命令字、数据长度、数据和校验和。

帧格式大致是：0xAA 0x55（帧头）、命令字（例如0x01表示更新剩余车位）、数据长度、数据内容、累加和（前面所有字节求和取低8位）。上位机按帧解析，收到0xAA 0x55后继续收固定长度的字节，最后核对校验和，校验通过才执行更新。这套协议虽然简单，但足够应对车位数量、道闸状态、事件记录这类小数据量的报文。

串口波特率我选了115200，没什么特殊原因，因为数据量小，9600也行。需要注意的是，STM32串口接收中断里不要把解析逻辑写得太长，正确做法是中断里只把字节放入接收缓冲区，主循环里再处理完整帧，否则中断占用时间过长会影响PWM和检测的实时性。

4.2 上云路径：ESP8266和W5500

如果要把数据送到局域网，最简单的方式是STM32通过USART接ESP8266 WiFi模块，用AT指令或者直接让ESP8266跑MQTT固件。STM32这边的职责就简单了，本地逻辑处理完数据后，把帧通过串口发给ESP8266，ESP8266负责MQTT发布到服务器。

这里有个容易踩的坑：ESP8266的供电要求瞬态电流很高，不能直接从STM32板的3.3V引脚取电，最好独立供电，否则WiFi连接瞬间会把电压拉低导致整个系统复位。我用的是一个AMS1117-3.3给ESP8266单独供电，虽然ES8266的IO逻辑电平是3.3V，但供电留足余量会稳很多。

如果不想用WiFi，也可以用W5500硬件TCP/IP协议栈芯片走有线以太网。STM32和W5500之间用SPI通信，引脚占用少，速度稳定，适合做固定安装的停车管理系统。不过如果只是交课程设计，ESP8266加本地MQTT服务器已经足够了。

5. 调试过程实录：问题、原因和解决办法

做这个项目的过程中，我遇到了不少问题，这里挑几个典型的分享。这些问题都是我在实际调试中踩过的坑，如果你也碰到类似现象，可以直接按这个思路排查。

5.1 车辆检测频繁误触发

现象：红外对射在室内试验时一切正常，搬到窗边出太阳后，即使没有车经过，系统也频繁判定有车辆进入。

原因分析：普通红外接收管在环境光较强时会收到大量红外辐射，接收电路输出电平被拉低，造成误触发。另外，红外模块安装角度偏了，太阳光直射到接收管上也会有同样效果。

解决办法：一是换用带调制频率的红外模块，比如E18-D80NK，它内部发射的是38KHz调制光，接收端只识别同样频率的信号，对环境光的抗干扰能力明显更强；二是在接收管上加遮光罩或黑色热缩管，物理上阻挡环境光；三是在软件里做连续确认，比如同一检测信号持续50ms以上才认定为有效触发，瞬时毛刺直接忽略。

5.2 道闸抬起时整个系统复位

现象：舵机转动瞬间，OLED黑屏、单片机重启，有时候会反复循环。

原因分析：舵机启动电流非常大，MG996R标称工作电流可能到几百毫安，堵转时2A都不夸张。如果舵机电源直接取自单片机板上的5V引脚，电源跌落会被单片机当成掉电复位处理。

解决办法：把舵机的正负极直接从稳压模块的输出端接出来，不要在MCU板上取电；在舵机电源输入端并联一个1000uF电解电容，电压跌落时能扛一下；同时检查地线，舵机地和MCU地要在电源出口处单点连接，不要形成环。改完这个供电结构之后，问题彻底消失。

5.3 程序下载失败，ST-LINK识别不了芯片

现象：Keil里点击下载按钮，提示无法连接ST-LINK或者找不到目标芯片，但上电后系统运行正常。

原因分析：最常见的有四种：一是驱动没装好，电脑识别不到ST-LINK；二是SWDIO和SWCLK两根线接反了；三是目标板供电不足，导致调试器无法稳定读取芯片；四是芯片被读保护，有次我频繁刷写后芯片就锁了。

解决办法：先检查设备管理器里有没有识别到ST-LINK调试器，没有就装驱动；然后再查SWD四根线的连接，特别是GND是否和电脑共地；BOOT0引脚在下载时要保持低电平，正常运行时也是低电平；如果确认是芯片被锁，用ST-Link Utility做全片擦除（Full Chip Erase），擦完再下载就恢复正常了。

5.4 车位数量越算越少，出现负数

现象：入口和出口的都检测过几次之后，剩余车位显示成负数。

原因分析：这个问题几乎都是计数逻辑没有加边界保护导致的。我排查后发现，是同一辆车在入口红外面前停了几秒钟，红外信号在有效和无效之间反复翻转，每当翻转一次，程序就当成一次新车辆进入，清零前最后一次进入动作重复扣了好几次。

解决办法：在软件里加入“触发锁定时间”，比如某方向检测到有效信号后，3秒内其他触发都不再响应。同时在计数函数里加上边界判断，剩余车位最小只能是0，最大不能超过总车位，数值越界就强制修正。这两个措施加上去之后，测试车辆连续往返多次，计数依然准确。

5.5 常见问题与排查速查表

一些操作心得

这个项目我最满意的地方在于它的完整性：入口检测、出口检测、车位管理、道闸执行、状态显示、串口通信全都在一条逻辑链上跑通。对学习来说，它把一个嵌入式系统的软件分层和状态机设计讲得清清楚楚。如果之后想继续扩展，可以往里面加摄像头车牌识别，STM32作为主控通过串口和K210或OpenMV通信，识别结果直接参与车辆放行判断，又能在硬件和通信上多学到不少东西。

实际操作中我最大的体会是：别急着写代码，先把供电结构和信号链路理清楚。很多项目看起来是软件bug，最后查下来都是硬件上的细节问题，尤其是地线和电源，这两个地方稳定了，软件调试才会顺利。