第二讲：电子标签基础——芯片架构、存储结构与状态机
各位同学好，欢迎来到第二讲。今天我们要聊的，是RFID标签最核心的三个东西：芯片内部长什么样、数据存在哪里、以及标签是怎么“变脸”的。
说实话，我刚入行那会儿，觉得标签就是个简单的“无线IC卡”。直到第一次调试读写器，发现标签死活不响应——后来才发现，是状态机没走对。嗯，从那以后，我再也不敢小看这三个基础模块了。
2.1 标签芯片架构：麻雀虽小，五脏俱全
别看一个无源标签只有米粒大小，它内部其实是一个完整的微型系统。我习惯把它的架构分成四大块：
- 射频前端：负责接收读写器信号、整流取电、反向散射通信。说白了，就是“吃饭”和“说话”的接口。
- 数字基带：解析命令、执行协议、控制状态机。这是标签的“大脑”。
- 存储单元：保存TID、EPC、User数据。这是标签的“记忆”。
- 防冲突引擎：处理多标签同时应答时的碰撞问题。这个我们后面专门讲。
我在项目中遇到过一款国产标签芯片，它的射频前端整流效率特别高，-18dBm就能启动。但代价是数字基带处理速度慢，遇到密集读取场景就容易丢包。所以你看，架构设计永远是个权衡。
核心要点：标签芯片的功耗预算极其有限（微瓦级），所以数字基带通常用硬连线逻辑实现，而不是跑软件。这意味着——协议一旦固化，后期没法升级。
2.2 存储结构：TID、EPC、User区
这是面试时最爱问的，也是实际开发中最容易踩坑的地方。我们按ISO 18000-6C（EPC Gen2）标准来拆解。
2.2.1 TID区（Tag Identifier）
TID是标签的“身份证号”，出厂时写入，全球唯一，不可修改。我见过有人想用TID做资产编码，结果发现——不同批次的标签，TID格式可能不一样。
| 字段 | 长度 | 说明 |
|---|---|---|
| 厂商代码 | 8位 | 由EPCglobal分配，比如Alien是0xE2 |
| 芯片型号 | 12位 | 标识具体芯片版本 |
| 序列号 | 12位 | 芯片级唯一编号 |
避坑指南：我曾经在项目中直接用TID做防伪校验，结果发现同一型号的标签，TID前20位完全一样。后来才知道，有些厂商的序列号只有后4位是变化的。所以——用TID做唯一标识时，一定要先读一批标签，确认序列号的分布范围。
2.2.2 EPC区（Electronic Product Code）
EPC是标签的“业务ID”，用户可写，通常用来存物品编码。标准长度是96位，但支持扩展到496位。
我个人习惯把EPC分成三段：
- 头标（8位）：标识编码类型，比如EPC Global的0x30
- 厂商代码（28位）：类似GS1的公司前缀
- 物品序列号（60位）：具体到每个单品
你想想看，如果EPC只存96位，那一个读写器最多能管理2^96个物品——理论上够用。但实际项目中，我见过有人把EPC当“记事本”用，存了中文编码进去，结果读写器解析出来全是乱码。嗯，这里要注意：EPC只支持16进制数据，别往里塞ASCII字符串。
2.2.3 User区（User Memory）
User区是标签的“草稿纸”，用户自定义。有的标签有，有的没有。容量从64位到64K位不等。
我建议这样规划User区：
- 前16位：存数据长度校验码（CRC）
- 中间N位：存业务数据（比如生产日期、批次号）
- 最后16位：存写入时间戳
小技巧：写User区前，一定要先读一下当前值。因为有些标签的User区是“写1清0”的，直接覆盖写可能会把原有数据搞乱。我吃过这个亏，那次写废了3000个标签，被老板骂了一周。
2.3 标签状态机：从“沉睡”到“对话”
标签的状态机，说白了就是标签在不同命令下的“反应模式”。EPC Gen2定义了7种状态，但实际开发中，你只需要关注4个：
- Ready（就绪）：标签上电后的初始状态，等待Query命令
- Arbitrate（仲裁）：标签参与防冲突轮询，但还没被选中
- Reply（应答）：标签被选中，准备发送数据
- Acknowledged（确认）：读写器确认收到数据，标签可以进入后续操作
为什么会这样设计？因为无源标签的供电不稳定。你想想看，标签在移动过程中，可能瞬间掉电又上电。状态机必须保证：掉电后自动回到Ready，而不是卡在某个中间状态。
我记得有一次调试，读写器发完Query命令后，标签一直不进入Reply。查了半天，发现是读写器的载波频率偏移太大，标签的PLL锁不住。嗯，这种问题在低成本读写器上特别常见。
状态转换的关键命令
| 当前状态 | 接收命令 | 下一状态 |
|---|---|---|
| Ready | Query | Arbitrate |
| Arbitrate | QueryRep | Arbitrate（继续轮询） |
| Arbitrate | ACK（匹配时隙） | Reply |
| Reply | ACK（确认） | Acknowledged |
| Acknowledged | Req_RN | Open/Secured |
实战建议：写驱动时，一定要在状态机每个转换点加超时处理。我曾经遇到过标签进入Acknowledged后，因为读写器没及时发Req_RN，标签直接超时跳回Ready。如果不加超时检测，你的驱动就会一直等，造成死锁。
2.4 三个模块的联动关系
最后，我画个简单的逻辑图（用文字描述）：
射频前端取电 → 数字基带上电 → 状态机进入Ready
→ 收到Query → 进入Arbitrate → 防冲突引擎计算时隙
→ 时隙匹配 → 进入Reply → 从存储区读取EPC
→ 反向散射发送EPC → 收到ACK → 进入Acknowledged
→ 收到Req_RN → 进入Open → 可读写TID/User区你看，芯片架构、存储结构、状态机，这三者是环环相扣的。射频前端供电不稳，状态机就会乱跳；存储区数据格式不对，读写器就解析不了；状态机没走对，标签就“装死”。
好了，这一讲就到这里。下一讲我们聊聊读写器驱动开发中最头疼的问题——防冲突算法。到时候我会分享一个我当年调试了三天三夜的案例，保证让你印象深刻。
课后练习：找一款UHF RFID标签，用读写器读它的TID和EPC。观察一下：TID的前几位是不是固定的？EPC是不是全零？User区有没有数据？然后想想——如果让你设计一个标签数据格式，你会怎么分配这三个区？