企业官网建设流程全解析

1. 这题到底在考什么：先把系统拆开看

刚拿到"基于STM32单片机智能电子密码锁指纹识别门禁锁无线WiFi视频尽快APP设计+红外测温液晶显示及密码错误蜂鸣器报警提醒设计26-081"这个题目时，很多同学的第一反应是"东西太多，不知从哪下手"。这很正常，题目就是把一个完整门禁系统的功能全部堆在了一行字里。但如果把它拆开看，其实就六个功能块：主控、身份认证、远程控制、温度检测、人机交互、报警提醒。

首先是主控，题目点名了STM32，默认就是STM32F103C8T6这一档，原因很实在：Cortex-M3内核、72MHz主频、64KB Flash、20KB RAM，带I2C、USART、SPI这些常用外设，芯片本身几块钱，学习资料又多，做课程设计和毕业设计都够用。再往上用F407当然也能跑，但纯属浪费，没必要跟自己的时间和预算过不去。

然后是身份认证部分，题目给了两套方案：密码盘和指纹识别。密码盘一般用3x4矩阵键盘，指纹模块则绕不开AS608这类光学指纹传感器。这里有个容易被忽略的细节——指纹模块和单片机之间走的是串口，波特率常用57600，但指纹比对本身是模块内部完成的，单片机只负责"下发采集指令"和"接收比对结果"，这大大减轻了主控的运算压力。很多人担心STM32跑指纹算法会不会卡顿，其实完全不会，因为算法根本不在STM32上跑。

远程控制这块，题目写的"无线WiFi视频尽快APP"像是机翻腔调，实际要表达的是"通过WiFi连接，用手机App实现远程开锁和视频查看"。WiFi用ESP8266模块性价比最高，十几块钱，支持TCP/IP协议栈，烧个AT固件就能用。至于视频，如果题目要求的是实时视频流，那STM32本身是不具备摄像头视频编码能力的，现实点的做法是外接一个带有WiFi视频能力的模块（比如ESP32-CAM）和主控分离工作，或者用App通过ESP8266查询"开锁记录和门磁状态"来代替视频。后面的章节我会专门讲怎么做的取舍，先说清这一点：STM32做主控的项目里，"视频"功能的实现路径必须重新设计，不能硬塞给STM32。

温度检测用的红外测温模块很明确——MLX90614系列。它通过I2C和主控通信，测的是物体表面发出的红外辐射，不需要接触皮肤就能读数，这在门禁场景里就是"测体温"。液晶显示部分，有人用LCD1602字符屏，有人用OLED，后者更清晰也更好看，现在年轻人做东西普遍偏爱OLED。

最后是报警提醒：密码错误蜂鸣器响，这是状态机里最简单的一个分支。"基于状态机的软件架构"、"硬件模块之间的电气隔离"、"通信协议设计"、"多任务轮询的时序安排"，这些才是题目真正的考点。这篇文章就按照我实际调试这套系统的顺序来讲，从硬件连线的坑讲到最后App对接的经验，尽量把能踩的雷都给你标出来。

2. 硬件接线和选型：这些坑我替你踩过了

2.1 指纹模块不是只接四根线就能跑

AS608指纹模块在淘宝上买的时候，店家通常会给你一个转接板，板上有六个引脚：VCC、GND、TXD、RXD、TOUCH和LED。核心的其实就四根：电源、地、模块发送（接单片机的RXD）、模块接收（接单片机的TXD）。注意是交叉连接——模块TXD送数据出来，必须进单片机的RXD；单片机的TXD送命令下去，必须进模块的RXD。很多人第一次接线把TXD和TXD直接对接，结果指纹模块完全不响应，查了半天发现是交叉线的问题。

需要特别提醒两块：

第一，AS608这个模块的供电要求是DC 3.6V到6V，不建议直接从STM32的3.3V稳压输出上取电。为什么？因为指纹模块内部的指纹比对瞬间电流能到100mA以上，而STM32核心板上的AMS1117-3.3稳压器本来就是给主控芯片用的，你再拖一个功耗不小的外设上去，很容易把336的压差拉崩，导致主控复位、屏幕闪、WiFi断连等灵异现象。最稳的接法是从USB的5V取电给指纹模块，让模块自己板载的稳压器降到3.3V。这个坑我亲眼见过好几个人栽进去。

第二，AS608模块的返回数据里有两个字节代表确认码，确认码为0x00就说明命令被正常执行。很多人在代码里不检查确认码，导致后面所有逻辑看起来都对但指纹就是录不进，其实问题出在前面某一步命令根本没被模块接受。

2.2 矩阵键盘扫描：行线列线都要加上拉

3x4矩阵键盘，一共12个键，行线（R1-R3）接STM32的PA0-PA2，列线（C1-C4）接PA3-PA6。扫描原理一句话：先让所有行线输出高电平，然后逐一拉低某一行，再去读列线的电平变化，从而判断是哪个键被按下。

这是很经典的做法，但实操中有一个很容易错的地方——键盘的连接端子如果没有内部上拉，读到的一直是0。有些STM32开发板上的GPIO内部上拉默认是关闭的，你在初始化的时候一定要设置成上拉输入模式（GPIO_Mode_IPU）。否则焊好的键盘接上去，按哪个键都"按不动"。

另外，扫描过程中要处理按键抖动。机械按键按下和弹起的一瞬间，电平会有大约10-20ms的不稳定区间，如果不做消抖，按下一次会被识别成两次甚至三次输入，密码"1234"就会变成"11234"或者更离谱。我通常的做法是检测到按键变化后先延时20到30ms，再读一次当前状态，两次电平一致才认为按键有效。这个延时放在定时器中断里做，不要用delay函数硬等，原因后面讲软件框架的时候会展开。

2.3 电磁锁和继电器：和单片机完全隔离

电磁锁是典型的大电流感性负载——工作电流几百毫安，通断瞬间的反向电动势可能到几十伏。你要是直接把这玩意接到STM32的引脚上，轻则复位，重则把芯片烧了。正确做法是中间加一个继电器或MOS管做隔离，而且要特别注意两点：

一是驱动继电器的引脚要加续流二极管。我在很多课程设计做的东西里看到有人不加这个二极管，结果继电器断开瞬间把三极管或芯片引脚打坏。建议就是并一个1N4007，负极接电源，正极接继电器线圈的集电极侧。续流二极管的原理很简单：电感电流不能突变，断开瞬间线圈会产生反向电动势，二极管给它一个安全泄放通道，防止高压击穿驱动管。

二是单片机的GND和电磁锁的电源GND要不要共地？答案是必须共地。很多人在这一点上纠结过：既然要隔离，为什么还要共地？这里的分工逻辑是"隔离强电对弱电的干扰"和"保证信号参考电位一致"两码事。你通过光耦隔离信号之后，继电器线圈侧的电源和单片机侧信号之间需要共同的参考地，否则光耦输出端的电平对单片机来说是个悬空的状态，读到的逻辑电平完全不可靠。信号级隔离用光耦，电源级参考必须共地，这个度要拿捏清楚。

2.4 红外测温模块的接线和精度问题

MLX90614有I2C接口，接法就是标准的SCL和SDA各接一根线上拉4.7k电阻到3.3V。需要注意，MLX90614的默认I2C地址是0x5A，数据手册上写的。接线看着简单，实际上手容易出三个问题：

• 第一个问题是模块供电电压。MLX90614有3V版本和5V版本，买到哪个版本就按哪个给，给错了读数就乱飘。
• 第二个问题是I2C总线上的电平。如果单片机和模块供电不同（比如单片机3.3V、模块5V），SCL和SDA必须做电平转换，最简单的做法是串一个1k电阻再接上拉。不做转换的话，模块的高电平输出对单片机的输入引脚来说就是超压，长期运行迟早出问题。
• 第三个问题是测量准确度。MLX90614测量的默认发射率被校准为1.0，但人的皮肤发射率大约在0.98左右，实测下来误差普遍在±0.3℃到±0.5℃之间。如果你在项目里报告里写"误差±0.1℃"，评委一眼就会怀疑你没实际测过。我在实际项目里会在程序里做一步软件补偿：把读到的物标温度乘以一个校正系数再加上一个偏移常数。系数的标定方式很简单：拿一支水银体温计和自己对比，室温环境多测几组，算一个校准值写进去。这个细节虽然小，但能让你在答辩的时候"有数据、有解释"。

2.5 LCD和蜂鸣器的小讲究

显示部分我建议用0.96寸OLED（I2C接口，四个引脚），ST7735之类的TFT彩屏也可以，但没必要。OLED的好处是自发光、视角大、代码成熟，U8g2库直接支持。液晶显示的内容规划好就行：开机显示当前温度、门状态、时间；等待密码输入时显示"PASSWORD:"；指纹验证通过显示"OPEN"；密码错误显示"ERROR"并伴随蜂鸣。

蜂鸣器分有源和无源两种，做报警提醒要选有源蜂鸣器。有源蜂鸣器内部带震荡电路，给个高电平就响，无源蜂鸣器需要MCU输出特定频率的方波才能发声。报警提示用有源蜂鸣器简单可靠，只需要一个NPN三极管驱动（别直接把蜂鸣器接在GPIO上，它需要的电流比GPIO能提供的更大）。响的时机也不用做太复杂：密码错误响一声长鸣，连续错三次进入30秒锁定并触发鸣叫，指纹匹配失败时短鸣三声，这就能把状态区分得很清晰。

3. 软件框架：状态机是这套系统的灵魂

3.1 为什么必须用状态机

第一次写这类项目的人通常会这么做：在main函数里写一个while(1)，里面从键盘读取、判断指纹、控制门锁、刷新屏幕……所有功能按一行行代码顺序执行，代码从几百行膨胀到一千多行，然后发现不同模块之间的"互相干扰"开始出现——比如正在做指纹比对的时候键盘按键没响应，比如蜂鸣器响的时候OLED刷新变慢了。这就是把"并发"硬做成了"顺序"的必然结果。

正确的思路是把系统看成一个状态机。我把这套门禁的状态拆成了五个：

• 空闲状态（IDLE）：屏幕显示时间和温度，等待键盘输入或指纹按下
• 密码输入状态（PWD_INPUT）：正在接收密码数字，管理输入长度和显示掩码
• 指纹验证状态（FP_CHECK）：已经触发指纹模块比对，等待模块返回结果
• 开门状态（DOOR_OPEN）：验证通过，驱动继电器打开电磁锁，倒计时5秒后自动落锁
• 报警锁定状态（LOCKED）：密码连续错误三次，锁定30秒，蜂鸣器周期性鸣叫

状态机的核心价值在于：任意时刻系统处在唯一状态，每个状态只处理自己关心的事件，别的状态的事件可以被忽略或缓存。这样一来，你在密码输入状态去触发指纹比对，代码上只需要一个状态迁移指令"当前状态 = FP_CHECK"，而不是在main函数里满世界加if判断。

3.2 主循环和定时器怎么配合

主循环采用"节拍轮询"模式。用一个定时器产生1ms中断，在中断服务函数里做三件事：

• 更新键扫节拍计数，每20ms扫描一次键盘（消抖刚好在20ms这个节拍里完成）
• 更新超时计数，比如密码输入超时30秒、开门保持5秒、锁定30秒，都用计数变量累计
• 更新蜂鸣器的发声时序，保证报警节奏不受主循环阻塞影响

主循环里则是一个大switch语句，按当前状态去执行对应代码块，同时不断轮询各种事件标志位。有的同学喜欢全部用中断、写回调，那套方法在裸机项目里反而容易把代码弄得很难读，而且多个中断源的优先级编排本身就容易出bug。轮询加中断混合的模式，我用了这么多年，在中小型嵌入式项目里就是最稳定、最好维护的。

3.3 密码状态的代码骨架

密码输入这块，我用一个二维数组存用户密码和一个临时数组存当前输入。每次按键后做了四个判断：

• 按下数字键：如果当前输入长度小于最大长度，将数字存入临时数组并追加一个"*"显示
• 按下确认键（我用'#'键代替）：对比临时数组和用户密码数组，两者一致进入开门状态，不一致蜂鸣器警报，并递增错误计数
• 按下取消键（我用'*'键代替）：清空输入数组，回到空闲状态
• 输入长度达到上限或者超时：自动清空或回到空闲

有个细节是在密码验证时要用循环比对而不是直接调字符串比较函数。为什么？因为密码长度通常固定，直接算好长度循环逐个比对自己写还少了调用开销和不确定性。

uint8_t verify_password(uint8_t *input, uint16_t len) { uint8_t stored[6] = {'1','2','3','4','5','6'}; if (len != 6) return 0; for (uint16_t i = 0; i < len; i++) { if (input[i] != stored[i]) return 0; } return 1; }

3.4 指纹模块的指令交互

AS608指纹模块的命令分成好几个组：采集指纹图像、生成特征、搜索比对、删除模板等。模块每次收到命令后执行完毕都会回传一个确认码和数据包。我在实操里验证过的基本流程：

录入指纹分两步：第一步按第一次，生成特征存缓冲区；第二步提示"请再次按同一手指"，再次采集后把两个特征合成模板存到模块Flash里的用户区。搜索比对是核心动作，STM32往模块发送搜索指令，模块在当前所有已注册的指纹模板里做匹配，如果找到了就返回一个指纹ID，找不到就返回确认码0x09。你在代码里直接读返回数据包的确认码字段就行，0x00即匹配成功。

这里有几个容易踩的坑：第一，模块启动需要一小段时间（大概100ms），上电后不要立刻发指令，先延时；第二，录入指纹那个动作里手指按下去不要太快松开，模块需要大约1秒的连续按压来扫描指纹图像，太快会报"采集超时"；第三，注册的指纹模板存储在模块板上Flash里，断电不丢，但如果你换了一块模块，存储的指纹数据就没了，这一点在做演示和交付的时候提前讲清楚。

指纹触发方式我选的是TOUCH引脚查询而不是串口命令轮询。AS608的TOUCH引脚有手指触碰时会输出一个高电平脉冲。把TOUCH引脚接在STM32的外部中断引脚上，这样当用户手指碰上去时单片机立刻收到中断事件，再在中断里置一个"有手指按下"的标志位。主循环检测到标志位以后再去给模块发比对指令。这个方式比一直轮询串口省心很多，也不会阻塞其他逻辑。

void EXTI_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line0) != RESET) { touch_flag = 1; // 手指触碰标记 EXTI_ClearITPendingBit(EXTI_Line0); } }

主循环里看到touch_flag就发指纹比对指令，比对期间有一个超时保护，如果30秒内没有判定结果就自动清掉状态回到空闲。

4. WiFi与App远程开锁：ESP8266的三种连接方案

4.1 ESP8266做透传还是做协议解析

远程功能无非是让手机App能和单片机通信。ESP8266作为WiFi模块接入家庭路由器，App通过路由器访问到ESP8266，再由ESP8266通过串口和STM32通信。这个链路里ESP8266扮演的是"网桥"角色。

但我做过不少方案对比，发现这里的实现路径差异很大，直接影响工程的复杂度和稳定性。

第一种方案，ESP8266烧NodeMCU固件或官方AT固件，由STM32主动通过AT命令控制模块连接WiFi、建立TCP连接，数据透传模式收发。优点是STM32全盘掌控，缺点是AT指令的时序非常"脆"——网络断开重连、TCP超时这些情况要处理很多分支，稍有不慎模块就卡死在AT返回状态里。做过的人都知道，ESP8266的AT固件连路由器偶尔抽风，要等很久才能重新握手。

第二种方案，ESP8266烧Native SDK做的自定义固件，直接在模块上跑一个小服务器。STM32只通过串口发送"开门""读状态"这样的简单命令，模块自己负责连网、维护连接、解析收到的JSON数据。这等于把通信压力从主控挪到了WiFi模块上。稳定性好很多，但需要写一点Lua脚本或C代码给8266。

第三种方案，用ESP8266做MQTT客户端，连接公共的MQTT服务器，手机App也通过MQTT收发消息。这是目前很多物联网项目的标配做法。单片机这边逻辑简化到极致：串口收到"OPEN"字符串就开门，收到"ALARM"就报警。

不管是哪种方案，App到设备的链路里有一个关键的规则要遵守：不要设计成"App直接绑定设备IP"的形式。家用路由器的DHCP分配IP可能是动态的，今天设备是192.168.1.5，明天重启就成了192.168.1.9，App还在连老IP必然失败。比较稳的做法是在局域网里用UDP广播做设备发现，或者干脆在ESP8266上固定一个静态IP。学校实验室的网络环境里，路由器允许设备列表管理，固定IP这条路最直接。

4.2 单片机与ESP8266的串口协议设计

STM32和ESP8266之间的数据格式用JSON虽然包了一段解析代码，但好处是后续扩展特别方便。比如设备主动上传一条JSON：

{"mac":"A0:20:A6:12:34:56","door":"closed","temp":"36.5","time":"2025-01-12 14:30:22"}

App要发指令就发：

{"type":"cmd","id":"1","action":"open"}

STM32那边的串口接收中断按帧收，一帧以"\n"结尾，然后丢给一个轻量级的JSON解析器抽取action字段。很多STM32课程设计资料里都喜欢自定义极其简短的协议，比如发0x01表示开门、0x02表示查询，确实代码更少，但只要有新的功能要加，比如远程报警、远程录入指纹，协议就会变得一团糟。用JSON做个最小子集，只解析一层，代码量也就多几十行，可维护性凭空高了一个层次。

要小心的是STM32串口接收中断容易被长帧刷爆。ESP8266上报的数据可能比较大，如果你用单字节中断一进来就处理，中断服务函数太长会把主循环卡死。建议做法是中断里只把收到字节放到环形缓冲区，主循环里再做帧头帧尾的拆分和解析，把"接收"和"处理"彻底分离。

void USART2_IRQHandler(void) { if (USART_GetITStatus(USART2, USART_IT_RXNE) != RESET) { uint8_t ch = (uint8_t)USART_ReceiveData(USART2); rb_write(&rx_ringbuffer, ch); // 环形缓冲，收得再快也不丢 } }

4.3 App开发：Blynk够用，但要明白它的边界

做App这块，很多人会直接推荐你用Blynk，因为拖拽界面、配几个控件就能远程控制单片机，看起来特别"快"。实际做起来也确实快，但有几个现实限制：

• Blynk免费版的数据点数有限，你要展示"温度、门状态、指纹状态、开关按钮、锁定按钮"一共要占掉多个数据点，可能会触发收费。
• Blynk的历史数据存储不是实时查询，刷新有点延迟，不适合做"实时门铃视频"这种需求。
• 要控制密码设置、指纹录入这类带交互流程的功能，Blynk的控件支持是不够的，你需要自己做一套有逻辑的App界面。

如果只做一个"远程开门、锁定、查看温度"的演示级App，Blynk完全够用。但如果你的题目答辩要求"App能够显示开锁记录、设置临时密码、实时观察温度曲线"这些交互功能，那我建议用安卓原生开发或微信小程序来做。我在实际项目里最终是用微信小程序（内嵌WebSocket）对接ESP8266的TCP服务器，效果很直观：小程序界面显示实时温度、门锁状态、一个开锁按钮和一个报警记录列表。微信小程序的好处是用户手机不需要安装额外的APK，做课程设计的展示环节非常加分。

这里有另外一个比较容易忽略的点：如果ESP8266是作为TCP服务器在局域网里监听，小程序里要用WebSocket的IP地址和端口要填对，而且手机和小程序连的必须是同一个WiFi。演示的时候如果两台手机一台连着实验室WiFi、一台用的手机热点，就会"明明代码没问题，就是连不上"，这是项目展示现场最高的翻车点。

5. 红外测温与门禁联动的策略设计

5.1 读取MLX90614的温度数据

MLX90614通过SMBus协议读取RAM里的两个16位寄存器，0x07是红外温度数据（也就是物体表面温度），0x06是环境温度。原始数据换算公式是0.02℃/bit，读取到的16位值乘以0.02再减去273.15就是开尔文换算后的摄氏度。代码上我直接用STM32硬件I2C（或者模拟I2C）读就行。

float mlx90614_read_temp(uint8_t reg) { uint8_t buf[3]; uint8_t addr = 0x5A; // 发送读寄存器命令 I2C_Start(); I2C_SendByte((addr << 1) | 0); I2C_SendByte(reg); I2C_Stop(); // 读取3字节数据（low, high, PEC） I2C_Start(); I2C_SendByte((addr << 1) | 1); buf[0] = I2C_RecvByte(ACK); buf[1] = I2C_RecvByte(ACK); buf[2] = I2C_RecvByte(NACK); I2C_Stop(); uint16_t raw = (uint16_t)((buf[1] << 8) | buf[0]); return raw * 0.02 - 273.15; }

第三个字节是PEC校验码，如果要求严谨，应该校验这个字节来判断通信链路是否正常。我在项目里读取完不校验PEC，因为I2C线很短、环境干扰小，不校验问题也不大。但如果你做的是产品级的项目，PEC校验建议加上，毕竟这是数据完整性的最后一道防线。

5.2 温度数据在门禁里怎么用

红外测温放进智能门禁系统，通常有两种设计思路，你写文档做答辩的时候这两条思路都会用到。

思路一是"测温联动"：当有人按指纹或输密码时，系统同步测量其额温，温度高于阈值（比如37.3℃）时拒绝开门并发出报警提示，门禁自动进入禁行状态。这种做法在常态化防控场景里有现实意义，也是题目里放"红外测温"的核心诉求。

思路二是"测温记录"：每次开门都记录一条温度数据，和指纹ID、时间戳一起存进EEPROM或者通过WiFi上传到App端，方便事后追溯。

我实现的时候把两个思路合在一起："测温成功且温度正常才执行开锁动作，否则即便指纹验证通过也不开锁"。所以你会在我的系统流程里看到：指纹匹配成功后，先读一次MLX90614，判定温度范围在34℃到37.3℃之间，再给继电器发送开门指令。如果体温偏高，LCD显示"TEMP HIGH"，蜂鸣器急促鸣叫，同时把这量信息通过WiFi上报到App。

这里需要提醒一下，MLX90614测的是"物体表面红外温度"，和医学上的"核心体温"不是一个概念。额头如果贴了刘海或者出汗，测出来的值会偏低很多；如果站在高温环境里（夏天室外晒过太阳），额温会虚高。在做文档和演示时，一定要说明这是"非接触式体表测温参考值"而不是"医学测量值"，这样答辩时不会被人揪住"测温不准"这点不放。

5.3 一个实际处理过的"误报警"问题

调试的时候我遇到过一个很有意思的问题：夏天中午实验室空调停了，室温升到33℃。有同学模拟演示"体温过高拒绝开门"的场景，手放上去之后MLX90614读出来的温度确实超过37.3℃，于是报警响起。但其实那人是靠红外辐射加热了传感器旁边的壳体，导致环境温度数据被拉高，物标温度读数跟着受到了串扰。

解决办法是在软件里加一个"温度突变检测"：如果两次读数的差值超过1.5℃，就再多读三次取中间值，并且将连续五次读数做滑动平均。这个滤波逻辑在处理红外测温这种易受干扰的传感器时很有用。你最终给评委演示的时候，用这个逻辑能解释"为什么读数稳定"，比干巴巴地说"我做了软件滤波"更有说服力。

6. 联调排错：从"点不亮"到"误开锁"的真实问题复盘

6.1 供电不稳导致的"间歇性抽风"

系统功能全部做完、进入联调阶段后的第一个大坑就是电源。我最初用的是USB线直接给STM32核心板供电，指纹模块、ESP8266、OLED、蜂鸣器全都从核心板的3.3V和5V引脚取电。结果发现一个规律：只要ESP8266开始连路由器，屏幕就闪一下；继电器吸合瞬间，蜂鸣器乱响一声；指纹比对的时候复位重启。典型的欠压欠流症状。

后来我换了一个5V/2A的适配器，通过面包板的电源轨统一供电，5V走一路给ESP8266和指纹模块，3.3V走一路给STM32和OLED，地线全部汇总到一点（星形接地）。问题直接消失。所以做这种多外设系统，第一优先解决的是电源架构，不是代码。我不是第一次见到有人排错两天，最后发现是USB口供电不足。

具体怎么设计电源分配，我建议：用DC-DC降压模块把适配器的5V转到稳定的5V轨，再用AMS1117-3.3生成3.3V轨。大功率外设（继电器线圈、蜂鸣器、指纹模块）直接接5V轨，STM32和OLED接3.3V轨。电容也不能省：每个供电节点并一个100uF电解电容加一个104陶瓷电容，吸收瞬态电流冲击。

6.2 指纹模块"UART连不上"的排查链路

遇到指纹模块连不上，不要急着换模块，按照这个顺序排查：

1. 用万用表量指纹模块VCC和GND之间的电压，确认在3.6V-6V范围内。
2. 确认STM32和模块之间是否交叉接线：TXD-RXD、RXD-TXD。
3. 检查串口初始化，波特率要跟模块匹配。AS608默认波特率是57600，但有些商家出厂改过。你可以先用USB转TTL接模块，打开串口助手发一个0xEF 0x01 0xFF 0xFF 0xFF 0xFF 0x01 0x00 0x08 0x03 0x01 0x00 0x05（获取模块参数），看看模块有没有返回。返回了说明模块活着、波特率正确。
4. 如果串口助手能通、板子不通，那就是引脚复用或者重映射没有配置对。很多STM32核心板的串口1引脚和板载LED有复用冲突，检查芯片原理图，别抢了引脚。

6.3 误开锁：没有做输入合法性检查

有一次我调试过程中发现：在密码输入状态随便敲满六位数字，系统竟然把门打开了。查了一下代码，原来是密码验证函数里我拿临时输入和存储密码逐位比较，但没有检查用户是否按了确认键。也就是说，只要输入长度够了就触发验证。这在正常逻辑里不会误判，但如果你在考试现场展示时，评委随手在键盘上乱按一串数字，刚好撞上一个匹配的密码，门就开了。

正确逻辑是：只有按下确认键('#'）才触发密码比对；比对之前先检查输入长度是否等于密码长度，不等于就直接报错；比对失败还要分情况处理——是长度不对还是数字不对。这个细节看似微小，但检测的就是你有没有把"状态"和"事件"分清楚。

6.4 现场演示最容易翻车的三个"环境变量"

最后给各位分享几个在做项目展示时最容易翻车的地方，我本来想直接讲完收工，但这几个实在太重要，一定得列出来：

一是在演示WiFi遥控时，千万别依赖现场WiFi。展馆或教室的无线网络可能开了AP隔离，设备之间不能互相访问。稳妥做法是自备一个小路由器，让ESP8266和你的手机都连着它，组成一个独立局域网。

二是红外测温的演示环境温度。MLX90614如果正对着一扇窗户，窗户的玻璃温度变化会导致读数跳来跳去。演示前选一个稳定的室内角落，避免传感器视野里有空调出风口、太阳直射等干扰源。

三是电磁锁的供电。锁体需要的电压和电流不同，有些电磁锁标称12V供电，你需要额外的12V电源适配器。在测试的时候，我建议先用5V继电器控制一个LED灯模拟开锁动作，等全部逻辑验证无误后再接真实电磁锁。这样可以避免调试时频繁吸合电磁锁把电源搞崩，也防止锁体长时间通电发热。

这台系统做到最后，软件部分其实只占了工作量的一半，另一半都花在排查硬件连接和通信问题上。但恰恰是这些问题才真正锻炼了人——毕竟门禁系统这种东西，难点从来不是某一项单独的技术，而是那么多模块在同一个系统里稳定协作。每解决一个问题，你对这套系统的理解就深一层。做完之后回头看，这个题目不仅不难，反而是把嵌入式开发里最典型、最有价值的场景都串起来练了一遍。