企业官网建设流程全解析

项目编号X504281| 主控 STM32F103C8T6 核心板 | 身份采集 ESP32-CAM + OV2640 | 楼层执行 28BYJ-48 步进电机 | 本地显示 OLED12864（I2C） | 按键 + 蜂鸣器 + LED 指示 | 通信 HTTP POST + TCP Socket | 服务端 jeesite + SpringBoot + MySQL + 虹软 SDK

摘要：本文介绍一套面向电梯场景的人脸门禁与楼层调度系统。硬件侧以 STM32F103C8T6 为核心板，ESP32-CAM 摄像头模组负责在按下开门键后拍照并把 JPEG 直接 POST 到服务端，28BYJ-48 步进电机用转动圈数模拟楼层高度，OLED12864 就地显示当前楼层与运行状态，蜂鸣器在识别不通过时发声。人脸比对由服务端调用虹软 SDK 完成，放行结论经 TCP Socket 回传主控后驱动电机动作。服务端基于 jeesite 平台与 SpringBoot 框架构建，以 MySQL 完成数据持久化，网页端提供用户与人脸绑定、楼层管理、门禁设备登记、实时数据查询与进出记录查询。

一、项目概述

电梯门禁的核心问题不是「要不要拦人」，而是「怎么把人和楼层对上」。刷卡方案里卡内只有编号，卡片丢失后后台既不知道是谁在用，也无法把卡与某一层楼稳定绑定。本项目改用人脸作为身份凭据，并把人脸库放在服务端，硬件侧只承担触发、采集与执行。

本文所述系统以 STM32F103C8T6 为主控，外接 ESP32-CAM 摄像头模组、OLED12864 显示屏、28BYJ-48 步进电机、按键、蜂鸣器与 LED 指示灯，摄像头负责按快门、服务端负责人脸识别、主控负责楼层判定与开门放行；服务端基于 jeesite 平台与 SpringBoot 框架构建并以 MySQL 持久化，网页端负责用户与人脸绑定、楼层管理、电梯实时状态与使用记录查询，把身份核验、楼层调度与运行记录整合进同一套可远程查看的闭环。

系统在 2025 年 5 月 完成整机联调，多次测试表明「按键—拍照—上传—识别—回传—运行」这条链路可以稳定往返。

1.1 系统技术架构

系统自上而下划分成应用层、服务层、网络层、控制层与感知执行层五个层次。

图 1 系统总体架构图

五层的关键分工是：摄像头只负责按快门与上传，主控只负责判定楼层与驱动电机，人脸比对始终在服务端。这也意味着换一套人脸库不必重新烧录固件。

1.2 系统功能结构

按部署位置划分为硬件系统、软件系统与交付服务三列。

图 2 系统功能结构图

三列之间只有一条边界：设备侧只做「触发 + 采集 + 执行」，人脸比对、身份判定与记录留存全部放在服务端。

二、硬件系统设计

2.1 硬件系统原理框图

整块板子的中心是 STM32F103C8T6 核心板模块，左侧是开门按键与摄像头模组，右侧是步进电机、显示屏、蜂鸣器与指示灯，整机由 TYPE-C 取电口单口供电。

图 3 硬件系统原理框图

从框图可以看出本项目在硬件上的一个取舍：身份采集这一路只连了两根线。ESP32-CAM 与主控之间仅接IO1(TX)与IO3(RX)，分别落在PA10与PA9上，也就是 USART1 的收发脚；供电另走 5 V 与 GND。模组其余引脚在图上没有任何网络 —— 这说明主控并不经手图像数据，JPEG 由模组自己经网络直接上传服务端。

2.2 硬件原理图

原理图用嘉立创 EDA 绘制，同时提供 pdf、png、json 与 schdoc 四种格式。本文的接线描述以json源文件中的网络标号为准。

图 4 硬件原理图

提示：解析原理图时建议直接读嘉立创 EDA 的json源文件。导出的 PDF 文字层只会包含已经连线的部分，而源文件里能取出「引出但未连接」的悬空网络标号 —— 本项目正是靠这一点发现核心板右侧的PB5与3.3V属于预留脚。提取方式是从schematics[0].dataStr.shape这组字符串里，用\^\^([\d.\-]+)~([\d.\-]+)\^\^(\S+?)~取网络标号坐标，用spiceSymbolName\([^\]*)\` 取元件型号。

2.3 硬件实物

实物装配以蓝色洞洞板作底板，蓝色核心板压在板面中部，28BYJ-48 步进电机经彩排线引出到板外，OLED12864 挂在板面下缘，摄像头插座与串口扩展口留在板边，整机由一根 USB 线供电与下载。

图 5 硬件实物总览

OLED12864 上实测显示四行：智能电梯门禁、楼层：01 F、状态：停止，以及一行人脸识别失败！。前两行说明屏幕上的汉字是提前取模固化的，只能显示预先取好的内容；最后一行说明识别未通过的提示会直接落在屏幕上，不必等人去后台查记录。

图 6 板载器件与接线特写

2.4 引脚分配

把这几根线排开来看，落点并不随意：

· 步进电机四相PA0/PA1/PA2/PA3恰好是TIM2 的通道 1 至 4（默认映射即可用）

· 显示屏SCK/SDA落在PB6/PB7，正是硬件 I2C1 的默认分配

· 摄像头两线落在PA9/PA10，正是USART1 的收发脚

·PB0给蜂鸣器、PB1给按键（配R210 kΩ）

· 核心板右侧的PB5与3.3V悬空未接，属预留

三组外设各占一路片上外设，彼此不抢资源。

三、逐线核对原理图得到的四处判断

把嘉立创 EDA 源文件里的网络标号提取出来、与 PDF 文字层逐条对照后，有四处值得单独说明。

3.1 步进电机的四相正好落在同一路定时器的四个通道上

28BYJ-48 的 A、B、C、D 四相依次接 PA0、PA1、PA2、PA3。这四个脚恰好是 STM32F103 的 TIM2 通道 1 至通道 4（默认映射即可用），也就是说四相驱动脉冲可以由同一路定时器的四个通道直接产生，既不必为每一步序再去找别的定时器，也不需要靠软件延时来凑节拍。对步进电机这种要求四相严格按时序轮流的器件，这样的落点是相当整齐的。

3.2 显示屏的接线恰好与硬件 I2C1 的默认分配吻合

OLED12864 的 SCK 接 PB6、SDA 接 PB7。在 IIC 屏上 SCK 就是时钟线 SCL，而 STM32F103 的硬件 I2C1 默认功能分配正是 SCL = PB6、SDA = PB7，两者完全一致。这块屏因此具备直接调用片上 I2C1 外设的条件，不必再用通用 IO 去模拟时序。

3.3 摄像头只占两线串口，图像不经主控搬运

ESP32-CAM 与主控之间只连了 IO1(TX) 与 IO3(RX) 两根线，分别接 PA10 与 PA9 —— 正是 USART1 的收发脚；供电另走 5 V 与 GND。模组其余引脚在图上没有任何网络。换句话说，主控这一侧并不经手图像数据，它只负责触发拍照与接收识别结果，JPEG 由模组自己经网络直接上传服务端。这条链路上主控不是数据通道，只是事件触发器。

3.4 核心板引出的 PB5 与 3.3V 属于预留

图纸在核心板右侧引出了 PB5 与 3.3V 两个网络标号，但从头到尾没有任何元件接上去。相比之下其余各脚都各就各位：PA9 / PA10 给了摄像头、PA0 ~ PA3 给了步进电机四相、PB0 给了蜂鸣器、PB1 给了按键、PB6 / PB7 给了显示屏。读原理图时把「引出来但没接东西」的脚单独记一笔，能避免在写接线表时凭位号顺序想当然。

以上四条并非对设计的质疑，而是对既有连线的如实描述 —— 本文只记录原理图上真实存在的连接，不对作者的意图作推测。

四、通信链路与数据交互

4.1 通信参数

为遵守平台规范，本文涉及的服务地址一律省略协议前缀，实际配置以完整地址为准。

图片链路与指令链路分开，是本项目在通信设计上最实用的一处安排。一张 JPEG 少则几十 KB，如果让它和放行指令挤在同一条通道上，识别结果就要排在图片后面慢慢等；而现在图片走 HTTP POST 直奔服务端，指令走 Socket 独立往返，两边互不阻塞。

4.2 数据交互时序

以「刷一次脸乘梯」为例，整个过程分成十二步：按键触发、发出拍照指令、图像以 HTTP POST 上传、服务端建立识别记录、调用识别引擎比对、结果写入记录、结论经 TCP Socket 回传、主控解析、通过则驱动电机模拟运行并刷新屏幕、不通过则蜂鸣器鸣响并提示。

图 7 系统数据交互时序图

这张图里有两处值得展开。第一处是「主控全程不搬运图像数据」：摄像头模组与主控之间只有两根串口线，JPEG 从模组直接进网络，主控只是事件的触发者。第二处是「比对结果不落在硬件上」：住户的人脸照片存在服务端，硬件侧既没有特征库也没有比对逻辑。

五、软件系统与界面功能

5.1 界面字段

把这五组与硬件对照可以看清数据的来路：「当前楼层 / 目标楼层 / 运行状态」直接取自主控上报的状态，与 OLED 上显示的是同一份数据；「进出记录」里的类型（外出 / 回家）则由服务端按比对结果写入。

5.2 登录页与住户登记

登录页是整套系统的入口，背景是一张电梯厅实景，正中的白色卡片上给出「登录账号」「登录密码」两个输入框与一个「登录」按钮。

图 8 登录页与新增用户页

新增用户页的页头写着基本信息【手机号码将作为登录的账户信息】，也就是说手机号同时承担账号与联系方式两个角色。字段依次为姓名、电话、楼层（下拉，默认第 1 楼）与图片上传（最多 1 张）。这里有一处值得留意：人脸是以照片形式绑定的，而不是把特征值写进硬件 —— 照片存在服务端，比对也在服务端做。

5.3 用户管理与门禁设备管理

图 9 用户管理页与门禁设备管理页

用户管理页实测注册了 4 条记录：王五（3 层）、张三（5 层）、林超（4 层）与雷天昊（2 层），人员状态一栏均为离家。「照片路径」一栏显示的不是一串路径文本，而是一张缩略图 —— 说明人脸是以图片形式存放在服务端，页面渲染时把图片回显出来。

门禁设备管理页实测只有 1 台：设备编号ZDBH01、设备名称梯控、online 状态在线、更新时间2025-05-04 13:12:54。页面提供设备编号与设备名称两个查询条件，也就是说加装第二台梯控设备时，后台不需要改代码，登记一条即可。

5.4 实时数据查询

图 10 实时数据查询页

实测截取的一帧为：更新时间2025-05-04 13:15:00、设备在线、当前楼层1楼、目标楼层--- 楼、运行状态停止。

这帧数据里有两点值得注意：

· 「目标楼层」显示三个短横线而不是数字，说明当下并没有待执行的呼叫，电梯处于驻停状态

· 「运行状态 停止」与「当前楼层 1楼」同时出现，与屏幕上显示的楼层：01 F / 状态：停止完全对应 —— 两者是同一份状态

下方「实时图像」区横向排开五张识别画面，作用是让人一眼看到最近几次有人经过摄像头时的画面，配合进出记录页可以核对某一条记录对应的影像。

5.5 进出记录查询

图 11 进出记录查询页

实测该查询共 31 条记录，每页显示 20 条，共 2 页。页面前六条依次是：王五（外出 13:06）、王五（回家 13:06）、张三（外出 13:04）、雷天昊（回家 12:59）、雷天昊（外出 10:51）、雷天昊（回家 10:50）。

从这六条能看出「类型」一栏的取值是成对的：同一个人先「外出」后「回家」，每次放行单独落一条记录，而不是把一次出行合并成一行。这种记法带来的好处是时间线完整，代价是表格里会有大量同名行，所以查询条件才把姓名与电话并列。

说明：本项目界面截图含真实手机号与人脸照片，已在交付前统一作不可逆遮蔽（马赛克 + 高斯模糊）。遮蔽后经高频细节能量自校验，各遮蔽区域降至原值的 0.3% 以下。

六、固件烧录与调试

硬件侧程序用 Keil 5 开发，烧录走串口下载工具完成。

图 12 串口烧录工具的烧录记录

实测这一条烧录记录的内容是：

端口 COM33, 波特率 115200 芯片 ID: 0x000412 STM32F103xx Low-density 芯片 Flash 容量为 32KB 开始擦除全部片内 Flash ... 成功 开始从 08000000 开始编程 ... 成功 成功从 08000000 开始运行 耗时 0.128 秒

把这条记录与实物照放在一起看，可以说清楚一件事：板子上的程序是通过串口写入并已经跑起来的。

七、系统视频展示

演示视频完整记录了系统从登录、录入人脸、绑定楼层，到按下开门键触发拍照、服务端识别、电机运行至目标楼层的全过程，时长约 5 分 47 秒。

图 13 演示视频封面

视频里可以重点看三处：一是按下开门键到屏幕出现识别结果之间的停顿，这段时间正是图像上传与人脸比对在服务端跑；二是识别通过后步进电机的转动，圈数与楼层差是对应的；三是识别不通过时的动作 —— 蜂鸣器鸣响、屏幕提示，门并不打开。

八、交付内容

如需完整交付清单，可在站内私信说明项目编号X504281与用途（学习 / 二次开发 / 课程设计），会按用途给出对应的资料组织方式。