第四章：策略引擎层设计
好，咱们今天聊聊策略引擎层。这一层在Type-C协议栈里，说实话，是个承上启下的关键角色。我做了这么多年嵌入式，发现很多工程师容易忽略这一层，结果就是系统行为不稳定，各种奇怪的问题冒出来。
4.1 策略引擎的状态机模型
策略引擎的核心，说白了就是一个状态机。但这不是普通的状态机，它要处理的事情特别杂——既要管电源协商，又要管数据传输模式切换，还得处理各种异常情况。
我个人习惯把策略引擎的状态机分成三个层次：
- 顶层状态：系统级状态，比如空闲、协商中、运行中、错误处理
- 中间状态：协议相关状态，比如Source/Sink的电源角色、数据角色
- 底层状态：物理层状态，比如CC线状态、VBUS状态
你想想看，这三个层次之间怎么联动？嗯，这就是策略引擎要解决的核心问题。
核心状态机模型（简化版）
typedef enum {
PE_IDLE, // 空闲状态
PE_SRC_STARTUP, // Source启动
PE_SNK_STARTUP, // Sink启动
PE_SRC_NEGOTIATION, // Source协商
PE_SNK_NEGOTIATION, // Sink协商
PE_OPERATIONAL, // 正常运行
PE_ERROR_RECOVERY, // 错误恢复
PE_DEBOUNCE, // 去抖状态
PE_WAIT // 等待状态
} pe_state_t;我在项目中遇到过一个问题：状态机设计得太细，导致状态切换路径太多，测试覆盖率根本达不到。后来我学乖了，状态数量控制在10个以内，每个状态的进入条件和退出条件都写清楚。
4.2 策略决策流程
策略决策流程，说白了就是「遇到什么事，该怎么办」。这个流程我建议用事件驱动的方式来设计。
举个例子，当检测到CC线电压变化时：
- 先判断是attach还是detach事件
- 如果是attach，判断是Source还是Sink角色
- 根据角色决定下一步动作——Source要开始供电，Sink要请求电源
- 进入协商流程，处理PD消息
- 协商完成，进入运行状态
避坑指南
我曾经在决策流程里忘了加超时处理，结果设备插上后一直卡在协商状态。嗯，从那以后我每个决策点都加了超时机制，超时后要么重试，要么进入错误恢复。
决策流程里还有一个关键点：优先级。比如同时收到电源请求和数据传输请求，该先处理哪个？我的经验是：电源优先。因为Type-C的电源管理是基础，数据传输可以等一等。
4.3 与协议层的接口设计
策略引擎和协议层之间的接口，我建议设计得尽量简洁。接口太复杂，耦合度就高，后面改起来很痛苦。
我常用的接口设计思路是这样的：
| 接口方向 | 接口名称 | 说明 |
|---|---|---|
| 策略引擎→协议层 | pe_send_pd_message() | 发送PD消息 |
| 策略引擎→协议层 | pe_set_data_role() | 设置数据角色 |
| 策略引擎→协议层 | pe_set_power_role() | 设置电源角色 |
| 协议层→策略引擎 | pe_event_callback() | 事件回调 |
| 协议层→策略引擎 | pe_state_change() | 状态变化通知 |
你可能会问：为什么不用更复杂的接口？其实原因很简单——接口越简单，调试越容易。我记得有一次调试一个Type-C充电问题，就是因为接口太复杂，数据流追踪起来特别费劲。后来我把接口精简到5个，问题一下子就定位到了。
注意事项
接口设计时一定要考虑异步处理。策略引擎和协议层可能运行在不同的任务或中断上下文中，所以接口要支持异步调用。我建议用消息队列或者回调函数的方式来实现。
4.4 实战经验总结
最后分享几个我在实际项目中踩过的坑：
- 状态机不要嵌套太深：嵌套状态机看起来很酷，但调试起来想哭。我建议用扁平状态机，配合事件表来管理。
- 决策流程要可配置：不同产品对Type-C的行为要求不一样，比如有的要支持PD快充，有的只要基本充电。把决策参数做成可配置的，能省很多事。
- 接口要有错误码：别用布尔值返回成功失败，用枚举错误码。这样出了问题，看日志就知道是哪一步错了。
好了，策略引擎层的内容就这些。下一章咱们聊聊协议层的具体实现，到时候会涉及到PD消息的编解码，那个更有意思。