最近有些問題困擾左右。一些小數據的存儲問題，現在的片上系統或者單片機系統或多或少的會帶一點DATA flash的存儲區，大不比以前的24cxx的時代了，當然24CXX也算的上是經典的存儲。但是就目前我做過的這種存儲大都是一些簡單的數據或者變量。只要存幾個地址即可，根本不存在管理的問題。也正是基于此，導致現在如果要是實現一個小的FLASH管理就顯得很繁雜，甚至無從下手，考慮了許久，想到了內存池，內存池的概念基本上和Data Flash 相似的，對比他們之間的差別主要在于扇區地址尋址和擦寫上，SRAM當然是讀寫隨便了，只要指針直搗之處即使原始物理地址寫入讀出即可，但是FLASH的特性注定不能這樣子搞。他是塊擦寫的。如此就很難搞的和內存池一樣靈活。
我想這樣解決之：
1、建立一個數據結構來管理已知的FLASH，作一個記錄，這個記錄由若干個小塊組成，小塊用鏈表。
2、按照MEM_POOL構建FLASH的分配和釋放機制，為APP提供接口。
3、建立中間區域，所謂中間區域即使最小可擦寫扇區，一般標定為512byte,用來作為程序-中間緩沖區-FLASH三者協同。
4、在管理記錄中加入兩套函數指針，指向驅動層的驅動函數，以提高靈活性，適應片外EEPROM或者小容量FLASH。
5、塊校驗和存儲自己的映像。管理為單鏈表結構，數據塊為線性結構。以減低代碼實現的復雜程度。
倘若是上百兆的FLASH或者NAND之類的，毫無疑問直接上文件系統是嘴有效的。主要是有些應用介于大容量之間，有沒有足夠的資源，只能是自己實現一套管理機制，
數據結構參考如下：
POOL list and BLOCK
BLOCK在這里不適用，換成最小的快，即=512BYTE
POOL管理FLASH
list 提供塊數量，
自從此數據結構誕生之時起就決定了他的物理存儲邊界和塊大小。
顯然對mem_pool做了裁剪，變成了一個完全是單鏈表的結構，代碼復雜度低得多。
說到底其實就是一張餅，然后用刀切，切成均勻的一小塊一小塊，小塊上面有的有芝麻有的沒有。
應該做出這張餅！
老偉
比特電子
|
