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里面定义的一些跟编译选项有关的预编译（例如#pragmaghs...这种是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：

NVMTestWriteData:0001020304050607 Runnable_NvMcalled(1),ret=0 Runnable_NvMcalled(2),ret=0 Runnable_NvMcalled(3),ret=0 Runnable_NvMcalled(4),ret=0 EEPROMReaddatafrom0x000C:FF Runnable_NvMcalled(5),ret=0 Runnable_NvMcalled(6),ret=0 EEPROMReaddatafrom0x0015:FF Runnable_NvMcalled(7),ret=0 Runnable_NvMcalled(8),ret=0 Runnable_NvMcalled(9),ret=0 Runnable_NvMcalled(10),ret=0 Runnable_NvMcalled(11),ret=0 Runnable_NvMcalled(12),ret=0 EEPROMWritedatato0x000C:F0 Runnable_NvMcalled(13),ret=0 Runnable_NvMcalled(14),ret=0 Runnable_NvMcalled(15),ret=0 EEPROMWritedatato0x000D:0001020304050607 Runnable_NvMcalled(16),ret=0 Runnable_NvMcalled(17),ret=0 Runnable_NvMcalled(18),ret=0 EEPROMWritedatato0x0015:F0 Runnable_NvMcalled(19),ret=0 Runnable_NvMcalled(20),ret=0 Runnable_NvMcalled(21),ret=0 Runnable_NvMcalled(22),ret=0 Runnable_NvMcalled(23),ret=0 NvMNotifyJobFinished_NvBlockNeed_8Byte_JobFinished(7,0) NVMTestWritefinish.

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

那么，关键问题来了：为什么写NvM有这么多操作，都是做什么用的？

审核编辑 ：李倩