AutoSAR配置与实践（配置篇）RTE对Ports的支持 – C/S原理进阶
AutoSAR配置与实践（配置篇）RTE对Ports的支持 – C/S原理进阶
- 一、 Polling和Waiting类型的 C/S接口执行流程详解
-
- 1.1 Polling流程详解
- 1.2 Waiting流程详解
- 二、存储请求信息的数据形式
-
- 2.1 Polling 类型接口执行状态存储形式
- 2.2 Waiting类型接口执行状态存储形式
- 2.3 存储内容介绍
-
- 2.3.1 Client Queue
- 2.3.2 Server Queue
- 三、Waiting和Pooling类型的差异对比
- 四、相关接口函数原型及解析
传送门 点击返回 ->AUTOSAR配置与实践总目录
关于C/S接口的介绍，此前在第1.3章节 和第2.4章节 我们分别对C/S ports的常见类型和基本原理已经做了初步介绍，有需要同学可以再看下，作为本章节学习的基础。
由于同步接口相对简单且此前已介绍，本章节重点介绍异步C/S接口中的Polling和Waiting两类接口。
一、 Polling和Waiting类型的 C/S接口执行流程详解
C/S接口从结果查询的角度，可以分类Pooling和waiting两大类，分别表示Client主动查询和等待Server端的执行结果通知。
1.1 Polling流程详解
Polling类型的异步C/S接口在配置工具的配置点如下：
Asynchronous:异步CS通信
Polling: Client主动轮询结果方式
Client请求流程主要业务：设置业务请求标志，触发Server端runnable运行
Server runnable流程主要业务：管理Client请求(1:1或者N：1)的状态
Client 获取结果流程主要业务: 主动查询Server执行结果
Client 获取结果有以下几类:
- Server已执行完毕，反馈RTE_E_OK
- Server尚未执行完毕但未超时，反馈RTE_E_NO_DATA
- Server尚未执行完毕但已超时，反馈RTE_E_TIMEOUT
1.2 Waiting流程详解
Asynchronous: 异步CS通信
Waiting: Client被动等待Server通知的方式
Client请求流程主要业务：设置业务请求标志，触发Server端runnable运行
Server runnable流程主要业务：管理Client请求(1:1或者N：1)的状态，Server告知Client端业务完成或者超时
Client 获取结果流程主要业务: 进入Wait状态，等待Server端通知结果。
结束client等待的两种情况:
1.Server已执行完毕，给client发送事件
2.等待超时，系统给client发送超时事件
注意：
- Polling时机由client端SWC调用Rte_call时机决定
- 超时时间内（配置决定）Polling不到结果，则结果返回超时。
二、存储请求信息的数据形式
2.1 Polling 类型接口执行状态存储形式
2.2 Waiting类型接口执行状态存储形式
2.3 存储内容介绍
2.3.1 Client Queue
系统将为每个不同的client请求开辟一片区域（可以理解为全局变量，结构体类型），用于存储请求中的状态信息，其中：
WaitingTaskCount： 在等待的task数量（多client时每个client的get_result请求所映射task可能不同）
WaitingTaskList: 正在等待的task列表
Completed： 是否请求已处理完成
Out Data: 对应请求接口的输出参数，用于存放请求到的数据
Result: 请求的结果，是请求到了数据还是超时
2.3.2 Server Queue
系统将为C/S接口中的Server请求开辟一片区域（可以理解为全局变量，结构体类型），用于存储请求处理中的状态信息，其中：
ClientId: 用于管理N ：1多client结构中相应Client的ID；
Rte_Active: 是否存在请求标志，用于控制一次调用只触发一次Server runnable执行；
Input： 请求接口的输入参数，用于存放输入的数。
三、Waiting和Pooling类型的差异对比
四、相关接口函数原型及解析
传送门 点击返回 ->AUTOSAR配置与实践总目录