STM32结合RFID图书管理系统：从硬件选型到云端联调全解析

简介：本资源是一套基于STM32平台的物联网图书管理系统毕业设计实战案例，面向高校电子、通信、自动化及物联网相关专业本科生，解决图书馆场景下图书借还、身份识别与数据管理等核心问题，适用于毕业设计选题、课程设计实践及嵌入式开发技能进阶学习。压缩包共229个文件，含48个C源码（涵盖STM32底层驱动如USART、TIM、ADC、I2C及RFID通信逻辑）、46个头文件、31个Java后端接口代码（支持Web管理端）、22个编译中间文件（.o/.d）及配套配置脚本（bat、hex、axf、uvprojx等），整体体积仅4.44MB，结构清晰、模块解耦。已有294人下载学习，提供完整软硬件协同方案：包括RFID读写模块驱动、STM32主控固件、PC端Java管理后台、详细设计文档与调试说明，覆盖从硬件连接、协议解析、串口通信到数据库交互全流程，特别适合理解嵌入式系统与上位机联动开发的关键实现细节。 做嵌入式方向的毕业设计，每年都有大量同学卡在“题目看得懂、真做起来处处是坑”这个环节。今天拿一个非常典型的题目来拆解——《物联网STM32基于RFID的图书管理系统》，这名字看起来长，其实核心就三件事：STM32做主控、RFID做身份识别、图书借还做业务逻辑。这个题目在物联网工程、电子信息、自动化这几个专业里出现频率极高，网上相关源码包、教程也不少，但真正能跑通、能答辩、能讲清楚原理的其实不多。这篇文章我就把这个项目的完整设计思路、硬件选型、软件实现、联调过程和踩坑点一次说透。

这套系统到底能做什么？简单说就是模拟一个小型图书馆的借还流程：学生拿校园卡（RFID卡）靠近读卡器，识别身份后可以借书，系统记录谁借了什么书、什么时候借的；还书时再刷卡，系统更新在库状态，同时把数据存下来。如果你打算在毕设基础上加物联网功能，还可以把这些借阅数据上传到云平台，手机端实时查看。适合的读者包括：正在做这个题目的本科生、想从零走通一次STM32完整项目的初学者，以及打算把类似方案迁移到其他RFID应用场景（比如门禁、考勤）的人。

1. 项目整体设计与思路拆解

很多同学拿到题目第一反应是“先敲代码”，这是最大的误区。STM32项目不像纯软件项目，改起来成本很高，硬件定了基本就改不动了。我的习惯是先把系统切成几个模块，画清楚数据流，再决定选型和排线。

1.1 系统功能需求拆解

图书管理系统说白了就是一套“身份 + 书目 + 状态”的管理逻辑。把需求列出来：

• 身份识别：每张RFID卡对应一个读者编号，刷卡后系统能识别出是谁。
• 借书操作：识别读者后，输入/扫描图书编号，系统校验图书是否在库，若在库则登记借出，记录当前时间。
• 还书操作：识别读者后，输入/扫描图书编号，系统校验这本书是否正处于借出状态，若是则登记归还，更新在库状态。
• 查询展示：当前读者是谁、当前操作结果、图书在库/借出状态，都需要在显示屏上反馈。
• 数据持久化：断电后不能丢数据，需要把借阅记录和图书状态存到非易失存储里。
• 提醒功能：操作成功或失败要有声音或指示灯反馈，方便用户感知。

这是最核心的功能集。如果你想加“物联网”的亮点，可以再加一条：把每一次借还操作记录和当前库存数据通过ESP8266/ESP32模块上报到云端，在网页或小程序上查看。只要主线功能完成，这部分属于锦上添花。

1.2 为什么选STM32+RFID这个组合

这个组合几乎是此类题目最稳妥的答案，原因有三。

第一，STM32是当前单片机领域事实上的标准平台，资料极其丰富，遇到问题基本都能搜到答案。不管是标准外设库还是HAL库，网上都有大量例程，哪怕你之前只学过51单片机，花一周也能上手。

第二，RFID解决方案成熟，成本极低。最常见的RC522模块工作在13.56MHz，支持ISO14443A协议的M1卡（S50），这种卡就是校园卡、公交卡同款技术。整套射频电路被厂家集成在一块小板上，MCU只要通过SPI接口发指令就能读卡号、读写卡内数据，完全不需要自己设计高频天线电路。

第三，这个题目的业务逻辑足够完整，难度梯度合理。它既有底层硬件驱动（SPI通信、GPIO控制），又有上层的业务状态机（借书、还书、查询、异常处理），既有代码量又有技术深度，非常适合作为毕业设计展示。

1.3 系统架构与数据流设计

我用一个简单的数据流来描述这个系统：

RFID卡片 --(13.56MHz)--> RC522读卡模块 --(SPI)--> STM32主控 | +--------------------+--------------------+ | 解析卡号 -> 查表 -> 执行借/还 -> 更新存储 | +--------------------+--------------------+ | +--------------------+--------------------+ | OLED显示状态 | 蜂鸣器提示 | 串口/4G/WiFi上云 | +-----------------------------------------+

整个系统STM32是绝对核心，外设都以它为中心。RC522通过SPI把卡号传进来，按键矩阵或第二块读卡模块用来输入图书编号，数据存到Flash或EEPROM，界面上用OLED/LCD显示。主循环里跑一个状态机，处理不同的用户操作。

我这里特别强调一下架构思维：把“读卡”和“业务处理”拆成两层。RC522只管把卡号读出来，至于这张卡是读者卡还是图书卡、当前是借书还是还书操作，都由状态机去判断。分层的代码结构和不分层的代码结构，在答辩时给老师的印象完全不一样。

2. 硬件选型与电路设计要点

硬件的原则是“够用 + 好调 + 资料多”，不要追求冷门高端芯片，那不叫加分，叫给自己挖坑。

2.1 主控芯片选型：STM32F103RCT6

我推荐用STM32F103RCT6，理由非常实际：

• 64引脚LQFP封装，GPIO数量足够。这个项目至少需要SPI（4根线）+I2C（2根线，如果OLED走I2C）+蜂鸣器（1个）+按键输入（2~4个）+串口（2根线），普通48脚的C8T6其实也能挤下，但RCT6留的余量更大，后续想加模块不用换片子。
• 256KB Flash+48KB RAM，可以完整跑FreeRTOS（如果有需要），也可以轻松放下完整的业务代码和日志缓冲。
• 价格便宜，开发板兼容性好。市面上最小系统板几十块钱就能买到，坏了换一块也不心疼。

如果是新手，直接买正点原子或者野火的STM32F103ZET6开发板也行，引脚兼容性更好，配套例程多。不过做最终实物时，还是建议用RCT6最小系统板，外部加上自己的底板，既省钱又能体现你的硬件设计能力。

2.2 RFID读卡模块：MFRC522详解

MFRC522是NXP推出的低电压、低成本的射频读写芯片，内部集成了13.56MHz的射频收发电路和通信接口，支持SPI、I2C、UART三种接口。市面上最常见的RC522模块就是基于这款芯片做的。

这个模块有几个关键参数你必须知道：

模块本身在PCB上蚀刻了天线线圈，拿来即用，不用自己画天线。它会把高频信号处理后的数据通过SPI接口和MCU交换。MCU发送指令，RC522执行寻卡（Request/PICC）、防冲突（Anticollision）、选卡（Select）、认证（Authentication）等操作，然后就能读写卡片扇区。

寻卡这个操作要着重理解。卡片进入射频场后会被能量激活，RC522发出请求信号，卡片回应UID（即卡号，4字节）；如果有多张卡同时在场，防碰撞机制会逐张分离出卡号；确认卡号后，再对卡选卡并验证密码，之后才能读写数据。所以你在代码里看到的PCD_Request、PCD_Anticollision这几个函数，就是对应这些协议步骤。

2.3 外围模块选型：显示、存储、提示

• 显示模块：首选0.96寸OLED（SSD1306驱动），I2C接口，只要两根线，显示信息量大，代码成熟。如果想让老师看得更清楚，也可以用LCD1602或者2.4寸TFT彩屏。OLED的不足是显示区域小，大段文字需要分屏翻页，但毕设展示完全够用。
• 存储模块：用STM32内部的Flash是最廉价的方案。F103RCT6有256KB Flash，其中主存储区可以按页（每页2KB）擦写，只要程序本身不大，剩余空间完全能存图书列表和借阅记录。缺点是需要自己实现磨损均衡和扇区管理，写坏了程序区就很麻烦。保守一点可以用I2C接口的AT24C02（256字节）或AT24C64（8KB），逻辑简单，缺点是容量小。我实际项目里用的W25Q64 SPI Flash（8MB），驱动现成，容量足够，配合FatFS文件系统还能存日志，这也是很多物联网项目在用的方案。
• 提示模块：蜂鸣器（有源）加一个普通LED就够了。操作成功响一声，失败连续响两声，声音和灯光配合，交互体验立刻不一样。
• 图书编号输入：很多同学会忽略这一步。最简单的方法是用矩阵键盘，4x4就能输入数字编号；进阶做法是再配一个RC522模块，每本书也贴一张RFID卡，刷卡选书，这样可以完全避免按键输入错误。在毕设答辩时，双读卡器方案会显得项目更完整，因为实际操作更接近于真实图书馆。

2.4 电路连接与供电设计

把引脚分配理清楚再连线，这是硬件设计的第一步，也是查问题的重要依据。以下是我实际使用的引脚分配：

供电方面有几个坑必须先说：

• RC522模块需要3.3V供电，绝对不要用5V去供。虽然很多开发板的RC522模块板载了电平转换电路，但不同厂家的模块做工差异很大，5V电源先烧芯片的事我见过不止一次。
• STM32的GPIO是3.3V逻辑，而某些蜂鸣器和继电器的驱动模块是5V逻辑电平。给这类模块加一级三极管或MOSFET驱动，别直接把GPIO怼上去。
• 如果系统里有ESP8266等WiFi模块，它的峰值电流能到300mA以上，这时主电源建议用5V/2A适配器，再用AMS1117-3.3把MCU供电和RFID供电分开。实际做的时候还要在电源输入端并一个100uF的电解电容，给瞬间大电流续命。

3. 软件框架与核心代码逻辑

软件是这套系统的灵魂，也是绝大多数人耗时间最多的部分。我把软件拆成几层来讲：驱动层、中间层、应用层。

3.1 开发环境的搭建：标准库还是HAL库

老话题，但每次都要强调。现在做这类项目有两种主流选择：

• 标准外设库（Standard Peripheral Library）：代码直接操作寄存器封装后的函数，结构简单，适合学习和USART、SPI、I2C这些基础外设的理解。缺点是厂商已停止更新，老工程多。
• HAL库（Hardware Abstraction Layer）：ST官方主推，STMCubeMX配置文件、管脚分配一目了然，生成的代码框架性很强。缺点是代码层次多、效率稍低、报错信息绕。

我的建议：如果你时间紧（2周内要出成果）、追求稳定，用HAL库配合CubeMX；如果你想借毕设吃透STM32底层，用标准库手写驱动。我个人在写这个项目时用了标准库，因为RC522和OLED的例程网上基本都是标准库，直接改起来快。但如果你要在网上搜各种现成源码抄作业，HAL库反而更顺手。

以SPI为例，标准库方式配置SPI1：

void SPI1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; SPI_InitTypeDef SPI_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_SPI1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5 | GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_SetBits(GPIOA, GPIO_Pin_4); SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex; SPI_InitStructure.SPI_Mode = SPI_Mode_Master; SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b; SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low; SPI_InitStructure.SPI_CPHA = SPI_CPHA_Low; SPI_InitStructure.SPI_NSS = SPI_NSS_Soft; SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_8; SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB; SPI_InitStructure.SPI_CRCPolynomial = 7; SPI_Init(SPI1, &SPI_InitStructure); SPI_Cmd(SPI1, ENABLE); }

这里的几个配置值得注意：SPI_CPOL_Low和SPI_CPHA_Low对应的是SPI Mode 0，RC522模块支持Mode 0，时钟空闲时低电平、数据在上升沿采样，这是常见选项。波特率预分频选了8，也就是PCLK1的18MHz/8=9MHz左右，RC522的SPI时钟上限是10MHz，留一点点余量更容易稳定。

3.2 MFRC522驱动与寻卡过程

RC522的驱动库网上很多，可以直接拿现成的改。但你不能只会调用，至少要能讲清楚几个核心函数做了什么事。

最重要的两个函数是PCD_Request（寻卡）和PCD_Anticoll（防碰撞），它们直接对应协议层操作：

// 寻卡，寻找射频场中的卡片 char PCD_Request(unsigned char req_mode, unsigned char *TagType) { char status; unsigned int backBits; // 发送PCD_TRANSCEIVE命令，req_mode为0x52表示寻所有卡 status = PCD_Comm(PCD_TRANSCEIVE, &req_mode, 1, TagType, &backBits); if ((status == MI_OK) && (backBits == 0x10)) return MI_OK; return MI_ERR; }

实际项目里我建议封装一个ReadCardId函数，把所有协议细节包进去，上层业务只关心最后拿到的卡号：

uint32_t ReadCardId(void) { uint8_t cardId[5]; uint8_t status; uint8_t i; status = PCD_Request(PICC_REQALL, cardId); if (status != MI_OK) return 0; status = PCD_Anticoll(cardId); if (status != MI_OK) return 0; // 卡号为4字节，整合成一个uint32_t方便存储和比较 uint32_t id = 0; for (i = 0; i < 4; i++) { id = (id << 8) | cardId[i]; } return id; }

这里有个关键点：寻卡函数一次只能处理一张卡。如果两张卡同时贴近读卡器，防碰撞会随机选一张返回，另一张需要再次调用寻卡才能读到。在实际借还场景里，这还是个小优点——避免误读。但在调试时，你可能会发现“卡贴上去没反应”，十有八九是寻卡函数只调用了一次，改成循环寻卡就好。

另外，中断方式比轮询方式更优雅。RC522的IRQ引脚可以在检测到卡片时主动通知MCU，这样主循环就不用每秒几百次轮询了。初始化时把IRQ配成下降沿触发的外部中断，在中断里置一个标志位，主循环检测到标志位后再去读卡号。不过要注意：RC522的IRQ需要设置ComIEnReg中断使能寄存器，不同库封装的函数名不一样，调试时先确认中断是否真的来了。

3.3 图书借还的业务状态机

这一层决定了你的代码逻辑是否清晰。很多同学的代码是一大段if else嵌套，从功能上看勉强能跑，但加一个功能就要改好几个地方，答辩时一问就乱。用状态机可以理清整个流程。

定义系统状态：

typedef enum { SYS_IDLE, // 空闲，等待刷卡 SYS_WAIT_BOOK, // 已识别读者，等待输入图书编号 SYS_BORROW_OK, // 借书成功 SYS_BORROW_FAIL, // 借书失败 SYS_RETURN_OK, // 还书成功 SYS_RETURN_FAIL, // 还书失败 SYS_QUERY // 查询状态 } SysState;

主循环的状态机骨架：

while (1) { switch (currentState) { case SYS_IDLE: if (cardDetected) { readerId = ReadCardId(); if (readerId != 0 && IsValidReader(readerId)) { currentState = SYS_WAIT_BOOK; OLED_ShowReaderId(readerId); } else { // 卡号不在读者表里，蜂鸣器响两声 BeepError(); } } break; case SYS_WAIT_BOOK: // 等待图书编号输入，可以是按键输入的编号 if (bookIdReady) { // 执行借书逻辑 if (BorrowBook(readerId, bookId)) { currentState = SYS_BORROW_OK; SaveRecords(readerId, bookId, BORROW); } else { currentState = SYS_BORROW_FAIL; } } break; // 其他状态处理... default: currentState = SYS_IDLE; break; } DelayMs(50); }

状态机的核心价值在于：任何时刻系统处在明确的状态，外部输入（刷读者卡、刷图书卡、按键）只会触发状态转移，不会出现“不知道现在在干嘛”的情况。借书时刷了读者卡，系统进入等待图书状态，这时再刷一张卡，如果刷出的是图书卡就直接绑定，如果又是读者卡就切换读者或者报错。边界逻辑清楚了，代码就稳了。

3.4 数据存储设计

图书信息、读者信息、借阅记录分别怎么存，这是数据层的核心。

• 图书表：每条记录包含图书编号、书名、作者、是否在库、当前借阅者卡号。单条定长120字节左右，500本书约60KB，用W25Q64绰绰有余。
• 读者表：读者卡号（4字节XDR映射），加上姓名、学号。一般几千条以内都很好处理。
• 借阅流水：每笔记录的格式可以是：流水号（4字节）+ 读者卡号（4字节）+ 图书编号（4字节）+ 时间戳（4字节）+ 借/还标志（1字节）。在Flash里以追加写的方式存，配合Flash的擦除特性，尽量少擦块，延长寿命。

如果你用W25Q64，我强烈建议直接在代码里做一个极简“文件系统”：划分区域，首页存分配表，数据区按页写。不需要引入FatFS，因为它还要管理目录结构、碎片，对嵌入式来说太笨重。自己写一个按偏移地址读写的简易存储层，配合一个“记录条数计数”，就足够支撑这个项目。

掉落存储时有一个必经之路：如果MCU正在写Flash时掉电，数据会损坏。我的处理办法是存两条备份，一条在主区、一条在备份区，读的时候校验两条是否一致，如果有一条校验失败就用另一条恢复。这个“双备份+校验”思路在答辩时讲出来非常加分，因为它是真实产品里必须考虑的可靠性问题。

3.5 物联网上云：让毕业设计真正名副其实

题目里带了“物联网”三个字，很多学校评审现场会关注这一块。你可以选择把数据上报到云平台。最简单而且稳定的方案是，STM32把借阅记录通过UART发给ESP8266，ESP8266通过MQTT协议上报到阿里云IoT平台或巴法云，在网页端做一个简单的数据可视化页面。

MQTT发布的内容可以是JSON字符串，比如：

{ "reader": "0A1B2C3D", "book": "101", "action": "borrow", "timestamp": 1699999999 }

这里要注意：STM32的串口数据帧格式得自己定，比如帧头（0xAA 0x55）+数据长度+数据内容+CRC16校验。ESP8266收到完整帧后再解析成JSON上报。如果你不定义帧格式，直接用printf把原始数据发出去，两边很容易发生粘包和错位。

实际上，很多同学在物联网上云环节最容易被卡住，不是因为代码难，而是因为不会配置云平台的产品模型和Topic。建议先在本机搭建一个EMQX Broker做测试，确认ESP8266能收发消息后，再迁移到云平台。这样调试周期非常短。

4. 实操过程与核心环节实现

这一节我按真实的调试顺序来走一遍，跟着这个流程，你能少走很多弯路。

4.1 开发准备与模块单独验证

拿到硬件后，先不要急着写业务代码，把每个模块单独点亮验证一遍。我的建议顺序是：

1. 点亮OLED，跑通显示“Hello”的例程。确认I2C接线和地址（SSD1306默认地址0x3C）正确。
2. 跑通RC522读卡号例程，在OLED或串口上打印卡号。
3. 测试W25Q64的擦写读例程，确认SPI通信正常。
4. 测试蜂鸣器和按键的GPIO输入输出。

这里我特别提一下RC522的测试方法。很多商家提供的例程里，PCD_Request用的是PICC_REQALL（0x52），这个命令会唤醒所有卡并返回卡类型。你拿一张空白M1卡贴近天线，串口应该会打印类似“Card ID: 0x1A 0x2B 0x3C 0x4D”的输出。

如果读不出卡号，不要盲目改代码。先检查这几件事：

• 模块供电是否稳定，用万用表测量模块VCC和GND之间是否有3.3V。
• SPI接线的SCK/MISO/MOSI是否一一对应，很多模块的丝印会印错。
• 片选信号NSS是否被正确拉低。RC522只有在NSS为低时才响应SPI通信。
• 模块的天线区附近不要放金属物体，天线表面不要覆盖大块导电材料。

4.2 卡号绑定与借还流程联调

单独模块都通了，接下来做接线绑定：给每本“书”绑定一张卡。这里有两种实现方式，取决于你选的是单读卡器+按键还是双读卡器。

双读卡器方式：

• 读卡器1（主）：识别读者卡。
• 读卡器2（辅）：识别图书卡，在初始化模式下可以给新书绑定编号。

初始化绑定流程：进入管理模式 -> 在辅读卡器上刷书卡 -> 在按键/上位机上输入图书编号 -> 系统把（书卡号，图书编号）写入图书表。

业务运行时流程：

• 借书：在主读卡器上刷读者卡 -> 屏显读者信息 -> 在辅读卡器上刷书卡 -> 系统查图书状态 -> 若“在库”，登记借出，蜂鸣器响一声，屏显“借阅成功”。
• 还书：同样刷读者卡 -> 刷书卡 -> 查到该书“已借出（且借阅者是当前读者）”，登记归还。
• 异常情况：图书不是借给这个读者的，屏显“非本人借书，无法归还”。

4.3 时序与驱动的细节

联调过程中最常出问题的不是逻辑，而是外设时序。RC522的执行流程比较长，完整检测一张卡需要几十毫秒，期间不能被打断。如果你的代码在调用读卡函数时开了中断，而中断服务函数里刚好又有比较耗时的操作，可能导致SPI时序错乱，读到的卡号是乱码或直接失败。

我的做法是：在SPI通信期间给关键操作加上临界区保护，用__disable_irq()和__enable_irq()包住对时序敏感的部分。串口和OLED打印放在SPI通信完成之后。

另外一个细节是RC522的软复位。每次系统初始化时，给模块的RST脚一个低脉冲再拉高，然后延时50ms，确保模块进入正常工作状态。否则模块可能还在上电自检阶段，SPI命令都不响应。

void RC522_Reset(void) { GPIO_ResetBits(GPIOB, GPIO_Pin_0); // RST拉低 DelayMs(50); GPIO_SetBits(GPIOB, GPIO_Pin_0); // RST拉高 DelayMs(50); PCD_Reset(); }

4.4 上云联调与数据核对

如果你加了ESP8266上云，联调时先用串口调试助手模拟STM32发数据给ESP8266，确认ESP8266能正确解析并上报。然后再把STM32的串口接到ESP8266上，用云端日志去核对收到的每一条记录。

云端数据核对是必须做的。我遇到过一次很奇怪的现象：云端显示的借书时间总是比实际时间早8小时。排查发现是ESP8266上电后会自带NTP校时，它上报的时间戳是UTC时间，而业务代码里没有转成北京时间。在WiFi模块的固件脚本里加8小时偏移就解决了。这种小问题如果不做端到端核对，根本发现不了，但答辩时老师如果问到“你这上云数据时间对吗”，答不上来会非常尴尬。

5. 常见问题与排查技巧实录

下面这些问题都是我实操过程中真实遇到过的，每一个都有具体解决方案，整理成速查表方便你直接对照。

再补充几个容易被忽视但影响很大的细节：

• 卡号存储不要用字符串，尽量转成uint32_t。4字节卡号转成整数后，无论是比较还是查表，都比你用字符数组去memcmp快得多，代码也干净。
• OLED显示内容要设计成分屏结构，比如第一屏显示当前读者信息，第二屏显示“请刷书卡”，第三屏显示操作结果。做界面设计时还要考虑刷了一本书但没刷读者卡的情况，这时系统应该停留在初始广告页，而不是报错。
• 按键消抖不能省。机械按键按下时会有约5-20ms的抖动，直接用GPIO判断按下，大概率会出现一次按下被识别成两次。最有效的消抖是10ms延时确认，或者用定时器在20ms内连续采样3次都稳定为低电平才算有效按下。

6. 关于这个项目的边界与进阶思路

整个项目做到这里，主干功能已经完整了。但毕设答辩时老师很喜欢问一个问题：“你这个系统还能怎么改进？”提前想好并做出部分实现，是非常加分的。

几个我认为值得做的扩展方向：

• 用FreeRTOS替代裸机状态机，把读卡、显示、通信拆成独立任务。任务间用消息队列传递卡号，能体现实时操作系统思想，也契合物联网设备的应用场景。
• 增加“超期未还”自动告警。在云端做定时任务扫描借阅记录，超过设定时长未还的书，推送提醒给管理员或读者。这个功能在真实图书馆里非常实用，做的过程也不复杂。
• 把展示端做成手机小程序。STM32通过MQTT把数据上报到云，小程序订阅同一Topic，这样在手机上就能看库存、借阅记录。做出来的效果比网页端更直观，而且小程序开发门槛不高。
• 给RC522增加低功耗策略。如果后续做无源物联网方向，卡片的功耗、天线的读写效率、能源采集都是可以深入挖掘的点。虽然毕设不一定需要做到，但你可以顺手查点文献，答辩时引用一两篇也行。

但我也要说一句实话：扩展功能是加分项，不要在核心功能还没完全稳定时就去折腾云平台和小程序。先保证借还主流程流畅跑通，断电不丢数据，界面无卡顿，答辩时能从头到尾演示完整流程，这个项目的基本盘就稳了。

7. 写在最后的实操心得

我做完这个项目最大的体会是：毕设的真正难点不在于技术本身，而在于把硬件、软件、业务逻辑这三条线拧成一股绳。很多同学在主控选型、模块接线这些地方反复纠结很久，真到写业务代码时反而没时间调。其实先把最简单的版本跑通，再逐步加功能，才是这类嵌入式项目最稳的节奏。

最后分享一个小技巧：整个项目从硬件配置到业务逻辑，每完成一个里程碑就做一次完整的“掉电重启测试”。拔掉电源再上电，看看系统能不能恢复到断电前合理的状态。这个动作看起来简单，却能提前暴露大量隐藏问题——存储写入是否完整、状态机是否回到正常状态、RFID模块是否正常复位。做到这一步，你对这套系统的掌控力度就完全不一样了。

本文还有配套的精品资源，点击获取