AUTOSAR Ea深度剖析

描述

我已经写了很多关于AUTOSAR Memory Stack相关的文章教程了,初学者按照这些教程步骤去实操,入门进阶是应该是没问题的了。

AUTOSAR的Memory是如何设计的?

一图读懂AUTOSAR NvM(附pdf版文档资源)

AUTOSAR NvM模块配置详解

AUTOSAR中的NvM、Ea和Eeprom之间是如何相互关联的?

但是对于好学的人,怎么可以止步于此呢!我刚学AUTOSAR搞EEPROM的时候,遇到一堆问题,就想对Ea这个模块刨根问底,看看其到底做了哪些功能。回想当初掉坑、苦恼摸索的日子,心觉甚是艰难,于是总结一下这个Ea模块。

温馨提示:本文会涉及或详细讲到以下内容:

分析AUTOSAR的Eeprom为什么效率比较低

如何将AUTOSAR Memory Stack移植到PC上模拟仿真

解读Ea里面的磨损均衡算法

以gif动图展现Eeprom的最终读写行为(文末有下载动图的方法)

1.AUTOSAR Eeprom读写效率很低?

之前我搞这个玩意的时候,好不容易将这个NvM和EEPROM等配置好,生成代码编译通过运行OK,还真以为OK了,谁知高兴早了。

如果对Ea里面的机制不了解的话,平时也不特别测试这个EEPROM的读写速度,很难发现这个效率问题。

之前,我们项目遇到一个问题,特意测试了下,从写NvM开始,到实际EEPROM写完返回Notification,就简单写几个字节就花了超20ms。

一开始不可置信,特意查了EEPROM手册,明明写一个page时间是<4ms,这几个字节也在一个page里面,怎么就花了数倍的时间!为了做个对比,直接拿个非AUTOSAR工程来试试,也就4ms上下。怎么会差别这么大?

为了搞清楚这个问题,一开始仿真看看这个过程在搞什么鬼,奈何这个NvM、Ea和EEPROM都是异步的,代码也很复杂,就Ea一个模块就15个C文件,没法看下去。

算法

撸码撸了很久,最后找到EEPROM的末端函数,看看这个EEPROM写入是如何进行的,里面传递的地址和数据到底是什么东西。

不看不知道,一看吓一跳,写一段Eeprom数据,除了有“写”的接口调用,也有“读”的接口调用,而且这个“写”还不止写一次……让我瞬间怀疑人生了,还以为我调用了好多次写接口。

因为这东西,搞得几天没觉好睡。为了搞清楚这Ea里面的行为,翻了很多AUTOSAR的官方文档和Ea、Eeprom里面的源码。虽然,能寻得一些皮毛,但是还是很不理解。

为了直观地理解这个操作过程,还根据《RTOS内存分析动图是怎么做的?(附源码)》里面的方法,做出了几个动图。

例如,用了《AUTOSAR NvM模块配置详解》里面的例子,通过NvM接口往Eeprom写入8个字节,其执行动作如下:

算法

其实,从这个图可以看出,调用一些NvM的写接口:

 

Rte_Call_NvMService_AC2_NvBlockNeed_8Bytes_WriteBlock(nvm_8bytes_wr_data);

 

其居然,对Eeprom进行了5次操作!可参考下图每个小图下面的Action描述。

算法

由于Eeprom的最大写入时间为4ms(我实验的EEPROM是4ms,其他型号请参考对于的规格书),所以Eeprom_MainFunction的周期时间定义 为4ms,确保其执行是可以顺利完成的。

从上面捕捉到的数据看,这个Eeprom的MainFunction至少执行了5次。所以,写一次NvM不是和写一次Eeprom时间等同的。

越搞越好奇,为什么写个NvM要读2次和写3次Eeprom呢?,不是浪费时间吗?

2.AUTOSAR 能否在PC上仿真测试?

为了彻底搞清楚这些过程动作,我不断尝试打log和仿真,很费时间,用起来很不爽。

想着,这AUTOSAR能否搬到PC上模拟?

整套AUTOSAR搬过去应该是非常困难的,因为涉及到很多硬件相关的接口。那么只是将AUTOSAR的Memory Stack(NvM、MemIf、Ea和Eeprom)搬到PC上运行,是否可行呢?

唯一跟硬件相关的只是Eeprom模块调用的IIC接口了,把IIC接口打桩不就行了。然后将实际写入EEPROM的数据重定向到PC上写文件不就行了。

想想好像也不难,不难那就干起来。

开发编译环境,我尝试了微软的visual studio IDE,用起来不爽,关键遇到一堆编译错误,后来换GCC编译(Windows上的Cygwin环境),顺手写了个Makefile。

一顿操作猛如虎,编译调试二百五。

都怪当初没好好学习,搞得现在将Makefile、Gcc编译、Cygwin的环境等等统统研究了一番,也算是额外的收获吧。

其实也很简单,就两步,而我走了很多弯路而已:

按这个思路搞下去,虽然要花一点点时间,你也会把AUTOSAR里面这几个模块的编译依赖也搞清楚了,对学习AUTOSAR是挺有帮助的。

添加所需的C文件,包括:

NvM、MemIf、Ea、Eeprom模块里所有的.c文件

配置生成的和Memory相关的文件,例如NvM_Cfg.c等

测试代码,例如仿真工程理解的main.c等

解决编译问题,gcc一个命令搞过去,肯定有很多编译错误的,例如:

第一个就是头文件找不到问题,通过gcc的-I参数指定路径就可以了;

还有就是AUTOSAR里面定义的一些跟编译选项有关的预编译(例如#pragma ghs...这种是Greenhills用的)问题,屏蔽这些没用的代码即可

Rte.c里面很多内容编译错误或者链接时找不到,这个只能把有用的函数或定义抠出来,重新放到一个文件里面,加入编译,而Rte.c就不要包含到编译选项了;

...

接下来最关键的就是Eeprom的读写接口了,因为我们就想通过这个看数据的,例如我是这样模拟这个write接口的:

 

FILE* f = fopen("./EEP_MEM.data", "rb+"); if (f) { fseek(f, addr, SEEK_SET); int cur = ftell(f); fwrite(data, len, 1, f); fclose(f); } printf("EEPROM Write data to 0x%04X: ", addr); MEM_PRINT_DATA(data, len);

 

直接操作文件,病通过printf输出log,丝滑一般顺畅。

然后,把你想看的过程都输出log,那么就可以得出我曾在《AUTOSAR NvM模块配置详解》就放出来过的log:

 

NVM Test Write Data: 00 01 02 03 04 05 06 07
Runnable_NvM called( 1), ret=0
Runnable_NvM called( 2), ret=0
Runnable_NvM called( 3), ret=0
Runnable_NvM called( 4), ret=0
EEPROM Read data from 0x000C: FF
Runnable_NvM called( 5), ret=0
Runnable_NvM called( 6), ret=0
EEPROM Read data from 0x0015: FF
Runnable_NvM called( 7), ret=0
Runnable_NvM called( 8), ret=0
Runnable_NvM called( 9), ret=0
Runnable_NvM called(10), ret=0
Runnable_NvM called(11), ret=0
Runnable_NvM called(12), ret=0
EEPROM Write data to  0x000C: F0
Runnable_NvM called(13), ret=0
Runnable_NvM called(14), ret=0
Runnable_NvM called(15), ret=0
EEPROM Write data to  0x000D: 00 01 02 03 04 05 06 07
Runnable_NvM called(16), ret=0
Runnable_NvM called(17), ret=0
Runnable_NvM called(18), ret=0
EEPROM Write data to  0x0015: F0
Runnable_NvM called(19), ret=0
Runnable_NvM called(20), ret=0
Runnable_NvM called(21), ret=0
Runnable_NvM called(22), ret=0
Runnable_NvM called(23), ret=0
NvMNotifyJobFinished_NvBlockNeed_8Byte_JobFinished(7,0)
NVM Test Write finish.

 

就这样,NvM执行后对Eeprom的操作过程就一目了然了,为什么效率低也变得很清晰了。

那么,关键问题来了:为什么写NvM有这么多操作,都是做什么用的?

审核编辑 :李倩

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分