RFID课程设计实战：RC522与M1卡底层原理及避坑指南

简介：中南大学RFID课程设计代码与实验报告，面向物联网、自动化等专业的高校学生，旨在帮助读者理解射频识别系统从底层通信到上层界面开发的完整链路，可作为课程设计或综合作业的直接参考。压缩包共320个文件，体积约8.72MB，包含21个C++源码文件、17个头文件、5个Qt界面文件，以及211张界面运行截图，能够完整还原项目每个功能模块的实现过程。项目基于Qt Creator开发，设计了一个RFID考勤签到场景，涵盖DBControl数据库操作、ClockInWidget签到界面、ManageWidget用户管理、MainWidget主窗口等模块，串联了数据库读写与界面交互的典型流程。配套实验报告对RFID系统原理、硬件选型、软件架构和功能实现做了系统梳理，读者可据此了解项目设计与排错思路。目前已有1313人学习参考，适合需要快速上手RFID应用开发或撰写实验报告的人群。

1. 某高校 RFID 课程设计：代码 + 实验报告，到底能帮你省多少事

很多人的 RFID 课程设计是这样完成的：找到一份能跑通寻卡的 Demo，把代码拷进工程，烧录后贴卡，屏幕亮了，报告复制粘贴，答辩时被问一句“讲讲防冲突原理”就卡住。RFID 课程设计的代码和实验报告，难的不是调通，而是你根本不知道这块读卡器模块在底层做了什么。这份资源里带的是完整可编译的工程源码和配套实验报告，覆盖从 13.56MHz 射频通信、ISO/IEC 14443A 寻卡流程到 M1 卡读写操作的全部内容。适合正在做 RFID 课设但不想只当“调包侠”的人，也适合答辩前想搞清楚“射频场里到底发生了什么”的同学。拿到手先别急着烧录，把代码里状态机的每一步和报告里的时序图对应起来，你会发现调试时间能省一大半。

2. ISO/IEC 14443A 与 13.56MHz 射频链路：先看懂寻卡在做什么

2.1 读卡器、标签与主机三端角色划分

一套最基础的 RFID 课程设计硬件链路由三部分构成：读卡器模块（典型的是 RC522）、标签（课程设计几乎都用 M1 卡，也就是 Mifare Classic 1K）、以及主控 MCU（常见 STM32 或 51 内核）。读卡器模块负责产生 13.56MHz 的载波信号，同时对标签回送的负载调制信号进行解调；主控通过 SPI 或 I2C 接口与 RC522 通信，把寻卡、防冲突、认证、读写这些命令打包成寄存器操作发下去。

这里要区分两个东西：寻卡不等于读卡号。“寻卡”是读卡器发出 14443A 的 REQA 命令，检测射频场内是否有卡片响应；而“读卡号”是寻到卡之后，通过防冲突循环拿到卡片的 UID。很多实验报告把这两个词混着写，答辩时被拆穿概率很高。RC522 的命令寄存器里，PCD_Request 和 PCD_Anticoll 是分开的两条命令，对应代码里的两个函数，这个边界一定要清楚。

2.2 ASK 调制与副载波：为什么卡片无电源也能回数据

卡片本身没有电池，它靠的是读卡器天线持续发射的 13.56MHz 电磁场供电。卡内的 LC 谐振电路在这个频率上感应出交流电压，经过整流稳压后给内部数字电路供电，这就是“无源标签”的原理。读卡器向卡片发命令时，用 100% ASK 调制把数据叠在载波上；卡片回数据时，用 847kHz 的副载波对负载进行调制，读卡器天线端的电压会有微小变化，经过解调电路还原成数字信号。

这也是为什么读卡距离普遍只有 5~10cm——卡片离天线太远，感应电压不够，内部电路起不来，通信自然中断。所以实验报告里“读卡距离”这一项，不是越大越好，而是要在供电和通信两个约束下取折中。你在调天线匹配电路时如果发现距离变近，先去量天线两端波形幅度，比盲目调发射功率有用得多。

2.3 防冲突循环：多张卡同时进入射频场会发生什么

如果两张卡同时进入射频场，它们会同时收到 REQA 并各自回复 ATQA，读卡器收到的就是叠加信号，无法识别。ISO/IEC 14443A 用位级防冲突算法解决这个问题：读卡器发送带有部分 UID 的 SEL 命令，每张卡对比自己的 UID，匹配的卡片继续回送剩余位，不匹配的退出竞争。如此一轮一轮逼近，最终只剩一张卡完整回送 UID，这就是防冲突循环。

RC522 的 PcdAnticoll 命令把这个循环收敛在硬件里，你只需要调用一次就能拿到 4 字节 UID 加 1 字节校验。但注意，防冲突循环只解决“多张卡被读卡器识别”的问题，不解决“我要读哪一张卡”的问题。课程设计里常见的做法是只读第一张卡，够用；但如果你做门禁或考勤系统，这里就要设计卡选择逻辑了。

下表是 14443A Type A 在课程设计里最常用到的几个参数，实验报告写“通信原理”部分可以直接对照填：

3. M1 卡存储模型与三类密钥操作：把实验报告里的截图对上号

3.1 16 扇区 × 4 块 × 16 字节：块地址是怎么算的

M1 卡（S50）的存储空间是 1K 字节，组织成 16 个扇区，每个扇区 4 个块，每个块 16 字节。第 0 扇区第 0 块是厂商固化的 UID 和厂商数据，出厂后不可改写；每个扇区的第 3 块是扇区尾块，存放密钥和访问控制位；其余块是数据块，可读可写，但能不能写要由访问控制位决定。

块地址计算是实验报告里最容易写错的地方。扇区 s 的第 b 块（b 取 0~3），绝对块地址 = s × 4 + b。比如扇区 1 的块 0 是绝对地址 4，扇区 5 的块 3 是绝对地址 23。代码里你写 PcdRead(blockAddr, buf) 时，传的是绝对地址，不是“扇区号 + 块号”的组合。有些同学在报告里写明“读取扇区 5 块 0”，但代码传参是 5，实际读到的是扇区 1 块 1，查半天发现是地址算错。

3.2 扇区尾块：KeyA、访问位、KeyB 的布局与出厂默认值

每个扇区尾块 16 字节的布局是固定的：字节 0~5 是 KeyA，字节 6~8 是访问控制位（Access Bits），字节 9 是厂商数据字节，字节 10~15 是 KeyB。很多入门教程只讲“存密钥”，不讲访问控制位，结果就是读卡一切正常，写卡永远失败——因为出厂默认的访问控制位允许读，但不一定允许在未认证状态下写。这属于每个做过 M1 卡读写的人都踩过的坑。

出厂状态的典型值是 KeyA = FF FF FF FF FF FF，KeyB = FF FF FF FF FF FF，访问控制位为 FF 07 80 69。这个配置下，数据块是“KeyA 或 KeyB 认证后可读可写”还是“只可读不可写”，取决于你用的是哪组密钥认证。课程设计里一般用 KeyA 默认密钥认证，能读能写，所以很多 Demo 能跑通。如果你在某个扇区上做过密钥改写或访问位修改，再拿默认驱动去读写，就会碰到“认证失败”或“写卡失败”。

3.3 认证、读、写三个命令的时序：0x60/0x30/0xA0

一次完整的 M1 卡读写操作，命令时序是这样的：读卡器先通过防冲突拿到 UID，然后用 PCD_AUTHENT（0x60 表示用 KeyA 认证，0x61 用 KeyB 认证）发起认证命令，认证通过后，用 0x30 读块，用 0xA0 写块。认证命令需要提供块地址、密钥类型、密钥内容和 UID；读和写命令只需要块地址和数据。

需要注意，认证是“按扇区”生效的：你用 KeyA 认证了扇区 4，只能对扇区 4 的四个块做读写；跳到扇区 5 必须重新认证。实验报告里如果流程图把“一次认证，全区读写”画出来，评委一看就知道是编的。代码实现上，每次读写前都调一次认证函数最稳妥，虽然多点开销，但换来的稳定性在课程设计里完全值得。

4. RC522 驱动与状态机初始化：从寄存器配置到一次完整读卡

4.1 SPI 接线与寄存器读写基元

拿到手的 RC522 模块，引脚一般是 SDA（SPI 片选）、SCK、MOSI、MISO、RST、IRQ、GND、VCC。课程设计里几乎都用 SPI 模式，四根线加上复位和电源，总共六根信号线。RST 引脚不是必须接，你可以把软复位和硬复位都做进初始化流程里，但如果硬件有条件，建议 RST 接一个 GPIO，调试时方便一键复位整个射频前端。

寄存器读写是驱动的地基。RC522 的寄存器是 8 位地址，读写由地址的最高位区分：地址 bit7 为 0 表示写，为 1 表示读。SPI 片选拉低后，先发地址字节，再发数据字节（写）或读回数据字节（读）。这个时序在示波器上很容易验证，也是排查“初始化卡死”的第一步。

下面是寄存器读写的两个基础函数，几乎所有上层命令都建立在它们之上：

// 写 RC522 寄存器：addr 是 8 位寄存器地址，val 是要写入的值 void RC522_WriteReg(uint8_t addr, uint8_t val) { SPI_CS_LOW(); // 片选拉低，开始一次 SPI 事务 SPI_SendByte((addr << 1) & 0x7E); // 地址左移一位，bit0 置 0 表示写 SPI_SendByte(val); // 写入数据 SPI_CS_HIGH(); // 片选拉高，结束事务 } // 读 RC522 寄存器：addr 是 8 位寄存器地址，返回当前值 uint8_t RC522_ReadReg(uint8_t addr) { uint8_t val = 0; SPI_CS_LOW(); SPI_SendByte(((addr << 1) & 0x7E) | 0x80); // bit0 置 1 表示读 val = SPI_ReadByte(); SPI_CS_HIGH(); return val; }

这里有个容易看懵的参数：传入的 addr 是寄存器编号，但在 SPI 总线上发送时要把编号左移一位，腾出最低位来放读写标志。很多移植失败的案例是直接把 datasheet 里的寄存器地址当作 SPI 字节发送，结果写到 0x00 这个地址上，行为完全错乱。另一个细节是所有函数都在片选拉低到拉高之间完成整个读或写流程，不要中途被中断打断，否则 SPI 时序会被截断。

4.2 PcdInit：软复位、定时器、天线使能的三段式

RC522 上电后不能直接寻卡，必须先完成一段寄存器初始化。网上流传的初始化代码大同小异，但核心就三段：软复位让它回到已知状态，配置定时器让它能自动判断射频通信超时，最后打开天线发射电路。

软复位的做法是往命令寄存器写 0x7F，然后等待芯片完成复位。有的代码接着写一堆定时器参数，看起来像玄学，实际上 TModeReg、TPrescalerReg、TReloadReg 三个寄存器共同决定了射频通信的超时时长。课程设计里不要求你精确计算，但也别随便乱改——改小了会出现“贴卡后偶发寻卡失败”，改大了会出现“读卡器长时间卡死”。下面是常用的初始化片段：

void RC522_PcdInit(void) { // 第一段：软复位，让芯片回到确定的初始状态 RC522_WriteReg(RC522_REG_COMMAND, 0x7F); delay_ms(10); // 给芯片内部复位留出时间，不能省 // 第二段：配置定时器，约 25ms 的通信超时阈值 RC522_WriteReg(RC522_REG_TMODE_REG, 0x8D); RC522_WriteReg(RC522_REG_TPRESCALER, 0x3E); RC522_WriteReg(RC522_REG_TReload_L, 0x1E); RC522_WriteReg(RC522_REG_TReload_H, 0x0E); // 第三段：发送/接收模式与调制宽度 RC522_WriteReg(RC522_REG_TXMODE, 0x00); RC522_WriteReg(RC522_REG_RXMODE, 0x00); RC522_WriteReg(RC522_REG_MODWIDTH, 0x26); // 第四段：天线使能，打开发射电路 RC522_WriteReg(RC522_REG_TXCONTROL, 0x83); RC522_WriteReg(RC522_REG_TXASK, 0x40); }

这块代码里最容易出问题的两个参数：第一，软复位后的 delay 不能删。有些同学为了“优化效率”把延时去掉，结果芯片还没复位完就配置寄存器，后面寻卡一直失败；第二，TXCONTROL 写 0x83 是把天线驱动的两个通道都打开，如果你用万用表量天线两端没有电压，先检查这个寄存器是否被后续代码意外改写。

4.3 PcdRequest 与 PcdAnticoll：寻卡、防冲突、取 UID 的完整代码

初始化做完，就可以进入寻卡流程了。RC522 的命令寄存器支持多种命令，课程设计最常用的是 0x52（寻卡）和 0x93（防冲突）。上层代码一般封装成两个函数：一个发寻卡命令并等待卡片应答，一个发防冲突命令取回 UID。下面是完整的一次寻卡取号流程：

// 寻卡并读取 UID，成功返回 0，失败返回非 0 uint8_t RC522_ReadCardNo(uint8_t *uid) { uint8_t status = 0; uint8_t cardType[2] = {0}; uint8_t uidBytes[5] = {0}; // 4 字节 UID + 1 字节校验 // 第一步：寻卡，期望收到 Type A 卡片的应答 status = RC522_Request(0x52, cardType); if (status != 0) { return 0x01; // 没有卡片进入射频场，或应答超时 } // 第二步：防冲突，逐位收敛后取回 UID status = RC522_Anticoll(uidBytes); if (status != 0) { return 0x02; // 多张卡冲突未收敛，或校验失败 } // 第三步：把 4 字节 UID 拷贝到调用方缓冲区 for (int i = 0; i < 4; i++) { uid[i] = uidBytes[i]; } return 0x00; // 完整流程走通 }

这个流程是课程设计的“主干道”：第一步若失败，先检查天线是否打开、卡片是否贴近；第二步若失败，大概率是射频场里有多张卡，或者卡片已经进入休眠状态需要先唤醒。第三步结束后，uid 数组里就是你能在串口打印出来的卡号。很多实验报告把这一段流程图写成了“寻卡 → 防冲突 → 读 UID”，但忽略了寻卡命令 0x52 和防冲突命令 0x93 是两个独立的命令时序——前者拿卡类型，后者拿卡号。答辩时把这个细节讲清楚，很容易加印象分。

4.4 阻塞式 vs 中断式读卡：课程设计答辩更看重哪种

RC522 的驱动有两种写法：阻塞式轮询和中断式。阻塞式最简单，发完命令后死循环等待 FIFO 里有数据，直到超时；中断式需要接 IRQ 引脚，命令发完后让出 CPU，等射频事件来了再进中断处理。课程设计多数用阻塞式，代码好写、调试直观，但答辩时如果被问“读卡时 MCU 还能不能干别的事”，答不上来就露怯了。

我一般会建议在阻塞式代码里加一个“超时看门狗”：每次寻卡前记录当前时间，超过 25ms 还没等到应答就退出，避免死循环。这个习惯在接液晶屏或舵机这类外设时尤其重要，否则一次寻卡卡死，整个系统都跟着停摆。实验报告的“系统设计”节里能写出这个超时机制，说明你真的考虑过实时性问题，而不是只会调库。

5. 避坑：读卡失败、可读不可写、发卡掉线，五个高频问题逐一拆

5.1 能寻卡但读不到 UID：防冲突返回值被误判

现象：贴卡后寻卡成功，但程序始终报“防冲突失败”，甚至偶尔成功偶尔失败。

原因：防冲突命令取回的数据是 4 字节 UID 加 1 字节校验位。很多移植过来的驱动只判断“返回状态是否为 0”，没有校验 UID 的 BCC（Block Check Character），导致某次通信中 UID 错一位但被当成成功，后续认证必然失败。

解决：在 RC522_Anticoll 函数里加一道校验，把前 4 字节异或后与第 5 字节比较，不一致直接返回错误。代码是在读完 FIFO 数据后追加的，别写在命令发送前面，否则没有任何意义。从那以后我每次读卡号都强制走一遍“取号后校验”的逻辑，再也没有被这种偶发问题坑过。

5.2 可读不可写：扇区尾块的访问位不是默认全 F

现象：读数据块一切正常，写数据块返回“认证失败”或“写卡失败”，换一块区域读又是好的。

原因：你读写的数据块所在扇区，尾块访问控制在出厂状态时，数据块默认状态下确实允许 KeyA 认证后读写。但如果这个扇区之前被别的程序做过“加密”或“改访问位”，默认密钥就失效了。

解决：先把扇区尾块读出来，检查字节 6~8 的访问位是否符合预期。实验室里常备一张“空白卡”专门做读写测试，别拿已经发过卡的样本调试。注意处理逻辑是“先检查访问位再决定是否改写”，不要一上来就把卡格式化，否则整张卡访问位错乱后很难恢复。

5.3 写卡成功后立即读回是旧数据：没有重新 Select

现象：写完一个块，马上读同一地址，返回的还是旧数据；停顿几百毫秒再读，又变成新数据。

原因：RC522 在执行写命令后，射频链路的状态机还停留在“写事务”中间态，此时直接发读命令，读卡器内部没有完成状态切换。看起来像“写卡失败”，实际是“读太急了”。

解决：写卡后加至少 10ms 延时，或者重新执行一次完整的“寻卡 → 防冲突 → 认证 → 读块”流程再做读回校验。课程设计实验报告里如果写到“写入后延时 10ms 读回验证”这个细节，说明你踩过坑且已经处理过了，比通篇贴代码强很多。

5.4 卡片贴近读卡器反而失败：负载调制与场强过载

现象：卡片离读卡器 1~2cm 时稳定识别，完全贴在天线上反而寻卡失败；拿开后又能识别。

原因：卡片和天线距离过近时，卡片的 LC 谐振电路对天线线圈的耦合过强，导致读卡器发射端场强被拉低，卡片端感应电压反而异常，解调电路进入非线性区。这是 RFID 近场通信的经典问题，不是模块坏了。

解决：固定一个 3~5mm 的间隙，比如在 PCB 天线上贴一层绝缘垫片，别让卡片完全贴合。如果必须贴合，尝试降低发射天线的驱动电流，或者调整匹配电容。实验报告里写“通信距离存在近场盲区，建议留空隙”，评委一听就知道你真的调试过。

5.5 实验报告里“初始化失败”的截图：复位时序没给 RC522 留时间

现象：上电后读寄存器全是 0xFF 或者写入值读回不对，截图显示“RC522 初始化失败”。

原因：主控上电后立刻对 RC522 发配置命令，但 RC522 自身还在上电复位阶段，SPI 接口虽然物理上通了，内部逻辑还没就绪。这和前面软复位后 delay 是同一个道理：射频芯片的复位时间比 MCU 慢。

解决：主控上电后先延时 50ms 再切到 SPI 外设片选，再延时 10ms 后才开始写寄存器。这个“上电等待”要在初始化函数最前面写，而且要真延时，别用空循环搪塞。把这段等待写进实验报告，说明你注意到了时序余量，比截图里堆一堆错误日志有用多了。

6. 进阶验证：把读卡距离、时序和“卡片无源”讲给评委听

答辩时最容易被追问的就是射频原理，而实验报告常常只贴在代码和截图。这里讲一个能快速验证卡片“无源供电”是否正常的小实验，也是我课程设计时用过最有效的验证手段：拿示波器探头接在天线两端，先记录空白状态下波形幅度，再把卡片贴近天线，观察波形幅度变化。正常情况下，卡片进入射频场后，天线端波形会出现一个明显的幅度下降或者调制包络，这就是卡片负载调制对天线的影响。把这个波形截图放进实验报告“通信原理验证”一节，比任何文字都直观。

如果示波器看到的波形完全没有变化，基本上判断天线匹配有问题或者卡片谐振频率偏离 13.56MHz；如果波形变化但寻卡不稳定，则优先检查 RC522 的接收通道寄存器配置。这套验证流程同样适用在换天线、换卡片品牌之后回归测试，尤其是从 S50 换到 S70 这种双卡大容量卡时，卡片谐振参数略有差异，别期望代码完全不动就能跑。

S70 和 S50 的驱动区别主要在块地址数量上：S50 是 16 扇区 × 4 块，最大块地址 63；S70 是 32 扇区 × 4 块，最大块地址 127。寻卡、防冲突、认证、读写命令完全一致，只需要把地址类型从 uint8_t 换成 uint16_t 就能兼容。如果你课程设计做的是“一卡一密”或“门禁系统”这类扩展功能，建议一开始就按 S70 的地地址范围设计数据结构和命令参数，后续加容量不用改驱动。

最后分享一个调试习惯：每次改完初始化参数或天线相关配置，我都强制自己完整跑一遍“上电延时 → 复位 → 配置 → 寻卡 → 防冲突 → 认证 → 读块 → 写块 → 读回校验”的链路，全程串口打印状态码，不跳过任何一步。这套流程跑通后再去做上层应用，能省出大量排查时间。希望帮到你。

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