看到“源码原理图”同时开源第一反应是这个项目值得完整复盘。STM32口罩识别门禁系统不是那种只给一段算法 demo 的教程资源它把口罩识别、门禁控制、状态显示和现场报警串在了一起覆盖从视觉识别到门锁执行这条完整链路。对正在做嵌入式课设、毕业设计或者在实验室想低成本搭一套门禁验证环境的人来说这类资料比单纯刷一个 LED 或者点一个屏幕要有用得多。这套项目资料编号是 0465A免费开源内容明确包含两部分工程源码和硬件原理图。源码解决“程序怎么写、逻辑怎么跑”的问题原理图解决“板子怎么画、元器件怎么接”的问题。两样东西放在一起意味着你不需要从零猜电路也不需要反向破解固件拿到资料后就可以沿着作者的实现路径去做二次修改。本文会从系统架构、原理图拆解、源码模块划分、串口对接、Keil 编译烧录、功能测试到常见问题排错把这套项目从头到尾拆一遍。1. 项目定位与核心能力速览先看基本信息。这套口罩识别门禁系统核心功能是在人员进入门前先判断“是否佩戴口罩”根据识别结果控制门禁动作。识别到佩戴口罩则允许开门未佩戴口罩则被拒绝同时给出明显的声光提示。整个系统围绕“视觉识别 门禁控制”两个中心展开视觉端负责把图像转换成结构化结果控制端负责根据结果驱动继电器、电磁锁、蜂鸣器、OLED 显示这类外设。从开源资料的使用角度看这套项目的定位是学习和验证不是一款可以直接大量生产的商业产品。它的价值在于提供一套可运行的最小系统让嵌入式开发者在普通开发板上体验“算法模块与主控模块联动”的完整流程。由于主控端和控制逻辑完全在源码里开放你可以很方便地调整开门时长、报警阈值、串口波特率、GPIO 引脚定义等参数也可以往上面叠加读卡器、指纹模块、语音播报、数据上报等功能。能力项说明项目类型嵌入式门禁系统STM32 主控 视觉识别模块开源内容源码 原理图资料编号 0465A核心功能口罩识别、门锁控制、蜂鸣器报警、OLED 状态显示主控平台STM32 系列常见为 STM32F103C8T6 或 STM32F407ZGT6以资料标注为准视觉平台常见采用 OpenMV、K210 等视觉模块与 STM32 通过串口通讯开发工具Keil MDK5、STM32CubeMX、视觉模组对应 IDE硬件工程原理图可用于核对接线也能作为画 PCB 的参考适合人群嵌入式初学者、课设/毕设学生、门禁类项目二次开发者商业落地不建议直接量产更多用于功能验证与学习这里的核心认知是单纯讨论“STM32 能不能识别口罩”没有意义。STM32F103C8T6 只有 72MHz 主频和约 20KB 的 RAM跑轻量级图像处理都很紧张更不要说在上面跑一个可用的口罩识别模型。所以主流做法是让视觉模块干重活STM32 干控制活两块板子结合起来。这个分工也正是整套原理图和源码设计的关键所在。2. 系统架构谁做识别谁做门禁控制这套口罩识别门禁系统的整体工作流程可以概括为摄像头采集画面视觉模块识别画面内的人脸与口罩状态把识别结果打包成串口数据STM32 收到数据后解析并执行门禁逻辑最终驱动电磁锁或舵机开门。流程环节负责硬件输出图像采集摄像头/视觉模组RGB 图像帧口罩检测视觉模块内部算法/模型是否佩戴口罩、置信度消息传递串口 UART自定义协议帧逻辑仲裁STM32 主控开门/拒入/报警执行动作继电器、电磁锁、蜂鸣器门锁动作与声光提示人机交互OLED、按键、指示灯当前状态与提示这种架构的优点很明确。第一责任边界清楚视觉模型和门禁业务互不干扰。你想换一个更强的口罩识别模型只需要动视觉端STM32 端接收的串口格式不发生变化你想把识别结果用于考勤记录也只需要在 STM32 端增加逻辑不必重新处理图像。第二实时性好STM32 作为主控可以很快响应串口事件门锁动作在毫秒级完成不会因为等待图像处理而导致开锁延时。第三成本可控视觉模块和 STM32 都可以选择常见的低成本开发板整体物料适合学校实验室使用。有人会问能不能直接把视觉识别放在 STM32 上做单芯片方案如果用的是 STM32H7、STM32MP1 或者加了外部 NPU 的高性能板子确实可以但那就不属于入门级课设的常规路线。从这套资料的关键字看它更贴近“K210 与 STM32 通讯”这种双芯片并行方案。K210 内部集成 KPU对口罩检测这类目标识别任务比较合适STM32 再负责稳定可靠的门锁控制。两块芯片处理各自擅长的任务比强行把它们塞到同一颗低性能 MCU 里要合理得多。3. 原理图拆解从电源到电磁锁驱动拿到原理图以后不要急着去看 CPU 有多少个引脚先按“电源、主控最小系统、摄像头接口、门锁驱动、外设交互”这几个区块去拆。开源原理图里通常会把不同功能模块画在不同页面或者用区域框线分隔开。如果原图是按单片集成画在一起的就要依靠网络标号来追踪连接关系。3.1 电源模块电源是整个系统的基础。常见的供电方式有两种一种是用 USB 的 5V 给主控板供电另一种是外部 12V 给电磁锁供电同时经过降压给主控板供电。原理图里需要关注三个关键点主控板逻辑电源一般是 3.3V由稳压芯片从 5V 转换得到。如果原图中采用 AMS1117-3.3 这类 LDO输入输出电容不要漏掉典型接法是输入 10uF 0.1uF输出 10uF 0.1uF。虽然这只是常规电路但很多自制板画错地方导致供电纹波偏大会直接让下载器识别不到芯片。电磁锁这类大功率负载最好不要从 MCU 的 3.3V 电源上取电。如果原理图设计里锁的电源是独立接口说明作者已经做了电源隔离处理。你要做 PCB 时也尽量把大电流回路和信号回路分开走线避免继电器动作瞬间拉低模拟电压。电源地线必须共地。STM32 的 GND、视觉模块的 GND、继电器驱动的 GND 最终要连接在一起否则串口信号电平没有公共参考点通讯会时好时坏。源码上表现为“视觉模块明明在工作STM32 却一直接收不到数据”硬件上查来查去其实就是地线悬空。3.2 STM32 主控最小系统主控最小系统是原理图中最基础的部分通常包含电源引脚、复位电路、晶振电路、启动模式选择、调试下载接口。以常见的 STM32F103C8T6 为例复位引脚 NRST 一般通过 10K 电阻上拉到 3.3V同时并联一个 100nF 电容到地BOOT0 通过电阻下拉到地正常运行模式从 Flash 启动SWD 下载接口的 SWDIO、SWCLK 要引出来方便连接 ST-Link。晶振电路要特别检查。STM32F103 的 HSE 典型接法是 8MHz 晶振配上两个负载电容常见取值是 10pF 到 20pF 左右具体以晶振规格和芯片数据手册为准。很多入门板为了减少元件把 HSE 省略直接用内部 HSI 时钟运行但某些源码中如果配置了外部晶振省略 HSE 会导致程序启动卡死在时钟初始化里。使用这套资料前先对照原理图确认晶振是否焊接、起振电容是否在板上。3.3 门锁驱动电路门禁执行部分有两种常见设计原理图上的差别很大。第一种是使用继电器模块STM32 GPIO 输出高电平或低电平控制继电器线圈继电器触点再控制电磁锁电源通断。这种接法比较安全驱动部分和负载部分隔离程度高。第二种是直接用三极管或 MOS 管驱动例如使用 NPN 三极管控制继电器或者用 MOS 管直接控制 12V 电磁锁回路。无论采用哪种都要看原理图中是否给感性负载并联了续流二极管。电磁锁本质是一个大电感断电瞬间会产生反向电动势。如果没有续流二极管反冲电压可能击穿三极管或 MOS 管也会导致 STM32 复位。源码程序写得再好硬件驱动电路不稳定门禁系统也会在长时间测试中频繁失灵。3.4 视觉模块与摄像头接口视觉模块通过串口和 STM32 通讯原理图上会用 TX、RX 网络标号标出。对接时记住一个原则A 的 TX 接 B 的 RXB 的 TX 接 A 的 RX也就是交叉连接。很多新手拿到原理图后容易盲目照抄如果视觉模块接口端标注为 STM32_TX2那么这一根线要接到视觉端的 RX 引脚不要对错。有部分设计会在串口之间加上电平转换芯片比如 SP3232、MAX3485 之类用于 RS232 或 RS485 远距离传输。如果只是开发板上近距离调试一般直接 TTL 电平互连就够了。这部分在原理图上要看清用的是哪种接口如果是 RS485 半双工程序里就需要额外控制收发方向引脚不能用普通串口初始化的方式直接收发。3.5 OLED、按键、蜂鸣器等交互外设OLED 显示通常采用 I2C 接口SCL 和 SDA 两根线接 I2C1 或软件模拟 I2C 的 GPIO。OLED 模块常见地址是 0x3C如果源码初始化后屏幕全白或没反应可以先用 I2C 扫描工具确认设备地址。按键和蜂鸣器比较简单按键一端接 GPIO另一端接 GND 或 VCC配合软件内部上拉/下拉使用蜂鸣器如果有源蜂鸣器给高电平就响无源蜂鸣器则要用 PWM 驱动。拿到开源原理图后第一遍读图顺序应该是找电源输入点看稳压芯片输出找 MCU 最小系统确认晶振和复位找串口接口追踪 TX/RX 网络标号找继电器或电锁驱动确认是模块还是分立器件。按照这个顺序读完就不会出现拿到原理图不知道从哪里下手的窘境。4. 源码结构STM32 工程和视觉工程怎么组织这套系统的源码通常会分成两个工程一个跑在 STM32 上一个跑在视觉模块上。如果资料包里把两个工程都给你了那就是最理想的情况直接对照阅读即可。如果只有一个 STM32 工程那视觉模块端可能只提供固件或模型文件你需要通过串口协议反推视觉端发送的数据含义。一个比较典型的源码目录结构如下MaskAccess/ ├── STM32_Code/ │ ├── Core/ │ │ ├── Inc/ │ │ └── Src/ │ ├── Drivers/ │ │ ├── CMSIS/ │ │ └── STM32F1xx_HAL_Driver/ │ ├── User/ │ │ ├── main.c │ │ ├── uart_protocol.c │ │ ├── door_control.c │ │ ├── oled_display.c │ │ └── buzzer.c │ └── MDK-ARM/ │ └── MaskAccess.uvprojx ├── Vision_Code/ │ ├── OpenMV/ │ └── K210/ ├── Hardware/ │ ├── STM32_Mask_Access.SchDoc │ └── BOM.csv └── Docs/ └── UserManual.pdf目录里的User文件夹往往是作者自定义逻辑的集中地。看源码时先打开main.c找到主循环和初始化函数再顺藤摸瓜打开各个外设文件。不要一上来就去读 HAL 库底层驱动那样很容易迷失在海量结构体里。STM32 端的功能逻辑比较合理的拆分方式是串口接收文件负责接收和校验视觉模块结果门控文件负责继电器开关和定时关门OLED 文件负责界面刷新蜂鸣器文件负责报警音提示。主循环负责调度这些模块识别串口是否有新帧到达需要开门就切换门控状态不需要开门就继续等待。所谓状态机就是把门禁系统的工作过程分成若干个稳定状态。正常待机时处于 IDLE收到佩戴口罩结果后进入开门流程开门到达限定时间后自动恢复待机收到未佩戴口罩结果则触发报警提示。这样写的好处是程序不会因为某个延迟函数卡死而错过下一帧识别结果。很多课设程序喜欢用HAL_Delay做延时但如果在主循环里用HAL_Delay阻塞 5 秒等待关门那视觉模块发来的新识别结果就无法及时处理。这个问题在门禁系统里尤为明显当一个人刚刷完脸进门另一个人紧跟着出现在摄像头前系统卡在门锁延时里第二个人就识别不了。更合理的做法是使用定时器记录溢出时间而不是用阻塞延时函数。视觉端的源码通常负责摄像头初始化、加载模型、循环推理、串口发送四件事。OpenMV 平台用 MicroPython 编写K210 平台根据型号可能用 MicroPython 或者 C 开发。源码的入口一般都比较短因为模型推理部分被封装在库函数中你只需要找到调用模型检测并生成结果的函数然后在结果后拼接协议帧发送即可。5. 串口通讯协议两端对接的关键在口罩识别门禁系统中视觉模块和 STM32 能不能对接成功几乎完全取决于串口协议是否一致。很多项目跑不通不是因为代码编译失败而是视觉端发送的数据格式和主控端解析的数据格式对不上。要么波特率不同要么帧长度不同要么校验方式不同。源码中如果自己定义了协议应该先去读协议部分的注释确认每个字节的含义。为什么要自定义协议而不是直接发送字符串直接发送类似“1”或者“0”的 ASCII 字符虽然简单但实际工程里很容易出问题。镜头前没有人的时候发什么识别置信度低于阈值的时候发什么表情包图片或者误检结果会不会导致开关门抖动如果直接用单个字符后续加时间戳、坐标、置信度、人员编号都要改协议维护成本很高。所以更稳的方式是设计一帧固定长度的二进制协议包含帧头、类型、数据、校验、帧尾。下面是一种非常简化的协议示例字节位置内容说明Byte00xA5帧头Byte1MaskState1 表示佩戴口罩0 表示未佩戴口罩0xFF 表示无人Byte2Reserved预留字节可放置信度或目标数量Byte3CheckSumByte1 到 Byte2 的校验和Byte40x5A帧尾使用固定长度为 5 字节的协议帧比发送任意长度的字符串更容易在 STM32 上做状态机接收。MCU 只需要按字节接收先判断当前是否处于等待帧头状态收到帧头后再累计接收直到帧尾或长度溢出。源码中可能会使用 DMA 加空闲中断也可能使用简单的串口接收中断具体实现要看作者选用的 STM32 型号。STM32 接收解析的示例思路如下#define FRAME_HEAD 0xA5 #define FRAME_TAIL 0x5A #define RX_FRAME_LEN 5 uint8_t g_rxBuf[RX_FRAME_LEN]; uint8_t g_rxCnt 0; uint8_t g_maskFlag 0xFF; void UART_RxByteHandler(uint8_t byte) { // 未开始接收时只认帧头 if (g_rxCnt 0 byte ! FRAME_HEAD) { return; } if (g_rxCnt RX_FRAME_LEN) { g_rxBuf[g_rxCnt] byte; g_rxCnt; } if (g_rxCnt RX_FRAME_LEN) { // 检查帧尾和校验 if (g_rxBuf[RX_FRAME_LEN - 1] FRAME_TAIL) { uint8_t sum 0; for (uint8_t i 1; i RX_FRAME_LEN - 2; i) { sum g_rxBuf[i]; } if (sum g_rxBuf[RX_FRAME_LEN - 2]) { g_maskFlag g_rxBuf[1]; } } g_rxCnt 0; memset(g_rxBuf, 0, RX_FRAME_LEN); } }视觉模块端的发送代码以 OpenMV 平台为例可以这样组织import sensor import time from pyb import UART sensor.reset() sensor.set_pixformat(sensor.RGB565) sensor.set_framesize(sensor.QVGA) sensor.skip_frames(30) sensor.set_auto_gain(False) uart UART(3, 115200) FRAME_HEAD 0xA5 FRAME_TAIL 0x5A while True: img sensor.snapshot() # 这里应为实际模型推理位置 # 判断结果会写入 mask_state1 表示佩戴口罩0 表示未佩戴口罩 mask_state 1 data bytearray([FRAME_HEAD, mask_state, 0x00, 0x00, FRAME_TAIL]) # 示例中对校验字节填了 0实际工程应按数据字节计算校验和 uart.write(data) time.sleep_ms(100)上面的代码重点是展示两端如何约定帧格式。需要特别说明真实模型推理不是一行注释就能完成的。OpenMV 上要先用 IDE 烧录对应的口罩检测模型然后在循环中调用模型接口得到检测框和分类结果再判断是否戴口罩。K210 上的逻辑类似调用 KPU 加载.kmodel文件检测到目标后再返回坐标和置信度。具体代码以源码为准不要把示例协议直接当成原工程代码使用。6. 环境搭建与烧录让代码跑起来拿到一个 Keil 工程后第一件事不是马上修改代码而是先把工程完整编译一遍。如果作者提供了 .uvprojx 工程文件直接用 Keil MDK5 打开。看到 Device 型号与你的开发板不一致时先对比芯片型号是 STM32F103C8T6 就需要在 Manage Run-Time Environment 或 Device 选项里选择对应型号。如果直接换了一个不同系列芯片引脚定义和外设时钟都会变程序不一定能编译通过。6.1 安装必要组件编译 STM32 工程通常需要安装对应的器件 Pack。打开 Keil 的 Pack Installer查找 STM32F1 系列或 STM32F4 系列并安装。缺少 Pack 时编译会报device not found一类错误那不代表源码有问题而是开发环境缺少芯片支持包。工程如果使用了 HAL 库还需要确认 Keil 的编译器版本与原工程兼容。老工程用 AC5新工程默认可能是 AC6。AC5 和 AC6 对代码的检查严格程度有区别某些源码变量声明放在 for 循环内部AC6 可能直接报错不一定是源码本身错误。遇到编译问题先看编译器版本和宏定义是否与原工程说明一致。6.2 编译工程在 Keil 中点击 Build 按钮观察 Output 窗口。编译完成后会显示生成的目标文件大小。如果工程开启的是调试版本会生成.axf和.hex文件。编译期间如果出现缺少头文件比如stm32f1xx_hal_conf.h找不到检查工程 Include Path 是否包含对应文件夹。很多从别人电脑拷贝过来的工程头文件路径是绝对路径换电脑后路径失效需要在 Options for Target 的 C/C 页面重新添加相对路径。6.3 烧录 STM32烧录方式有 ST-Link、J-Link、串口 ISP 等。对入门级开发板ST-Link 最方便。连接好 SWDIO、SWCLK、GND、3.3V 四根线之后在 Keil 的 Debug 设置里选择 ST-Link Debugger然后点击 Download。如果连不上目标芯片先检查驱动是否安装、接线是否松动、板子供电是否正常、BOOT0 跳线是否设置成 Flash 启动。如果使用 STM32CubeProgrammer也可以直接在命令行按下面方式烧录实际路径要替换成你自己的工程输出文件STM32_Programmer_CLI.exe -c portSWD modeNORMAL resetHWrst \ -w .\MDK-ARM\MaskAccess.hex -v视觉模块端的烧录则要看平台。OpenMV 工程在 OpenMV IDE 中打开.py文件连接 USB 后点击运行。K210 工程如果使用 MaixPy IDE也是连接后运行如果使用 Kendryte IDE 或命令行工具需要把编译出的固件通过烧录工具写入 Flash。核心步骤是先确认摄像头能否出图再烧录模型最后运行代码。不要一股脑把模型和程序烧进去后才发现摄像头初始化失败。7. 功能测试与效果验证源码烧录完成后不能只看编译通过就认为系统正常需要设计一套测试用例来验证门禁逻辑。测试环境建议放在桌面或实验台上先用普通直流电源或 USB 供电测试控制逻辑不要一开始就接真实的 220V 电磁锁。你可以用一个 LED 代替继电器输出或者用万用表测量 GPIO 电平变化先确认程序行为再接入真实负载。测试项输入条件预期结果通过标准主控启动上电复位OLED 显示初始界面或门禁状态屏幕不白屏蜂鸣器不异常长鸣口罩识别成功视觉模块前出现佩戴口罩的人脸串口收到 MaskState1STM32 控制继电器吸合锁动作持续设定时间后自动释放未佩戴口罩视觉模块前出现未佩戴口罩的人脸串口收到 MaskState0门锁不动作蜂鸣器或指示灯给出提示锁保持关闭无人在镜头前摄像头看不到目标或置信度过低系统回到待机状态不产生误开门脉冲连续识别多次切换是否佩戴口罩门禁状态稳定跟随识别结果不出现偶发反转或串口帧错乱距离变化从 0.5 米到 2 米范围内测试在合理距离内识别稳定过远时允许拒识但不能乱开门判断这套系统是否成功的核心标准不是屏幕上显示出的字符而是 STM32 是否根据协议帧产生正确的控制输出。如果视觉模块显示识别到了口罩但 STM32 端的继电器不动问题往往出在串口协议或 GPIO 配置上而不是出在模型识别能力上。这时就可以在 STM32 端临时添加调试日志把收到的每一字节通过另一个串口打印出来或者用 USB 转 TTL 工具接在视觉模块 TX 线上监听原始数据。比较简单的验证方法是在 STM32 收到戴口罩结果后让开发板上的 LED 翻转收到未戴口罩结果后让另一个 LED 翻转。这种方式成本低能在不上锁的情况下快速确认链路是否通畅。确认无误后再把继电器接上观察门锁动作。每次测试之间留出足够的间隔避免继电器频繁通断导致触点温度升高。测试项目里还要加入“无人误判”场景。很多口罩识别模型在没有人脸时会输出一些误检如果 STM32 端不判断置信度只看到数值 1 就开门容易出现门锁自己弹开的情况。源码中如果视觉端能区分“有人戴口罩”“有人未戴口罩”“无人”三种状态主控端就一定要对这个状态做完整的分支处理而不是简单把非 0 当成开门信号。8. 资源占用与稳定性观察嵌入式项目不讲显存讲的是 Flash、RAM、帧率和实时性。程序跑起来以后主要观察两类资源一类是 STM32 编译产物的片段大小另一类是视觉端识别的帧率和延迟。打开 Keil 的 Build Output 窗口可以看到类似下面这种信息Program Size: Code12340 RO-data448 RW-data96 ZI-data8464如果芯片是 STM32F103C8T6Flash 为 64KBRAM 为 20KB。Code RO-data RW-data 不要超过 Flash 容量RW-data ZI-data 不要超过 RAM 容量。如果工程配置完 OLED、串口、定时器等多个外设后 ZI-data 偏大通常是因为在源码中定义了大数组或者使能了大量缓冲区。对于主控资源紧张的工程尽量把图像缓冲、协议缓冲放到视觉端STM32 端只保留必要的小数组。视觉端主要关注推理耗时。使用 OpenMV 或 K210 时IDE 控制台通常能显示程序运行时间。如果一帧推理耗时超过了 1 秒门禁系统日常体验会很差通行效率跟不上。可以通过降低分辨率、使用更小的模型、提高置信度阈值、减少全图扫描区域等方式优化。比较常见的做法是先把人形或人脸候选框检测出来再对候选框区域做口罩分类而不是对整幅图像逐像素扫描。系统稳定性还体现在长期运行上。门禁设备可能需要连续通电数小时甚至数天如果程序里频繁申请内存却不释放或者状态机在异常分支死循环就会出现越跑越卡、门禁失效的现象。常见的改进是加一个简易看门狗用 STM32 的独立看门狗 IWDG 定时喂狗。主循环正常运行时周期重置看门狗如果程序卡死看门狗超时将自动复位芯片。但要注意喂狗位置不能放在中断里否则主逻辑卡死时中断还在喂狗就检测不到异常了。9. 常见问题与排错清单实际搭建这类系统时最耗时间的不是代码编写而是“编译过了但运行不对”的排查阶段。下面按常见程度整理了问题清单。问题现象可能原因排查方式解决方案Keil 编译报 device not found缺少器件 Pack 或芯片型号不匹配查看工程 Device 设置安装对应 Pack选择正确型号下载提示 cannot access targetSWD 接线错误、板子没供电、BOOT0 被拉起检查四线连接和供电电压重新接线BOOT0 拉低后复位再试烧录后 OLED 白屏I2C 地址不对或 GPIO 配置错误扫描 I2C 设备地址核对源码引脚把软件地址改成 0x3C 或按原理图调整视觉模块能识别但 STM32 不动作串口引脚接反或波特率不一致用串口监听工具抓 RX 数据交叉 TX/RX统一波特率继电器频繁抖动发送周期过短或状态判断过于灵敏加串口日志查看协议帧变化在 STM32 端增加连续多帧确认逻辑只有在靠近摄像头时才识别模型被缩小或分辨率过低检查视觉端图像预处理缩放区域调整检测区域和输入分辨率未戴口罩也能触发开门模型置信度低时误检查看置信度输出提高识别阈值增加关键帧计数OLED 反复闪烁I2C 总线上同时挂多个设备且速率太高降低 I2C 速率将 I2C 时钟从 400K 降到 100K电磁锁吸合后无法释放继电器触点粘连或驱动管被击穿万用表测量继电器线圈电压检查续流二极管和驱动管型号串口收不到数据是最常见的两边对接问题。排查时要先用逻辑分析仪或 USB 转 TTL 串口工具单独监听视觉模块的发送端看它是否真的在发送数据。如果视觉模块已经在发送但 STM32 收不到就去查 STM32 的串口引脚配置和中断是否开启。很多 HAL 库工程默认只初始化串口没有调用接收中断启动函数导致数据一直到达硬件寄存器但程序无法感知。某些源码在main()中会调用类似HAL_UART_Receive_IT()的接口实际工程要以源码为准检查是否漏了这一句。门禁逻辑不稳定时不要反复改代码先记录触发前的环境状态和上一次串口帧数据。给一张 A4 纸画个时间线哪一帧触发了开门哪一帧没有触发继电器动作时刻距收到帧的时间差是多少。有了日志和运行时间线才能判断是模型误判问题、协议丢帧问题还是驱动电路响应问题。没有日志就凭感觉改代码很容易把原本正常的协议解析也改坏。10. 二次开发方向与合规建议跑通这套源码之后下一步不只是停留在演示。你可以基于现有逻辑做很多实际扩展把整套门禁系统打磨成更适合真实场景的设备。第一个方向是增加身份识别能力。目前系统只判断“有没有戴口罩”无法记录“是谁在什么时候进入”。可以增加 RFID 读卡器模块例如 RC522让人员在刷卡的同时完成口罩检测只有“已授权卡片 佩戴口罩”两个条件同时满足时才能开门。STM32 的串口协议也可以扩展帧类型把视觉端的结果和读卡结果合并进同一套仲裁逻辑。第二个方向是升级视觉端算力。如果后续要从口罩识别升级到更完整的“人脸识别门禁系统”可以考虑使用 RK3588 这类更高算力的平台。RK3588 可以运行更完整的人脸检测、人脸对比和口罩识别模型STM32 继续承担底层门锁控制和传感器采集双板之间的串口协议仍然可以沿用。对实验室项目来说这种循序渐进的做法比直接换平台重新开发更稳。第三个方向是加上云平台或上位机记录。STM32 可以把每一次开关门事件通过串口或网络模块发送到上位机支持考勤、来访记录查询、异常开门报警等功能。上位机界面可以选择简单的 QT 或者 Web 后端以 JSON 格式接收 STM32 上报的数据。开发通信协议时注意增加设备编号和事件时间避免以后接入多台门禁后无法区分数据来源。在合规方面这类门禁项目有几个必须注意的边界。口罩识别会采集摄像头画面即使模型只输出口罩