简介这份面向嵌入式开发、物联网课程设计与毕业设计场景的PDF文档围绕基于STM32F103RCT6的实验室智能门禁系统展开重点解决传统门禁功能单一、环境安全监测不足与远程管理缺失等问题。内容涵盖RFID-RC522刷卡开门、DHT11温湿度检测、火焰与MQ2烟雾监测、SG90舵机模拟门锁、OLED本地显示、蜂鸣器报警以及ESP8266接入华为云IoT和Android APP远程查看与控制等模块。资源包共1个文件为51.33MB的PDF适合按章节检索硬件选型、接口连接、固件设计、通信层与应用层架构。已有114人学习可作为课程设计、毕业设计或项目复现的参考方案帮助读者理清从需求分析、模块划分到云端对接与系统调试的完整实现思路。1. 实验室门禁的难点从来不在刷卡那一刻实验室的门禁和写字楼不一样。写字楼里的人一年到头工位不变权限发一次能用三年实验室里的人员是流动的一个课题组带两个实习生、外校来借设备的同学只在周末出现、毕业生离校当天权限就该收回。把这张名单写死在 STM32 的 Flash 里改一次就要抱着仿真器去现场烧录做不了几个星期就没人愿意继续维护了。基于 STM32 设计实验室智能门禁系统并接入华为云 IOT本质上就是把「谁能进、什么时候能进、进去过几次」这三个判断从单片机搬到云上。STM32 端只做四件事读卡、驱动电锁、把结果通过 MQTT 报上去、断网时靠本地白名单保证门还能开。这样管理员改权限只需要在云平台上点几下设备下一次同步就生效。适合看下去的人有两类做过 STM32 点灯串口实验、想把它做成一个连云的完整闭环的以及实验室管理员想搞清楚到底谁在凌晨两点刷卡进了动物房。下面从硬件接线一路写到云端 Topic 和排错日志。2. STM32 门禁终端的硬件选型与接线落地2.1 读卡方案的取舍RC522、PN532 与指纹模块实验室门禁最常用的是 13.56MHz 的 Mifare 卡选型基本在这三条路里挑。方案接口成本适合场景主要坑MFRC522SPI最低校园卡、门禁扣只读 4 字节 UID天线贴金属外壳读距骤降PN532I2C/串口中等需要读手机 NFC、扇区数据指令集复杂I2C 上拉电阻容易漏指纹模块串口较高不愿发卡的实验室指纹库存在模块里换模块要重录如果只是刷校园卡开门RC522 足够了。它能拿到卡片的 UID配合本地白名单就能完成 90% 的判断。PN532 的价值在于能读卡内扇区数据可以做「卡 扇区密钥」的双因子但实验室场景里这类需求不多。2.2 一张接线表SPI 读卡器、继电器与门磁以 STM32F103 为例SPI1 固定在 PA5/PA6/PA7 上片选和其余外设走普通 GPIO。外设引脚模式说明RC522 SCKPA5复用推挽SPI1 时钟建议不超过 5MHzRC522 MISOPA6浮空输入主机输入RC522 MOSIPA7复用推挽主机输出RC522 CSPA4推挽输出软件片选低有效RC522 RSTPA3推挽输出复位低有效继电器 INPB0推挽输出低电平吸合默认输出高门磁PB6上拉输入门开时被磁簧拉到低电平蜂鸣器PB1推挽输出鉴权失败提示接线里有两个容易被忽略的点。一是 RC522 必须用 3.3V 供电5V 会直接烧掉二是读卡天线周围要留出净空区如果装在铁质门框上读距会从 5cm 掉到 1cm 以内解决方法是把读卡板用亚克力垫出来 5mm 以上或者干脆换成带外置天线的读头。2.3 门锁驱动为什么不能直接用 GPIO 拉电磁锁电磁锁和电插锁基本都是 12V、工作电流 500mA 起步STM32 的 IO 输出能力只有 25mA直接接上去要么开不动要么把 IO 口拉死。另外锁线圈是感性负载断电瞬间产生的反向电动势足以击穿三极管。常见做法是「独立 12V 电源 继电器或低边 MOS 管 续流二极管」三级结构。继电器模块自带光耦隔离的可以直接用裸继电器就要自己加 1N4007 反并联在线圈两端。下面是继电器控制脚的初始化代码/* 继电器为低电平触发初始化时输出高电平避免上电瞬间误开锁 */ static void Lock_GpioInit(void) { GPIO_InitTypeDef gpio {0}; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE); gpio.GPIO_Pin GPIO_Pin_0; gpio.GPIO_Mode GPIO_Mode_Out_PP; gpio.GPIO_Speed GPIO_Speed_2MHz; GPIO_Init(GPIOB, gpio); GPIO_SetBits(GPIOB, GPIO_Pin_0); /* 默认闭锁 */ gpio.GPIO_Pin GPIO_Pin_6; /* PB6 门磁 */ gpio.GPIO_Mode GPIO_Mode_IPU; GPIO_Init(GPIOB, gpio); }GPIO_Speed_2MHz是有意选的低档继电器控制信号不需要边沿速率速度快反而增加干扰。初始化后立刻SetBits这一句很关键——很多板子上的继电器是低有效上电默认输出低会直接把门打开调试阶段尤其危险。2.4 下载调试口与最小系统工程下载调试用 SWD 两线足够PA13SWDIO和 PA14SWCLK保留出来。如果 PB3、PB4、PA15 要当普通 IO 用需要先关闭 JTAG 只留 SWD/* 只保留 SWD释放 PB3/PB4/PA15 作为普通 IO */ GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);在 Keil5 里新建工程时先把对应系列的器件包装好否则新建工程向导里找不到料号。时钟树配置建议直接把外部晶振设成 8MHz、系统时钟配到 72MHzHAL 库用户注意 SysTick 默认走 1ms如果后面跑 RTOS 要改成别的时基。3. 固件实现从读卡 UID 到开锁的完整链路3.1 MFRC522 的 SPI 时序与 UID 读取RC522 的寄存器地址是 7 位读写方向位在最低位所以地址要先左移一位再拼方向位。这是新手最容易写错的地方写错的表现是读回来永远是 0x00 或 0xFF。static uint8_t RC522_SpiRW(uint8_t addr, uint8_t data) { uint8_t rx; RC522_CS_LOW(); SPI1_ReadWriteByte((addr 1) 0x7E); /* 读操作地址左移bit0 0 */ rx SPI1_ReadWriteByte(data); RC522_CS_HIGH(); return rx; }拿到正常通信之后读卡流程是「寻卡 → 防冲突 → 校验 → 取 UID」四步。uint8_t RC522_ReadUid(uint8_t *uid) { if (RC522_Request(PICC_REQIDL, g_atq) ! MI_OK) return 0; /* 寻天线区内空闲卡 */ if (RC522_Anticoll(g_atq) ! MI_OK) return 0; /* 防冲突取 UID */ /* 第 5 字节是前 4 字节的异或校验值 */ if ((g_atq[0] ^ g_atq[1] ^ g_atq[2] ^ g_atq[3]) ! g_atq[4]) return 0; memcpy(uid, g_atq, 4); return 4; }PICC_REQIDL的意思是只响应处于空闲状态的卡已进入认证流程的卡不会重复响应天然起到一点去重作用。异或校验这一步不要省读卡时偶发的 SPI 位翻转会让 UID 变成另一个合法卡号如果这个号恰好撞进白名单就是一次误开门。3.2 本地白名单的存储结构与查找白名单存在 Flash 的独立一页里结构上是一个头部加一个定长数组头部放魔数、版本号和条目数数组里每条是 4 字节 UID 加 1 字节权限位比如 bit0 表示可以开哪扇门。查找用线性扫描就够——实验室规模一般不会超过 200 人200 次 4 字节比较在 72MHz 上耗时不到 10 微秒为了这点时间引入哈希表不划算。更新的方式是整页擦除重写写完把版本号加一再通过属性上报把list_version同步给云端两边对不上就说明设备还没拿到最新名单。3.3 开锁状态机与超时回锁开锁最怕两件事一是开了不关二是关了不开。用状态机把这两个动作固定下来。typedef enum { LOCK_IDLE, LOCK_UNLOCKED } lock_state_t; static lock_state_t g_lock_state LOCK_IDLE; static uint32_t g_unlock_tick 0; void Lock_Task(void) { switch (g_lock_state) { case LOCK_IDLE: if (g_open_req) { /* 鉴权通过后由业务层置位 */ Lock_RelayOn(); g_unlock_tick SysTick_GetMs(); g_lock_state LOCK_UNLOCKED; g_open_req 0; } break; case LOCK_UNLOCKED: if (SysTick_Elapsed(g_unlock_tick) UNLOCK_HOLD_MS) { Lock_RelayOff(); /* 到时强制回锁 */ g_lock_state LOCK_IDLE; } break; default: g_lock_state LOCK_IDLE; break; } }UNLOCK_HOLD_MS一般设 3000 到 5000。设太短人还没推门锁又锁上了设太长等于门在那段时间里敞着。3.4 断网时的降级策略门禁是安防设备断网不能变成不能开门。三档策略按风险从低到高排断网时长行为记录方式小于 30 秒只走本地白名单正常开门内存缓存复网后补报30 秒到 24 小时本地白名单 强制记录写入 Flash 环形缓冲区超过 24 小时只允许高权限卡普通卡拒绝蜂鸣器长鸣提示管理员提示Flash 写寿命有限离线记录不要每条都写按分钟聚合或者攒够 32 条再落盘能显著延长擦写次数。4. 接入华为云 IoTDA产品模型、Topic 与报文格式4.1 产品模型怎么建服务和属性的最小集合在 IoTDA 控制台创建产品时先想清楚设备要报什么、要收什么属性建多了后面维护麻烦。门禁系统一个服务就够命名成Access。属性名类型说明card_uidstring最近一次刷卡卡号十六进制 8 位open_resultint0 成功1 白名单外2 时段外3 锁故障lock_stateint0 闭锁1 开锁door_stateint0 关闭1 打开门磁list_versionint本地白名单版本号fw_verstring固件版本OTA 时比对用命令侧建两个remote_open管理员远程开门可带持续时间参数和sync_list触发设备拉取最新白名单。远程开门命令一定要设有效期否则一条半年前下发的命令在设备补连网络时被执行门就莫名其妙开了。4.2 MQTT 连接参数与 Topic 拼接设备侧连接需要三样东西平台接入地址、设备 ID、设备密钥。三元组在控制台注册设备时生成密钥只显示一次务必当场存下来。Topic 是拼出来的格式固定/* 属性上报 */ snprintf(topic, sizeof(topic), $oc/devices/%s/sys/properties/report, DEVICE_ID); /* 订阅命令下发通配符 # 匹配本设备所有命令 */ snprintf(topic, sizeof(topic), $oc/devices/%s/sys/commands/#, DEVICE_ID); /* 命令响应request_id 从下发报文中原样带回 */ snprintf(topic, sizeof(topic), $oc/devices/%s/sys/commands/response/request_id%s, DEVICE_ID, request_id);注意命令响应如果不发云端会认为设备处理超时并重试下发门禁场景下重试等于重复执行务必在业务处理完成后立即回响应。4.3 属性上报报文的拼装上报报文是固定结构的 JSON用一个 buffer 拼出来就行不必为省几百字节引入 JSON 库。char json[192]; snprintf(json, sizeof(json), {\services\:[{\service_id\:\Access\,\properties\:{ \card_uid\:\%02X%02X%02X%02X\, \open_result\:%d, \lock_state\:%d, \door_state\:%d, \fw_ver\:\%s\}}]}, uid[0], uid[1], uid[2], uid[3], open_result, lock_state, door_state, FW_VER);service_id必须和控制台里建的服务名完全一致大小写敏感写错了平台不会报错只是数据进了空服务在设备详情里看不到。card_uid用%02X保证每个字节补零否则0x0A会输出成A云端比对时对不上。4.4 命令下发的解析与安全执行收到remote_open命令后不建议直接开锁中间要过三道判断判断项目的不通过时的响应命令签发时间防止过期命令重放result_code 1设备当前是否布防检修模式下不允许远程开result_code 2门磁是否为关门本来就开着不开锁result_code 3响应报文结构固定snprintf(resp, sizeof(resp), {\result_code\:%d,\response_name\:\remote_open\, \paras\:{\result\:\%s\}}, code, code 0 ? OK : REJECT);云平台对时间戳的容忍是有限的如果设备 RTC 走偏太多带时间的判断会出问题所以开机后做一次 NTP 对时、把时间写回 RTC 是标准动作。5. 联调排错串口日志、时间与锁抖动5.1 从串口日志入手定位连接失败调试阶段最有效的动作是把所有 AT 交互和报文原样打到串口上。常见失败点按出现频率排连接被拒三元组里的设备 ID 或密钥写错或者设备在控制台没启用。连上就断心跳间隔没设或者网络模块供电不足WiFi 模块发射瞬间拉垮 3.3V。上报无数据service_id和服务名不一致或者 Topic 里的{device_id}没被替换。排查时先确认「能连上」再确认「能上报」最后才查业务逻辑一次只改一个变量。把 MQTT 的连接返回码打出来比自己猜快得多。5.2 时间不同步带来的连锁问题设备没有 RTC 电池时每次上电时间从 2000 年开始算。这会导致两个现象一是离线记录的刷卡时间全是错的云端按时间查根本对不上二是带时间窗口的鉴权规则比如「只允许 8:00 到 22:00 进入」会全天误判。解决办法是联网成功后立刻向平台或 NTP 服务器取一次时间写进 RTC之后每小时校准一次。记录开关门时间时统一用校准后的时间戳不要用开机以来的毫秒计数。5.3 继电器抖动、读卡冲突与看门狗复位三个高频硬件级问题继电器反复吸合多数是业务层重复触发了开锁请求。在状态机里加一条「非 IDLE 状态忽略开锁请求」就能根治同时把开锁日志打出来看触发源。读卡偶发失败先看 SPI 速率超过 5MHz 后杜邦线飞线的信号质量就撑不住了降到 2MHz 通常立刻稳定。如果换板子依旧检查天线区域的铺地和净空。看门狗复位一般都是网络任务在阻塞主循环。把网络收发拆成非阻塞状态机或者给喂狗单独留一条时间基准不要在主循环末尾简单喂一次。5.4 一张排查表收口现象优先检查常用手段完全连不上平台供电、天线、三元组串口打 AT 交互看连接返回码能连上不上报service_id、Topic控制台设备详情看消息跟踪刷卡无反应SPI 片选、天线净空读 RC522 版本寄存器正常应为 0x92开了不关状态机超时分支打点记录进入 UNLOCKED 的时刻频繁重启看门狗、供电纹波示波器看 3.3V 在 WiFi 发射瞬间的跌落6. 进阶把门禁数据用起来与远程升级的落点6.1 上报数据落到数据库做进出统计设备上报的属性会进云平台的数据流转通道转发到自己的数据库后就能做统计。表结构建议按「一条刷卡记录一行」设计字段至少包含 card_uid、open_result、ts、device_id。下面这条 SQL 可以按人统计某段时间的进出情况SELECT card_uid, COUNT(*) AS open_times, MIN(FROM_UNIXTIME(ts / 1000)) AS first_in, MAX(FROM_UNIXTIME(ts / 1000)) AS last_in FROM device_access_log WHERE open_result 0 AND ts BETWEEN ? AND ? GROUP BY card_uid ORDER BY open_times DESC;open_result 0这个过滤条件不能省失败的刷卡记录同样有价值——连续多次失败往往意味着有人在试卡。给ts和card_uid各建一个索引几百万行数据下这个查询也在百毫秒级。6.2 白名单版本号做成属性是最省事的同步手段设备每次上报都把list_version带上云端写一条规则如果上报的版本低于最新名单版本就下发sync_list命令。这样做的好处是设备不需要主动轮询也不会在名单没变的时候反复拉取。对比「设备定时全量拉取」的做法流量和功耗都低一个量级尤其是电池供电的临时门禁点。6.3 远程升级前的版本核对OTA 最容易翻车的地方是升到一半断电设备变成砖。可靠的流程是先把固件下载到外部 Flash 或备份区校验 CRC 通过后再切换启动标志重启由 Bootloader 判断标志决定跳转到新固件还是旧固件。上报fw_ver之后在平台侧确认所有设备版本一致再清理备份区。如果设备没有外部 Flash退而求其次的做法是分片下载加校验每片写入前先擦除目标扇区全部写完后置一个「升级就绪」标志。这样即使中途断电Bootloader 看到标志不完整仍然会启动旧固件门还能开。本文还有配套的精品资源点击获取