6818开发板+RC522 RFID门禁系统设计与实现

6818平台的板子拿来刷成门禁，这个说法平时听到的不少，但真正从RFID读卡、白名单校验到电磁锁控制一条龙跑通的，其实没那么简单。我在做模拟项目时，用的就是一块6818（S5P6818 八核 A53）开发板，配了一个最普通的RC522 RFID模块，最后做出来的效果接近商用门禁的日常使用体验：刷卡秒开、非法卡有报警、每次开门都有日志、掉电后恢复不用人工干预。

这篇文章把整个设计和落地过程拆开来讲，适合手里正好有一块6818或类似Linux开发板、想做成一个出门能演示、进厂能验收的智能门禁系统的朋友。我会从为什么选6818加RFID这个组合、硬件连线里容易翻车的细节、读卡程序的完整逻辑、核心控制程序怎么写、连续跑一周会暴露哪些问题，以及怎么测才算项目验收合格这六个部分，尽量把我实际调试中踩过的坑都交代清楚。

当然，每个项目的硬件版本、引脚定义可能有差异，所以我给出的接线和代码思路是按最常见做法来的，具体拿到板子之后还是要对着原理图核对引脚复用关系。

1. 为什么门禁方案偏偏选了6818加RFID

1.1 6818平台在门禁场景里的角色定位

门禁系统听上去是个小项目，但如果用单片机做，你会发现真正费时间的不是"刷个卡",而是把整个业务逻辑跑顺。单片机要搞定白名单存储、日志回查、时间管理、屏幕菜单、用户增删改，这些功能每加一个就会让代码复杂度上升一个台阶。

6818这种平台完全不一样。它本质上就是一台小电脑，跑的Linux系统，有完整的文件系统、进程管理、网络协议栈，你可以在上面直接用SQLite做数据库，用QT做界面，用C或者Python写业务逻辑。RC522模块只负责做一件事：读出卡片唯一序列号。剩下的判断、执行、记录，全部交给应用层处理。

我做这个项目时的分工很简单：6818主板上电自动启动门禁程序，程序启动后完成三件事——初始化SPI总线和RC522、打开数据库、把门锁继电器拉到"断电关锁"的安全状态。然后进入一个无限循环，读到卡就查库，查到就开门，查不到就报警。整个架构非常清爽，不需要乱七八糟的中间层。

1.2 选RC522还是其他RFID方案

RFID卡种类很多，常见的有125kHz低频卡、13.56MHz高频卡、超高频无源卡。门禁项目里纠结最多的就是125kHz和13.56MHz。125kHz卡（比如EM4100）读卡距离远一点，模块也便宜，但卡片本身数据存储能力很弱，基本就是只读序列号，加密扩展这条路基本堵死。13.56MHz的M1卡（S50）虽然读卡距离在2-5cm左右，但协议标准、卡片内容可读写、能针对扇区做加密，而且更接近市面上大多数门禁卡的实际标准。

RC522是13.56MHz读写模块里非常成熟的一款，支持SPI、I2C、UART三种接口，价格低、资料多、替代料多，就算片子坏了也容易换。我在6818平台上用的是SPI接口，四根线加电源就能跑，对我来说这是它最大的优势：引脚占用少，传输速率也够用。

对比一下我当时考虑过的几种方案，各有特点：

从这个对比能看出来，嵌入式教学和中小型门禁项目选RC522是最平衡的选择。它有足够的技术纵深——后面对接加密卡、做扇区认证、写卡授权，全都可以在同一个模块上做升级。顺便说一句，如果你买的是带金属屏蔽罩的RC522模块，实际读卡距离会比裸板稍微近一点，装外壳时要把天线区留出来，不要用金属外壳直接包住线圈。

2. 硬件连接里最容易翻车的三个环节

2.1 RC522模块与6818的SPI接法

RC522和6818之间的物理连接是整个项目的基础，但恰恰是这一步很多人出问题。标准RC522模块上有6个引脚：SDA（SS）、SCK、MOSI、MISO、IRQ、GND，另外还有一个RST复位脚和一个VCC电源脚，不同厂家的丝印可能略有差异，但绝大多数都是这套定义。

我当时在6818上用的是SPI1控制器，引脚复用关系大致如下，具体板子请查原理图：

这里最大的坑是供电电压。RC522核心逻辑工作电压是3.3V，很多红色PCB模块板载了AMS1117稳压，允许5V输入，但SPI引脚的电平仍以3.3V为参考。6818的GPIO是3.3V电平，如果你图方便把模块VCC接到5V，模块本身可能不烧，但MISO引脚回给6818的电平逻辑上还是安全的，问题不大。真正危险的是反过来：有些模块没有稳压，你直接给5V，模块可能冒烟。所以没查清楚模块有没有稳压之前，一律先上3.3V。

IRQ引脚我建议直接悬空。RC522支持中断模式，但6818上做中断要配置引脚、写中断处理函数，单纯读卡业务的循环轮询已经够快。在SPI速率调到1MHz左右时，一次完整的寻卡加读卡号大概只需要几毫秒，刷卡时感觉不到延迟。

2.2 门锁执行机构的选型与驱动

门禁最终是靠锁来执行的，锁选不对，程序写得再好也没用。市面上常见的有电插锁、磁力锁、电控锁和电磁锁。区别在于：电插锁靠锁舌插入门框固定门体，断电时锁舌靠弹簧弹出，通常用于玻璃门；磁力锁靠电磁铁吸合固定门板，断电即开，适合防火门；电控锁兼容机械钥匙，一般用在铁门。

我最终选的是断电开型（通电上锁、断电开锁）的电磁锁。没有特殊说明的木门、办公室隔断门，这种锁安全性最高：发生火灾或者停电时，锁自动打开，人不会被困住。虽然断电自动开锁听起来会让门禁形同虚设，但你想一下，门禁的目的是验证身份，不是把人在火灾里锁死，断电开锁是行业通用做法。

电磁锁本身是12V供电、启动瞬间电流不小，绝对不能直接从6818的IO口取电。正确做法是用继电器模块：6818的GPIO控制三极管或继电器线圈，继电器触点再去控制12V回路的通断。我用的继电器模块是高电平触发和低电平触发都支持，通过跳线帽切换，实际使用时我把它调到低电平触发模式——也就是GPIO为低时继电器吸合，门锁通电。这样有个额外好处：程序崩溃或系统宕机时，GPIO悬空状态不会把门锁死。

给继电器线圈并联一个反向续流二极管这个操作，很多人会忽略。继电器线圈在断电瞬间会产生很高的反向电动势，如果不加二极管，轻则造成GPIO口电平抖动，重则把相邻芯片打坏，甚至让6818整个板子复位。这个坑我在下文专门讲，这里先记住：电源线上串个1N4007或1N5819，二极管负极接电源正极、正极接电源负极，方向不能反。

2.3 电源与地线处理

门禁系统最不显眼但又最影响稳定性的，就是供电。6818板卡我用的是5V/3A的电源适配器，电磁锁单独用12V/3A适配器。很多人觉得共用一个12V电源然后板卡上再降压就好了，实际上LED灯箱、电锁启动瞬间的大电流会直接把5V电源轨拉低，Linux系统遇到欠压轻则读卡失灵，重则当场重启。

两个电源之间只需要把GND连在一起，保证逻辑电平有共同的参考地。控制信号从6818出来到继电器，只要地不共，GPIO电平完全没法判断，这是TTL电路的基本功。我在调试第一天就碰到过板子和继电器各自供电、信号线接上后毫无反应的情况，原因就是地没连。

供电回路里还有一个细节：6818的USB口往往也能给板子供电，但接上电磁锁后的瞬间电流会让USB口电压崩掉。正式调试时一定要用外接适配器，不要依赖电脑USB供电，不然你会看到非常诡异的现象：程序一开门，系统就重启。

3. 从读卡到出号：RC522读取UID的完整代码逻辑

3.1 6818上跑RC522驱动，内核态还是用户态

RC522驱动有两种路线：一种是写内核模块，注册成字符设备，应用层去read；另一种是绕过驱动，在用户态直接用SPIDEV设备节点操作SPI总线。国内很多教材喜欢教第一种，但如果你是来快速做项目的，我建议走用户态SPIDEV方案。

6818的Linux内核一般已经编译了spi-dev驱动，启动后能看到 /dev/spidev1.0 这样的节点。应用层可以用 ioctl 设置SPI模式、速率、位数，然后直接通过 read/write 和RC522寄存器交互。好处显而易见：不需要编译内核、不需要处理模块加载顺序、调试时可以单步打印寄存器值，出了问题能快速定位是时序问题还是数据问题。

SPI参数设置上，我用的模式是SPI_MODE_0（CPOL=0，CPHA=0），速率1MHz，8位字长。有些RC522模块在2MHz下也工作正常，但官方数据手册推荐不高于10MHz，而6818的引脚和走线质量决定实际极限值，我保守起见用了1MHz，读卡依然流畅。

3.2 关键代码逻辑：寻卡、防冲突、选卡再到读卡号

RC522的读卡流程是固定的：寻卡（PCD_Request）-> 防冲突（PCD_Anticoll）-> 选卡（PCD_Select）-> 读卡号/写卡号。寻卡是让模块发出请求信号，等待卡片进入射频场；防冲突是当两张卡同时出现在感应区时挑出一张；选卡是锁定该卡，之后才能读写。M1卡每次激活后UID是不变的，所以我们实际业务只用到防冲突返回的4字节卡号。

下面是一段缩减后的C语言核心逻辑，不含完整错误处理，只展示主流程，我在6818上就是这么跑的：

static int rc522_write_reg(uint8_t addr, uint8_t val) { uint8_t tx[2] = { (addr << 1) & 0x7E, val }; // 写寄存器，地址低字节清零 // 通过 /dev/spidev1.0 发送 tx，忽略返回值 return spi_write(tx, 2); } static int rc522_read_reg(uint8_t addr) { uint8_t tx[2] = { ((addr << 1) & 0x7E) | 0x80, 0 }; // 读寄存器，地址低字节置1 uint8_t rx[2] = { 0, 0 }; spi_transfer(tx, rx, 2); return rx[1]; } static uint8_t rc522_request(uint8_t mode) { uint8_t valid_bits = 0x07; uint8_t cmd[2] = { mode, 0x00 }; // mode=0x26 表示寻卡 uint8_t back[2] = { 0, 0 }; // 发送 PCD_TRANSCEIVE 命令，等待卡片响应 // 具体做法：把数据写入 FIFO，发送命令，等待应答位 rc522_write_reg(CommandReg, PCD_IDLE); rc522_write_reg(FIFOLevelReg, 0x00); rc522_write_reg(FIFODataReg, cmd[0]); rc522_write_reg(FIFODataReg, cmd[1]); rc522_write_reg(BitFramingReg, valid_bits); rc522_write_reg(CommandReg, PCD_TRANSCEIVE); // 等待 CommandReg 的 RxReady 位，即可完成一次找卡 return (rc522_read_reg(CommandReg) & 0x08) ? 0 : 1; } static int rc522_anticoll(uint8_t *uid) { uint8_t cmd = 0x93; // 防冲突命令，用于第1级 uint8_t data[5] = { 0x20, 0x00, 0x00, 0x00, 0x00 }; // BCD 校验留给时序去补 // 发送防冲突指令并接收4字节UID + 1字节CRC // 成功后 uid[0..3] 即为卡号 return 0; }

上面这段代码我故意省掉了寄存器细节，因为重点不在逐字节抄代码，而在于你要理解流程：先通过FIFO把命令写进RC522，然后拉高StartSend开始通信，置位RC522的接收标志后就能从FIFO读出卡回复的数据。如果你手里有现成的rc522.c参考，对着这个流程改掉I2C或别的引脚定义，就能在6818上复现。

有个容易混淆的地方：防冲突返回的4字节，有些资料叫UID，有些叫序列号，实际操作中M1卡的UID出厂唯一，但你读到之后必须把它当成唯一凭证来用。不同厂家的卡，第4字节可能是校验位，也有的资料说是整个4字节都有效。稳妥的验证方法是拿同一张卡在不同的终端上读，如果始终一致，就当它是稳定标识。

3.3 读不到卡时的排查顺序

读卡不识别是RFID项目最高频的问题。我的排查顺序是：

先看模块供电，万用表量模块VCC和GND之间是不是稳定3.3V，如果电压低于3.0V，基本就是供电不足或线太细；再量RST引脚有没有拉高，RC522复位脚低电平时整个芯片处于关闭状态；用示波器或逻辑分析仪看SPI的CLK有没有时钟输出，没有时钟就查引脚复用配置，6818的GPIO默认可能不是SPI功能；最后检查天线线圈有没有严重变形或短路，模块靠近金属物体时读卡距离会骤减。

还有一个常见误区是天线距离。RC522在理想环境下读卡距离大约5cm，但很多调试中实际只有2cm。如果卡片必须贴到模块上才读出来，大概率是天线谐振偏了或者模块前面有金属遮挡。解决方案是让天线区域悬空，不要直接贴在铁质门框或金属外壳上。

4. 门禁核心控制程序：从白名单校验到继电器动作

4.1 核心主循环的状态机设计

读卡功能跑通之后，真正的业务逻辑才开始。门禁程序的本质是一个状态机：空闲状态等卡，读到卡进入校验状态，校验通过进入开门状态，开门时间到回到空闲状态。把状态设计好了，程序才不会乱，也方便后续加更多交互。

我用了一个简单的轮询线程，核心逻辑可以描述为：

1. 初始状态：继电器释放（默认断电开锁为释放状态=锁门，视你选的锁类型而定，这里假设通电上锁电磁锁，则初始为高电平输出）。
2. 循环调用防冲突检测，如果返回有卡，记住这次读到的UID。
3. 为了避免用户手动抖动、卡片在感应区边缘停留造成的误识别，连续读到相同UID达到5次且时间跨度超过50ms，才认为有效刷卡。
4. 拿有效UID去SQLite查询白名单表，判断是否存在，并且用户的status字段为正常、过期时间还没到。
5. 校验通过：GPIO输出低电平触发继电器吸合，门锁通电开门，同时记录一条开门日志；开门状态持续5秒后自动关闭。
6. 校验失败：保持门锁关闭，蜂鸣器滴三声，LED闪红灯，记录一条非法尝试日志。

这个状态机的好处是，把所有分支都控制在很小的范围内。后续你如果想加密码键盘、加远程开门、加人脸识别，只需要在空闲状态前挂一个事件源：键盘输入、网络命令、识别结果都当成"开门请求"处理，统一走校验分支。

4.2 SQLite白名单和操作日志表设计

白名单用纯文件存也可以，但并发和查询是硬伤。Linux上多个线程同时读写同一个文件，要么加锁，要么忍受数据错乱。SQLite在这个场景几乎是完美方案：轻量、单文件、支持SQL查询、自带事务。嵌入式设备上不需要单独装数据库服务器，一个so文件搞定一切。

我建了两张表，一张存用户白名单，一张存开门日志：

CREATE TABLE users ( id INTEGER PRIMARY KEY AUTOINCREMENT, uid TEXT NOT NULL UNIQUE, name TEXT NOT NULL, role TEXT DEFAULT 'user', status INTEGER DEFAULT 1, expire_time TEXT DEFAULT '2099-12-31 23:59:59' ); CREATE TABLE records ( id INTEGER PRIMARY KEY AUTOINCREMENT, uid TEXT NOT NULL, event TEXT, result INTEGER, time TEXT DEFAULT (datetime('now', 'localtime')) );

users表里status字段用1表示正常、0表示挂失。校验逻辑很简单：

SELECT * FROM users WHERE uid=? AND status=1 AND datetime(expire_time) > datetime('now');

如果查不到记录，说明卡不在白名单或者已挂失。这里有一个管理细节：给用户发卡时不要直接拿卡的原始UID当主键，UID只是一个身份标识，换卡之后数据库里的记录改一下uid就行，用户的其他信息和权限不会丢。

开门日志用records表记录，每次成功或失败都写一行。实际项目中，我还会用一个后台线程定期清理三个月前的数据，防止日志无限膨胀把Flash写满。SQLite文件在掉电时有一定概率损坏，好在门禁场景的数据量不大，每天定期备份一次records文件就够了。

4.3 继电器输出时的防抖和超时保护

开门控制看似就是GPIO拉低几秒，真正要做好的点其实有两个：一个是防抖，一个是超时保护。

防抖的逻辑我上面提到了，就是连续读到同一张卡5次再触发。有人觉得多此一举，实际调试时你会看到，用户刷卡时卡片在感应区停留的瞬间读数会跳动，如果每次都触发继电器，会出现开门之后继电器立即关闭又立即打开的现象，门锁疯狂抖动，甚至带动门体乱响。用一个简单的连续计数数组就能解决。

超时保护也很关键。我设的开门时间是5秒，从继电器吸合那一刻开始倒计时。如果门装的是闭门器，人推门进去之后门自动关，5秒足够；如果门没有闭门器，人进去之后门可能一直开着，这时候如果没有超时保护，继电器一直吸合，电磁锁始终通电，不但耗电，还会让锁体发热。

代码实现上不要用sleep来计时，因为主循环还要继续读卡。我会在确认开门时记录一个时间戳，然后在循环顶部检查当前时间和开门时间戳的差值，超过了就直接置继电器关闭。这样逻辑非常简单且不会被阻塞。

if (door_open && (now - door_open_time) > OPEN_DURATION_MS) { gpio_set(RELAY_PIN, 1); // 开门超时，自动关锁 door_open = 0; }

这里顺便说一个实际中的细节：投入运行时，门禁主机通常放在门内，开锁后刷卡的人推门进去，如果正反两个方向都有人在刷卡，程序会不会被自己人挡住？我当时的做法是规定开门状态下不响应任何新卡请求，直到超时关门后才重新进入可刷卡状态。这样既能保证时序清晰，也避免了门一直开着导致数据混乱。

5. 连续跑了一周后暴露出来的问题

5.1 反电动势导致系统重启

这是我踩过最深的坑。项目最初在实验桌上一切正常，把锁装到门框上正式测试时，一开门整个6818系统就重启。第一次还以为是接线松动，反复试了几次，发现规律很明确：每次继电器吸合都正常，继电器断开那一刻系统就崩溃。

问题出在电磁锁和继电器线圈的感性负载上。断开瞬间，电流不能突变，电感会产生一个反向高压尖峰，这个尖峰通过继电器驱动电路的寄生电容耦合到GPIO线上，再通过GPIO内部保护二极管灌到3.3V电源轨上，直接把电源打穿。6818的Linux对这种瞬时欠压非常敏感，轻则卡顿，重则掉电重启。

解决方法是给继电器线圈并联续流二极管，方向是负极接电源正、正极接电源负。你如果买的是一体化继电器模块，很多出厂时已经焊好了二极管，但便宜的裸板没有。加二极管之后，反向尖峰被钳位在0.7V左右，问题立刻消失。这一步是嵌入式控制感性负载的标准动作，做完这个项目之后，我只要用继电器控制任何感性设备，第一件事都是检查有没有续流二极管。

5.2 读卡模块贴铁装壳后距离骤减

第二个问题是在给门禁加外壳时出现的。读卡模块原本裸奔时距离4cm，装进金属底盒后突然只有1cm，刷卡体验瞬间变差。原因是RC522的天线线圈紧贴金属壳体，金属在射频场中会感应出涡流，涡流又产生反向磁场，抵消了大部分读卡能量。

解决思路有两种：一是让天线线圈和金属壳拉开距离，至少留出2-3cm空间；二是把天线朝外放在非金属面板后面，比如亚克力板或塑料面板后面。我最后选了亚克力面板方案，读卡距离恢复到4cm左右。这里要提醒，门禁读卡区域的安装位置尽量不要贴着铁质门框，如果必须在金属表面附近使用，要么换用抗金属读头，要么接受短距离刷卡的体验。

5.3 卡片复制和系统安全升级路线

M1卡（S50）有一个绕不开的问题：以现在的技术手段，普通的M1卡可以被低成本设备复制，甚至手机NFC都能模拟一张卡。如果门禁项目只校验UID，那安全等级在安防行业里最多算入门。我们做实训和教学没问题，但如果是给真实办公场景做门禁，我建议在设计之初就把安全升级路线留出来。

RC522本身支持M1卡的扇区认证和读写，可以在卡片某个扇区写入项目特定的密钥或授权标识，开锁时不仅校验UID，还校验扇区内容。这样做比只读UID安全很多，因为普通复制卡没有原始扇区数据，即使拿到了卡号也过不了扇区认证。

更进一步，如果预算充足，可以换用支持国密或更高安全等级的CPU卡读写模块，卡片内部有独立加密单元，无法被普通设备复制。我在6818项目里预留了一个桥接函数：所有卡认证都封装成check_card_auth()，后续升级成CPU卡时只要替换这一层函数，上层业务逻辑几乎不用改。

6. 测试流程与项目验收建议

6.1 从功能到稳定的完整测试清单

项目交付之前，我列了一个门禁专用测试清单，覆盖功能、边界和异常三类。不要觉得这是走形式，实际上很多问题都是在这个阶段发现的。

其中"开门瞬间断电恢复"这条非常容易被人忽略。如果你用断电开锁的电磁锁，断电瞬间门本来就开了，人进去之后电源恢复，此时系统如果上电默认GPIO输出低电平触发开门，门就会被重新打开一次，这是很大的安全漏洞。我的做法是程序启动阶段先把所有GPIO输出设成安全默认值，再初始化外设和数据库，确保启动过程中门锁始终是关闭状态。

6.2 提升长期运行可靠性的几个手段

门禁设备要7x24小时工作，很多实验室演示程序跑一天就挂，问题往往出在内存泄漏和野指针上。我在6818上做了几件事：主循环里不动态分配内存、所有固定数据结构在启动时一次性分配；读取UID的缓冲区复用；SQLite每次查询后第一时间finalize语句释放内存。

如果程序意外崩溃，看门狗能自动把系统拉起来。6818内核开启看门狗后，应用程序定期喂狗，如果应用卡死或者异常退出，内核会在几十秒后触发系统复位。我单独写了一个心跳线程，每5秒写一次看门狗设备节点，这样即使主循环卡住，喂狗线程还能正常工作，系统不会误重启。

另外，为了在野外或弱电井环境里做到掉电自动恢复，6818的电源端我加了一个小的超级电容或UPS模块（视项目预算而定），保证断电后系统能优雅关闭，不会因为Flash正在写SQLite而损坏数据库文件。实测下来，断电恢复后门禁服务能在40秒内重新进入正常读卡状态，卡片白名单和近7天的日志都不会丢。

6.3 扩展方向：远程管理、多门联动、摄像头抓拍

门禁项目做完基础版之后，后续可以非常自然地向几个方向发展。6818板载以太网口和WiFi模块接口，我可以把每次开门记录实时同步到后台服务器，办公室里就能看到谁几点进了门；如果有多扇门，每扇门用一台6818门禁机，后台统一管理白名单，卡挂失在一台机子上操作，全部门禁点同步生效；想更高级一点，可以在开门触发瞬间调用摄像头拍照，把刷卡人照片和UID关联，以后有人用复制卡闯门禁时就能抓到现场。

我在扩展阶段做了一个非常小的后台Demo：门禁机通过HTTP POST把开门记录发给某台服务器上的Python脚本，脚本解析后写入MySQL。这块的工作量比想象中小，因为门禁端只需要一个异步上传线程，不需要处理复杂协议。网络断掉时数据缓存在本地SQLite，网络恢复后自动补传，这样所有记录最终都是完整的。

我个人在这一轮测试里体会最深的一点是：嵌入式门禁项目的难点从来不是某个模块本身，而是把读卡、业务、控制、日志、回传这些环节在真实硬件环境里打磨稳定。RC522的驱动资料网上很多，硬件连接也不复杂，真正拉开差距的地方是你有没有处理反电动势、光纤磁干扰、断电恢复这类"小事"。把这些细节都考虑进去，才算是把一个教学级Demo做成真正能交付的项目。