我已经写了很多关于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有这么多操作,都是做什么用的?
审核编辑 :李倩
全部0条评论
快来发表一下你的评论吧 !