很多人都觉得AUTOSAR的Memory很复杂，搞了很久都摸不透里面的原理策略。

其实，AUTOSAR的Memory在AUTOSAR的架构下，封装得很好，只是我们很多人从普通嵌入式软件开发模式而来，一下子转不过弯而已。

本文就从普通嵌入式软件开发中的Memory入手，逐步讲解AUTOSAR的Memory原理策略。

注：以下讲的Memory方案是指EEPROM、DataFlash等非易失性存储（NVM）的软件方案。

1.传统嵌入式存储方案

试想下，一个简单的嵌入式系统软件里，如果想存储写信息到EEPROM（假设外置的EEPROM，通过IIC访问），你会如何设计？

最简单的办法，写好IIC通信，直接根据EEPROM的地址通过IIC进行访问，反正就是操作EEPROM，不用管那么多。但是软件结构比较混乱，驱动和应用混在一起。

这种做法，但凡有点软件层次结构概念的人都不会这么干，当然只是临时调试下硬件是无所谓的。

那么，改进下软件设计，把IIC驱动单独出来，是很常用的做法吧，比较IIC算是MCU的驱动，除了可以访问EEPROM，还可以用来跟其他外设通信，做成独立公共的驱动模块，是理所当然的。软件层次结构就像下面的这样子。

当然，对软件有追求的人，肯定是比较鄙视上面两种结构的，EEPROM好歹也要单独一个模块吧。单独一个应用倒是无所谓，如果要好几个应用要读写EEPROM，岂不是乱成一团了！

于是，设计成这样的接口，看起来是比较理想的。

普通的嵌入式软件的EEPROM设计，大多都是这样的，也比较灵活。

然而，AUTOSAR有更高的追求，它把EEPROM、DataFlash等NVM看成一类存储，而不管存储的实际介质是什么，统统都叫NVM。

于是乎，设计一个NVM的模块就呼之欲出了。NVM的对外的接口是统一的，而它对接DataFlash或EEPROM，还分别多加了一个FEE和EA这样的模块。

2.AUTOSAR的存储方案

到这里，我们对比下这几种方案。

上图方案A和方案B就不考虑了，那方案C和方案D的对比，差别在哪？

除了NVM这个模块是通用性的，还多出了个FEE和EA，那么FEE和EA分别是干嘛的？

在解释这两个模块之前，先从AUTOSAR的架构层面来看看，实际上FEE和EA就在Memory Hardware Abstraction层里面，注意关键字Abstraction。

FEE是 F lash E EPROM E mulation的缩写，而EA是 E EPROM A bstraction的缩写。

AUTOSAR考虑问题比较周到，NVM的存储是要考虑寿命的，特别是用在汽车行业。

一般情况下，DataFlash的P/E Cycle是10万次，EEPROM的是100万次。另外，DataFlash的擦写单位是比较大的，如果只想写一两个byte，需要擦除一大片，非常不友好。

于是要将DataFlash模拟成EEPROM来使用，这个FEE就出来了。当然FEE还考虑了磨损均衡算法，英文一般叫Wear Leveling。

那EA呢？因为EEPROM不同厂家做的地址、page管理等方式不一样，所以要做个抽象层来统一管理下，同时也加入了磨损均衡算法，来增加EEPROM的寿命。

以下以在0x0008地址写入0x11, 0x22, 0x33, 0x44这四个字节内容为例，看看EEPROM和DataFlash的实际操作情况：

很明显，EEPROM在同一个位置频繁操作也不是非常好的，只要次数多也是会影响寿命的，而Flash在这方面的劣势就更明显了，不但擦写单位比较大，寿命也比较短，所以这个FEE和EA的抽象是有必要的，磨损均衡技术也是有必要的。

至于这个磨损均衡技术是怎么实现的，涉及到的内容比较多，后续再细讲。

细心的小伙伴，会发现，为什么还有个MemIf？

实际上这个MemIf很简单，仅仅是统一封装了下FEE和EA的接口，为NVM提供一个统一的接口管理而已，如果非要说，那只能说NVM比较娇贵，啥都要给它准备得好好的。

3.NVM的存储结构

这样就完了吗，软件架构层次基本就这样了。

然而，AUTOSAR里面的这个Memory这一套东西，是很有搞头的，怎么说呢？

除了层次分明外，它对存储的结构抽象得很明确，于是就有了RAM Block，Data Set等这样的概念。

4 .AUTOSAR NVM的配置

讲了这么多，NVM怎么使用？

想其他AUTOSAR的Mode模块一样，NVM的接口不是给应用直接调用的，而是通过AUTOSAR的开发工具链给SWC配置NVM的Service接口，然后生成对应的Runnable等接口调用的，这里有套规则。