RC522+Mifare S50 RFID课程设计：从寻卡认证到答辩验收-开发者社区

简介：面向高校物联网、嵌入式相关课程学习者与课程设计备赛者，这套中南大学RFID课程设计资料以完整源代码和实验报告为核心，围绕射频识别系统的编码实现、签到应用与实验总结展开。压缩包共320个文件、约8.72MB，含21个cpp源文件、17个h头文件、5个ui界面文件及大量png截图，并辅以obj、o编译中间件和dll、so动态库与数据库文件，可清晰看到Qt项目从源码、界面到构建产物的组织方式。目前已有1317人学习下载，具备一定参考热度。读者能获得RFID标签交互、数据库存取、用户管理、签到界面设计等模块的实现思路，也可借实验报告梳理系统架构、硬件选择、功能实现、问题解决与结果分析，适合课程设计对照、Qt与SQLite实践及物联网入门项目复盘。

1. 一张刷不开的卡：RFID课程设计真正要交付的三样东西

答辩前一晚读卡器突然不认卡，串口吐出一串乱码，这是我在做 RFID 课程设计时最真实的一幕。13.56MHz 的读卡模块本身不算难，难的是让代码、实验报告、现场演示三样东西对得上：代码能跑通寻卡、防冲突、扇区读写，报告能把每一步的波形和数据讲清楚，演示时换一张卡也不能出错。这套方案面向要交 RFID 课程设计或毕设初稿的人，主控用常见的开发板，读卡芯片用 RC522，卡片用 Mifare One S50，从接线、驱动、业务逻辑一路做到验收表格。整套东西跑通大概两三天，但想让它经得起提问，得把下面几个模块拆明白。

2. 需求拆解与器件选型：四个功能模块和一张选型对比表

2.1 功能边界：把「刷卡亮灯」拆成四层可验证能力

很多同学拿到题目第一反应是写一个if (卡号 == 某个值) 亮灯，跑通就交。这种实现在答辩现场只要换一张卡、或者老师问一句「防冲突怎么做的」，基本就答不上来。我一般会把课程设计的功能拆成四层，每一层单独可测：

第一层是寻卡与防冲突，要求读卡器能同时在场有多张卡时稳定返回其中一张的序列号，不出现丢卡、乱码；第二层是扇区认证与读写，要求对指定扇区用 KeyA 或 KeyB 完成三次相互认证，并能正确写入 16 字节数据块；第三层是业务逻辑，包括卡号白名单比对、余额扣减或考勤时间戳记录、非法卡拒绝；第四层是数据上报与展示，把每次操作通过串口送到上位机，界面或终端能看到卡号、时间、结果。

这四层对应实验报告里的四个章节，也对应现场演示的四个动作。把边界划清楚的好处是：调试时你知道问题出在哪一层，不会在「卡刷不上」这种笼统的描述里瞎猜。

提示：课程设计评分表上通常有「功能完整性」和「创新性」两项，四层结构基本能把完整性拿满，创新性可以放在业务层，比如加一个挂失卡黑名单或者消费限额。

2.2 主控与读卡芯片选型：三套组合的实际差距

选型这件事，网上说法多，实际差别主要在供电、调试便利性和资料量。下面这张表是我带过几轮之后总结的对比，分数按课程设计场景打分，不是工业场景：

课程设计我建议直接用第一种。RC522 是 SPI 接口，寄存器手册虽然只有几十页，但每一页都是干货，寻卡、防冲突、认证、读写全都能自己控制，写完一遍对 RFID 协议栈的理解会比调用现成库深得多。PN532 自带协议栈，开发快但容易变成「只会调 API」，答辩时被追问细节会难受。

卡片选 Mifare One S50，1K 容量，分 16 个扇区，每个扇区 4 个块，每块 16 字节，第 3 块是密钥和控制位。这个结构必须记牢，后面写扇区地址时全靠它。

2.3 通信链路与调试口：留一条能看见内部状态的通道

调试口的设计经常被忽略，但它是整个项目的「黑匣子」。我的做法是：主控的硬件串口（通常 D0/D1）留给上位机通信，另外用软件串口或者 USB 转 TTL 单独开一路日志口，专门打印寄存器状态、寻卡返回值、认证结果。这样上位机协议不会被打断，日志也能开得很啰嗦。

日志格式建议固定成[层][函数][结果码]，比如[DRV][rc522_request] status=0x00、[BIZ][check_whitelist] uid=1A2B3C4D result=DENY。看起来土，但排查问题时能一眼定位到哪一层断了。血泪经验是：日志里带结果码比带「成功/失败」这种中文字符串有用得多，因为结果码能直接和芯片手册对照。

3. 总体架构与硬件落地：三层软件结构与SPI接线表

3.1 模块划分与数据流

软件分三层，层与层之间只传结构体，不传寄存器值：

驱动层：rc522_drv.c，负责 SPI 读写寄存器、复位、天线开关、收发命令，对外只提供rc522_request、rc522_anticoll、rc522_transceive三个函数。
卡片操作层：mifare.c，在驱动层之上实现认证、读块、写块，对外提供mifare_auth、mifare_read_block、mifare_write_block。
业务层：app.c，维护白名单表、余额表、操作日志，调用卡片操作层完成一次完整业务，再调用上报模块。

数据流是单向的：读卡器中断 → 驱动层取卡号 → 卡片操作层认证 → 业务层判断 → 上报。单向的好处是任何一层出问题都能单独替换验证，比如怀疑认证有错，可以直接用驱动层函数读出卡号，看能不能读到，从而排除硬件问题。

3.2 引脚接线表与SPI时序注意点

RC522 模块是 3.3V 器件，5V 直接上去会烧。接线表如下：

| 模块引脚 | 主控引脚 | 说明 | | SDA / SS | D10 | 片选，低电平有效，必须由软件控制 | | SCK | D13 | SPI 时钟，课程设计用 4MHz 以内 | | MOSI | D11 | 主出从入 | | MISO | D12 | 主入从出 | | RST | D9 | 复位脚，低电平复位，上电后要给一次高电平 | | 3.3V | 3.3V | 严禁接 5V | | GND | GND | 必须共地 |

两个容易忽视的时序点：第一，SPI 模式要用SPI_MODE0，时钟空闲低电平、上升沿采样，模式选错表现为读出来全是 0x00 或 0xFF；第二，片选拉低到第一个字节之间不要加延时，RC522 对片选建立时间敏感，代码里digitalWrite(CS, LOW)之后直接SPI.transfer，中间插delay反而会出错。

3.3 电源与天线布局：最容易被判定为「玄学」的部分

读卡距离忽远忽近，换一块板子就好了，这种问题八成在电源和天线。RC522 模块峰值电流能到 100mA 左右，如果和主控共用一条 USB 供电，一旦屏或者其他外设也在耗电，读卡距离会明显缩水。做法是给模块单独一路 3.3V，或者至少在模块电源脚旁边并一个 10μF 电解加一个 0.1μF 瓷片。

天线部分不要用排线延长，模块自带 PCB 天线是调好的，飞线一接，电感变了，谐振点偏移，读卡距离直接掉一半。如果结构上必须延长，把整块模块靠近卡片，主控用排线往远处拉，别去动天线侧。

注意：测试时把模块放在金属桌面上，读卡距离会明显变短，这是涡流损耗，不是模块坏了。垫一层纸板或者亚克力再测，数据才有可比性。

4. 关键代码实现：从寄存器读写到扇区认证的完整链路

4.1 驱动层：寄存器读写与寻卡

RC522 的 SPI 协议是「地址字节 + 数据字节」，地址字节最高位表示读写方向，低 7 位是寄存器地址左移一位。先把最底层的两个函数写对，后面所有功能都建立在它们上面：

// rc522_drv.c —— SPI 底层，只做寄存器搬运 #include <SPI.h> #define RC522_CS 10 #define RC522_RST 9 static void rc522_write_reg(uint8_t addr, uint8_t val) { digitalWrite(RC522_CS, LOW); SPI.transfer((addr << 1) & 0x7E); // 写：读写位为 0 SPI.transfer(val); digitalWrite(RC522_CS, HIGH); } static uint8_t rc522_read_reg(uint8_t addr) { uint8_t val; digitalWrite(RC522_CS, LOW); SPI.transfer(((addr << 1) & 0x7E) | 0x80); // 读：读写位置 1 val = SPI.transfer(0x00); // 送哑字节换回数据 digitalWrite(RC522_CS, HIGH); return val; } // 寻卡：返回 0 表示场内有卡，卡类型写入 tagType uint8_t rc522_request(uint8_t reqMode, uint8_t *tagType) { uint8_t status; rc522_write_reg(CommandReg, PCD_IDLE); rc522_write_reg(ComIEnReg, 0x77); // 开定时器/接收/空闲中断 rc522_write_reg(FIFOLevelReg, 0x80); // 清空 FIFO rc522_write_reg(FIFODataReg, reqMode); // 0x52 = 寻场内所有卡 rc522_write_reg(CommandReg, PCD_TRANSCEIVE); rc522_write_reg(BitFramingReg, 0x87); // 发送最后字节全部 8 位 status = rc522_wait_for(0x30); // 等接收中断 if (status != 0) return status; tagType[0] = rc522_read_reg(FIFODataReg); tagType[1] = rc522_read_reg(FIFODataReg); return 0; }

rc522_write_reg和rc522_read_reg里的(addr << 1) & 0x7E是手册规定的地址编码方式，写成addr直接传会读到错误寄存器。PCD_TRANSCEIVE是「发送并接收」命令，BitFramingReg设成 0x87 表示最后一个字节的 8 位全部参与发送，寻卡命令只有 1 个字节，不设这个位芯片会少发一位，表现为永远寻不到卡。rc522_wait_for(0x30)是轮询ComIrqReg的接收中断位，超时时间建议给 25ms 左右，太长会拖慢主循环。

4.2 防冲突、选卡与扇区认证

寻到卡之后要做防冲突拿完整序列号，S50 的序列号是 4 字节。流程是：防冲突命令 → 读 5 个字节（4 字节 UID + 1 字节校验）→ 选卡命令 → 进入认证。

// 认证指定扇区的一个块，key 为 6 字节密钥，uid 为 4 字节卡号 uint8_t mifare_auth(uint8_t block, uint8_t *key, uint8_t *uid) { uint8_t buf[12]; buf[0] = PICC_AUTHENT1A; // 0x60 用 KeyA 认证，0x61 为 KeyB buf[1] = block; // 目标块号，必须落在同一扇区 memcpy(&buf[2], key, 6); // 6 字节密钥 memcpy(&buf[8], uid, 4); // 4 字节卡号 return rc522_transceive(buf, 12, NULL, 0); } // 读一个 16 字节数据块 uint8_t mifare_read_block(uint8_t block, uint8_t *out) { uint8_t cmd[4] = {PICC_READ, block, 0, 0}; // 0x30 读命令 uint8_t len = 0; uint8_t status = rc522_transceive(cmd, 2, out, &len); if (status != 0 || len != 16) return 1; // 长度不对说明有丢包 return 0; }

认证函数的block参数要注意：S50 里每个扇区有独立的密钥，认证一次只对当前扇区有效，跨扇区读写要重新认证。很多同学写了一个auth(block=8)之后去读第 4 块，读出来全是 0，就是踩了这个坑。mifare_read_block里检查返回长度是否等于 16 很关键，长度不足通常意味着通信被干扰，直接返回错误比返回半截数据要好，后者会让上层逻辑做出错误判断。

写块的命令是0xA0，一次写 16 字节，写完建议立刻读回来比对，S50 的写操作有失败概率，不比对的话演示时会出现「写进去了但其实没写」的情况。

4.3 业务层：白名单、余额与操作日志

业务层的核心是一张表和一个状态机。表的每一项对应一张卡，状态机负责「寻卡 → 查表 → 执行动作 → 记录日志」。

typedef struct { uint8_t uid[4]; // 卡号，低字节在前 uint8_t role; // 0 普通卡，1 管理卡，2 挂失卡 uint16_t balance; // 余额，单位分 } CardRecord; // 一次完整的刷卡业务 uint8_t app_handle_card(uint8_t *uid) { int idx = app_find(uid); if (idx < 0) { app_log(uid, "UNKNOWN", 0); return 2; } // 未登记 if (cards[idx].role == 2) { app_log(uid, "FROZEN", 0); return 3; } if (cards[idx].role == 1) { app_log(uid, "ADMIN", 0); return 0; } if (cards[idx].balance < FARE) { app_log(uid, "LOW", cards[idx].balance); return 4; } cards[idx].balance -= FARE; // 扣费 app_log(uid, "OK", cards[idx].balance); return 0; }

app_find用线性查找就够，课程设计的白名单一般不超过 20 张卡，没必要上哈希。返回码我定义成 0 成功、2 未登记、3 挂失、4 余额不足，每个码对应上位机一种提示，实验报告里可以直接做成一张错误码表，答辩时老师问「异常怎么处理」就有话说了。

app_log里除了卡号和结果，一定要记主控的运行时间戳，这样上位机才能按时间排序，考勤场景下这个时间戳就是原始数据。

4.4 串口上报协议与上位机解析

串口上不要直接打印人类可读字符串，做一帧固定格式的二进制协议，解析起来简单，也不怕数据里出现逗号。帧结构建议：

| 字段 | 长度 | 说明 | | 帧头 | 2 | 0xAA 0x55，用于对齐 | | 长度 | 1 | 负载字节数 | | 命令 | 1 | 0x01 刷卡记录，0x02 心跳 | | 负载 | N | 卡号 4 字节 + 结果 1 字节 + 时间 4 字节 | | 校验 | 1 | 前面所有字节异或 |

import serial, struct def parse(buf): if len(buf) < 6 or buf[0] != 0xAA or buf[1] != 0x55: return None length = buf[2] if len(buf) < length + 5: return None frame = buf[:length + 5] if frame[-1] != xor_sum(frame[:-1]): # 校验不过直接丢弃 return None cmd = frame[3] payload = frame[4:4 + length] uid, result, ts = struct.unpack('<4sBI', payload) return {'cmd': cmd, 'uid': uid.hex(), 'result': result, 'ts': ts} def xor_sum(data): s = 0 for b in data: s ^= b return s

解析函数里最重要的不是解包，是校验和对齐。串口数据会粘包，收到半帧是常事，len(buf) < length + 5这一句就是用来挡半帧的，校验和再挡一次被干扰的帧。有了这两道，上位机基本不会出现乱码。struct.unpack里的<表示小端，主控如果是小端架构可以直接对应，换平台时这个字符必须改。

5. 避坑与排查：六个最容易翻车的现场问题

现象一：读出来全是 0x00 或 0xFF。原因通常是 SPI 模式选错或者 MISO 悬空，也可能是片选没接对。解决办法是先读VersionReg，正常应该返回 0x91 或 0x92，读不到正确版本号就说明底层没通，不用往下查业务逻辑。

现象二：能寻到卡但认证永远失败。九成是密钥或块号错了。S50 出厂默认密钥是 6 个 0xFF，很多教程里写的密钥是别人改过的；另外认证的块号必须和你后面读写的块号在同一个扇区，跨扇区不重新认证一定失败。

现象三：读卡距离只有一两厘米。先看供电，模块单独供电和共用供电差距很明显；再看模块是否贴着金属或手机；最后确认天线附近有没有走其他信号线。这三条排除完，距离一般能回到 3 到 5 厘米。

现象四：连续刷同一张卡，程序卡死。原因是上一帧的接收中断没有清干净，第二次进中断时状态位还是旧的。在每次rc522_transceive开头把ComIrqReg的相关位写 1 清零，再开始新的一帧，问题就没了。

现象五：写块成功但读回来是旧数据。大概率是写完之后没等芯片内部 EEPROM 写入完成。写完给 5 到 10ms 再读，或者直接读回来比对，比不出来就重写一次，比盲目相信返回值靠谱。

现象六：演示时好好的，换台电脑上串口就乱码。波特率没对齐，或者上位机用了不同的编码。协议是二进制帧，波特率必须两边写死成同一个值，别用自动协商。

提示：把上面六条做成一张排查表贴在实验报告附录里，答辩时老师翻到这一页，会认为你真的调过。

6. 验收与答辩：把实验报告写成能对着数据说话的文档

验收这一天，老师通常只给你五分钟，前两分钟看演示，后三分钟提问。演示脚本我建议背下来，按固定顺序走：先放一张未登记的卡，屏幕提示「未登记」；再放登记过的普通卡，显示扣费成功和余额；最后同时放两张卡，看防冲突能不能正常返回其中一张。三个动作对应四层功能里的三层，剩下那层「数据上报」用上位机界面直接展示日志列表。

实验报告的写法，重点不在篇幅，在数据。下面这张表是我一般会放进报告的结构，每一栏都要有实测值，不能写「正常」「良好」这种词：

答辩提问高频集中在三个方向：一是协议细节，比如「防冲突用的什么算法」，答「基于序列号的位碰撞检测，用0x93命令逐位筛选」；二是异常处理，直接翻到上面那张表的拒绝项讲；三是创新点，把业务层的挂失和限额拿出来说，别硬吹硬件。

我踩过最深的一次坑是：报告里所有数据都是「测试通过」，老师当场让我复现一条，结果因为换了张卡没跑通。从那以后我每次写报告，每条实测数据都强制走一遍现场复现，能复现的才写进去，不能复现的就老实写「受环境影响未稳定复现」。这套代码加报告的完整结构和表格，拿去改改卡号、换换业务规则就能交，希望帮到你。

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