企业官网建设流程全解析

简介：基于STM32F103与OV7670的车牌识别系统设计，是一份面向嵌入式方向毕业设计的完整方案，适合高校学生、嵌入式初学者及智能交通项目开发者参考。项目以STM32F103为控制核心，通过OV7670图像传感器采集车辆图像，系统性地覆盖了图像去噪、灰度化、直方图均衡化等预处理环节，以及字符分割、特征提取与模式识别等车牌识别关键步骤，并针对渝、辽、沪、浙、苏、粤六个省份的车牌样式特点进行了识别优化，以提高不同地区车牌的识别准确率。资料中还包含车牌识别AD格式电路图，能够帮助理解模拟数字转换电路与摄像头接口的设计要点，对硬件选型、电路搭建和调试排错有直接参考价值。压缩包约16.54MB，已有2193人学习，整体可作为毕业设计选题、系统框架搭建与算法验证的实用参考资料。

1. 项目背景与整体认知

1.1 这个毕设到底在做什么

先说结论：基于STM32F103和OV7670的车牌识别系统，本质上是一套“嵌入式图像采集 + 上位机算法处理”的典型教学案例。它的核心链路是——OV7670摄像头完成图像采集，STM32F103作为主控负责配置传感器、缓存图像数据并通过串口或USB传给PC端，最终由PC端跑OpenCV或其他图像处理算法完成车牌区域的定位、字符分割和识别。

这几年我陆陆续续帮人看过不少类似的毕设项目，STM32F103 + OV7670这个组合出镜率极高。原因不复杂：STM32F103是Cortex-M3内核的经典芯片，资料多、外设丰富、开发门槛低；OV7670则是30万像素级别的CMOS图像传感器，价格便宜（几块钱到十几块钱一片），输出的RGB565/YCbCr422格式非常适合给单片机做图像采集教学。两者组合在一起，既能体现嵌入式底层能力（I2C寄存器配置、DMA传输、FIFO时序控制），又能衔接上层图像处理算法，正好覆盖了电子信息、自动化、计算机等专业毕业设计要考察的几项核心技能。

但这里我必须先把一个关键问题说清楚：STM32F103这颗MCU的主频最高72MHz，SRAM只有20KB（大容量型号到48KB），Flash最大512KB。拿它直接跑车牌识别算法——比如边缘检测、连通域分析、字符模板匹配——不是不行，而是性能极其紧张，跑起来很吃力。业界常见的做法有两种：要么用OV7670输出JPEG压缩数据（OV7670内部自带压缩引擎，但需要额外购买带FIFO的模块），把识别任务交给PC；要么干脆把OV7670当成图像采集前端，通过串口把原始图像数据传到上位机，识别全部在PC上完成。

所以你在做这个项目之前，先想清楚一件事：你到底是想要一个“能跑通的完整系统”，还是想要一个“纯嵌入式端实现识别”的硬核方案？方向不同，工作量和技术路线差别很大。

1.2 这个项目的技术链条和应用场景

从技术链条来看，这个项目横跨了三个层面：

• 硬件层：STM32F103最小系统板（或者自己画PCB）、OV7670摄像头模块（带FIFO版本更推荐）、供电电路、串口转USB模块、PC上位机。
• 驱动层：STM32的I2C驱动（用于配置OV7670寄存器）、DMA + 定时器驱动（用于读取FIFO数据）、串口/UART驱动（用于图像数据传输）。
• 算法层：OpenCV图像预处理（灰度化、二值化、边缘检测）、车牌定位（颜色特征或形态学操作）、字符分割、模板匹配或OCR识别。

应用场景方面，虽然这个项目是教学性质，但它映射的实际需求很明确——停车场出入口管理、高速收费站车牌抓拍、小区门禁系统，这些场景的核心图像采集端和识别端架构，和这个毕设是高度一致的。唯一区别是工业级系统会用更高分辨率的相机、更稳定的补光方案和专用识别芯片或GPU，但“图像采集 + 传输 + 算法识别”这条链路原理完全相同。

所以，如果你是冲着“把项目做完、顺利答辩”这个目标来的，这个文章里的方案可以直接用；如果你是想把项目做扎实、甚至在简历上写一句“熟悉嵌入式视觉系统开发”，那这篇文章的方法论同样适用，而且我会把一些常规文档里不讲的经验都交代清楚。

2. 系统整体方案与关键选型分析

2.1 架构设计：为什么识别不在单片机上做

这是整个项目最核心的一个决策点，也往往是答辩时老师最爱问的问题。很多同学拿到题目后的第一反应是——STM32F103 + OV7670，那我直接在STM32上跑车牌识别算法呗。这个想法本身没错，但实际做起来会遇到几个硬伤：

第一，内存不够。一帧QVGA（320×240）的RGB565图像裸数据是320×240×2 = 153600字节，也就是150KB。而STM32F103的大容量型号最多也就48KB SRAM，连一帧图像都存不下。这时候你得用OV7670带FIFO的模块，摄像头先把一帧数据写入FIFO芯片（通常是AL422B，容量384KB），MCU再从FIFO里分批读出来处理。

第二，算力不够。车牌识别里最基础的车牌定位算法，比如Sobel边缘检测加形态学闭运算，在一张320×240的灰度图上，72MHz主频的Cortex-M3裸奔跑起来，大概需要几百毫秒到一秒以上。这还只是定位，后面还有字符分割、模板匹配，整体跑完可能要好几秒。作为毕设演示不是不能接受，但实时性确实谈不上。

第三，算法调试难度高。嵌入式端的图像处理库和调试工具远不如PC端方便。你在PC上用OpenCV几行代码就能看到中间结果，在单片机上你得把每一帧中间处理结果通过串口发出来看，开发效率低一个量级。

所以我的建议非常明确：如果你不是对嵌入式算法优化有特别强烈的兴趣，采用“单片机采图 + 串口传输 + PC端识别”的架构。这样STM32部分重点展示的是你对底层硬件、时序控制、外设配置的理解，PC端展示的是你对图像处理算法的掌握，两部分都有技术含量，而且工作量分配合理、调试难度可控。

这个方案在答辩时的表达口径也很清晰：“考虑到MCU算力与内存资源限制，本设计采用主从式架构。前端STM32完成图像采集与传输，后端PC完成车牌识别算法，在保证系统功能完整性的同时，兼顾了实时性与可扩展性。”这句话一说，老师基本不会在这个方向上继续纠结。

2.2 器件选型：OV7670模块的版本差异

OV7670摄像头模块在淘宝上有两种常见版本，长得几乎一样，但内部电路差很多，买之前一定要看清楚。

第一种是裸传感器版本，摄像头直接引出D0-D7数据线、PCLK、VSYNC、HREF、SIOC、SIOD等信号，所有时序控制都需要MCU自己完成。这种版本便宜，但用起来很麻烦，尤其是你要在STM32的GPIO上手动去读PCLK时钟边沿的数据，稍微有点时序抖动就会出花屏。

第二种是带FIFO版本，模块上多了一片AL422B FIFO芯片（或者类似的缓存芯片），摄像头采集的图像数据会自动写入FIFO，MCU只需要在VSYNC信号出现时等待一帧写入完成，然后通过读FIFO的方式把图像数据取出来。这种版本贵一点（多十几块钱），但用起来舒服太多，强烈推荐。

在买带FIFO版本时还要注意一个细节：有些模块把FIFO的写时钟（WRCLK）接到了OV7670的PCLK上，摄像头输出一像素，FIFO就自动存一像素；读时钟（RDCLK）则接到STM32的某个定时器通道上由MCU控制。这种设计下，你只需要在VSYNC下降沿（一帧结束）后等一小段时间，然后疯狂读FIFO即可。

此外，OV7670有几种分辨率模式：QQVGA（160×120）、QVGA（320×240）、VGA（640×480）。做车牌识别，QVGA是一个比较均衡的选择——分辨率足够识别车牌字符，图像数据量又不至于太大。VGA的话单帧裸数据有921600字节（按RGB565算），传输时间会明显拉长，而且对于30万像素的传感器来说，VGA和QVGA在图像细节上的差距并不大。

2.3 供电与电平匹配是容易踩的坑

OV7670模块的工作电压是2.45V到3.0V，很多模块板上自带稳压电路，可以直接用3.3V供电。但如果你用的是裸传感器版本，或者模块上没有稳压芯片，一定要确认供电电压，否则传感器的模拟部分可能工作不正常，表现为图像偏色、有横纹。

另一个容易忽略的问题是I2C上拉电阻。OV7670的SCCB接口（本质上就是I2C，只是时序定义略有差别）需要外部上拉电阻，一般模块上已经焊好了，但如果你自己画PCB或者用杜邦线连接，一定要记得加上4.7kΩ左右的上拉电阻。否则I2C通信会时好时坏，配置寄存器的时候偶尔成功偶尔失败，排查起来非常痛苦。

STM32的GPIO电平是3.3V，OV7670模块的信号线也是3.3V，正常情况下不需要电平转换。但如果你的STM32开发板是5V供电的，注意别把5V引到模块的3.3V引脚上，这个错误烧过不少人的摄像头。

3. OV7670驱动与图像采集的实操细节

3.1 SCCB接口配置：初始化顺序有讲究

OV7670的寄存器配置走的是SCCB协议，它和标准I2C的区别在于：SCCB只支持单字节写、单字节读和突发读，不支持重复起始条件（repeat start）。好在STM32的硬件I2C外设可以直接拿来用，只要把通讯速率控制在400kHz以下，绝大多数模块都能正常响应。

下面我给出一个用标准库（Standard Peripheral Library）配置I2C1的示例，这是STM32F103系列最常用的开发方式：

void I2C1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; I2C_InitTypeDef I2C_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE); // I2C1_SCL -> PB6, I2C1_SDA -> PB7 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // 开漏复用 GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); I2C_InitStructure.I2C_Mode = I2C_Mode_I2C; I2C_InitStructure.I2C_DutyCycle = I2C_DutyCycle_2; I2C_InitStructure.I2C_OwnAddress = 0x30; I2C_InitStructure.I2C_Ack = I2C_Ack_Enable; I2C_InitStructure.I2C_AcknowledgedAddress = I2C_AcknowledgedAddress_7bit; I2C_InitStructure.I2C_ClockSpeed = 200000; // 200kHz I2C_Init(I2C1, &I2C_InitStructure); I2C_Cmd(I2C1, ENABLE); }

OV7670的SCCB从机地址是0x42（写地址），一个典型的写寄存器函数长这样：

uint8_t OV7670_WriteReg(uint8_t reg, uint8_t val) { // 起始条件 + 从机地址(写) // 发送寄存器地址 // 发送寄存器值 // 停止条件 }

这里有一个非常关键的初始化顺序问题。OV7670上电后默认输出的是VGA分辨率的RGB565图像，但如果你想切换到QVGA或者其他输出格式，必须按照一定的顺序写寄存器。有一个比较容易出问题的点是：必须先设置分辨率相关的寄存器，再设置输出格式相关的寄存器，最后设置图像质量控制寄存器。如果顺序反了，可能出现图像花屏、颜色错乱或者干脆没有输出。

我习惯的做法是先将OV7670恢复默认值（写寄存器0x12的bit7为1，即RESET），延时50ms以上，然后再逐项写入配置。这个RESET操作非常必要，因为模块上电后内部的寄存器状态是不确定的，如果不先复位就直接配置，会出现“这次配置成功了、下次配置失败了”的随机现象。

3.2 关键寄存器配置参考表

下面是我实际调试过的一套QVGA RGB565配置，可以直接套用。注意这些值是基于OV7670官方手册和常见模块（如ATK-OV7670）的默认配置整理出来的：

这套配置的效果是输出320×240分辨率的RGB565图像，数据在FIFO里按行排列，每像素2字节。需要特别提醒的是，不同型号模块的寄存器复位值和默认值可能有差异，网上搜到的配置表也不尽相同。我的建议是，拿到模块后先看商家提供的初始化代码，如果没有，就用上面这套作为起点，再根据实际图像效果微调。调试时把图像保存下来逐项调整，比盲目改寄存器值要高效得多。

3.3 图像数据的读取：DMA + 定时器方案

OV7670带FIFO模块的数据读取，核心思路是：当一帧图像写入FIFO后，STM32通过DMA从FIFO读出数据，存储到SRAM缓冲区，然后通过串口发送到PC。

这里有一个常用的技巧：用定时器生成读时钟信号。

void TIM2_PWM_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_OCInitTypeDef TIM_OCInitStructure; // 使用PA1作为PWM输出，接到FIFO的RDCLK RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); TIM_TimeBaseStructure.TIM_Period = 7; // 8分频 TIM_TimeBaseStructure.TIM_Prescaler = 0; TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1; TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable; TIM_OCInitStructure.TIM_Pulse = 3; // 占空比约50% TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1Init(TIM2, &TIM_OC1InitStructure); TIM_Cmd(TIM2, ENABLE); }

这个PWM输出的频率大概就是72MHz / 8 = 9MHz，也就是每秒钟能从FIFO读出900万个像素。QVGA一帧有76800个像素，理论上1kHz的帧率都够，但实际中由于DMA读取和串口发送之间存在同步开销，稳定在10-20帧每秒完全没有问题。

读取一帧图像的核心逻辑可以用下面这段伪代码描述：

void OV7670_CaptureFrame(uint8_t *buffer, uint32_t size) { // 1. 等待VSYNC下降沿（一帧写入完成） while(OV7670_VSYNC == 1); while(OV7670_VSYNC == 0); while(OV7670_VSYNC == 1); // 2. 稍微延时，确保FIFO写指针稳定 delay_ms(10); // 3. 拉低WE，进入读模式 OV7670_FIFO_WE_LOW(); // 关闭写入 OV7670_FIFO_OE_LOW(); // 使能输出 // 4. 通过DMA读取FIFO数据到buffer // 这里需要配置DMA的源地址为FIFO数据端口，目的地址为buffer // 5. 读取完成后拉高WE，恢复写入 OV7670_FIFO_WE_HIGH(); OV7670_FIFO_OE_HIGH(); }

这个过程中的时序配合很容易出问题，常见的表现是图像有规律的错位或者撕裂。遇到这种问题，优先检查WE和OE的时序切换，以及VSYNC的边沿检测方式。有些模块的VSYNC是低电平有效，有些是高电平有效，一定要看模块的原理图确认。

4. PC端车牌识别算法设计与实现

4.1 图像接收与预处理流程

串口把图像数据发到PC端之后，第一步是把原始RGB565数据转换成OpenCV能处理的BGR格式。这里有个细节值得注意：OV7670输出的RGB565，在字节序上可能是大端或者小端，取决于寄存器的配置。如果你发现图像颜色整体偏蓝或者偏红，第一反应应该是交换高低字节，而不是怀疑白平衡配置有问题。

import cv2 import numpy as np import serial def read_image_from_serial(port, baudrate=921600, width=320, height=240): ser = serial.Serial(port, baudrate, timeout=5) # 等待帧头 while True: header = ser.read(2) if header == b'ST': # 自定义帧头 break # 读取数据 data = ser.read(width * height * 2) # 转换为numpy数组 img_rgb565 = np.frombuffer(data, dtype=np.uint16).reshape(height, width) # 分离R、G、B分量 r = ((img_rgb565 >> 11) & 0x1F) << 3 g = ((img_rgb565 >> 5) & 0x3F) << 2 b = (img_rgb565 & 0x1F) << 3 img_bgr = cv2.merge([b, g, r]) return img_bgr

收到图像之后，预处理流程通常包括灰度化、高斯滤波、直方图均衡化、Sobel边缘检测、形态学闭运算等。车牌区域在图像中的特征是高对比度的边缘密集区域，尤其是字符区域和车牌背景之间的边界非常明显。

4.2 车牌定位与字符分割的具体实现

车牌定位在传统图像处理方案里，最实用的一种是基于颜色特征的方法。蓝底白字车牌是主流，所以可以先把RGB图像转换到HSV空间，然后提取蓝色区域，再做形态学处理，找到最大的连通域作为候选车牌区域。

def locate_plate(img_bgr): hsv = cv2.cvtColor(img_bgr, cv2.COLOR_BGR2HSV) # 提取蓝色区域（蓝色车牌的色调范围大约在100-124之间） mask = cv2.inRange(hsv, (100, 43, 46), (124, 255, 255)) # 形态学操作，去除噪声并填充孔洞 kernel = cv2.getStructuringElement(cv2.MORPH_RECT, (5, 5)) closed = cv2.morphologyEx(mask, cv2.MORPH_CLOSE, kernel, iterations=2) # 找到所有轮廓 contours, _ = cv2.findContours(closed, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) # 按面积排序，取最大的一个 if len(contours) == 0: return None plate_contour = max(contours, key=cv2.contourArea) x, y, w, h = cv2.boundingRect(plate_contour) # 车牌长宽比一般接近3.14:1，可以做一次校验 aspect_ratio = w / h if aspect_ratio < 2.0 or aspect_ratio > 5.0: return None return img_bgr[y:y+h, x:x+w]

定位到车牌区域后，接下来是字符分割。为了降低光照不均对二值化的影响，可以对方形区域先做自适应二值化，然后通过垂直投影找到字符的左右边界。正常车牌的7个字符（省简称汉字 + 字母 + 字母/数字组合）之间的空隙相对固定，可以用投影直方图比较靠谱地切分出来。

def segment_characters(plate_roi): gray = cv2.cvtColor(plate_roi, cv2.COLOR_BGR2GRAY) # 自适应阈值二值化 binary = cv2.adaptiveThreshold(gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY_INV, 11, 2) # 去除边框和铆钉区域 binary = remove_border(binary) # 垂直投影 vertical_projection = np.sum(binary, axis=0) / 255 # 寻找字符边界 chars = find_char_boundaries(vertical_projection) return chars

字符识别部分，如果项目要求不高，用模板匹配就够用。准备一套标准字符模板（包括各省简称、字母、数字），对分割出的字符做尺寸归一化后逐一匹配，取相似度最高的作为结果。如果想让系统更有“含金量”，也可以接入OCR引擎如Tesseract，或者用PaddleOCR，不过对于毕业设计来说，模板匹配已经能说明问题，答辩效果也不差。

4.3 算法性能实测与优化方向

在自己PC上跑通上述算法流程，我用一张在真实停车场环境下采集的图片（光照正常、车牌清晰），从图像读入到识别出车牌号，总耗时大约在80到150毫秒之间，基本满足演示要求。如果摄像头正对车牌、距离在1到1.5米，识别率能达到90%以上；如果车牌有倾斜、遮挡或者光照特别差，识别率会明显下降。

提升识别率有几个简单有效的方向：一是图像预处理阶段加入透视校正，把倾斜的车牌区域矫正成矩形；二是二值化环节使用更大的自适应窗口，降低噪点干扰；三是在字符匹配阶段使用多个模板，覆盖不同字体和磨损程度的车牌。

5. 系统联调与问题排查实录

5.1 硬件联调中遇到的高频问题

这个项目在联调阶段容易出现的问题，我按出现频率从高到低整理成一张速查表：

最典型的坑是I2C配置时“头几次能读到，后面就读不到了”。这种问题绝大多数是SCL和SDA的上拉电阻没焊或者虚焊，也有的是两条线接反了。处理办法是用示波器或逻辑分析仪先看SCL和SDA上有没有正常的波形，再谈寄存器配置的事。

5.2 串口传输协议的坑：你的波特率可能虚高

很多同学拿到STM32后用串口传图像，直接上921600甚至更高波特率。但实际上，STM32的USART在921600波特率下，如果系统时钟精度不高，或者用了内部RC振荡器（HSI）而不是外部晶振（HSE），波特率误差可能超过容忍范围，导致传输出错率上升。

我的建议是，优先用外部8MHz晶振作为系统时钟来源，并把USART的波特率配置在460800或者更保守的230400。一帧QVGA RGB565图像是153600字节，在460800波特率下（8N1格式，实际有效数据率约46080字节/秒），传一帧需要3.3秒左右。这个速度演示起来确实有点慢，如果嫌慢，可以做图像压缩——把RGB565转成灰度图，大小直接减半，或者用OV7670输出RGB444/YCbCr422减小数据量。另一个更快的方法是用USB虚拟串口（VCP），速度能到1Mbps以上，但驱动配置稍复杂，需要装ST官方的VCP驱动。

传输协议上，我习惯自定义一个简单的帧格式：帧头（2字节，如0xAA 0x55）+ 数据长度（2字节）+ 图像数据 + 校验（1字节累加校验）。PC端通过帧头同步，用数据长度确定一帧图像的大小。这样做的好处是即使传输中出现丢包，也能通过帧头重新同步，不会出现整帧数据错乱。

5.3 答辩时遇到的技术追问怎么答

这个项目在答辩环节，老师通常会在三个方向发问：为什么选择这个架构？怎么保障系统的稳定性？算法在什么条件下会失效？

架构问题我在2.1节已经给了参考答案。稳定性的问题可以这样回应：硬件层面，OV7670的I2C配置增加了校验机制（写后读验证）；传输层面，串口协议带帧头和累加校验，丢帧后上位机能自动重新请求；软件层面，增加了看门狗定时器，主循环卡死会自动复位。这三个层面体现了嵌入式系统设计的“可靠性思维”，比单纯说“项目能跑”要高一个档次。

失效条件的问题，如果用的是传统图像处理方案，就如实回答“在强逆光、车牌倾斜超过15度、夜间无补光条件下识别率会下降”，然后补一句“后续可以通过加入透视矫正、自动白平衡、以及补光电路来增强环境适应性”。这样既体现了你对算法边界有清晰认知，又能体现你思考过改进方向。

6. 总结与经验心得

做这个项目前后我花了大约三周时间，真正调试通过、图像稳定传输、识别率能看的版本是在第二周的周五才跑通的。中间踩过最大的一个坑，也是最想提醒后来人的一点：不要一上来就写代码，先把手头的硬件模块吃透。我指的“吃透”不是看完数据手册，而是画一块最小测试板（或者用面包板搭出来），把I2C读寄存器这个动作跑通，把一帧图像的显示调通，再考虑往上叠算法。这一步看起来慢，其实是最省时间的。

另外，这个项目做完之后其实还有很多可以扩展的空间。比如把PC端的识别算法换成深度学习（YOLO系列或者PaddleOCR），识别率会提升一大截；把串口传输换成Wi-Fi或者以太网，就能变成一个分布式系统的前端采集节点；给STM32加上停车场的道闸控制逻辑，配合继电器模块，就是一个完整的停车场门禁样机。顺着这些方向往下做，这个毕设的深度和广度都会好很多，写进简历里也会更有说服力。

最后分享一个小技巧：调试OV7670的时候，在PC端写一个单独的“图像预览”程序，不要每次都把识别算法跑完整一遍。先把图像显示出来，确认图像质量没问题，再开始调识别算法。图像质量不过关，算法调得再努力也是白搭。这个习惯我一直保留到后来做工业视觉项目，屡试不爽。

本文还有配套的精品资源，点击获取