1. 从零拆解一个带指纹和蓝牙的STM32门禁项目
智能门禁这个东西，听起来像是小区物业才会关心的设备，但真正动过手的人都知道，它其实是嵌入式入门到进阶的一条黄金练手路线。原因很简单：它同时踩中了输入采集、身份校验、执行控制、数据存储、无线通信这五个嵌入式最核心的模块，而且每一个模块都有足够多的坑让你踩。我前后做过三版基于STM32的门禁方案，从最早的纯密码键盘，到后来加指纹模块，再到最后把蓝牙也塞进去做手机端管理，每一版都让我对"稳定"这两个字有了新的理解。
这篇文章面向的是手里有STM32开发板、想做一个能真正跑起来而不是只点亮LED的门禁系统的朋友。不管你是电子类专业的学生在做课程设计，还是刚转行嵌入式的工程师想找个完整项目练手，这套方案都能直接参考。我会把密码验证、指纹识别、蓝牙通信这三条链路从硬件选型到代码逻辑全部拆开讲，重点放在那些教程里不会写、但实际调试时一定会遇到的问题上。
先说清楚这个系统的整体定位：它不是一个工业级产品，而是一个功能完整、逻辑闭环、可扩展的原型系统。核心控制器用STM32F103系列就够，外接矩阵键盘或触摸键盘做密码输入，指纹模块走UART，蓝牙模块也走UART，电磁锁或继电器做执行机构，再加一块OLED或LCD做状态显示。听起来模块不多，但当你把四个UART设备挂到同一颗芯片上时，资源分配和中断优先级的问题就会立刻暴露出来。
提示：本文所有方案基于常见工程实践补充，具体引脚和参数请以你手头模块的数据手册为准，不要照搬引脚号。
2. 主控选型与资源分配：为什么F103C8T6是甜点而不是妥协
2.1 三款常见主控的横向对比
很多人一上来就问"用F103还是F407"，这个问题本身没有标准答案，关键看你系统里最吃资源的部分是什么。门禁系统的资源消耗大头不在运算，而在外设数量和中断响应。我整理了一张对比表，是我实际用过的三款芯片在这个项目里的表现：
| 芯片型号 | 主频 | UART数量 | Flash | 指纹+蓝牙+调试串口 | 实际体验 |
|---|---|---|---|---|---|
| STM32F103C8T6 | 72MHz | 3 | 64KB | 刚好够用 | 性价比最高，但UART要精打细算 |
| STM32F103RCT6 | 72MHz | 5 | 256KB | 充裕 | 引脚多，适合加屏幕和存储 |
| STM32F407VET6 | 168MHz | 6 | 512KB | 非常充裕 | 性能过剩，成本翻倍 |
F103C8T6只有3个USART，而指纹模块、蓝牙模块、调试串口正好占满3个。如果你还想加一个GSM模块或者第二个指纹模块，就必须换RCT6。我第一版就是用C8T6，结果调试串口和蓝牙抢USART1，折腾了半天才改成蓝牙走USART2、指纹走USART3、调试走USART1重映射。
2.2 时钟树配置里最容易翻车的地方
F103的时钟配置看起来是模板代码，但门禁系统对串口波特率精度要求比较高，尤其是指纹模块，波特率偏差超过2%就可能出现校验错误。外部晶振必须用8MHz，PLL倍频到72MHz，然后APB1分频系数设成2，这样USART2和USART3挂在APB1上得到36MHz时钟，波特率计算才准确。
如果你用的是内部HSI做时钟源，串口在高波特率下会累积误差，指纹模块偶尔能通、偶尔超时，这种间歇性故障最难查。我的建议是：只要板子上有8MHz晶振，就一定要用HSE，别图省事用内部时钟。
// 关键时钟配置片段（标准库） RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_USART1, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2 | RCC_APB1Periph_USART3, ENABLE); // APB1 = 36MHz，USART2/3波特率寄存器按36MHz计算2.3 中断优先级的分层设计
三个UART同时工作，中断优先级如果乱设，会出现指纹数据被蓝牙中断打断导致丢包的情况。我的分配原则是：指纹 > 蓝牙 > 调试串口。指纹模块的数据包是定长的，一旦丢字节整个包就废了；蓝牙数据可以容忍轻微延迟；调试串口最不重要。
在NVIC里，指纹USART3设抢占优先级1，蓝牙USART2设抢占优先级2，调试USART1设抢占优先级3。这样指纹中断永远能打断蓝牙，保证指纹识别的实时性。
3. 指纹模块的选型与UART通信实战
3.1 光学式还是半导体式：别只看价格
市面上常见的指纹模块分两类：光学式和半导体式。光学式便宜、耐用、对环境光不敏感，但识别速度慢，手指有汗或脱皮时容易失败；半导体式识别快、体积小，但对静电和潮湿敏感，冬天干燥时经常识别不了。
门禁场景我推荐光学式，比如常见的R307、FPM10A这类。原因很实际：门禁装在户外或门口，温差和湿度变化大，半导体式在这种环境下故障率明显更高。光学式虽然慢个两三百毫秒，但胜在稳定。
| 类型 | 识别速度 | 抗环境干扰 | 价格 | 门禁适用性 |
|---|---|---|---|---|
| 光学式 | 300-500ms | 强 | 低 | 推荐 |
| 半导体式 | 100-200ms | 弱 | 中高 | 不推荐户外 |
3.2 指纹模块的通信协议拆解
指纹模块的UART协议是命令包+应答包的结构。命令包格式一般是：包头(2字节) + 芯片地址(4字节) + 包标识(1字节) + 包长度(2字节) + 指令(1字节) + 参数 + 校验和(2字节)。校验和是从包标识开始到参数结束所有字节的累加和。
很多人卡在"模块不响应"这一步，其实90%是校验和算错了。注意校验和是两字节，高字节在前，而且计算范围不包括包头。我见过有人把包头也算进去，结果模块一直返回错误码。
// 校验和计算示例 uint16_t calc_checksum(uint8_t *buf, uint16_t start, uint16_t len) { uint16_t sum = 0; for (uint16_t i = start; i < start + len; i++) { sum += buf[i]; } return sum; } // 发送时：buf[len] = sum >> 8; buf[len+1] = sum & 0xFF;3.3 指纹录入与匹配的完整流程
指纹操作分三个核心动作：录入、比对、删除。录入时需要两次按压生成模板，模块内部会做特征提取和合并。这里有个坑：两次按压如果手指位置差异太大，模块会返回"特征合并失败"。正确做法是第一次按手指中心，第二次稍微偏移但保持覆盖面积，让模块采集到更完整的特征。
比对时模块返回的是匹配ID和置信度分数。置信度一般0-255，超过阈值（通常50-100）才算匹配成功。我建议把阈值设高一点，比如80，宁可让用户多按一次，也不要误识别放陌生人进去。
注意：指纹模板存储在模块内部Flash，掉电不丢失，但模块的Flash寿命有限，不要频繁做录入删除操作，测试阶段可以用模块的RAM缓存模式。
3.4 指纹识别的容错处理
实际使用中，指纹识别失败是常态，不是异常。手指太干、太湿、有污渍、按压角度不对都会失败。我的代码里做了三次重试机制：第一次失败提示"请重按"，第二次失败提示"请擦干手指"，第三次失败才判定为验证失败并记录日志。
这个细节看起来小，但用户体验差别巨大。没有重试机制的门禁，用户按一次没反应就以为坏了；有重试机制的门禁，用户会自然地调整手指再试一次。
4. 密码验证链路：从矩阵键盘到安全存储
4.1 键盘选型与扫描逻辑
密码输入用4x4矩阵键盘最经济，8个IO口就能读16个键。但矩阵键盘有个经典问题：按键抖动和鬼键。硬件上每个按键并联0.1uF电容能缓解抖动，软件上必须做20ms延时消抖。
扫描逻辑我推荐行扫描法：依次把每一行拉低，读列线状态，哪一列为低就说明哪个键被按下。这个方法比行列反转法简单，代码量少，适合门禁这种按键频率不高的场景。
// 行扫描法核心逻辑 for (uint8_t row = 0; row < 4; row++) { GPIO_WriteRow(row, 0); // 当前行拉低 delay_us(10); uint8_t col = GPIO_ReadCol(); if (col != 0x0F) { // 有列被拉低 delay_ms(20); // 消抖 if (GPIO_ReadCol() == col) { return key_map[row][col]; } } GPIO_WriteRow(row, 1); // 恢复高电平 }4.2 密码存储：明文是绝对不行的
我见过太多课程设计把密码直接写在代码里，或者明文存在Flash里。这在原型阶段无所谓，但如果你想让这个项目有一点实用价值，密码必须加密存储。
最简单的方案是用哈希+盐值。用户设置密码时，生成一个随机盐值，把密码和盐值拼接后做一次哈希（比如简单的MD5或者自己实现的轻量哈希），存储哈希值和盐值。验证时用同样的盐值重新计算哈希，比对结果。
// 简化版哈希存储思路 uint8_t salt[8] = {0x1A, 0x2B, ...}; // 随机生成，存Flash uint8_t hash[16]; hash_password(input_pwd, salt, hash); // 自定义哈希函数 if (memcmp(hash, stored_hash, 16) == 0) { // 验证通过 }这样即使有人读出了Flash内容，也拿不到原始密码。虽然轻量哈希不是密码学安全的，但对于门禁原型来说，已经比明文存储高了一个量级。
4.3 密码过期与错误锁定机制
热词里出现了"密码过期"，这在门禁系统里其实是个很实用的功能。我给它加了密码有效期：管理员密码可以设置30天有效期，到期后强制修改。普通用户密码可以设置永久有效，但连续输错5次锁定3分钟。
锁定机制用计数器+时间戳实现。错误次数存在备份寄存器（BKP）里，掉电不丢失；锁定时间用RTC时间戳判断。这样即使有人断电重启，锁定状态依然有效，防止暴力破解。
| 机制 | 实现方式 | 存储位置 | 掉电保持 |
|---|---|---|---|
| 错误计数 | 计数器 | BKP寄存器 | 是 |
| 锁定时间 | RTC时间戳 | BKP+RTC | 是 |
| 密码有效期 | 到期时间戳 | Flash | 是 |
5. 蓝牙通信：手机端管理与数据同步
5.1 蓝牙模块选型：HC05还是BLE
热词里"hc05蓝牙模块连接不上"出现频率很高，说明很多人卡在蓝牙调试上。HC05是经典蓝牙模块，配对简单、透传稳定，但功耗高、只支持安卓经典蓝牙。BLE模块（如JDY-31、AT-09）功耗低、支持iOS，但协议复杂，需要处理GATT服务。
门禁系统我推荐HC05，原因很直接：门禁通常有稳定供电，不需要低功耗；手机端只需要发几条控制指令，不需要高速传输；HC05的AT指令简单，调试成本低。如果你要做iOS端App，那就必须用BLE，但开发量会翻倍。
5.2 AT指令配置的完整流程
HC05出厂默认波特率通常是9600，但很多指纹模块也是9600，如果两个模块波特率一样但挂在不同的UART上，倒是不冲突。配置HC05的步骤：
- 按住模块上的按键上电，进入AT模式，此时指示灯慢闪
- 用USB转TTL连接模块，波特率设9600
- 发送
AT测试，返回OK说明通信正常 - 发送
AT+NAME=SmartLock设置设备名 - 发送
AT+PSWD=1234设置配对密码 - 发送
AT+UART=115200,0,0设置通信波特率 - 断电重启，进入正常透传模式
注意：AT模式下波特率是固定的9600，改完通信波特率后，下次进入AT模式还是要用9600连接，别搞混了。
5.3 手机端指令协议设计
蓝牙透传的本质是串口无线化，所以手机端发的指令格式要和STM32的串口解析逻辑对齐。我设计了一套简单的文本协议：
OPEN：远程开门PWD:123456：修改密码ADD:1：进入指纹录入模式LOG：读取开门记录STATUS：查询系统状态
每条指令以换行符结尾，STM32收到后解析并执行，返回OK或ERR:原因。这种文本协议比二进制协议好调试，用手机串口助手就能直接测试。
5.4 蓝牙连接不上的排查链路
HC05连不上是高频问题，我总结了一套排查顺序：
- 供电：HC05峰值电流能到40mA，如果从STM32的3.3V LDO取电，可能供电不足。用万用表量模块VCC，低于3.2V就是供电问题。
- 串口交叉：模块TX接STM32 RX，模块RX接STM32 TX，这个接反了完全没反应。
- 波特率：AT模式和透传模式波特率可能不同，确认当前模式。
- 配对密码：手机端配对时提示密码错误，检查
AT+PSWD设置。 - 被其他设备占用：HC05只能被一个设备连接，如果之前连过别的手机，需要先断开。
我遇到过最诡异的一次是模块能配对但发数据没反应，最后发现是手机端App的发送格式带了回车符，而STM32的解析代码没处理\r，只处理了\n。这种问题只能靠抓串口日志定位。
6. 系统整合：多任务调度与状态机设计
6.1 为什么不用RTOS
很多人第一反应是上FreeRTOS，但门禁系统的任务其实不复杂：读键盘、读指纹、读蓝牙、控制锁、刷屏幕。这些任务都是事件驱动的，没有硬实时要求。用RTOS反而增加了栈溢出、优先级反转的风险。
我的方案是主循环+状态机。主循环里依次轮询各个模块，每个模块有自己的状态标志。指纹模块收到完整包后置位标志，主循环检测到标志就处理。这样代码结构清晰，调试也简单。
6.2 状态机的状态划分
系统状态我分了六个：
IDLE：待机，显示时间和状态PWD_INPUT：密码输入中FINGER_WAIT：等待指纹UNLOCK：开锁状态，倒计时ADMIN：管理员模式LOCKED：锁定状态
状态之间的跳转由事件触发：按键事件、指纹匹配事件、蓝牙指令事件、超时事件。每个状态只处理自己关心的事件，其他事件忽略。这样逻辑不会乱。
typedef enum { STATE_IDLE, STATE_PWD_INPUT, STATE_FINGER_WAIT, STATE_UNLOCK, STATE_ADMIN, STATE_LOCKED } SystemState; void state_machine(void) { switch (current_state) { case STATE_IDLE: if (key_pressed()) current_state = STATE_PWD_INPUT; if (finger_detected()) current_state = STATE_FINGER_WAIT; break; // ... 其他状态处理 } }6.3 开锁执行的硬件细节
电磁锁和继电器是两回事。电磁锁通常需要12V供电，电流能到500mA以上，STM32的IO口绝对驱动不了，必须用继电器或MOS管做隔离驱动。继电器模块要注意续流二极管，否则线圈断电时的反向电动势会打坏IO口。
我用的是光耦+MOS管方案，光耦隔离STM32和驱动电路，MOS管控制电磁锁。这样即使电磁锁短路，也烧不到主控。开锁时间设3-5秒，太短用户来不及推门，太长电磁锁发热。
提示：电磁锁断电时会产生反向电压，续流二极管必须靠近锁的接线端，不要放在驱动板上，否则导线电感还是会引入干扰。
7. 调试过程中踩过的坑与排查经验
7.1 指纹模块和蓝牙模块互相干扰
这个问题困扰了我两天。现象是：蓝牙连接后，指纹识别成功率骤降。用示波器看电源纹波，发现蓝牙模块工作时电源上有明显的尖峰。原因是两个模块共用一条3.3V电源线，蓝牙发射瞬间的电流突变影响了指纹模块的供电。
解决方案是电源分离：指纹模块单独用一个LDO供电，蓝牙模块用另一个，两个LDO的输入并联但输出分开。或者在每个模块的VCC引脚就近加100uF+0.1uF电容。改完之后指纹识别率恢复正常。
7.2 串口接收丢包：环形缓冲区是必需品
一开始我用的是"收到一个字节就处理"的方式，结果指纹数据包经常解析失败。原因是主循环处理其他任务时，串口中断来了新字节，覆盖了还没处理的旧字节。
后来改成环形缓冲区：串口中断只负责把字节塞进缓冲区，主循环从缓冲区取数据组包。缓冲区大小设256字节，足够容纳指纹模块的最大包。这个改动之后，丢包问题彻底消失。
#define UART_BUF_SIZE 256 typedef struct { uint8_t buf[UART_BUF_SIZE]; volatile uint16_t head; volatile uint16_t tail; } RingBuffer; void USART3_IRQHandler(void) { if (USART_GetITStatus(USART3, USART_IT_RXNE) != RESET) { uint8_t data = USART_ReceiveData(USART3); uint16_t next = (rb.head + 1) % UART_BUF_SIZE; if (next != rb.tail) { // 缓冲区未满 rb.buf[rb.head] = data; rb.head = next; } USART_ClearITPendingBit(USART3, USART_IT_RXNE); } }7.3 Flash读写导致系统卡顿
密码和日志存在内部Flash里，每次写入都要擦除整个页（1KB或2KB），擦除时间能到几十毫秒。如果每次开门都写日志，系统会明显卡顿。
我的优化方案是日志缓存+批量写入：日志先存在RAM里，攒够10条或者系统空闲超过30秒再统一写入Flash。这样既减少了擦写次数，又避免了卡顿。另外，Flash擦写时最好关中断，防止中断服务程序访问Flash导致总线冲突。
7.4 蓝牙指令的粘包和分包
蓝牙透传是字节流，没有包边界。手机端快速发两条指令，STM32可能一次收到两条粘在一起；或者一条长指令被分成两次收到。处理方法是按换行符组包：收到\n才算一条完整指令，缓冲区里没遇到\n就继续等。
这个逻辑和指纹模块的定长包处理不一样，指纹是定长，蓝牙是变长。两种组包方式要分开处理，不能混用。
8. 功能扩展与个人经验总结
8.1 可以继续加的东西
这套系统跑通之后，扩展方向很多。加一个DS3231 RTC模块可以做精确的时间记录和密码有效期管理；加一个SD卡模块可以存大量开门日志；加一个ESP8266/ESP32可以接入网络做远程管理；加一个蜂鸣器可以做操作提示音。
我个人最推荐先加RTC，因为时间戳是很多功能的基础。DS3231走I2C，精度比STM32内部RTC高得多，而且自带纽扣电池，掉电走时。
8.2 关于安全性的实话
这个系统的安全性，说实话，防君子不防小人。指纹可以被复制，密码可以被窥探，蓝牙可以被截获。但作为原型系统，它的价值在于完整实现了身份验证的三种方式，并且每种方式都有基本的防护措施。
如果你要做真正商用的门禁，需要考虑加密芯片、安全元件、防拆开关这些东西。但那是另一个量级的项目了，不适合作为入门练手。
8.3 我个人的几点体会
做这个项目最大的收获不是学会了某个模块，而是理解了系统整合的难度。单个模块跑通很容易，但把四个模块塞进一颗芯片，让它们互不干扰地工作，才是真正的挑战。资源分配、中断优先级、电源设计、缓冲区管理，这些才是嵌入式工程师的核心能力。
另外，调试工具比代码更重要。一个逻辑分析仪、一个USB转TTL、一个万用表，能帮你省下大量猜测的时间。我现在的习惯是：任何通信问题，先抓波形，再看代码。波形不会骗人，代码会。
最后说一个细节：门禁系统的用户体验往往被忽视。开锁后要有明确的提示音或屏幕反馈，密码输入要有掩码显示，指纹失败要有重试引导。这些细节不涉及技术难点，但决定了这个系统是"能用"还是"好用"。我在第三版里加了OLED显示和蜂鸣器反馈之后，整个系统的完成度感觉完全不一样了。
