我已經(jīng)寫了很多關(guān)于AUTOSAR Memory Stack相關(guān)的文章教程了，初學(xué)者按照這些教程步驟去實操，入門進(jìn)階是應(yīng)該是沒問題的了。

AUTOSAR的Memory是如何設(shè)計的？

一圖讀懂AUTOSAR NvM(附pdf版文檔資源)

AUTOSAR NvM模塊配置詳解

AUTOSAR中的NvM、Ea和Eeprom之間是如何相互關(guān)聯(lián)的？

但是對于好學(xué)的人，怎么可以止步于此呢！我剛學(xué)AUTOSAR搞EEPROM的時候，遇到一堆問題，就想對Ea這個模塊刨根問底，看看其到底做了哪些功能。回想當(dāng)初掉坑、苦惱摸索的日子，心覺甚是艱難，于是總結(jié)一下這個Ea模塊。

溫馨提示：本文會涉及或詳細(xì)講到以下內(nèi)容：

分析AUTOSAR的Eeprom為什么效率比較低

如何將AUTOSAR Memory Stack移植到PC上模擬仿真

解讀Ea里面的磨損均衡算法

以gif動圖展現(xiàn)Eeprom的最終讀寫行為（文末有下載動圖的方法）

1.AUTOSAR Eeprom讀寫效率很低？

之前我搞這個玩意的時候，好不容易將這個NvM和EEPROM等配置好，生成代碼編譯通過運(yùn)行OK，還真以為OK了，誰知高興早了。

如果對Ea里面的機(jī)制不了解的話，平時也不特別測試這個EEPROM的讀寫速度，很難發(fā)現(xiàn)這個效率問題。

之前，我們項目遇到一個問題，特意測試了下，從寫NvM開始，到實際EEPROM寫完返回Notification，就簡單寫幾個字節(jié)就花了超20ms。

一開始不可置信，特意查了EEPROM手冊，明明寫一個page時間是<4ms，這幾個字節(jié)也在一個page里面，怎么就花了數(shù)倍的時間！為了做個對比，直接拿個非AUTOSAR工程來試試，也就4ms上下。怎么會差別這么大？

為了搞清楚這個問題，一開始仿真看看這個過程在搞什么鬼，奈何這個NvM、Ea和EEPROM都是異步的，代碼也很復(fù)雜，就Ea一個模塊就15個C文件，沒法看下去。

擼碼擼了很久，最后找到EEPROM的末端函數(shù)，看看這個EEPROM寫入是如何進(jìn)行的，里面?zhèn)鬟f的地址和數(shù)據(jù)到底是什么東西。

不看不知道，一看嚇一跳，寫一段Eeprom數(shù)據(jù)，除了有“寫”的接口調(diào)用，也有“讀”的接口調(diào)用，而且這個“寫”還不止寫一次……讓我瞬間懷疑人生了，還以為我調(diào)用了好多次寫接口。

因為這東西，搞得幾天沒覺好睡。為了搞清楚這Ea里面的行為，翻了很多AUTOSAR的官方文檔和Ea、Eeprom里面的源碼。雖然，能尋得一些皮毛，但是還是很不理解。

為了直觀地理解這個操作過程，還根據(jù)《RTOS內(nèi)存分析動圖是怎么做的？（附源碼）》里面的方法，做出了幾個動圖。

例如，用了《AUTOSAR NvM模塊配置詳解》里面的例子，通過NvM接口往Eeprom寫入8個字節(jié)，其執(zhí)行動作如下：

其實，從這個圖可以看出，調(diào)用一些NvM的寫接口：

Rte_Call_NvMService_AC2_NvBlockNeed_8Bytes_WriteBlock(nvm_8bytes_wr_data);

其居然，對Eeprom進(jìn)行了5次操作！可參考下圖每個小圖下面的Action描述。

由于Eeprom的最大寫入時間為4ms（我實驗的EEPROM是4ms，其他型號請參考對于的規(guī)格書），所以Eeprom_MainFunction的周期時間定義 為4ms，確保其執(zhí)行是可以順利完成的。

從上面捕捉到的數(shù)據(jù)看，這個Eeprom的MainFunction至少執(zhí)行了5次。所以，寫一次NvM不是和寫一次Eeprom時間等同的。

越搞越好奇，為什么寫個NvM要讀2次和寫3次Eeprom呢？，不是浪費(fèi)時間嗎？

2.AUTOSAR 能否在PC上仿真測試？

為了徹底搞清楚這些過程動作，我不斷嘗試打log和仿真，很費(fèi)時間，用起來很不爽。

想著，這AUTOSAR能否搬到PC上模擬？

整套AUTOSAR搬過去應(yīng)該是非常困難的，因為涉及到很多硬件相關(guān)的接口。那么只是將AUTOSAR的Memory Stack（NvM、MemIf、Ea和Eeprom）搬到PC上運(yùn)行，是否可行呢？

唯一跟硬件相關(guān)的只是Eeprom模塊調(diào)用的IIC接口了，把IIC接口打樁不就行了。然后將實際寫入EEPROM的數(shù)據(jù)重定向到PC上寫文件不就行了。

想想好像也不難，不難那就干起來。

開發(fā)編譯環(huán)境，我嘗試了微軟的visual studio IDE，用起來不爽，關(guān)鍵遇到一堆編譯錯誤，后來換GCC編譯（Windows上的Cygwin環(huán)境），順手寫了個Makefile。

一頓操作猛如虎，編譯調(diào)試二百五。

都怪當(dāng)初沒好好學(xué)習(xí)，搞得現(xiàn)在將Makefile、Gcc編譯、Cygwin的環(huán)境等等統(tǒng)統(tǒng)研究了一番，也算是額外的收獲吧。

其實也很簡單，就兩步，而我走了很多彎路而已：

按這個思路搞下去，雖然要花一點點時間，你也會把AUTOSAR里面這幾個模塊的編譯依賴也搞清楚了，對學(xué)習(xí)AUTOSAR是挺有幫助的。

添加所需的C文件，包括：

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

配置生成的和Memory相關(guān)的文件，例如NvM_Cfg.c等

測試代碼，例如仿真工程理解的main.c等

解決編譯問題，gcc一個命令搞過去，肯定有很多編譯錯誤的，例如：

第一個就是頭文件找不到問題，通過gcc的-I參數(shù)指定路徑就可以了；

還有就是AUTOSAR里面定義的一些跟編譯選項有關(guān)的預(yù)編譯（例如#pragmaghs...這種是Greenhills用的）問題，屏蔽這些沒用的代碼即可

Rte.c里面很多內(nèi)容編譯錯誤或者鏈接時找不到，這個只能把有用的函數(shù)或定義摳出來，重新放到一個文件里面，加入編譯，而Rte.c就不要包含到編譯選項了；

...

接下來最關(guān)鍵的就是Eeprom的讀寫接口了，因為我們就想通過這個看數(shù)據(jù)的，例如我是這樣模擬這個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執(zhí)行后對Eeprom的操作過程就一目了然了，為什么效率低也變得很清晰了。

那么，關(guān)鍵問題來了：為什么寫NvM有這么多操作，都是做什么用的？

審核編輯 ：李倩