简介：本资源是一套基于125kHz RFID技术的ID卡读卡器嵌入式源码工程，面向嵌入式开发初学者、门禁/考勤系统开发者及RFID技术实践者，解决低频ID卡（如EM4001兼容的4001卡）快速识别与数据解析的核心问题，适用于门禁控制、停车场管理、会员卡终端等实际场景。压缩包共32个文件，97KB，涵盖4个C语言源文件（含main.c、EM4095.c等关键驱动逻辑）、2个头文件（config.h等）、2个Hex可执行镜像、多个Keil工程配置文件（uvproj、uvopt、uv2）及编译中间产物（.lst、.obj、.m51），完整呈现从底层射频芯片（EM4095）通信、信号解码到主控逻辑实现的全链路代码结构。已有1156人学习下载，读者可直接复用V14优化版本的连续读卡逻辑、200ms级快速响应机制、抗干扰错误处理策略，并通过.bak备份文件追溯迭代演进过程，深入理解125k ID卡协议解析、软硬件协同设计与嵌入式性能调优方法。

1. 125kHz ID卡读卡器原代码：不是“万能解码器”，而是硬件协议层的精准对齐工具

你手头有一批老式门禁卡、食堂卡、考勤卡，背面印着“EM4100”“TK4100”“HID ProxCard II”或模糊写着“125kHz”，用市面上几十块的USB RFID读卡器一刷，软件显示一串十六进制数，但换到另一套系统里就识别失败——不是卡坏了，是协议解析没对上。这类ID卡不加密、无存储分区、不交互，靠载波调制（ASK/OOK）和曼彻斯特编码传递固定ID，但不同厂商在起始位长度、校验方式、数据位序（MSB/LSB）、是否补零等细节上各自为政。所谓“125K读卡器原代码”，指的不是通用驱动，而是针对EM4100系列芯片（如4001卡）底层时序与帧结构的完整实现：从GPIO电平采样、边沿检测、脉宽分析，到曼彻斯特解码、CRC-16校验、ID提取，全部可调试、可修改、可移植。它适合嵌入式开发者做国产替代读头、安防设备厂商做协议兼容适配、教学实验室讲授RFID物理层原理，也适合想搞懂“为什么同一张卡在A设备能刷、B设备报错”的工程师。这不是拿来即用的黑盒子，而是一份带注释的协议显微镜。

2. EM4100协议深度拆解：为什么必须从原始电平开始解析

EM4100类ID卡（含4001卡）的通信本质是单向、无应答、模拟载波调制。主流读卡器芯片（如RDM6300、MLX90129）输出的是TTL电平信号，但其原始波形隐含了所有协议信息。直接依赖芯片内置解码（如RDM6300的UART输出）会丢失关键调试能力：当卡识别率低、偶发乱码、或需支持非标卡时，你无法定位问题是出在天线匹配、供电噪声、还是解码逻辑本身。原代码的价值，正在于把“芯片自动完成”的环节全部展开，让你看到每一微秒的电平变化如何被翻译成ID。

2.1 卡片响应帧结构：64位原始比特流的硬约束

EM4100标准帧长为64位，结构固定：

• 前导码（Preamble）：9个连续高电平（每个约262μs），用于接收机同步；
• 起始位（Start）：1位高电平（262μs）；
• 数据位（Data）：32位ID（通常为十进制8位或10位，对应HEX 20位，高位补零）；
• 校验位（Parity）：1位奇校验（覆盖32位ID）；
• 结束位（Stop）：1位低电平（262μs）；
• 后续为重复帧（Loop）。

提示：4001卡虽常被归为EM4100兼容卡，但部分批次在起始位后插入1位保留位（Reserved Bit），导致标准解码失败。原代码中em4100_decode_frame()函数内START_BIT_LEN与RESERVED_BIT_OFFSET两个宏定义，就是为此预留的调节入口。

2.2 曼彻斯特编码规则：电平跳变即数据，而非高低电平本身

EM4100使用曼彻斯特编码，规则简单但易误读：

• “0” 表示：前半周期高电平 + 后半周期低电平（下降沿在中间）；
• “1” 表示：前半周期低电平 + 后半周期高电平（上升沿在中间）；
• 每位总宽度固定为262μs（±10%），因此半个周期≈131μs。

这意味着：不能通过测量高/低电平持续时间来判断0/1，必须检测边沿位置。原代码中detect_edge_timing()函数采用定时器捕获模式（如STM32的TIM_IC），记录每次电平跳变的精确时刻，再计算相邻跳变的时间差，从而还原出原始比特流。若改用普通GPIO轮询，因CPU中断延迟，131μs级精度根本无法保证。

// 示例：STM32 HAL库下边沿捕获关键逻辑（摘自原代码timer_capture.c） void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim) { if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1) { uint32_t now = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1); static uint32_t last_edge = 0; uint32_t pulse_width = (now > last_edge) ? (now - last_edge) : (0xFFFFFFFF - last_edge + now); // 关键：只关心跳变间隔，而非电平状态 if (pulse_width > 120 && pulse_width < 145) { // 131μs ±10%，判定为半周期 append_bit(1); // 上升沿→1，下降沿→0（依实际接线定义） } else if (pulse_width > 250 && pulse_width < 275) { // 全周期，可能是起始/结束位 append_bit(0xFF); // 特殊标记 } last_edge = now; } }

这段代码的核心思想是：放弃“读电平”，专注“抓跳变”。pulse_width的阈值范围（120–145μs）是实测经验值，直接决定解码鲁棒性。原代码包中config.h文件提供了MANCHESTER_HALF_PERIOD_MIN和MAX两组宏，供你在不同MCU主频、不同晶振精度下微调。

2.3 CRC-16校验实现：不止是查表，更要理解多项式选择

EM4100使用CRC-16-IBM（又称CRC-16-ANSI），生成多项式为x^16 + x^15 + x^2 + 1（0x8005）。但原代码并未直接调用标准CRC库，而是在crc16_em4100.c中实现了按位计算版本：

uint16_t crc16_em4100(uint8_t *data, uint8_t len) { uint16_t crc = 0xFFFF; // 初始值 for (uint8_t i = 0; i < len; i++) { crc ^= (uint16_t)data[i] << 8; for (uint8_t j = 0; j < 8; j++) { if (crc & 0x8000) { crc = (crc << 1) ^ 0x8005; } else { crc <<= 1; } } } return crc; }

注意两点：第一，初始值为0xFFFF（非0x0000），这是EM4100规范要求；第二，输入数据是32位ID的字节序——原代码默认按data[0]为ID最高字节（Big-Endian），若你的卡ID在示波器上观察到低位先传，则需在调用前调用reverse_bytes(data, 4)。这个细节在decode_id_from_bits()函数注释中有明确警示。

3. 原代码工程结构与核心模块移植指南

该资源并非单一C文件，而是一个可编译、可烧录、可调试的嵌入式工程，目标平台为ARM Cortex-M系列（以STM32F103C8T6最小系统板为参考）。其目录结构设计直指量产需求：驱动层抽象、协议层解耦、应用层可替换。理解此结构，是你成功移植到自己硬件的第一步。

3.1 工程目录树：四层分离，拒绝“上帝文件”

125k_reader_src/ ├── Core/ // 应用层：主循环、LED指示、串口输出 │ ├── main.c │ └── app_rfid.c // ID处理、去重、格式化输出 ├── Drivers/ // 驱动层：与MCU外设强绑定 │ ├── stm32f1xx_hal_conf.h // HAL配置开关 │ ├── rfid_gpio.c // 天线驱动IO初始化（TX/RX使能） │ └── timer_capture.c // 定时器输入捕获，核心采样模块 ├── Protocol/ // 协议层：完全独立于硬件，可复用于ESP32/Arduino │ ├── em4100_decoder.c // 曼彻斯特解码、帧同步、ID提取 │ ├── crc16_em4100.c // 专用CRC校验 │ └── id_formatter.c // ID格式转换（HEX→DEC，分段显示） └── Inc/ // 全局头文件 ├── em4100_protocol.h // 帧结构定义、宏常量 └── config.h // 可配置参数：采样精度、超时阈值、调试开关

注意：Protocol/目录下的所有.c文件不包含任何HAL或寄存器操作，只处理uint8_t*数据流。这意味着：若你用ESP32开发，只需重写Drivers/目录（用ESP-IDF GPIO中断替代TIM捕获），Protocol/可原封不动复用。这是原代码工程价值的关键体现。

3.2 关键参数配置表：改这5个宏，适配90%硬件差异

config.h是移植成败的咽喉。以下5个宏必须根据你的实际电路调整，原值基于RDM6300模块+STM32F103标准设计：

修改后务必重新编译，且RFID_CAPTURE_PRESCALER变更后需同步检查timer_capture.c中__HAL_TIM_SET_COUNTER(&htimx, 0)的调用时机，避免捕获窗口偏移。

3.3 串口输出协议：不只是打印，而是为上位机留好接口

原代码默认通过USART1（PA9/PA10）以115200bps输出解码结果，格式严格遵循如下规则，方便Python/Qt上位机解析：

[START]ID:00012345,CRC:ABCD,LEN:8[END]\r\n

• [START]与[END]为固定ASCII字符串（0x5B 0x53 0x54 0x41 0x52 0x54 0x5D），非控制字符；
• ID:后为8位十进制ID（不足位左补零），CRC:后为4位大写HEX校验码；
• LEN:8表示ID有效数字位数（EM4100标准为8，4001卡可能为10）；
• 每帧以\r\n结尾，无空行。

提示：若需对接Modbus RTU或JSON API，不要修改app_rfid.c中的printf，而应修改id_formatter.c中的format_id_output()函数，将输出重定向至全局缓冲区output_buf[]，再由外部模块统一打包。这是原代码预留的扩展钩子。

4. 避坑：EM4100解码的五个经典翻车现场与自救方案

用原代码跑通Demo只是起点，真正在项目中落地时，90%的问题不出在代码逻辑，而出在硬件链路与环境干扰。以下是我在某高校门禁改造项目中踩过的坑，每一条都附带示波器截图验证过的解决方案。

4.1 现象：示波器看波形完美，但代码始终解码失败

原因：GPIO输入模式配置错误。原代码假设RX引脚接在RDM6300的TTL_OUT，该信号为3.3V CMOS电平。若你误接到Wiegand_DATA0（开漏输出，需上拉），或MCU引脚未开启内部上拉/下拉，导致空闲电平浮动，边沿检测失效。
解决：用万用表量RX引脚空闲电压。若非稳定3.3V或0V，立即检查rfid_gpio.c中GPIO_InitTypeDef的Pull字段。RDM6300必须配GPIO_NOPULL，而Wiegand接口必须配GPIO_PULLUP，二者绝不可混用。

4.2 现象：同一张卡，靠近读头时识别率100%，距离>5cm时ID错乱

原因：天线匹配网络失谐。EM4100工作在125kHz，理想天线感抗需≈容抗。原代码适配的PCB天线（100mm×100mm，8圈），其谐振点受PCB板材介电常数、铜厚、周围金属影响极大。示波器测得载波幅度衰减>6dB即告警。
解决：不依赖理论计算，用网络分析仪扫频（或简易版：信号发生器+高频探头）。找到实际谐振峰（如118kHz），在匹配电容C_match（通常并联在天线两端）上并联微调电容（5–20pF瓷片电容），直至125kHz处S21损耗最小。原代码硬件BOM中C_match=100nF仅为参考值。

4.3 现象：解码出的ID末尾几位总是0000，或CRC校验恒失败

原因：ID字节序（Endianness）与卡片物理传输顺序不一致。EM4100芯片手册写明“MSB first”，但部分4001卡厂为兼容旧设备，实际发送LSB first。原代码默认MSB first，若卡为LSB first，则32位ID被整体反转。
解决：在em4100_decoder.c中找到decode_id_from_bits()函数，取消注释第127行reverse_bits_in_bytes(id_bytes, 4);。更稳妥做法：用逻辑分析仪抓取原始比特流，对照手册确认起始位后第1位是ID最高位还是最低位。

4.4 现象：多卡同时进入场区，只识别到第一张卡，后续卡无响应

原因：缺少防冲突机制。EM4100是纯ID卡，无防冲突指令，但读卡器需在检测到首张卡后，强制关闭载波发射（rfid_gpio.c中set_rf_power(0)），等待100ms以上再重启，否则多卡磁场叠加导致解码器锁死。
解决：在app_rfid.c的rfid_task()主循环中，加入状态机：STATE_IDLE → STATE_CARD_DETECTED → STATE_DECODE_WAIT → STATE_POWER_OFF_DELAY。原代码config.h中MULTI_CARD_DELAY_MS宏即为此设计，默认150ms。

4.5 现象：烧录后LED常亮不闪，串口无任何输出

原因：启动文件与链接脚本不匹配。原代码基于STM32F103C8T6（64KB Flash），若你用F103CBT6（128KB），而STM32F103C8Tx_FLASH.ld链接脚本未更新Flash大小，导致.text段溢出，程序跳转到非法地址。
解决：打开Core/Startup/startup_stm32f103xb.s，确认STACK_SIZE和HEAP_SIZE未超限；核对STM32F103C8Tx_FLASH.ld中FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 64K。若用CBT6，必须改为LENGTH = 128K，否则main()永不执行。

5. 实战技巧：用逻辑分析仪反向验证解码正确性，三步锁定99%协议问题

当示波器只能看模拟波形、万用表只能测直流电压时，逻辑分析仪（哪怕是最便宜的Saleae Logic 4）是你验证原代码解码正确性的终极后悔药。我坚持在每个RFID项目初期，用它做三步交叉验证，从未再被“卡能刷但ID不对”这种玄学问题困住超过2小时。

5.1 第一步：捕获原始GPIO电平，确认采样无失真

将逻辑分析仪通道1接MCU的RFID_RX引脚，设置采样率≥5MHz（推荐10MHz），捕获时长10ms。触发条件设为“上升沿”，确保捕获到完整帧。关键看三点：

• 前导码9个高电平是否等宽（262μs±10%）；
• 相邻跳变间最短间隔是否≥120μs（排除噪声毛刺）；
• 整帧长度是否≈64×262μs≈16.8ms。

若发现脉宽严重抖动（如100μs与300μs交替），说明天线阻抗不匹配或电源纹波过大，此时调代码毫无意义，必须先修硬件。

5.2 第二步：导出CSV，用Python重放解码逻辑

逻辑分析仪导出CSV后，用以下Python脚本（需numpy）重现实时解码过程，与原代码结果逐位比对：

import numpy as np import pandas as pd # 读取CSV，假设列为"time_us,level" df = pd.read_csv("rfid_capture.csv") times = df['time_us'].values levels = df['level'].values # 提取跳变时刻（简化版，实际用diff） edges = np.where(np.diff(levels) != 0)[0] edge_times = times[edges] # 计算脉宽（单位：μs） widths = np.diff(edge_times) # 手动应用原代码阈值 bits = [] for w in widths: if 120 <= w <= 145: bits.append(1) # 半周期→数据位 elif 250 <= w <= 275: bits.append(0) # 全周期→起始/结束位 else: bits.append(-1) # 无效 print("Replayed bits:", bits[:64]) # 打印前64位

运行后，若bits数组与原代码debug_print_bits()输出完全一致，证明采样与边沿检测无误；若有差异，问题必在timer_capture.c的捕获精度或config.h的PRESCALER设置。

5.3 第三步：对比CRC，定位ID提取阶段错误

取逻辑分析仪捕获的32位ID数据（从第10位起共32位），手动转为HEX字符串，用在线CRC计算器（选CRC-16-IBM，初始值0xFFFF，无反转）计算校验码。若结果与原代码输出的CRC:ABCD不一致，说明em4100_decoder.c中ID截取位置错误。此时打开decode_id_from_bits()函数，重点检查：

• start_idx是否从第一个有效数据位开始（跳过前导码和起始位）；
• id_len_bits是否严格为32；
• id_bytes[0]是否对应ID最高字节（MSB）。

从那以后我每次接到新卡型，都强制走一遍这三步：先抓波形看硬件，再用Python重放验证采样，最后比CRC定ID。省下的调试时间，够我喝三杯咖啡。希望帮到你。

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