4、POS机关键任务分析：交易处理任务、刷卡/扫码任务、打印任务、通信任务、UI刷新任务的实时性需求
做POS机系统这么多年，我最大的体会就是：实时性不是玄学，是每一毫秒都要算清楚的账。你想想看，顾客在收银台前等着，收银员按了确认键，结果屏幕卡了3秒才出结果——这种体验，谁受得了？
今天咱们就来拆解一下POS机里那几个最关键的“硬骨头”任务。我习惯把它们分成五类：交易处理、刷卡/扫码、打印、通信、UI刷新。每一类任务的实时性要求都不一样，处理不好就会出大问题。
4.1 交易处理任务：心脏级别的实时性
交易处理任务，说白了就是POS机的“心脏”。它负责接收交易请求、校验数据、调用加密算法、生成报文、等待应答、解析结果。这个任务的实时性要求有多高？
核心指标：端到端延迟 ≤ 500ms（从刷卡到显示结果）
其中，交易处理任务本身的执行时间必须控制在 100ms以内，否则整个流程就会超时。
我记得有一次做某银行的认证测试，对方要求交易响应时间不能超过300ms。我们当时用的是一颗Cortex-M4的芯片，主频只有120MHz。一开始怎么调都差一点，后来发现是加密算法那块用了软件实现，换成硬件加密引擎后，直接降到了80ms。嗯，这里要注意：加密运算一定要用硬件加速，别指望CPU硬扛。
交易处理任务的优先级，我建议设置为最高优先级（优先级0）。为什么？因为它是整个系统的核心，一旦被抢占，整个交易流程就会卡住。我曾经见过一个项目，把打印任务的优先级设得比交易处理还高，结果每次打印小票时交易就超时——这显然是不对的。
4.2 刷卡/扫码任务：中断驱动的“快枪手”
刷卡和扫码任务，本质上是一个数据采集+解码的过程。刷卡器通过磁头读取磁道数据，扫码枪通过摄像头捕捉二维码图像。这两个任务的实时性要求，主要体现在“响应速度”上。
| 任务类型 | 响应时间要求 | 数据量 | 处理方式 |
|---|---|---|---|
| 刷卡任务 | ≤ 10ms（从刷卡到数据就绪） | 约200字节 | 中断驱动 + DMA |
| 扫码任务 | ≤ 50ms（从扫码到解码完成） | 约1-5KB（图像数据） | 中断驱动 + 硬件解码 |
我个人习惯把刷卡任务做成中断服务程序（ISR），因为刷卡器的数据是串行过来的，每来一个字节就要立刻收走，否则会丢数据。扫码任务稍微复杂一点，因为图像数据量大，如果让CPU去解码，那CPU就别干别的了。我建议用硬件解码模块，或者至少用DMA把图像数据搬到内存里，再开一个中等优先级的任务去处理。
避坑指南：我曾经遇到过一个问题——刷卡器在交易处理过程中突然触发中断，导致交易处理被中断了200μs。虽然200μs看起来不多，但交易处理任务里有一个加密运算的临界区，被中断后上下文切换开销反而更大。后来我把刷卡中断的优先级调低了一级，只在交易处理的空闲窗口里响应刷卡，问题就解决了。
4.3 打印任务：看似慢，实则不能拖
打印任务，很多人觉得它慢就慢呗，反正小票打印要几秒钟。但你想过没有？打印任务如果占用了CPU太久，其他任务就会饿死。
打印机的驱动方式有两种：一种是轮询方式，CPU不断查询打印机状态，直到打印完成；另一种是中断方式，打印机每打完一行就发一个中断，CPU再送下一行数据。我强烈建议用中断方式，原因很简单——轮询方式会把CPU锁死，其他任务根本没法运行。
打印任务的实时性要求其实不高，但它的执行时间很长。打印一张小票可能需要2-3秒，如果这期间CPU一直在忙打印，那UI刷新、通信应答都会受影响。我的做法是：把打印任务拆成多个小步骤，每打印一行就主动让出CPU，让其他任务有机会运行。
关键点：打印任务的优先级不要设太高，建议设为中等（优先级2或3）。
同时，打印任务中不要做任何阻塞操作，比如等待打印机就绪时，应该用信号量或事件标志来挂起任务，而不是死循环等待。
4.4 通信任务：不能丢，不能慢
通信任务负责和后台服务器交互，包括发送交易报文、接收应答、心跳保活等。这个任务的实时性要求，取决于通信协议和网络环境。
一般来说，通信超时时间在5-10秒之间。但注意，这个超时是端到端的，包括网络延迟、服务器处理时间、报文解析时间。如果通信任务本身处理得太慢，比如报文解析花了1秒，那留给网络的时间就只剩4秒了——万一网络波动一下，交易就超时了。
我建议通信任务使用独立的任务栈，并且栈空间要留足。为什么？因为通信协议栈（比如TCP/IP）通常需要较大的栈空间，如果和别的任务共用栈，很容易栈溢出。我曾经在调试一个项目时，发现通信任务偶尔会崩溃，查了三天才发现是栈空间不够，多分配了2KB就稳定了。
通信任务的优先级，我建议设为次高优先级（优先级1）。因为通信任务通常有超时机制，如果被长时间抢占，会导致超时重传，反而增加网络负担。
4.5 UI刷新任务：人机交互的“面子工程”
UI刷新任务，说白了就是让屏幕显示内容。这个任务的实时性要求，其实是最容易被低估的。很多人觉得“屏幕慢一点没关系”，但用户可不这么想——按了按键没反应，用户会以为机器死机了。
UI刷新任务的实时性要求，主要体现在两个方面：
- 按键响应延迟 ≤ 50ms：用户按下按键后，屏幕必须在50ms内给出反馈（比如按键高亮、页面跳转）。
- 动画流畅度 ≥ 30fps：如果UI有动画效果（比如支付成功后的对勾动画），刷新率不能低于30帧/秒。
我个人习惯把UI刷新任务放在最低优先级（优先级4或5）。为什么？因为UI刷新是“锦上添花”的任务，交易处理、通信这些才是“雪中送炭”。但要注意，UI刷新任务不能完全被饿死——如果其他任务一直占用CPU，屏幕就会卡死。我的做法是：在UI刷新任务里加一个定时器触发，每20ms强制刷新一次，即使其他任务再忙，也要给UI留出时间片。
注意：UI刷新任务中不要做任何耗时操作，比如加载图片、解析字体等。这些操作应该提前在初始化阶段完成，或者放到后台任务中异步处理。否则，一次刷新就可能卡住几十毫秒，整个系统都会感觉“卡顿”。
4.6 任务优先级总结
好了，说了这么多，咱们来总结一下这五个任务的优先级和实时性要求。我习惯用一张表来管理：
| 任务名称 | 优先级 | 最大允许延迟 | 关键约束 |
|---|---|---|---|
| 交易处理任务 | 0（最高） | 100ms | 加密运算必须硬件加速，临界区要短 |
| 通信任务 | 1 | 500ms | 独立栈空间，避免超时重传 |
| 刷卡/扫码任务 | 2 | 10ms（刷卡）/ 50ms（扫码） | 中断驱动，DMA传输，避免阻塞 |
| 打印任务 | 3 | 2-3秒（整体） | 拆分成小步骤，主动让出CPU |
| UI刷新任务 | 4（最低） | 50ms（按键响应） | 定时器触发，不做耗时操作 |
你可能会问：为什么刷卡/扫码任务的优先级比打印高？原因很简单——刷卡和扫码是交易的“入口”，如果入口堵住了，后面的交易处理根本没法开始。而打印是交易的“出口”，晚几秒打印小票，用户最多抱怨一句，但不会导致交易失败。
嗯，这就是我多年做POS机系统的一点心得。说白了，实时性调度就是一场“资源争夺战”，谁更重要，谁就优先拿到CPU时间。但别忘了，优先级高的任务不能无限霸占CPU，否则低优先级任务会饿死，整个系统反而会出问题。下一章，咱们聊聊具体的调度策略和代码实现。