物联网STM32图书馆管理系统：RFID借书、ESP8266透传与上位机联动实践

简介：面向毕业设计场景的物联网图书管理系统项目包，融合STM32嵌入式、RFID识别与Java后端技术，兼顾嵌入式开发与后台管理需求，解决书店图书库存实时更新与信息化管理问题，适合计算机、物联网专业学生用于课程设计或毕设参考。压缩包共含229个文件，约4.46MB，主要包含C/H源码、Java后端工程、Keil工程与编译产物、XML/Properties配置文件及说明文档等，覆盖从MCU驱动、RFID读卡到数据库交互的完整软件链路。其中C/H源码涵盖USART、I2C、ADC、定时器等STM32标准库外设驱动，Java代码则承担后端服务与接口逻辑，整体目录结构便于按模块阅读。开发环境涉及Idea、MySQL、VsCode、Keil5，适合在已有基础板上快速验证，也可对照理解软硬联调过程，目前已有898人学习/下载。借助该资源可快速理解RFID图书管理系统的软硬件分层，复用外设驱动与业务代码，为同类智慧图书馆项目提供可直接改造的工程模板。

1. 物联网STM32图书馆管理系统，先从借书动作说起

大学图书馆里的高频借还场景，恰好是嵌入式系统最经典的实战样本。你刷卡、机器“嘀”一声、屏幕弹出书名和学号，这个动作背后并不只是RFID读卡器读到一串卡号那么简单，它是“感知层 + 控制层 + 传输层 + 应用层”四层物联网架构的完整落地。用STM32做主控，RFID做身份识别，再搭配Wi-Fi模块把数据送到上位机或云平台，就构成了一套可以真正跑起来的图书管理系统。

这个毕业设计题目的价值在于：它不像纯上位机项目那样只写Java或C#窗体，也不像纯嵌入式项目那样只点LED灯，而是把I2C/SPI总线驱动、串口通信、数据库事务、HTTP协议整个串起来。你完成的不只是一张原理图配一段main函数，而是一个从硬件到数据库的闭环系统。适合那些想证明自己既看得懂时序图、也能写业务逻辑的应届生。

这套方案常见做法是：STM32F103C8T6作为主控，RC522负责读卡，ESP8266做网络透传，上位机用C#或Python Flask接收数据并更新MySQL数据库。接下来，先从硬件选型和电路连接说起。

2. 硬件选型与型号匹配：STM32与RC522、ESP8266的接线边界

2.1 为什么是STM32F103C8T6，而不是F4或H7

STM32家族庞杂，但在这个题目里，F103C8T6几乎是默认选择。原因有三点：第一，Cortex-M3内核主频72MHz，处理ISO/IEC 14443A协议的位流解码绰绰有余；第二，芯片内置的SPI、USART、I2C外设恰好覆盖RFID读写器、Wi-Fi模块、OLED屏三类常见外设；第三，该芯片在市面上的开发板、最小系统板存量极大，参考代码和故障案例都容易找到，调试周期短，这是毕业设计进度能咬牙推进的实用保障。

如果选F407甚至H743，处理能力确实过剩，但引脚的5V容忍度、3.3V电平匹配逻辑反而要重新核对。图书管理系统的数据量本身极小——一次借书操作就是几十字节的卡号加学号信息，F103的2×10KB SRAM和64KB Flash完全够用。

F103还有一个容易忽视的优势：它的USART支持硬件流控和DMA。在后续用ESP8266通过串口透传数据时，开启DMA不占用CPU就能把卡号数据发出去，主循环还能继续扫描按键或刷新OLED显示。这个特性在你做系统联调时会明显感到顺滑。

2.2 RC522射频模块接线与电平匹配注意事项

RC522是NXP推出的经典RFID读写芯片，工作在13.56MHz频段，支持SPI和I2C两种接口模式。在与STM32连接时，常用SPI模式，接线组合如下表所示。

关于电平匹配要专门提醒：RC522模块的逻辑电平是3.3V，而STM32F103的GPIO虽然标注“5V容忍”，但那是针对输入场景。如果你用的是5V供电的Arduino式扩展板，又同时把RC522接到STM32上，必须确认模块上是否自带电平转换芯片。大部分红色小板的RC522不带转换，直连3.3V单片机的IO口最安全。

2.3 ESP8266串口透传的角色定位：不用AT指令固件之外的复杂方案

ESP8266在这里承担的是“网络搬运工”。把STM32串口2与ESP8266的UART对接：STM32的PA2（USART2_TX）接ESP8266的RXD，PA3（USART2_RX）接ESP8266的TXD，波特率统一设置为115200。模块先用AT指令配置为STA模式并连接路由器，之后再通过TCP或HTTP方式把借阅记录推到上位机。

有同学纠结是让ESP8266跑MQTT协议直连云平台，还是做最简单的TCP透传。从工作量评估，毕业设计阶段做TCP透传更稳健——你只需要在ESP8266上执行几组AT指令建立TCP连接，然后STM32用串口直接发送数据即可。MQTT方案意味着上位机还得搭一个Broker，调试链路变长，延毕风险直线上升。

还有一个常见选型问题：要不要用ESP32替代“STM32+ESP8266”的组合？如果用ESP32，那标题里的STM32就名存实亡了。两个方案各有取舍，但从题目符合度和学习覆盖面来看，STM32主控加ESP8266通行的组合最能体现“系统设计”的完整度。

3. RFID读卡程序设计：从SPI初始化到卡号解析的完整时序

3.1 SPI初始化参数：时钟极性、相位和速率怎么配合RC522

RC522的命令帧格式、状态机逻辑都有官方数据手册可查，但调通SPI时序才是第一步。先看初始化代码：

void RC522_SPI_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_High; SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge; SPI_InitStructure.SPI_NSS = SPI_NSS_Soft; SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_32; SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB; SPI_Init(SPI1, &SPI_InitStructure); SPI_Cmd(SPI1, ENABLE); }

这段代码中有三个参数决定RC522能否正常工作。第一个是SPI_BaudRatePrescaler_32，它把72MHz系统时钟分频到2.25MHz，RC522的SPI时钟上限约为10MHz，2MHz级别留了足够余量，对长走线的抗干扰能力也更友好。第二个是SPI_CPOL和SPI_CPHA的组合——RC522要求时钟空闲时为高电平、数据在第二个边沿采样，这个组合不能凭感觉改，否则读出来的卡号会全是0xFF。第三个是SPI_NSS_Soft，片选信号完全由软件控制，先用GPIO拉低、再发命令、结束后拉高，这个顺序在RC522读写时序里非常关键。

3.2 寻卡、防冲突、选卡、认证四步流程的代码骨架

读一张M1卡的完整流程不是“读一下”那么简单，而是由寻卡、防冲突、选卡、认证四个阶段构成。M1卡（如S50）内部有16个扇区，每扇区4个块，块0的前4字节是4字节卡号。要读到卡号，代码骨架如下：

// 寻卡模式：0x52表示寻所有在感应区的卡 char RC522_Request(unsigned char mode, unsigned int *tagType) { char status; unsigned int cardType; RC522_WriteRawRC(0x0D, 0x07); // 清中断标志 status = RC522_ToCard(PICC_REQALL, &cardType); if (status == MI_OK) { *tagType = cardType; } return status; } // 防冲突，拿到4字节卡号 char RC522_Anticoll(unsigned char *serialNumber) { char status; unsigned char i; unsigned char checksum = 0; unsigned char buffer[2]; RC522_WriteRawRC(0x0D, 0x00); status = RC522_ToCard(PICC_ANTICOLL, buffer); if (status == MI_OK) { for (i = 0; i < 4; i++) { serialNumber[i] = buffer[i]; checksum ^= buffer[i]; } if (checksum != buffer[4]) { status = MI_ERR; } } return status; }

防冲突阶段返回的4字节数据就是卡号。M1卡的防冲突机制解决的是“两张卡同时进入感应区”的问题，卡会返回自己的序列号，同时带一个校验字节。在校验时用异或方式把4个字节逐位异或，结果等于第5个字节才算数据有效。如果你在实际运行中发现识别到的卡号时对时错，最先检查的就是这个异或校验逻辑。

认证阶段要调用RC522_ToCard发送PICC_AUTHENT1A命令，同时传入扇区密码。对图书管理系统而言，只需要读取卡号做身份识别，并不一定要深入操作卡内数据块，所以认证后直接退出即可，不用写块操作。

3.3 蜂鸣器与LED反馈：状态提示的最小实现

每次刷卡成功或失败，必须有明确的物理反馈，否则调试人员对着屏幕根本不知道模块是没读到卡还是读错了卡。这个反馈可以做得极简：

void Beep_Short(void) { GPIO_SetBits(GPIOB, GPIO_Pin_12); delay_ms(80); GPIO_ResetBits(GPIOB, GPIO_Pin_12); }

用一个PB12引脚接有源蜂鸣器，读卡成功时调用Beep_Short发出短促提示；读到未登记卡号时则调用Beep_Long长鸣两次。LED同理，刷卡成功的绿色LED亮200ms、红色LED保持熄灭。代码逻辑本身没有难度，但这一步对后续联调的价值极大——不用接串口调试线，光靠听觉就能判断主程序是否进入读卡分支。

4. 数据上行与图书管理：STM32串口组帧、ESP8266转发与上位机入库

4.1 串口组帧协议：避免粘包和半包的关键设计

RFID读到卡号后，数据不能裸发。假设你直接通过串口printf发送卡号，上位机收到的可能是一串连续字符，无法判断哪几位属于本次操作。解决办法是自定义一个简单的帧协议。

组帧代码示意：

void Send_RFID_Frame(unsigned char operation, unsigned char *cardId) { unsigned char frame[10]; unsigned char checksum = 0; unsigned char i; frame[0] = 0xAA; frame[1] = 0x55; for (i = 0; i < 4; i++) { frame[2 + i] = cardId[i]; checksum += cardId[i]; } frame[6] = operation; checksum += operation; frame[7] = checksum; frame[8] = 0x0D; frame[9] = 0x0A; for (i = 0; i < 10; i++) { while (USART_GetFlagStatus(USART2, USART_FLAG_TXE) == RESET); USART_SendData(USART2, frame[i]); } }

帧头0xAA55的作用是让上位机接收时快速定位数据起始位置。校验和防止串口传输过程中出现单字节错误；上位机收到后重新累加，如果和校验字节不相等就丢弃本帧。帧尾的回车换行则是为了兼容串口调试助手直接查看原始数据时的可读性。

这里有个容易被忽略的点：USART2的TXE标志必须等待置位再发送下一字节，否则会丢数据。在72MHz主频下，一次TXE等待周期远小于115200bps一个字节的传输时间，理论上稳定，但不检查标志位直接连发的做法在调试阶段很难排查出丢帧问题。

4.2 ESP8266透传配置：连接路由器与上位机的AT指令序列

ESP8266作为Wi-Fi透传模块，它的配置只需要在系统初始化时执行一次。具体指令序列如下：

AT+RST AT+CWMODE=1 AT+CWJAP="your_ssid","your_password" AT+CIPMUX=0 AT+CIPSTART="TCP","192.168.1.100",8080 AT+CIPMODE=1 AT+CIPSEND

每条指令后面都要等待ESP8266返回“OK”或“ERROR”再进行下一步。前三行实现复位和工作模式设定；AT+CIPMUX=0将模块设为单连接模式；AT+CIPSTART中的IP地址和端口是上位机监听的地址；AT+CIPMODE=1开启透传模式，此后所有从串口2收到的数据都自动经TCP发往服务器；AT+CIPSEND则激活发送通道。

在STM32代码中，这些指令可以先通过串口2逐条发送，再等待“OK”回包。为了简化，也可以在上电时延时2秒让ESP8266自动连接串口调试助手预先配置好的参数。但自动配置的稳定性取决于路由器环境，还是建议把AT指令固化在STM32固件中。

4.3 上位机接收与数据库落库：Python Flask作为中转层

上位机的角色是TCP服务端加MySQL写入器。用Python Flask写一个轻量接口，既接收ESP8266的TCP长连接，也提供REST接口供Web页面查询。接收数据后解析帧格式，再把卡号、学号、书名、借书时间写进数据库。

import socket import pymysql def parse_frame(data): if len(data) < 10: return None if data[0] != 0xAA or data[1] != 0x55: return None card_id = data[2:6].hex() checksum = sum(data[:7]) & 0xFF if checksum != data[7]: return None return {"card": card_id, "op": data[6]} server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind(("0.0.0.0", 8080)) server.listen(5) while True: conn, addr = server.accept() data = conn.recv(1024) frame = parse_frame(data) if frame: db = pymysql.connect(host="localhost", user="root", password="123456", database="library") cursor = db.cursor() if frame["op"] == 0x01: sql = "INSERT INTO borrow_record (card_id, borrow_time) VALUES (%s, NOW())" else: sql = "UPDATE borrow_record SET return_time=NOW() WHERE card_id=%s AND return_time IS NULL" cursor.execute(sql, (frame["card"],)) db.commit() db.close()

这个脚本的核心是让STM32的代码保持简洁——所有业务逻辑都交给上位机处理。TCP长连接在同一时间只有一个ESP8266连入时工作良好；如果后续要做多工位扩展，则需要改用多线程accept或在ESP8266端启用AT+CIPMUX=1的多连接模式。

5. 调试要点与关键坑位：天线匹配、读卡距离、串口乱码三类高发问题

5.1 读卡距离过短：调整天线匹配电路而不是增大发射功率

RC522模块读卡距离通常在3~5厘米，但不少同学做出来只有不到1厘米，甚至卡必须贴在感应线圈表面才能识别。多数情况下问题出在模块上两个用于天线阻抗匹配的电容上。

RC522模块PCB上通常会预留两个可调电容（常见位置在天线线圈附近，丝印标注为C1和C2），出厂默认配置适用于标准天线。如果你的读卡距离明显异常，可以尝试用万用表测量天线两端电阻正常值应为几欧姆到几十欧姆，如果开路说明天线损坏或焊点脱落。如果是自己画PCB，天线的尺寸、线宽和圈数必须参考数据手册计算，不是随便画个线圈就能工作。

不要试图通过提高SPI速率或加放大器来增加距离。RC522的发射功率由内部寄存器控制，默认值已是合规上限，再往上调可能导致模块发热和误读。调换C1/C2电容容值直到读卡距离恢复是最稳妥的办法。

5.2 串口打印乱码：检查晶振频率与波特率误差

STM32串口输出到电脑调试助手看到乱码，最典型的根源是外部晶振频率不匹配。很多最小系统板用的是8MHz晶振，但F103也可以通过内部HSI时钟运行在72MHz。如果用内部时钟生成的波特率与上位机实际配置存在误差，115200波特率下传输一个字节的时间偏差会累积成连续错码。

排查方法：先看开发板上的晶振丝印，如果是8MHz，确认代码里SystemInit已经正确配置；如果是12MHz晶振而代码仍然按照8MHz倍频，串口输出必定乱码。另一种可能是上位机串口调试助手的波特率与实际不一致。这种问题用示波器测TX引脚的波形周期，对比理论波特率即可直接定位。

5.3 上位机频繁收到FF或00：SPI时序与卡放置方式的另类干扰

当所有接线都正确、代码逻辑也没问题，上位机却频繁收到0xFF或0x00，常常是因为RC522的SPI时钟极性和相位配置不对。0xFF是MISO线在无数据传输时的空闲电平，说明RC522根本没有响应对应的命令。解决办法是回到RC522数据手册第8章的SPI时序图，逐项对比CPOL和CPHA的值。

还有一类情况是卡号偶尔正确偶尔全FF，此时要检查读卡时是否有金属物体靠近天线区域。线圈天线的磁场会因金属涡流而衰减，桌面上如果有金属支架或钥匙串，移开即可恢复正常。这个因素在实验室工位上特别容易被忽略。

6. 读卡数据结构化与批量借还优化：把RFID系统从“能跑”变“靠谱”

到这里为止，系统已经能完成最基本的“刷卡-上传-入库”流程。最后一节要解决的是两个让系统更接近真实生产环境的问题：读卡数据结构化存储和多册图书同时借还的操作模式。

图书管理系统的数据结构不能只存卡号和学号，还要关联图书条码。在M1卡内，卡号只解决了“你是谁”的问题，而“你借了什么书”需要一次借书操作中依次刷两张卡——一张身份卡、一张图书ID卡。STM32程序里需要至少维护一个简单的状态机，定义系统当前处于“等待刷读者卡”还是“等待刷图书卡”状态。

状态机实现代码：

typedef enum { STATE_IDLE, STATE_WAIT_BOOK } SystemState; SystemState currentState = STATE_IDLE; unsigned char currentReaderCard[4]; void RFID_StateMachine(unsigned char *cardId) { if (currentState == STATE_IDLE) { memcpy(currentReaderCard, cardId, 4); Send_RFID_Frame(0x03, cardId); // 0x03表示读者认证 currentState = STATE_WAIT_BOOK; } else if (currentState == STATE_WAIT_BOOK) { Send_RFID_Frame(0x04, currentReaderCard); // 读者卡号 Send_RFID_Frame(0x05, cardId); // 图书卡号 currentState = STATE_IDLE; } }

协议帧0x03、0x04、0x05都是自定义的，上位机根据操作码拼接出完整的借阅记录，写入borrow_record表时同时写入reader_card和book_card两个字段。这里要注意一个细节：两次Send_RFID_Frame之间如果没有任何延时，ESP8266透传时有可能把两帧TCP数据包合并发出，上位机需要按帧头重新切割数据流，而不是每次recv都当作一帧完整数据。建议在每次Send_RFID_Frame后加一个100ms的延时，给TCP栈一点缓冲时间。

多册图书批量借还也是一样的逻辑，状态机层面只需要把STATE_WAIT_BOOK改成STATE_WAIT_MULTI_BOOK，并允许连续接收多张图书卡。每收到一张卡号就立即发送一帧，直到收到代表“结束借阅”的按钮按下事件或超时信号，再回到STATE_IDLE。这种设计的价值在于，读者一次最多能借的图书数量可以完全由上一位机配置，嵌入式端不需要维护一个固定大小的数组。

调试这个状态机时，最实用的手段是在串口调试助手中手动模拟上位机，观察STM32发送的帧是否符合预期顺序。先不要接ESP8266，直接用USB转TTL线看USART2的输出，确认状态机无误后再把ESP8266串入链路。这个顺序能缩小一半的排查范围。

如果你的借书量级更大，比如一个学院几千人同时使用，还值得把RC522的防冲突算法用足，让系统支持一次放入多张卡时逐张读取。M1卡的防冲突机制天然支持这种情况，RC522_Anticoll函数已经做了循环处理，只需要在代码里增加“防冲突完成后，如果仍有卡在感应区，自动发起下一次寻卡”的逻辑。毕业设计能做到这一步，技术上已经完全超出“能跑”的要求，接近可演示的完整业务闭环。

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