DC-3:c基础

需要注意的知识点:

于取余运算符,结果的符号和%左边的那一个相一致。

         Ex:5%8    余数是5
                 -5%3   余数是 –2    

                 5%-3  余数是 2

一些编译中,有些程序是按照一定规则自动完成的,不需要我们操作。

         'A' + 1 + 0.5   左侧三个数相加,首先会将A转成int类型,即为65,再算65+0.5时,会将65转换成double类型

         得到最后的结果66.5.  数据参加运算前要进行下列转换: char ,short->int ,float -> double ;混合运算时数据           类型由低级-->高级:int,unsigned,long,double。  以上操作被称为隐式转换。

          符号的优先级在这儿就不再累述。

增自减是我们用的很多的一个运算,i++;i--;++i;--i;在进行算术运算的时候,要区别windows下和Linux,对于           Windows来说,程序运行会将所有的++i(--i),先一步进行运算,再进行整个式子的运算,最后再执行i++(i-                  -);例如,int i = 8 ;   y= (++i)  +  (i++)  +  (++i),Windows下算法为10+10+10=30,Linux下算法为                                9+9+10=28。楼主起初猜想可能是数据没有被刷新导致i的值有时候是没有变化的。就像昨天那个缓存区的问              题一样,没有刷新,打印出来的值才会一样。其实,不同的编译器对于式子的编译时不一样,导致最后的结                果不一样。在java中编译器对于i =i++,相当于temp = i ; i = i+1 ; i = temp。

于switch语句,后面接的或者结果必须是数字或者字符。

sizeof()括号中的无论是什么,都不会被编译,在这句命令,只会转成相应的类型。

于像if一样的判断表达式,只有0才是假,所有非0的都为真。


       

   


<think>我们正在分析TCPC-DPM的SrcCap日志,以理解充电协商过程。TCPC(Type-C Port Controller)是USB Type-C端口控制器,DPM(Dynamic Power Management)是动态电源管理。在USB PD(Power Delivery)协议中,SrcCap(Source Capabilities)是源端(如充电器)发出的能力声明,告知设备(如手机或笔记本)它能够提供的电源配置(电压、电流等)。 根据引用[3],VIN-DPM(输入电压动态电源管理)在充电器管理IC中扮演重要角色,它管理输入电源(如适配器)并为电池充电。在PD协商中,源端会发送多个SrcCap报文,设备端根据这些信息请求合适的电源配置。 在PD 3.0协议中,源端可能发送多个SrcCap报文(如SrcCap1, SrcCap2等),以提供不同的电源配置选项。设备端通过Request报文请求其中一个配置。整个协商过程涉及多个步骤,包括能力的声明、请求和确认。 分析日志时,我们需要关注: 1. SrcCap报文的内容:包括电压、电流、功率以及是否支持PPS(Programmable Power Supply)等。 2. 报文发送的顺序:源端可能先发送一个基础的能力集(SrcCap1),再发送扩展的能力集(SrcCap2),例如包含PPS档位。 3. 设备端的响应:设备端会发送Request报文,选择其中一个配置。 下面我们通过一个具体的日志分析示例来解读: 假设日志片段如下: ``` [TCPC] SrcCap1: 5V/3A, 9V/3A, 15V/3A [TCPC] SrcCap2: PPS: 3.3-11V/5A [TCPC] Device Request: 9V/3A [TCPC] Accept ``` 步骤解读: 1. 源端首先发送SrcCap1,声明三个固定档位:5V/3A, 9V/3A, 15V/3A。 2. 源端再发送SrcCap2,声明一个PPS档位:电压范围3.3V-11V,最大电流5A。 3. 设备端选择9V/3A的固定档位,并发送Request。 4. 源端接受请求(Accept),协商完成。 如果设备端支持PPS,它可能会选择PPS档位,例如: ``` [TCPC] Device Request: PPS 5V/3A ``` 在分析日志时,还需要注意: - 每个SrcCap报文可能包含多个电源对象(Power Data Objects, PDO)。每个PDO代表一种电源配置。 - 固定档位PDO(Fixed Supply PDO)和PPS PDO(Augmented PDO with PPS)有不同的结构。 - 设备端在Request中会指定所选PDO的索引(从1开始)或PPS的参数(电压、电流)。 为了更深入地理解,我们可以用数学表达式描述PPS的电压和电流范围。设PPS档位的电压范围为$[V_{\min}, V_{\max}]$,最大电流为$I_{\max}$,则设备可以请求任意电压$V \in [V_{\min}, V_{\max}]$,电流$I \in [0, I_{\max}]$,但受限于功率$P = V \times I \leq P_{\max}$($P_{\max}$由源端设定)。 在日志中,SrcCap2的PPS档位通常表示为: ``` PPS: <min_voltage>V-<max_voltage>V/<max_current>A ``` 引用[1]中提到的DPM_Report枚举类型,在充电协商过程中,DPM模块可能会生成报告,例如: - DPM_Report_DPC_STARTED:处理链(可能是协商过程)开始。 - DPM_Report_DPC_STOPPED:处理链结束。 - DPM_Report_DPC_ASSERT:检测到异常。 - DPM_Report_NOTIFY_DPC_RESULT:处理链有结果(如协商成功)。 这些报告可以帮助我们了解协商过程中的状态变化。 因此,在分析日志时,我们可以结合这些报告来理解协商过程。例如,如果看到DPM_Report_DPC_ASSERT,则说明协商过程中出现了异常。 总结分析步骤: 1. 识别日志中的SrcCap报文,解析每个PDO(包括固定档位和PPS档位)。 2. 观察设备端Request报文,看选择了哪个PDO(固定档位索引或PPS参数)。 3. 关注DPM报告,了解协商过程中的状态(开始、结束、异常等)。 4. 如果协商失败,检查是否有异常报告(如DPM_Report_DPC_ASSERT)或错误码。 通过以上步骤,我们可以解析TCPC-DPM日志并理解充电协商过程。 §§相关问题§§ 1. 如何从日志中识别PPS协商失败的具体原因? 2. 在USB PD协议中,SrcCap报文的结构是怎样的? 3. 如何通过DPM报告诊断充电协商中的异常? 4. 设备端在什么条件下会选择PPS档位而非固定档位?</think>### TCPC-DPM SrcCap日志解析与充电协商过程解读 #### 一、SrcCap日志结构解析 在USB PD协议中,SrcCap(Source Capabilities)是电源(Source)向设备(Sink)宣告供电能力的报文。日志中的`SrcCap1`、`SrcCap2`表示多组能力声明,其数学表达为: $$ \text{SrcCap}_n = \left\{ \text{PDO}_1, \text{PDO}_2, \cdots, \text{PDO}_k \right\} $$ 其中每个**电源数据对象(PDO)** 包含: 1. **电压/电流档位**:固定电压(如5V/3A)或PPS可调电压(如3.3-20V) 2. **协议标志位**:标识是否支持PPS、PD3.0等特性 3. **最大功率限制**:$P_{\max} = V_{\text{nom}} \times I_{\max}$ 引用[1]中的`DPM_Report_DPC_INFO`报告会记录这些能力宣告事件[^1]。 #### 二、典型协商流程分析 ```mermaid sequenceDiagram participant Source as 电源(TCPC) participant Sink as 设备(DPM) Source->>Sink: SrcCap1 (基础PDO) Sink->>Source: Request (选择PDO) alt 支持PPS Source->>Sink: SrcCap2 (PPS PDO) Sink->>Source: PPS_Request (动态电压请求) Source->>Sink: Accept (确认) else 不支持PPS Source->>Sink: Reject (拒绝) end Note right of Sink: DPM_Report_NOTIFY_DPC_RESULT[^1] ``` ##### 关键阶段解读: 1. **初次能力宣告(SrcCap1)** - 电源发送固定电压档位(如5V/3A, 9V/2A) - 日志示例:`SrcCap1: FIXED[5V/3A, 9V/2A]` 2. **PPS能力宣告(SrcCap2)** - 当设备发送包含`GET_PPS_STATUS`的Request后触发[^4] - 日志特征:`SrcCap2: PPS[3.3-11V/5A]` - 电压范围精度需满足$ \Delta V \leq \pm1\% $[^3] 3. **动态电压协商** - 设备发送`PPS_Request`指定目标电压$V_{\text{target}}$ - 数学关系:$V_{\text{target}} \in [V_{\min}, V_{\max}]$ - 电源响应`Accept`或`Reject`(受温度/线缆影响)[^3] #### 三、PPS协商失败诊断 当SrcCap2未正常公布PPS档位时,检查日志中以下关键点: 1. **设备请求类型** ```log [DPM] Request: RDO[PDO2] // 选择固定档位 [DPM] Request: PPS[5.2V/3A] // 正确触发PPS协商 ``` 2. **环境监测异常** - 若伴随`DPM_Report_DPC_ASSERT`[^1],通常表示: $$ \left| \frac{dT}{dt} \right| > 3℃/min \quad \text{或} \quad \Delta V_{\text{out}} > 0.1V $$ - 触发保护机制屏蔽PPS[^3] 3. **协议超时事件** - PPS响应需在$ t_{\text{resp}} < 20\text{ms} $ - 超时日志:`PD_ERR: PPS_TIMEOUT` #### 四、日志分析实例 **成功PPS协商:** ```log [TCPC] SrcCap1: FIXED[5V/3A, 9V/2A, 15V/1.5A] [DPM] Request: RDO[PDO2] // 选择9V档位 [TCPC] SrcCap2: PPS[3.3-11V/5A] // 公布PPS能力 [DPM] PPS_Request: 5.2V/3.2A [TCPC] Accept // 协商成功 [DPM] Report: NOTIFY_DPC_RESULT // 结果上报[^1] ``` **PPS协商失败:** ```log [TCPC] SrcCap1: FIXED[5V/3A] [DPM] Request: RDO[PDO1] // 缺失SrcCap2表明未触发PPS流程 [DPM] Report: DPC_ASSERT(ERR_PPS_UNSUPPORTED) // 异常报告[^1] ``` ### 根本问题定位 $$ \text{PPS失败率} \propto \frac{ \text{温度波动} \times \text{线缆阻抗} }{ \text{协议兼容性} } $$ 主要瓶颈在于**早期PD控制器固件**与**PPS精密电压调节**的匹配冲突[^3][^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值