Autosar bswm 代码分析记录

汽车电子笔记

已于 2022-06-21 20:55:53 修改

阅读量1k

点赞数 3

分类专栏： Autosar CP 文章标签： mcu

于 2022-06-21 17:11:56 首次发布

本文链接：https://blog.csdn.net/xinyelaozhang/article/details/125394927

版权

Autosar CP 专栏收录该内容

3 篇文章 3 订阅

订阅专栏

1.总述

BswM 下本身分为 modeArbitration ，modeControl， general 三大配置组

1. modeArbitration

arbitration 主要用于条件判断的搭建，类比C 语言中中 if 判断条件。其下有四个配置组：

logicExpressions,
设置各种条件（modeConditions）的逻辑组合，与或非异或等
modeConditions,
设置各种基础判断条件，requestPort与状态量的（等于不等于大于小于）关系
RequestPorts，
设置各种port 及其状态量
标准模块中在这个配置组里面都有各自对应的 port 和其状态量（如Comm模块和其各种CommunicationMode）
除了标准模块外，用户还可以定义自己的port 口，用于后续的条件判断（modeCondtions 中）
Rules，
连接判断条件和其处理操作

2. modeControl

主要建立各种处理操作。其下也有四个配置组

Actions，
主要设置的动作是对前面RequestPorts 的状态量操作，timer 操作，也可以通过callout 函数编写自己的处理
ActionLists，
设置Actions 的组合，因为某些条件满足后，需要做很多不同的处理操作
在生成的代码中，一个actionlist生成一个函数，其中包含配置的 action 子函数
RteModeRequestPorts，
连接需要关联的Rte port
SwitchPorts，
没有用过

3. general

功能模块或接口的使能配置，schedule 函数的调度周期之类的

4. 代码分析

api 函数分析，bswm 的 api 函数主要分为三类

初始化函数，BswM_Init （一般放置在EcuM_StratupTwo 中）
主调函数， BswM_MainFunction
模块的同步函数
- 标准模块的状态通知，如 BswM_ComM_CurrentMode
- 自定义的状态通知，如 BswM_RequestMode

因为对 modeRequest的处理有立即处理的（immediate），和延迟处理（Deffered），在可抢占式的os 中可能出现函数的重入场景。这也是bswm 的模块函数复杂的地方。
另外，一个modeRequest 可能在多个 Rules 中作为判断条件，因此一个modeRequest 的状态变化可能引发多个actionList 的执行。这也是造成bswm 函数复杂的另一个地方。
bswm 代码中用了分层的方式来处理上述场景需求
1. 当 Generic request 发生后，先转化成 ModeRequestQueue中的记录
```
FUNC(void, BSWM_CODE) BswM_RequestMode
(
    BswM_UserType requesting_user,  /*The user that requests the mode.*/
    BswM_ModeType requested_mode    /*The requested mode.*/
)


FUNC(void, BSWM_CODE) BswM_ImmediateModeRequest
(
	uint8 start, 			/*Start Value Of Immediate User Index.*/
	uint8 end				/*End Value Of Immediate User Index.*/
)
```
  当请求的user Id 跟 BswM_GenericMapping[] 中某个元素的 ExternalId 一致时，则将该元素的immediateUser_start/end 作为索引，将ModeRequestQueue[] 记录为Queued。
2. 将 ModeRequestQueue 中的记录，根据 Rules 转化成 ActionListQueue 中的记录，并执行对应的actionlist
```
FUNC(void, BSWM_CODE) BswM_ProcessQueuedRequests(void)
```
  在 ModeRequestQueue [] 中查找有记录（Queued）的元素，用其index 值在 BswM_ImmediateUser 中找到对应的元素。然后根据ImmediateUser 对应的Rules 检查，将需要执行的actionlist 记录到 ActionListQueue 中，然后进行执行。
3. 一个modeRequest 对应多个Rules, 但是为甚么中间要多加一级 ImmediateUser？
  
  自己的理解，主要是考虑到多个Rules 本身的排序是不连续的，所以多使用一级 ImmediaimmteUser。
  外部发出请求的User 对应多个ImmediaimmteUser，每个ImmediaimmteUser 再对应多个Rules, 通过这种方式来实现管理。
  或许这个理解是错误的，只是自己的理解，并非最初的设计意图。
  同样的实现目的，为啥不用一个mapping数组来实现呢？