【ISO14229_UDS_0x31服务详解】

最新推荐文章于 2024-03-04 12:38:06 发布
最新推荐文章于 2024-03-04 12:38:06 发布
阅读量1.3k 收藏 7
点赞数 1
分类专栏： ISO14229-UDS诊断服务介绍 文章标签： mcu
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43722921/article/details/132278695
版权

目录

1、0x31服务（RoutineControl，例程控制服务）

  Service description：
  0x31服务（RoutineControl，例程控制服务）被客户端用于执行定义的一系列步骤并且获取相关的结果。该服务有很大的灵活性，但典型的使用方法可能包括如下的功能：例如擦除内存，重置或者学习自适应值，运行自测试，覆盖正常的服务端控制策略以及服务端值随时间变化的功能。一般来说，0x31服务用于控制更复杂类型的输出，而0x2F服务(inputOutputControlByIdentifier)服务用于控制相对简单的输出(如，静态的)。
  0x31服务（RoutineControl，例程控制服务）被客户端用于：
  — 开启一项例程；
  — 停止一项例程；
  — 请求一项例程的执行结果；
  一项例程由一个2字节的例程标识符( routineIdentifier)来表示。
  以下内容详细讲述了引用了例程标识符(routineIdentifier)的开始例程，停止例程，并且请求例程结果的使用方法：
  开始例程
  在StartRoutine请求消息完成和第一个响应报文完成之间的一段时间内，如果响应消息是肯定的或否定的，则该例程应在服务端内存中启动，这表明请求已经执行或正在执行。
  例程可以是正在运行而不是正常运行代码的测试，也可以是正常运行代码使能的或者执行的例程。特别是在第一种情况下，可能需要使用0x10服务(DiagnosticSessionControl)在特定的诊断会话下切换服务端，或者在使用StartRoutine服务之前使用SecurityAccess服务解锁服务端。
  停止例程
  在StopRoutine请求消息完成和第一个响应报文完成之间的一段时间内，如果响应消息是肯定的或否定的，则该例程应在服务端内存中启动，这表明请求已经执行或正在执行。
  请求例程结果
  该子函数通过引用例程标识符(routineIdentifier)被客户端用于请求结果(如，退出的状态信息)，其结果由服务端内存中执行的例程产生。
  基于例程结果，其结果可以在stopRoutine子函数参数(如正常/异常的Exit With Results)中的肯定应答报文中接收，请求例程结果的子函数应该被使用。routineResults的一个例子可以是服务端收集的数据，由于服务端性能限制，这些数据在例行执行期间是无法传输的。

2、请求报文格式

2.1 请求报文定义

  下表定义了请求报文的格式：

字节序号参数值约定字节值
#1RoutineControl Request SIDM0x31
#2

sub-function = [
       routineControlType ]		M0x00 - 0xFF

#3
#4		routineIdentifier [] = [
         byte#1 (MSB)
         byte#2 (LSB)
M
M
0x00 – 0xFF
0x00 – 0xFF

#5
.
.
#n		routineControlOptionRecord[] = [
               routineControlOption#1
               .
               .
               routineControlOption#m ]
C/U
.
.
C/U
0x00 - 0xFF
.
.
0x00 - 0xFF

  C：此参数是用户可选的，用于子函数参数startRoutine和stopRoutine。

2.2 请求报文中子函数参数定义

  该服务使用子函数参数用来区分例程的控制类型。子函数参数的解释和使用方法见下表：

字节序号参数值约定
0x00ISOSAEReserved
ISO保留		M
0x01startRoutine
该参数表示服务端启动了由控制标识符指定的例程		M
0x02stopRoutine
该参数表示服务端停止由控制标识符指定的例程		M
0x03stopRoutine
该参数表示服务端返回由控制标识符指定例程执行的结果		M
0x04 - 0x7FISOSAEReserved
ISO保留		M

2.3 请求报文中数据参数定义

  该服务在请求报文中的数据参数定义如下表所示：

定义
routineIdentifier
该参数表示服务端内部例程
routineControlOptionRecord
该参数记录包含了
— 例程进入选项参数，其具体描述了例程的启动条件(如，timeToRun，startUpVariables等)
— 例程退出选项参数，其具体描述了例程的停止条件(如，timeToExpireBeforeRoutineStops变量等)

3、肯定应答报文

3.1 肯定应答报文格式定义

字节序号参数值约定字节值
#1RoutineControl Response SIDM0x71
#2routineControlTypeM0x00 - 0x7F

#3
#4		routineIdentifier [] = [
        byte#1 (MSB)
        byte#2 (LSB) ]
M
M
0x00 - 0xFF
0x00 - 0xFF
#5routineInfoC10x00 - 0xFF

#6
.
.
#n		routineStatusRecord[] = [
        routineStatus#1
        .
        .
        routineStatus#m ]
U
.
.
U
0x00 - 0xFF
.
.
0x00 - 0xFF

  C1：RoutineInfo该参数的字节指定了一个方案(例如，StartRoutine, StopRoutine, RequestRoutineResults)，以允许通用的外部测试设备处理任何例程。即使ISO/SAE定义的routineStatusRecord的大小等于“0”数据字节，该参数对于由ISO/SAE规范(例如ISO 27145-3, SAE J1979-DA, ISO 26021)定义的任何例程也是必需的。对于routineStatusRecord完全由汽车制造商定义的例程，是否支持该参数，这个功能是可选的。该字节的定义应留给车辆制造商。
  U：RoutineStatusByte #m只包含在routineStatusRecord[]中，如果车辆制造商指定了routineIdentifier (RID)。

3.2 肯定应答报文数据参数定义

  该服务肯定应答报文中使用到的数据参数的定义见下表：

定义
routineControlType
该参数的bit 6 - 0表示请求报文中的子函数参数。
routineIdentifier
该参数表示请求报文中的routineIdentifier。
routineInfo
RoutineInfo字节编码是特定于汽车制造商的，并为汽车制造商提供了一种机制，该机制可以支持基于该返回值的所有实现例程(例如，如果需要stopRoutine或requestRoutineResults)的通用外部测试设备处理。
routineStatusRecord
该参数记录被用于给到客户端：
— 例程开始后服务端状态的附属信息；
— 例程停止后服务端状态的附属信息(例如，总运行时间、停止前例程生成的结果等)。
— 例程的结果(退出状态信息)，该例程先前已在服务端中停止

4、支持的否定应答码(NRC_)

  本服务实施了如下否定响应代码，下表记录了每个否定应答码发生的情况，如果服务端在错误场景使用了该服务，则应使用如下列出的否定响应码。

NRC描述
0x12sub-functionNotSupported
请求的子函数总体不被支持或者不被RoutineIdentifier所支持时，会发送该NRC
0x13incorrectMessageLengthOrInvalidFormat
请求报文长度不正确时，会发送该NRC
0x22conditionsNotCorrect
当请求的RoutineControl不被满足时，会发送该NRC
0x24requestSequenceError
以下情况会发送该NRC：
— 例程当前处于活动状态，当接收到’startRoutine’子函数时无法重新启动(给定例程是否可以在活动时重新启动取决于车辆制造商)；
— 当接收到’stopRoutine’子函数时，例程当前没有活动；
— 当收到’requestRoutineResults’子函数时，例程结果不可用(例如，请求的routineIdentifier从未启动)；
0x31requestOutOfRange
以上情况会会发送该NRC：
— 服务端不支持请求的routineIdentifier；
— 用户可选的routineControlOptionRecord包含请求的routineIdentifier的无效数据；
0x33securityAccessDenied
客户端发送了一个请求，其带有有效安全的数据标识符，并且服务端的安全特征是激活的。
0x72GeneralProgrammingFailure
如果服务端在执行访问服务端内部存储器的例程时检测到错误，则应返回此NRC。例如，当例程擦除或编程永久存储器设备(例如闪存)中的某个存储器位置时，对该存储器位置的访问失败。

  0x31服务(RoutineControl，例程控制服务)的否定应答码(NRC)具体处理过程。
在这里插入图片描述

5、0x31服务（RoutineControl，例程控制服务）案例说明

  Example #1：sub-function = startRoutine
  本小节规定了在服务端中启动一个例行程序的测试条件，在技术人员摆动被测系统的所有线束连接器时，持续(尽可能快地)间歇地测试所有输入和输出信号。routineIdentifier通过routineIdentifier 0x0201引用这个例程。
  测试条件：ignition = on, engine = off, vehicle speed = 0 [kph]；
  客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  0x31服务(RoutineControl，例程控制服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1RoutineControl Request SID0x31
#2

sub-function = startRoutine,
            suppressPosRspMsgIndicationBit = FALSE		0x01

#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01

  0x31服务(RoutineControl，例程控制服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1RoutineControl Response SID0x71
#2routineControlType = startRoutine0x01
#3
#4
#5		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)
routineStatusRecord [ routineStatus#1 ] = vehicle manufactuer specific		0x02
0x01
0x32

  Example #2：sub-function = stopRoutine
  本小节规定了在服务端中停止一个例行程序的测试条件，在技术人员摆动被测系统的所有线束连接器时，持续(尽可能快地)间歇地测试所有输入和输出信号。routineIdentifier通过routineIdentifier 0x0201引用这个例程。
  测试条件：ignition = on, engine = off, vehicle speed = 0 [kph]；
  客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  0x31服务(RoutineControl，例程控制服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1RoutineControl Request SID0x31
#2

sub-function = stopRoutine,
            suppressPosRspMsgIndicationBit = FALSE		0x02

#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01

  0x31服务(RoutineControl，例程控制服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1RoutineControl Response SID0x71
#2routineControlType = stopRoutine0x02
#3
#4
#5		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)
routineStatusRecord [ routineStatus#1 ] = vehicle manufactuer specific		0x02
0x01
0x30

  Example #3：sub-function = requestRoutineResults
  这个示例展示了如何在例程完成后获取结果值。当技术人员对测试系统的所有线束连接器上“摆动”时，程序已经连续地(尽可能快地)间歇地测试了所有输入和输出信号。引用这个例程的routineIdentifier是0x0201。试验条件： ignition = on, engine = off, vehicle speed = 0 [kph]。
  客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  0x31服务(RoutineControl，例程控制服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1RoutineControl Request SID0x31
#2

sub-function = requestRoutineResults,
            suppressPosRspMsgIndicationBit = FALSE		0x03

#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01

  0x31服务(RoutineControl，例程控制服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1RoutineControl Response SID0x71
#2routineControlType = requestRoutineResults0x03
#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01
#5
#6
.
.
#n		routineStatusRecord [ routineStatus#1 ] = Vehicle Manufactuer Specific
routineStatusRecord [ routineStatus#2 ] = inputSignal#1
.
.
routineStatusRecord [ routineStatus#m ] = inputSignal#m		0x30
0x33
.
.
0x8F

  Example #4：sub-function = startRoutine with routineControlOption
  本条款规定了在变速箱控制单元中启动例行程序的测试条件，以在特殊模式下标定某一档位的换挡。挡位可以是#1到#20之间的任意档位，模式可以是台架、独立和车载。RoutineIdentifier通过routineIdentifier 0x0202引用这个例程。
  测试条件： ignition = on, engine = off, vehicle speed = 0 [kph].
  客户端通过将suppressPosRspMsgIndicationBit(子函数参数的第7位)设置为“FALSE”(“0”)来请求响应消息。
  0x31服务(RoutineControl，例程控制服务)的请求报文使用如下，由客户端发往服务端：

字节顺序Description字节值
#1RoutineControl Request SID0x31
#2

sub-function = startRoutine,
            suppressPosRspMsgIndicationBit = FALSE		0x01

#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01
#5
#6		routineControlOption#1 [ selected gear ] = vehicle manufacturer specific
routineControlOption#2 [ test condition ]		0x06
0x01

  0x31服务(RoutineControl，例程控制服务)的应答报文使用如下，由服务端发往客户端：

字节顺序Description字节值
#1RoutineControl Response SID0x71
#2routineControlType = startRoutine0x01
#3
#4		routineIdentifier [ byte#1 ] (MSB)
routineIdentifier [ byte#2 ] (LSB)		0x02
0x01
#5
#6
.
.
#n		routineStatusRecord [ routineStatus#1 ] = Vehicle Manufactuer Specific
routineStatusRecord [ routineStatus#2 ] = response time
.
.
routineStatusRecord [ routineStatus#m ] = inputSignal#m		0x32
0x33
.
.
0x8F

返回UDS诊断服务功能单元介绍目录

三星小卤蛋
关注
  • 1
    点赞
  • 踩
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
汽车UDS诊断之例程控制服务（0x31）深度剖析
心骗小白话的博客
06-23 1万+
1.英文术语 目录 1.英文术语
SS-ISO_14229-3_2012.zip_14229_14229-3_2012_ISO 14229_uds
09-24
道路车辆uds诊断，14229-3-2012标准
UDS_$31服务，学习笔记
最新发布
m0_50837859的博客
03-04 183
【代码】UDS_$31服务，学习笔记。
UDS系列-31服务（Routine Control）
诊断协议那些事儿's blog
06-18 2419
客户端使用 RoutineControl(例程控制)服务执行指定的步骤顺序并获取任何相关结果。该服务具有较大的灵活性，但一般应用可以包括清除内存、重置或学习白适应数据、运行白检、覆盖正常的服务器控制策略和控制服务器值随时间而变化，以及预定义序列(如关闭敞篷车顶)等。在一般情况下，将该服务用于控制输出时，该服务可用于更为复杂类型的控制，而 inputOutputControlByldentifier (按标识符的输入输出控制)却用于相对简单(如静态)的输出控制.
UDS诊断系列之十三 例程控制（31）服务 上
Chenglim的博客
09-04 5087
例程控制服务主要功能是由客户端请求服务端开始、结束一个例程，以及获取例程执行的状态和结果。
UDS诊断（ISO14229-1） 31服务
m0_56208280的博客
01-15 2981
31服务，即 RoutineControl（例程控制）服务，该服务允许客户端使用 RoutineControl（例程控制）服务执行指定的步骤顺序并获取任何相关结果。
UDS统一诊断服务
05-07
ISO 14229-1道路车辆—统一诊断服务 应用层协议
【UDS】ISO14229之0x31服务
weixin_48498880的博客
11-05 6238
RoutineControl”，例程控制该服务执行指定的步骤操作并获取相关结果，相比0x2F服务，具有较大的灵活性，可用于较为复杂类型的控制。一般应用包括清除内存（多数用在更新ECU软件），重置或学习自适应数据，运行自检，方向盘角度零点标定等。0x31服务在实际运用中要比0x2F复杂些，但那又怎样，通过本章讲解是否对该服务熟悉那么一勾勾呢？下一章 DTC控制 0x85服务见！->返回总目录
UDS 服务 Service 0x31 - RoutineControl
usstmiracle的博客
10-22 1万+
这里对 RID 的三种控制类型做一个详细的介绍：启动 RID 如果对诊断请求的响应是肯定或否定，则表明该请求已被执行或正在进行中，例程将从 StartRoutine 请求消息完成到第一响应消息完成之间的某个时间在服务器的内存中启动。如果是动态的，则数据长度应为在参数currentDataLength中提供，该参数保存字节的长度（以字节为单位）最后一个dataIn参数。如果是动态的，则datalength应该在参数currentDataLength中提供，该参数持有最后一个dataln参数的字节长度。
UDS_RoutineControl(0x31)服务
weixin_68852042的博客
11-08 219
服务 Service 0x31 RoutineControl 是用于对主机厂定义的一些特定程序的控制操作（启动程序、停止程序、请求运行结果）的服务。它可以让诊断仪对（如ECU）中的某些例程进行控制，例如擦除内存、检查编程依赖性、执行OBD测试等。与2F服务相比，2F的基本功能都可以通过31服务来实现，不过用2F来实现的功能来用31服务，未免有点大材小用，因此31服务则是用于更复杂的输入输出控制场景，而2F服务则可用于较为简单常见的输入输出控制场景。
【UDS诊断】——0x31服务
热门推荐
LOVE135149的博客
02-21 3万+
文章目录一、服务概述二、报文1.请求报文定义2.肯定响应3.报文讲解3.1格式及内容3.2举例 19服务作用是允许外部诊断仪（Client）通过该服务读取存储在ECU芯片内的故障码（DTC）状态信息 一、服务概述 二、报文 1.请求报文定义 2.肯定响应 3.报文讲解 3.1格式及内容 发 送： 19 +02+DTCStatusMask（状态掩码） 正响应： 59+02+DTCStatusAvailabilityMask（ECU支持的状态掩码）+DTC-状态位 3.2举例 ①：DTC DIDs(随便举的
UDS诊断服务列表.pdf
11-14
介绍诊断和通信管理功能单元、数据传输功能单元、存储数据传输功能单元、输入输出控制功能单元、例行程序功能单元、上传下载功能单元以及ISO15031-5中具体的每个服务的详细总结。
ISO 14229-4.zip_14229-4_ISO 14229_uds_uds 14229_uds诊断
07-15
诊断参考文档 汽车控制器 UDS 14229-4
ISO14229(2006).zip_Bootloader_UDS ISO14229_UDS14229协议_uds_汽车UDS
07-14
UDS 协议文件，可以供在CAN、Bootloader以及汽车电子的设计时参考
ISO14229_iso14229中文_iso14229_UDS协议中文
06-01
汽车CAN总线的UDS协议中文版可以深入学习
ISO 14229-3.zip_ISO 14229-3_ISO-14229_UDS ISO_uds_诊断uds
07-14
诊断参考文档 汽车控制器 UDS 14229-3
《UDS协议从入门到精通》系列——图解0x31：例行程序控制
车载系统攻城狮
11-01 1461
一文详解UDS中最灵活的服务0x31-例程控制，图解+示例快速搞懂如何使用！！
[UDS] --- RoutineCommunicationControl 0x31
M2嵌入式
10-30 417
client端使用RoutineControl服务执行定义的步骤序列并获取任何相关结果。该服务具有很大的灵活性，典型的用法包括擦除内存，复位或学习自适应数据，运行自检，覆盖正常服务器控制策略以及控制服务器值随时间变化等功能。预定义的序列（例如：关闭的敞篷车顶）等等。通常，当用于控制输出时，此服务用于更复杂的类型控制，而inputOutputControlByIdentifier用于相对简单（例如：静态）的输出控制。
跟我学UDS(ISO14229) ———— 0x31(RoutineControl)
永远的菜鸡小詹的博客
06-24 8813
  客户端请求启动/停止服务器中的例程或请求例程结果。客户端使用 RoutineControl 服务来控制 RID，RID 由两字节的例程标识符标识。具体的控制类型有以下三种：第一种： 启动 RID；第二种： 停止 RID；第三种： 查询 RID 执行结果。这里对 RID 的三种控制类型做一个详细的介绍： 启动 RID  如果对诊断请求的响应是肯定或否定，则表明该请求已被执行或正在进行中，例程将从 StartRoutine 请求消息完成到第一响应消息完成之间的某个时间在服务器的内存中启动。例程可以是运行，
iso-14229_14229_uds协议栈_uds-iso-14229_iso14229文档_iso+14229_源码.zip
06-25
### 回答1： iso-14229是一项用于汽车电子系统通信的协议，其全称为ISO14229 Unified Diagnostic Services（UDS）on Controller Area Network（CAN）。该协议旨在为车辆的诊断、维护和修复提供标准化的方法。ISO 14229定义了诊断服务和通信的标准化消息格式，包括诊断数据、错误码、故障清除等，以使不同车辆的系统实现得到统一和互操作性。 ISO14229 UDS协议栈是用于实现ISO 14229诊断协议的软件组件。该协议栈的实现可分为物理层和软件层两个部分，其中物理层是指使用CAN总线对车辆的执行单元进行通信，而软件层则是指实现ISO 14229标准的协议堆栈。该协议栈具有标准化、可重用和可配置的特点，可在不同的客户平台上使用。 ISO 14229的文档是对该协议的规范和说明，包括协议的基本架构、消息格式、错误码表、会话层和传输层的细节等。该文档是实现ISO 14229协议的必要依据，可用于开发UDS协议栈的开发人员和车辆诊断工程师。 源码.zip则是UDS协议栈的实现源代码，包括物理层和软件层代码。开发人员可根据该源码了解UDS协议栈的实现细节和技术实现，并根据需求进行二次开发。 综上所述，ISO-14229_14229_UDS协议栈_UDS-ISO-14229_ISO14229文档_ISO 14229_源码.zip等组件，是用于实现汽车电子系统诊断的标准化协议，可为车辆的维护和修复提供规范的方法。开发人员和车辆诊断工程师可根据这些组件进行UDS协议栈的开发和实现。 ### 回答2： ISO-14229是用于诊断汽车电子控制单元（ECU）的标准协议。该协议旨在提供一种标准化的方法，让技术人员可以使用相同的工具和流程诊断不同制造商的汽车。 14229 UDS是该标准的通信协议栈。UDS指协议栈中定义的通用诊断服务，该服务可用于访问ECU的内部数据和状态。ISO14229文档提供了UDS协议栈的详细规范，以及相关的数据格式和命令集合。 此外，文档和源代码可以帮助工程师实现符合ISO-14229标准的诊断工具或ECU，提高汽车诊断系统的质量和效率。源码.zip则是UDS协议栈的代码包。 总之，ISO-14229标准和UDS协议栈提供了一种标准化的、可靠的汽车诊断协议。它们有助于提高汽车技术人员的工作效率，同时减少汽车诊断工具和软件的开发成本。 ### 回答3： ISO-14229是一种用于汽车电子系统的通讯协议。它定义了诊断通信的规范和协议，允许车辆厂商和供应商使用这些规范和协议来开发和测试车载电子控制单元。其中，UDS协议栈是实现ISO-14229的关键技术之一，能够为客户端提供远程访问ECEs的可能性。 ISO-14229规定了接口：UDS（Unified Diagnostic Service），用于与电子控制单元（ECU）之间进行通讯。 UDS协议栈则实现了UDS协议的接口，可以自动进行诊断和测试，发生故障时还能产生错误报告。 相应地， ISO14229文档描述了在ISO14229-1文档中定义的UDS协议的特定应用，与ISO15765-2的特定要求相结合。 它还包括了EVITA Light文档中的安全方面。 源码.zip文件则包含了UDS协议栈的源代码，可以在开发与应用中使用，实现对汽车电子控制单元的简便对话操作。 总之，ISO-14229及其UDS协议栈实现了车载控制电子单元的标准化通讯，可简化车辆诊断和维护过程，提高效率和可靠性。同时，相应的规范、文档和源代码也为相关人员提供了方便和支持。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值