基于STM32的五种验证方式融合门禁系统设计与实战

简介：这是一款面向嵌入式开发者、物联网实践者与计算机视觉初学者的STM32多功能智能门禁系统完整工程，解决传统门禁安全性低、验证方式单一的问题，适用于智能家居、办公室门禁及教学实验场景。资源包共271个文件，含49个C语言源码（.c）、46个头文件（.h）、44个编译中间文件（.o）及调试配置（.uvprojx/.axf）、硬件驱动（stm32f10x_tim.c等）、人脸识别Python脚本（.py）和OpenCV图像处理模块，整体压缩包仅8.95MB，结构清晰、模块解耦，便于理解多传感器融合与RTOS级任务调度逻辑。已有65人学习下载，项目提供可直接烧录运行的KEIL工程、OLED中文界面驱动、ESP32-CAM实时人脸采集与比对流程、蓝牙APP通信协议实现，以及舵机控制、声光反馈等完整执行链路，是掌握STM32外设集成、嵌入式AI落地与多模态身份认证设计的高价值参考范例。

1. 项目概述：一个门禁项目到底能塞进多少种验证方式

先把话说清楚，这个项目就是把RFID刷卡、指纹识别、密码输入、蓝牙APP控制、人脸识别这五种验证方式，全部集成到一套基于STM32的控制系统里。听起来像是把一堆模块简单拼在一起对吧？实际做下来你会发现，真正的难点根本不在“接不接得上”，而在“这么多外设抢资源的时候怎么保证稳定”，以及“每一种验证失败之后系统该怎么优雅地处理”。

我最初做这个项目是为了解决实验室的门禁管理问题。原来的方案是单纯的RFID刷卡，卡丢了就进不去，管理员还得手动删卡加卡，非常被动。后来逐步加了密码盘、指纹模块，再后来有同学提议能不能用手机控制，就加了蓝牙模块。最后人脸识别是考虑到双手都抱着设备的时候，刷卡和按密码都不方便，索性又把摄像头和识别算法加进来了。做着做着就发现，这不就是一个典型的“多生物特征+多凭据”融合验证系统吗，放在课程设计、毕业设计、甚至产品原型里都很有代表性。

这个项目适合谁参考？如果你正在做嵌入式相关课设、准备电子设计竞赛，或者想在门禁、考勤、智能储物柜这类方向做个原型验证，那这套东西的思路和代码结构能帮你省掉大量踩坑时间。我下面会从架构选型、每个模块的接入细节、验证逻辑的融合方式，到实际调试中遇到的坑，一条线讲清楚。

2. 系统整体架构：为什么选STM32F103系列，主控资源怎么分配

2.1 主控选型的取舍逻辑

这套系统的主控我用的是STM32F103ZET6，属于F103系列里的高密度型号。说实话，做门禁系统不一定要上ZET6，如果你手上的是C8T6或者RCT6，资源紧张一点但也不是不能用。选ZET6的核心原因是它的引脚数量充足，我后面要同时挂TFT液晶屏（FSMC接口）、指纹模块（串口）、蓝牙模块（串口）、RC522（SPI）、矩阵键盘（GPIO）、摄像头模块（DCMI接口），引脚不够的话就得频繁切换复用，调试起来非常痛苦。

另外一个选型逻辑是生态成熟度。STM32F103是市面上资料最多、教程最全的芯片，没有之一。不管是寄存器版还是HAL库版，遇到问题基本都能搜到答案。人脸识别部分虽然需要额外接一个协处理模块，但主控芯片本身不需要跑算法，负担可控，F103的72MHz主频应付这些外设的调度已经够了。

2.2 系统功能模块划分

整个系统的功能可以拆成四层来看。最底层是感知层，包括RC522射频模块、AS608指纹模块、4x4矩阵键盘、HC05蓝牙模块、OV2640摄像头。第二层是主控层，也就是STM32F103ZET6，负责读取所有感知数据、解析指令、维护状态机。第三层是执行层，包括电磁锁驱动电路、蜂鸣器、LED指示灯、OLED显示屏。第四层是数据层，这里我用的是AT24C02存储用户ID和权限列表，虽然容量只有2Kbit，但存几十组ID和权限标志足够了。

硬件连接上需要注意，STM32的默认JTAG引脚是PA13-PA15、PB3-PB4，如果这些引脚被你拿去接了别的外设，程序下载一次之后第二次就下载不进去了。我自己就踩过这个坑，把PB3接了指纹模块的复位脚，结果第一次烧录正常，第二次MDK直接提示找不到芯片。解决办法是禁用JTAG只保留SWD，在初始化代码最前面调用GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)，用SWD接口下载调试，这样就能省出PB3-PB4两个引脚。

2.3 供电设计的优先级

这是经验之谈，门禁系统的供电设计优先级甚至比代码还高。整套系统里电磁锁是最大的耗电设备，额定12V/1.5A，指纹模块峰值电流能到100mA以上，摄像头模块虽然电流不高但对纹波敏感，蓝牙模块工作电流在30mA左右。如果全部从一个USB口取电，电磁锁一吸合，电压跌落直接导致指纹模块重启，表现出来就是“刷卡正常，指纹怎么按都没反应”。

我的解决方案是分离供电：12V适配器直接给电磁锁供电，通过一个DCDC降压模块输出5V给STM32最小系统板和指纹模块，再用AMS1117从5V降到3.3V给RC522、OLED和蓝牙模块供电。摄像头模块单独从5V取电，避免和其他3.3V外设抢电流。电源地必须单点连接，防止形成地环路导致通讯异常。这个供电方案我实测跑了一个月没有出现一次异常重启。

3. 五种验证方式的模块选型与硬件接入细节

3.1 RFID刷卡模块：RC522的SPI时序和天线布局

RFID部分用的是MFRC522芯片的模块，读写M1卡。RC522支持SPI、I2C、UART三种接口，我选SPI是因为速率最高，读卡速度快，而且STM32的SPI1可以通过硬件NSS管理片选。接线方面特别注意IRQ引脚，很多人做的时候不接IRQ，靠轮询方式读卡，这在单卡场景下没问题，但一旦卡片靠近天线区域，轮询时机卡在别的外设处理上，就会漏掉读卡事件。我把IRQ接到了PA4，配置为外部中断输入，卡进入天线区域就触发中断，中断服务程序里置一个标志位，主循环检测到标志后再执行寻卡操作。

天线布局上有个容易被忽略的细节，RC522模块的天线区域正上方不要走电源线或信号线，铜箔会对射频场产生屏蔽效应。我最初画PCB的时候图省事，在模块天线正上方走了I2C的SDA线，结果刷卡的识别距离从原来的5厘米直接缩水到1厘米，怎么调整都恢复不了。后来重新布线避开天线区域，识别距离才恢复正常。

3.2 指纹识别模块：AS608的指令集和图像质量处理

AS608指纹模块是目前DIY项目里用得最多的光学指纹模块，通过串口发送指令包进行握手、录入、比对、删除等操作。它的指令格式是固定的包头+包长度+指令码+参数+校验和，初始化时必须先发送握手指令获取模块确认，之后所有操作都要等待模块返回应答包，不能连续发送指令，否则模块会丢指令。

实际调通后，我觉得指纹识别最影响体验的环节是录入指纹时要控制按压质量。AS608录入指纹需要连续按压4次，每次模块都会返回一个质量分数，低于阈值会直接返回“图像质量差”的错误码。很多用户按指纹的时候手指有汗或者按压角度不对，反复失败就很烦躁。我的做法是在OLED上实时显示当前按压的质量评分，低于40分就直接提示“重按”，不让用户白等。另外在代码里要做超时处理，默认等待3秒无操作就返回主界面，避免卡在录入流程里出不来。

3.3 密码键盘：矩阵键盘的去抖和组合键逻辑

密码输入用4x4矩阵键盘，16个按键承载数字0-9、确认、取消、退格、修改密码等功能。矩阵键盘有个老生常谈的问题就是按键抖动，我用的消抖方案是检测到低电平后延时20ms再确认一次电平状态，这样能滤掉绝大多数机械抖动。但消抖只是基础，真正需要设计好的是组合键逻辑，因为键盘上没有专门的“管理员模式”按键，我用“*+#+确认”作为进入管理员模式的组合键，用户首次使用需要先注册管理员指纹和密码。

密码存储方面，明文存储是不可取的，但STM32上跑AES加密又有点重，我采用了简单哈希的处理方式：将密码字符串通过MurmurHash算法生成32位哈希值存入AT24C02。校验时将输入密码再次计算哈希比对，即使存储芯片被拆下来读数据，也无法直接还原密码。这个方案在嵌入式场景下足够安全，而且运算开销极低。

3.4 蓝牙模块：HC05的AT指令配置和APP对接

蓝牙模块用HC05，主从一体，支持AT指令配置。这个模块网上说不稳定的人很多，但大部分情况下都是供电和电平问题，不是模块本身的问题。HC05的TXD/RXD是3.3V电平，直接接STM32的串口引脚没问题，但如果你用的是5V单片机或者通过USB转TTL调试，一定要确认电平匹配，否则会出现收发乱码。

配置HC05的AT指令集有个细节，进入AT模式需要按住模块上的按键再上电，此时模块的波特率会变成38400，而正常通讯的数据波特率是9600。这个切换导致很多人在配置完一次之后，重新上电发现又连不上了，其实就是因为AT模式和透传模式的波特率不一样。我后来把HC05的波特率通过AT指令统一设置为9600，这样AT模式和透传模式保持一致，调试体验好了很多。

手机APP我用的是BLE调试助手，自己写个简单的Android应用也可以，但如果是课程设计展示，直接使用现成APP能省去大量时间。

3.5 人脸识别模块：OV2640加协处理器的路子和纯OpenCV的区别

人脸识别是整个系统里计算量最大的部分。当时我面临两个选择：一个是在STM32上直接跑OpenCV人脸检测算法，另一个是外接一个专门的人脸识别协处理模块。先说结论，前者在F103上基本跑不动。

STM32F103的CPU频率只有72MHz，SRAM只有64KB，要在这样的资源上跑LBP或Haar特征的级联分类器，一帧320x240的灰度图检测耗时在2秒以上，而且精度非常低。更何况人脸识别还需要特征比对，这需要训练好的特征库和匹配算法，在F103上完全不可行。所以我的方案是选用了集成了人脸检测、特征提取、比对功能的协处理模块，摄像头用OV2640通过DCMI接口把图像传给协处理模块，模块内部完成检测和识别后通过串口把结果返回给STM32。

这个方案的优点是STM32只做指令下发和结果处理，不需要跑重计算。缺点是每个协处理模块自己的API有点封闭，而且价格比单纯用OpenCV贵。如果项目预算充足或者想做成本地训练模型的人脸识别，其实更好的方案是直接用树莓派或Jetson Nano跑Python+OpenCV+dlib，但在STM32这个题目下，协处理模块是更务实的选型。

4. 核心验证逻辑的实现：状态机设计、指令分发和失败处理

4.1 系统状态机设计

五种验证方式全部就位之后，最核心的设计任务就是把这五条验证路径融合到一个统一的状态机里。我用的是简化版状态机，系统共分为六个状态：待机态（IDLE）、密码验证态（PWD_CHECK）、RFID验证态（RFID_CHECK）、指纹验证态（FP_CHECK）、蓝牙验证态（BLE_CHECK）、人脸验证态（FACE_CHECK）。主循环里通过当前状态分发到对应的处理函数，每次验证流程结束，无论成功失败，最终都会回到待机态。

这里有个关键设计决策，我没有采用“先选验证方式再进入对应验证流程”的菜单式结构，而是把所有验证方式都放在待机态并行监听。也就是说，系统处于待机态时，RC522、AS608、蓝牙、键盘、人脸模块全部处于工作状态，任何一个模块触发事件都会将系统切换到对应验证状态。这样做的好处是用户不需要任何学习成本，拿起卡就刷，按了密码就验证，靠近摄像头就识别，贴近实际门禁的使用习惯。

4.2 多模块并行事件监听的处理方式

这里就涉及到一个单片机开发的经典问题了：多个外设都要实时响应，但CPU只有一个，怎么安排优先级？我的处理策略是中断+标志位+主循环轮询。所有能产生中断的外设都用外部中断或串口接收中断来置位自己的事件标志，主循环检测到某个标志后立即执行对应的验证流程，执行期间临时关闭其他中断服务程序里的置位操作，但不清空标志，等当前验证流程结束后再统一处理。

举个例子，用户在刷卡的瞬间另一只手按了键盘上的一个数字，这时RFID中断先触发，系统进入RFID_CHECK状态，同时键盘中断也置了位。当RFID验证失败，回到待机态后主循环会立刻检测到键盘事件标志，然后切换进入密码验证态。这样用户会感觉到系统“连读”了他两个操作，不会丢事件。这个细节在演示的时候观感特别重要，很多门禁产品给人“反应迟钝”的感觉，就是因为丢了用户的操作事件。

不过这里要提醒一点，中断服务函数里绝对不能做耗时操作，比如读卡、驱动OLED这种，只能在中断里置标志位，实际处理放到主循环。如果你在中断里调用HAL_Delay()，轻则系统卡顿，重则直接进入HardFault，连调试器都连不上。

4.3 验证优先级和权限分级设计

五种验证方式之间并非全等关系，我设置了优先级：人脸识别 > 指纹识别 > 密码 > 蓝牙 > RFID。优先级最高的不需要解释，人脸识别和指纹识别作为生物特征，安全性最高。密码和蓝牙作为半安全的验证方式，适合临时授权。RFID刷卡安全性最低，因为卡可以被复制，适合作为备用验证方式。

权限分级方面，系统里设置了两个级别：普通用户和管理员。普通用户只能执行开门操作，管理员可以执行添加用户、删除用户、修改密码、查询记录等操作。识别到管理员指纹或管理员密码后，系统自动进入管理员菜单，这时候LCD上会显示可操作的选项列表。这个设计让系统具备一定的可管理性，而不是一个纯演示的“刷一下就开门”的玩具。

4.4 验证失败处理策略

门禁系统的失败处理往往比成功处理更重要。初始版本里我的逻辑是验证失败就直接返回待机态，结果在实际使用中出现了两个问题：一是用户不知道验证失败的原因，以为系统坏了；二是连续被恶意尝试的时候没有任何拦截机制，安全性堪忧。

后来我加了三个机制。第一，每一次验证失败都在OLED上显示具体原因，包括“卡未注册”“指纹不匹配”“密码错误”等，3秒后自动清除。第二，连续5次验证失败后触发90秒锁定，锁定期间所有验证方式全部失效，OLED上显示倒计时，这个机制能有效延缓暴力破解。第三，所有验证事件带有时间戳，通过蓝牙查询历史记录的时候可以看到准确的操作时间和结果，这对事后排查很重要。

5. 实操过程中的关键调试经历：从单模块到系统联调

5.1 单模块调试阶段的踩坑记录

在把所有模块整合到一块板上之前，我先把每个模块分开调试，确保每个模块单独都能正常工作。这个过程听着简单，但实际踩了不少坑。

RC522模块的调试是最快的，因为SPI通信的底层库很成熟，直接用网上开源的MFRC522库，改一下引脚映射就能用。但要注意一个细节，RC522模块的SPI速率要控制在2MHz以下，速率太高会导致M1卡通信不稳定，表现为偶尔能读到卡偶尔读不到。这个问题的原因是MFRC522芯片本身的最大SPI时钟是10MHz，但不少廉价模块的PCB布线和天线匹配做得很随意，实际稳定工作频率远低于标称值。

AS608指纹模块的调试比较折磨人。模块的应答包严格区分大小包，不同指令的应答包长度不一样，如果你在接收缓冲区里直接按固定长度解析，很容易错位。我的解决办法是先把一整包数据接收完备再解析，接收完一个包头后，根据包头里的指令码和长度位动态计算应该接收多少字节，直到接收完整个包再处理。这种“攒包再处理”的思路在串口通信里非常实用，尤其是跟指纹模块、人脸模块这类“发一个指令回一长串数据”的设备打交道的时候。

蓝牙模块的调试前期一切顺利，后期遇到一个奇怪的问题：模块偶尔会变砖，表现为AT指令返回错误或者无法连接手机。排查了半天发现原因是我用USB转TTL连接HC05的时候，不小心让模块的EN引脚悬空，导致模块进入了不稳定状态。接一个10K上拉电阻到3.3V之后问题消失。

5.2 多模块集成时的资源冲突与稳定性问题

单模块调试通过后，把它们全部集成到一块主板上，第二个阶段的挑战才真正开始。

最大的问题是串口资源紧张。STM32F103ZET6有5个串口，但指纹模块、蓝牙模块、人脸模块各占一个，剩下的还得留一个给PC调试打印日志。我的分配方式是：USART1接指纹，USART2接蓝牙，USART3接人脸模块，USART4接调试串口。这样分配的原因很简单，USART1和USART2是默认引脚，不需要重映射，USART3用了PB10-PB11，同样不需要重映射，USART4用了PC10-PC11，也避免了和其他外设冲突。

资源冲突之外，信号完整性也是一个容易出问题的环节。OV2640的DCMI接口数据线有8根，加上PCLK、VSYNC、HREF，一共十几根信号线，如果这些线跟其他模块的信号线在PCB上平行走线过长，会产生串扰。最典型的故障现象是，摄像头模块工作时，指纹模块的串口偶尔会收到乱码。排查方法是用示波器观察指纹模块TXD线上的波形，发现摄像头工作时该引脚上有毛刺。解决方案是把摄像头的数据线包地处理，并在每个信号线上串联33欧姆的阻尼电阻，问题就解决了。

5.3 稳定性测试与优化

系统集成后，我做了48小时连续运行测试，目的是验证系统在长期运行下不会死机或出现内存泄漏。测试过程中发现一个问题，OLED显示屏在长时间显示同样的内容后会出现轻微的残影，这是因为OLED像素点长时间恒亮导致的。解决方法是开启OLED的屏幕保护功能，也就是说，在系统处于待机态超过30秒后，屏幕自动切换为“时钟界面”或直接熄灭，按键唤醒后再回到主界面。这样既省电又能减轻OLED残影问题。

另一个稳定性优化点在看门狗。系统跑着跑着总会有意外情况，比如指纹模块握手失败导致卡死在等待响应的循环里。我在主循环里加了一个独立看门狗（IWDG），每500ms喂一次狗，如果主循环执行时间超过500ms（说明死循环了），看门狗就自动复位系统。这个机制保证了即使出现极端情况，系统也能在1秒内自动恢复，不至于需要人工断电重启。

5.4 功耗优化与低功耗模式

门禁系统通常是7x24小时通电的，功耗是个必须考虑的指标。初始版本整机功耗在300mA左右，对于长期通电的设备来说确实偏高。我做了一些优化。

STM32的时钟配置上，将APB2总线上所有未使用的外设的时钟关闭，只保留正在使用的外设时钟。外设这一块，OLED和RC522在不工作的时候可以进入掉电模式，RC522模块有个软复位指令，可以进入PowerDown模式，这时候待机电流仅有uA级别。蓝牙模块可以通过AT指令进入休眠模式，但考虑到蓝牙模块需要随时响应手机连接，我没有采用休眠方案。综合下来，整机待机功耗从300mA降到了约150mA，主要功耗集中在蓝牙模块、摄像头模块和OLED上。

对于电池供电的便携场景，可以考虑进一步的深度休眠方案，用定时器唤醒+RTC时钟中断的方式让系统在无操作时进入STOP模式，但这个方案还没有在这个项目中完整实现，就不展开讲了。

6. 常见问题排查方法与实践经验速查

6.1 问题排查思路总览

这里把我实际调试中遇到过的问题以及排查思路整理成表格，方便大家直接对照。很多问题看起来症状一样，实际上根因完全不同，排查时要先从供电和外设冲突入手，再分析代码逻辑。

6.2 几个需要特别注意的实操细节

• 电源设计上，建议在STM32的3.3V电源引脚旁边放至少两个100nF的陶瓷电容，并且靠近引脚放置，一个耐压稍微高一点的10uF钽电容做储能。不要为了省元件把这几个电容省掉，单片机工作不稳定往往就是因为旁路电容缺失。

• 接线方面，所有外设的GND必须和STM32的GND共地，否则串口通信和SPI通信都会出现无规律丢包。我见过有人只接了信号线和电源线，没接地线，然后到处问为什么数据收发不正常，这种基础问题必须先排除。

• RC522模块建议使用3.3V供电，不要接到5V上，虽然很多模块板载了电平转换芯片，但长期5V供电会导致芯片温度升高，进而影响射频稳定性。

• 指纹模块的录入指纹和比对指纹需要在相同的光线条件下进行，如果环境光变化非常大（比如从室内走到室外），指纹模块的比对成功率会明显下降。产品化的时候需要考虑给光学指纹模块增加遮光结构。

• 蓝牙配对的问题上，HC05的默认配对密码是1234，如果手机连接不上，先确认模块是不是进入了AT模式（AT模式下无法配对），再确认手机蓝牙缓存里是否有旧的配对记录，最好清除缓存后重新搜索。

7. 后续扩展方向和一些额外的思考

系统做到这里，已经具备了一个完整门禁产品的基本形态。但如果你有精力继续往深做，我建议可以从三个方向扩展。

第一，增加云平台联动。当前系统的所有验证记录都存在本地AT24C02里，容量有限而且查询不便。如果增加一个ESP8266模块，通过串口连接到STM32，就可以把验证记录上传到云平台，实现远程查询和远程授权。这个方向的门槛不高，ESP8266的AT固件直接能和STM32通信。

第二，增加更丰富的人机交互。当前我用的OLED已经能显示基本信息，但如果换成带触摸的串口屏，可以让管理员操作界面变成图形化菜单，体验会好很多。串口屏的集成难度不大，只是成本会高一些。

第三，将人脸识别升级为本地端到端方案。如果用更强的MCU，比如STM32H743或者直接用树莓派CM4，就能在本地跑完整的深度学习人脸识别流程，不需要外接协处理模块。这条路性能更强，但开发和调试复杂度也会明显上升，需要你对Linux环境和模型部署有一定的经验。

门禁系统的核心安全逻辑，其实不只是验证方式本身的安全性，还包括混合验证策略的灵活性。比如说，你可以在此基础上增加“双重验证模式”——要求用户先刷卡再按指纹才能开门，这对于高安全等级的场景非常有用。在现有状态机代码结构上，增加这种复合验证流程，改动量并不大。

多验证方式的融合系统，最大的价值不是把五种硬件堆在一起炫技，而是通过这一套流程，真正理解嵌入式系统如何处理多外设并发、如何做状态管理、如何在资源受限的条件下实现相对复杂的业务逻辑。把这些能力掌握住，换个场景做智能家居网关、做工业数据采集器，思路都是相通的。

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