简介一份面向嵌入式开发者和RFID入门学习者的125kHz读卡器源码工程围绕EM40014001卡等低频ID卡的识别与读取展开适用于门禁、停车场、会员卡等场景。压缩包共32个文件体积仅97KB以C源码、头文件、工程配置文件为主并包含hex固件、汇编启动文件及备份文件便于查看完整读卡流程和工程结构。目前已有1152人学习下载。代码公开了从天线信号检测、解码到卡号解析的实现细节内含EM4095相关驱动逻辑和多次迭代后的读卡优化如V14版本有助于理解125kHz RFID通信协议、曼彻斯特编码、信号处理及防错机制同时也能学习Keil工程组织方式和硬件调试思路。对于想改造或自研低成本读卡模块的开发者这份精炼源码具备直接参考价值。 做了好几年嵌入式手头的门禁、考勤类项目里有一半都绕不开125K射频识别。最近一个项目需要自己从零调一套125K读卡器网上搜了一圈所谓“原代码”不是缺解调部分就是只适配某一颗单片机真正能跑起来读到卡号的没几个。我把整个链条重新捋了一遍从天线谐振到曼彻斯特解码再到最终的ID输出每一步都踩了不下两三次坑这篇直接把完整思路和关键代码骨架写清楚想自己搞定125K读卡器的朋友可以参考。1. 125K为什么还没被淘汰应用场景与方案对比1.1 低频识别仍然占据的赛道125KHz是低频RFID最常见的载波频率市面上绝大多数EM4100、T5577、HID Prox卡都跑在这个频段。它读取距离通常只有几厘米传输速率也慢1Kbps左右但胜在方案极度成熟、标签成本极低一枚EM4100兼容卡几毛钱一块PIC或STM32加一个天线驱动电路就能做整机。门禁考勤、巡更点检、停车场月卡识别、钥匙管理柜、宠物芯片这类场景至今还是125K的天下。低频的核心优势是抗金属和水。13.56MHz的NFC标签贴近金属就读不动隔一层水膜也容易失效而125K靠的是磁场耦合波长更长金属干扰和液体吸收的影响小得多所以工业设备、户外环境、桌面门禁这些场合很少把125K彻底替换掉。1.2 和13.56MHz、900MHz相比怎么选参数125kHz13.56MHz900MHz UHF通信速率约1-2kbps106-848kbps30-200kbps读取距离3-10cm5-10cm1-10m抗金属/水较好较差差标签成本极低中等中等偏高典型应用门禁、考勤、动物识别公交、支付、防伪仓储、物流、汽车电子标识如果你只是做一个“靠近刷卡、验证通过”的小系统功耗和成本是第一考量13.56带来的高速率根本用不上反而因为天线调试、卡密问题多出一堆麻烦。125K读卡器从硬件到解码逻辑都相对简单这也是它生命力这么强的原因。2. 读卡器硬件设计天线谐振、解调芯片与信号链2.1 天线线圈与LC谐振匹配读卡器和标签之间本质是变压器耦合。读卡器天线是一个线圈内部有交变电流产生125KHz交变磁场标签天线在这个磁场里感应取能。标签芯片会周期性地改变自身负载读卡器天线端电压随之产生微小起伏解调电路把这种幅度变化提取出来就得到了标签回传的曼彻斯特编码信号。要让发射效率最高天线线圈必须工作在谐振状态。基本公式是f 1 / (2π√(LC))天线线圈的电感由匝数、尺寸、形状决定。绕制成矩形或圆形通常电感量在几百μH到几mH之间。假设实测L1.2mH要谐振到125kHz所需电容为C 1 / (4π² f² L) ≈ 1 / (4 × 9.87 × 125000² × 0.0012) ≈ 1.35nF我踩过的第一个坑就是直接用理论圈数绕天线没实测电感就焊电容结果谐振点偏了十几kHz读卡距离只剩1cm。绕好天线之后一定要用电感表测实际值再算电容不要迷信仿真结果。2.2 解调方案的三种路线125K读卡器最核心的部分不是天线而是把标签回传的微弱调制信号还原成单片机可处理的数字波形。实际项目里通常有三条技术路线分立元件方案天线并联谐振电容取样绕组上的信号经二极管包络检波后接比较器整形输出TTL电平给MCU。成本最低但AGC缺失距离一近信号削顶失真距离一远幅值太小非常难调。专用收发芯片方案典型芯片包括EM4095、AT88RF001等它们集成天线驱动、解调、AGC、滤波和比较器外部只需一个天线和少量阻容MCU直接接收解调后的数字输出。这是目前工业产品的主流做法。ADC直接采样方案MCU用ADC高速采样天线包络全软件解调。灵活性最高但占据大量CPU资源对低端MCU不友好。我倾向于EM4095这类专用芯片。原代码的复杂度和稳定性才真正可控把最难搞的模拟信号处理交给芯片MCU专注做时域解码开发周期能缩短一半以上。如果对成本极度敏感再考虑分立方案但需要做好长时间调试的心里准备。2.3 布局与供电这几件事做错会很麻烦天线下方不要铺大块地铜。磁场会被地平面的涡流削弱实测读距直接腰斩。天线四周留出至少5mm净空避免电路走线形成的寄生环耦合干扰。给模拟解调部分用LDO供电不要直接吃DC-DC的输出纹波否则比较器输出会叠一层毛刺。EM4095的天线输出端需要并联合适的谐振电容有的资料要求再串联一个小电阻降低Q值否则信号过冲会导致误判。3. EM4100帧结构与曼彻斯特解码的核心逻辑3.1 64位帧到底怎么排列EM4100可以说是125K标签的默认协议几乎所有入门读卡器教程都拿它开刀。一帧数据固定64位排列顺序是9位全为1的同步头用于让读卡器锁定帧起始10组数据块每组5位其中低4位是有效数据、第5位是偶校验位4位列校验位对上面10组数据按列做偶校验1位停止位固定为0。这10组有效数据里前两组是版本号或客户代码中间8组才是通常所说的32位卡号。不同读卡器输出卡号时有的只取这32位有的把版本号也拼进去实际读数不一致是常见现象搞清帧结构之后就能理解为什么了。3.2 曼彻斯特编码的时间尺度EM4100回传的波特率由载波分频得到典型配置是RF/64对125KHz就是约1953bps每位持续约512μs。曼彻斯特编码的规则是逻辑0位周期的前半段为高电平后半段为低电平也就是“10”逻辑1位周期的前半段为低电平后半段为高电平也就是“01”。这种编码的优点是电平在每个位周期内必然跳变一次接收端不需要知道绝对值只需要测量跳变边沿就能还原数据。3.3 为什么位同步是解码的灵魂很多人写的解码程序是“每512μs采样一次电平”看起来能行实际一跑就错。原因有二一是晶振或载波频率存在误差位周期不是严格512μs二是读卡器解调输出边沿有抖动固定间隔采样很容易落在跳变沿附近采到一个不稳状态。正确做法是利用帧同步头做自动频率估计。同步头是9个连续的1对应波形是“010101…”交替跳动相邻跳变间隔正好是半个位周期测出这组间隔的平均值就得到了当前实际位周期T的一半。后续解码都以这个估计值为基准允许的误差范围控制在±15%到±20%低于这个范围容易把正常跳变漏掉高于这个范围又容易把毛刺误判成数据。4. 原代码的骨架定时器捕获、间隔测向与校验输出4.1 为什么选输入捕获而不是GPIO轮询MCU监听解调输出信号最省事的方式是GPIO中断但EM4100同步头期间约每256μs就有一个跳变主程序同时还要做按键、显示、通信一旦被其他中断卡住很容易丢边沿。更稳妥的是用定时器输入捕获通道硬件自动记录边沿时刻再把时间差交给软件处理。每个边沿产生一次中断但中断里只读寄存器、记差值、做一次极轻量的判定压力小很多。我的实现步骤是这样的定时器配置为上升沿和下降沿都捕获或者只捕获下降沿再辅以电平状态判断。每次捕获中断读取CCR寄存器与上次捕获值相减得到相邻边沿间隔delta。把delta推入环形缓冲区主循环从缓冲区取数据进行帧解析。初始化示意void capture_init(void) { // 以STM32 TIM2为例 RCC-APB1ENR | RCC_APB1ENR_TIM2EN; TIM2-PSC 0; // 定时器时钟直接计数 TIM2-ARR 0xFFFF; // 16位循环计数 TIM2-CCMR1 TIM_CCMR1_CC1S_0; // TI1 - IC1 TIM2-CCER | TIM_CCER_CC1E | TIM_CCER_CC1P; // 捕获使能双边沿触发 TIM2-DIER | TIM_DIER_CC1IE; TIM2-CR1 | TIM_CR1_CEN; NVIC_EnableIRQ(TIM2_IRQn); }4.2 根据边沿间隔还原比特流拿到delta之后要和已估计的半位周期T_half做比较。假设当前状态是“上一次跳变的方向已经确定”本次跳变间隔基本就三种可能delta约为0.5T这是码片内部的跳变直接确定当前位数据delta约为1T说明连续两个位相同中间那次位于码片边界的跳变没有发生或没被采样到需要补一位delta约为1.5T说明连续三个位相同需要补两位。举个例子如果当前检测到的是下降沿且间隔为0.5T对应波形必然是“10”也就是逻辑0如果间隔为1T前面一位和当前位相同按前一个位的值再输出一次。代码里我会用接近度比较static uint8_t classify_delta(uint32_t delta, uint32_t half_period) { if (delta half_period * 3 / 4) return 0; // 0.5T if (delta half_period * 5 / 4) return 1; // 1T if (delta half_period * 7 / 4) return 2; // 1.5T if (delta half_period * 9 / 4) return 3; // 2T return 0xFF; // 异常 }同步头阶段可以先测到多个0.5T间隔取平均值作为half_period这个值在整帧解码过程中保持动态更新等于给解码器加了一个自动频率校准解决了晶振偏差问题。4.3 帧状态机与校验输出解码流程做成状态机比较清晰IDLE状态下等待同步头——出现连续9个高电平时确认帧起始接着逐位收集后续bit每收到5位做一次行校验收满10组后再做列校验和停止位判断全部通过才输出卡号。核心伪码typedef enum { ST_IDLE, ST_SYNC, ST_DATA, ST_PARITY, ST_VALIDATE } decode_state_t; void process_bit(uint8_t bit) { switch (state) { case ST_IDLE: if (bit 1) { sync_count; if (sync_count 9) { state ST_DATA; bit_count 0; } } else { sync_count 0; } break; case ST_DATA: rx_buffer (rx_buffer 1) | bit; bit_count; if (bit_count 64) { state ST_VALIDATE; } break; case ST_VALIDATE: if (em4100_check(rx_buffer)) { output_id extract_id(rx_buffer); } state ST_IDLE; sync_count 0; break; } }校验函数判断的是行偶校验、列偶校验、停止位是否正确uint8_t em4100_check(uint64_t frame) { // 低9位必须是同步头全1 if ((frame 0x1FF) ! 0x1FF) return 0; // 逐组检查行偶校验 for (int row 0; row 10; row) { uint8_t group (frame (9 row * 5)) 0x1F; if (count_ones(group) 1) return 0; } // 列校验位在bit 59~62 // 停止位为bit 63必须是0 if ((frame 63) 1) return 0; return 1; }需要特别注意EM4100的数据是低位先发所以从frame里提取卡号后如果要打印成十六进制往往需要做位序翻转否则和商用读卡器读出来的卡号对不上。我第一次调的时候满屏十六进制都对不上标签表面印刷的ID后来发现就是位序问题不是协议没解对。5. 实测定标过程与三个最容易翻车的细节5.1 读距从1cm到5cm的修正过程初版板子读距只有1cm贴着都时不时断。我用示波器勾天线端波形发现谐振电压峰值根本不在125K附近再测天线电感实际值和仿真相差20%。换掉电感、重新算电容之后谐振电压抬升明显读距到了4cm左右。后来又做了两件事把解调供电从DC-DC纹波比较明显的输出换成LDO把天线两端并联的谐振电容从X5R换成C0G材质。C0G的温漂和电压偏置特性远好于X5R谐振频率稳定了读距又提升了一点。如果有人问到底能读多远按我的实测2到5cm属于正常范围。想再远一点无非是提高天线Q值、增大发射电流、降低噪声这三条路但每条路都有代价门禁场景其实不需要强求距离。5.2 解码偶发错卡的根因项目测试阶段出现过偶发把卡号读错的情况持续半天又自己消失。后来用逻辑分析仪抓DEMOD_OUT的波形发现解调信号上有大量窄毛刺有些毛刺宽度不到20μs但足以被输入捕获当成真实边沿处理。解决办法分两层硬件上在比较器输出到MCU之间加一级RC滤波时间常数取5到10μs把窄毛刺滤掉软件上在解码器里加最小间隔过滤小于0.3倍半位周期的间隔直接丢弃。两层叠加之后误码率明显下降连续读几千次没再出错。5.3 上电瞬间假同步的处理还有一个易踩点读卡器天线上电起振的瞬间会有几十毫秒的振荡建立过程这个阶段EM4095的输出不稳定可能产生一串无序方波。如果代码一看到9个连续1就进入数据接收很容易被这段乱码骗进错误状态。我的处理是在同步判定之后不会立刻开始取数而是要求前9位bit满足曼彻斯特编码连续性并在收满64位后强制做行校验和列校验。任何一步不满足就直接回IDLE而不是把校验失败的frame丢弃后继续在错误相位里找数据。靠这层逻辑上电握手过程变得稳定连标签一直放在天线上的场景都能正确定位每一帧的起始。5.4 从零复刻时值得先做的两件事如果你想把这个项目真正落地建议第一步就买一个USB逻辑分析仪抓一段EM4100的DEMOD_OUT波形对着数据手册逐位标注同步头、数据块、校验位把时序彻底看懂再动手写解码。第二步是做一个最简单的测试用例固定一张已知卡号的标签把解码结果打印出来和商用读卡器读数做对比立刻就能发现自己有没有位序问题和校验逻辑错误。我之前遇到过来的开发者在网上看到一段“原代码”就急着移植结果不知道那段代码假设的是差分曼彻斯特而EM4100用的是标准曼彻斯特整体波形逻辑完全不同查了两天没查出来。先把波形读懂源码写得再乱也不怕。本文还有配套的精品资源点击获取