一、课程导论与项目全景
1.1 轨道交通支付系统概述
各位同学，咱们这门课要聊的，是轨道交通支付模块。说白了，就是地铁闸机里那个让你「嘀」一下就能过的小东西。
我做了十几年嵌入式，见过太多人只盯着代码看。但支付模块不一样——它是个典型的软硬件协同设计案例。硬件上要抗干扰、低功耗，软件上要保证交易安全、响应迅速。两者缺一不可。
轨道交通支付系统，核心就三件事：
- 读卡：识别你的公交卡、手机NFC、甚至二维码
- 扣费：和后台服务器确认余额，完成交易
- 放行：控制闸机打开，让你通过
听起来简单？我当年第一次做地铁项目时，就栽在「读卡」这一步。闸机口电磁干扰大，读卡距离稍微远一点就失败。后来发现是天线匹配电路没调好——硬件问题，软件再优化也救不了。
核心要点：支付模块不是单纯的嵌入式系统，它涉及金融安全、实时控制、人机交互。软硬件必须从一开始就一起设计，而不是各干各的。
1.2 软硬件协同设计方法论
什么叫软硬件协同设计？我打个比方。
你想想看，盖一栋楼。硬件是钢筋水泥，软件是水电布线。传统做法是：先盖好楼，再凿墙布线。结果呢？墙也破了，线也走得不合理。
协同设计就是：盖楼之前，水电工和泥瓦匠坐在一起画图纸。哪里留孔，哪里走线，一次搞定。
具体到咱们的支付模块，方法论分四步：
- 需求分析：搞清楚要支持哪些支付方式、响应时间要求、功耗限制
- 功能划分：哪些功能用硬件实现（比如加密运算），哪些用软件实现（比如协议栈）
- 接口定义：软硬件之间的通信协议、数据格式、时序要求
- 联合调试：硬件打样回来，软件立刻跑起来，边测边改
我的经验：第二步「功能划分」最容易出问题。我曾经有个项目，把NFC协议解析全放在软件里，结果CPU跑不过来，闸机反应慢半拍。后来把部分解码逻辑移到硬件协处理器，问题才解决。
嗯，这里要注意：不是所有功能都适合用硬件实现。硬件开发周期长、改起来麻烦。软件灵活，但性能有限。怎么取舍？我一般遵循「二八原则」——80%的常规处理用软件，20%的关键瓶颈用硬件。
1.3 本课程项目目标与交付物
这门课不是光讲理论。咱们要真刀真枪做一个完整的支付模块原型。
项目目标很明确：
- 设计一个支持NFC刷卡 + 二维码扫码的闸机控制器
- 实现脱机交易（断网也能扣费，联网后同步）
- 响应时间控制在300毫秒以内（从刷卡到开闸）
- 整机功耗低于5W（工业级要求）
最终交付物包括：
| 交付物 | 说明 |
|---|---|
| 硬件原理图 + PCB | 主控选型、电源设计、NFC天线、二维码模组接口 |
| 嵌入式软件源码 | RTOS + 驱动 + 支付协议栈 + 人机界面 |
| 软硬件接口文档 | 寄存器定义、中断分配、DMA通道、时序图 |
| 测试报告 | 功能测试、压力测试、功耗测试、EMC测试 |
避坑指南：我曾经带过一个团队，大家埋头干了三个月，最后发现硬件和软件的接口定义不一致——软件以为中断号是5，硬件实际配的是7。结果联调时花了整整一周排查。所以，接口文档必须在设计阶段就定下来，并且双方签字确认。
好了，课程导论就到这里。下一章咱们开始搭开发环境，选主控芯片。记住一句话：好的开始是成功的一半，但好的设计文档是成功的另一半。