MemIf

和所有的抽象層作用差不多，MemIf把Driver層的模塊抽象出來提供給上層使用，具體層級結構如下：

NvM調用MemIf提供的標準接口，例如MemIf_ReadWrite等；在MemIf根據(jù)已配置的抽象驅動模塊（FeeEA）分別調用不同的API，實際舉例如下：

根據(jù)標準，F(xiàn)ee或者Ea又會調用MeeAcc提供的接口去訪問不同的Flash驅動。

我們以Vector的實際代碼為例，在MemIf層配置提供的接口如下：

/**-- MemHwA Function Pointers --**/
CONST(MemIf_MemHwAApi_Type, MEMIF_CONST) MemIf_MemHwaApis[MEMIF_NUMBER_OF_DEVICES] =
{
   /*  Fee_30_SmallSector  */ {
    Fee_30_SmallSector_Read, 
    MemIf_Fee_30_SmallSector_WriteWrapper, 
    Fee_30_SmallSector_EraseImmediateBlock, 
    Fee_30_SmallSector_InvalidateBlock, 
    Fee_30_SmallSector_Cancel, 
    Fee_30_SmallSector_GetStatus, 
    Fee_30_SmallSector_GetJobResult, 
    Fee_30_SmallSector_SetMode
  }
};

在Fee層級配置的Flash驅動接口如下：

/* FLS API pointer table */
CONST(Fee_30_SmallSector_FlsApiType, FEE_30_SMALLSECTOR_PRIVATE_CONST) Fee_30_SmallSector_FlsApi0 = 
{
   /*  Read Service  */ Fls_Read, 
   /*  Write Service  */ Fls_Write, 
   /*  Compare Service  */ Fls_Compare, 
   /*  Erase Service  */ Fls_Erase, 
   /*  Blank Check Service  */ Fls_BlankCheck, 
   /*  Get Status Service  */ Fls_GetStatus, 
   /*  Get Job Result Service  */ Fls_GetJobResult
};

發(fā)現(xiàn)沒有，這一層的API并沒有MemAccM相關的接口，所以雖然規(guī)范定義了這樣的層級結構，但是在實現(xiàn)上有多種可能，簡單有效才是硬道理。

Fee

之所以在車規(guī)MCU里需要提供這樣的機制，主要還是為了節(jié)約成本，提供數(shù)據(jù)的高效、實時存儲，滿足車規(guī)對于Data Flash百萬次刷寫的要求。

在AUTOSAR的規(guī)范里，也提供了這樣類似的示例機制來提高DFlash的使用壽命：

在該示例中，共計有1500Bytes數(shù)據(jù)需要管理，這些數(shù)據(jù)被均勻分成10個Block；當Fee發(fā)現(xiàn)某個Block數(shù)據(jù)更改并且需要重新編程的時候，他會找到目前空閑的Flash空間把數(shù)據(jù)寫進Flash并設置有效。需要注意的是，在設計Fee驅動時，需要考慮到Flash IP支持的最小可擦除單位和最小可編程單位，只要熟悉IP特性，才能做好Flash磨損均衡算法。

小結

NvM的狀態(tài)機每家供應商的代碼區(qū)別還是挺大的，不過我們在看代碼的時候首先需要了解這些API的調用時序，如下圖為用戶調用NvM_Write服務的時序圖：

熟讀AUTOSAR NV Data Handling Guideline，才能更好理解代碼，必要時自己畫一個狀態(tài)遷移圖。

來源：汽車MCU軟件設計

審核編輯：湯梓紅