1. <tt id="5hhch"><source id="5hhch"></source></tt>
    1. <xmp id="5hhch"></xmp>

  2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

    <rp id="5hhch"></rp>
        <dfn id="5hhch"></dfn>

      1. 嵌入式系統中的線性Flash文件系統設計

        時間:2024-09-14 16:42:20 理工畢業論文 我要投稿
        • 相關推薦

        嵌入式系統中的線性Flash文件系統設計

        在嵌入式系統中,為了便于對閃存(Flash)空間進行管理,會采用文件的形式來訪問Flash。目前,可以購買到的Flash文件系統一般都是兼容DOS的文件系統(Flash File System,FFS),這對需要一個具有復雜的目錄層次,并且DDS文件兼容的系統來說是必要的;但是對大多數的嵌入式應用來說,這種文件系統太過奢侈。筆者在參與嵌入式系統項目的時候,設計了一種線性文件系統,它適用于大多數的嵌入式應用對Flash文件系統的需求。

        線性文件系統設計基于三個目標:一是提供給應用程序通過文件名而不是物理地址訪問系統Flash的能力;二是文件系統的設計獨立于實時操作系統(RTOS),這樣可以很容易移植到不同的嵌入式應用中;三是設計統一的底層接口,適應不同的Flash類型。本文設計的線性文件系統為典型的嵌入式系統提供了所需的類文件系統能力。需要注意的是,本文件系統不支持復雜的Flash扇區擦寫次數均衡算法,沒有目錄層次,并且和其它的文件系統不兼容。

        1 線性文件系統

        線性文件系統的設計思路是這樣的:文件分為文件頭和文件數據區兩個部分,每個文件按照順序存放在Flash中,以單向鏈表來鏈接文件。文件的起始部分是文件頭,包含文件的屬性、指向下一個文件頭的指針、文件頭和文件數據區的32位循環冗余校驗和(CRC32)等。文件頭用一個32位的字來表示文件屬性,每位表示一種屬性,如數據文件或者是可執行文件,是否已刪除的文件等,具體可以根據應用的需要來定義文件的屬性;文件頭和文件數據區維護獨立的CRC32校驗,使文件系統能更精確檢測文件的完整性。文件的起始地址沒有特殊需求,分配給文件系統的Flash大小限制了文件的大小。另外,線性文件系統作為嵌入式系統的一個功能模塊,它為應用程序提供與標準文件系統類似的API接口,如:read()、write()、open()、close()、stat()和seek()等。對于同時在多片Flash的系統而言,每片Flash相當于一個目標,文件都可存儲在任何一片中(當然受物理空間限制),但不能跨片存儲。

        圖1 Flash文件系統空間

        在第一個文件創建之前,必須進行初始化,將所有分配給文件系統的Flash空間擦除。當創建第一個文件時,起始位置從文件系統的起始地址開始,文件頭指針指向下一個空文件的起始位置(鏈表尾部);第二個文件的位置從當前的鏈表尾部開始,同時文件頭中的鏈表指針指向新的尾部。刪除文件時,僅僅是簡單地把文件頭的標識位中的活動文件標識位置0,表示刪除。這樣,在經過多次刪除之后,就有必要運行碎片整理模塊來進行文件系統Flash空間的碎片整理。碎片整理模塊還需要在文件系統Flash空間尾部留一個扇區來數據備份,以便當碎片整理被打斷時(如下電或者復位)可以恢復文件系統。這個保留的扇區稱空閑扇區。它必須放在文件系統空間之后,這樣可以保證文件系統的所有文件在所占用的Flash空間是連續的。整個文件空間的分配如圖1所示。

        陰影部分是文件頭,數據結構如下:

        struct hdr{

        unsigned short hdrsize; /*文件頭字節數*/

        long filsize; /*文件頭版本*/

        long filsize; /*文件大小*/

        long flags; /*描述文件的標識*/

        unsigned long filcrc; /*文件數據的CRC32的值*/

        unsigned long hdrcec; /*文件的最后修改時間*/

        struct hdr *next; /*指向下一個文件頭的指針*/

        char name[NAMESIZE]; /*文件名*/

        char info[INFOSIZE]; /*文件描述信息*/

        };

        碎片整個記錄區包含兩種數據類型:碎片整理文件頭信息表defraghdr和文件區扇區整理前后的CRC值備份表sectorcre。具體的地址分配從空閑扇區的起始地址減1開始,往前分配文件系統扇區數乘以4字節作為sectorcrc的空間;從sectorcrc起始地址減1開始,往前分配活動文件個數乘以64字節作為碎片整理文件頭信息表。這兩個結構定義如下:

        struct defraghdr{

        struct hdr *ohdr; /*文件頭的原始位置指針*/

        struct hdr *nextfile; /*指向下一個文件的指針*/

        long filsize; /*文件大小*/

        unsigned long crc; /*這個頭的CRC32值*/

        unsigned long ohdrcrc; /*原始文件頭CRC32值的拷貝*/

        long idx; /*碎片整理表頭的索引*/

        long nesn; /*新的文件尾的扇區號*/

        long neso; /*新的文件尾的扇區偏移量*/

        char *nda; /*新的文件起始地址*/

        char fname[NAMESIZE]; /*文件名*/

        };

        struct sectorcrc{

        unsigned long precrc; /*碎片整理前扇區數據CRC32的值*/

        unsigned long postcrc; /*碎片整理后扇區數據CRC32的值*/

        };

        從上面介紹可知,除了文件數據之外,文件系統還需要如下4種額外的開銷。

        ①文件頭:這是每個文件必須的開銷,如果文件名和信息域各24字節,那么整個文件頭共76字節。

        ②碎片整理文件頭信息表:每個活動(非刪除)的文件在進行碎片整理時在這個表里創建一個表項,每個表項64字節。

        ③碎片整理前后的扇區CRC32值表:保存文件整理前后的CRC32值,總的字節數約為文件所占扇區數的4倍。

        ④空閑塊:用來在碎片整理過程中備份當前整理扇區數據。

        【嵌入式系統中的線性Flash文件系統設計】相關文章:

        嵌入式系統中的Flash存儲管理03-18

        UML 在嵌入式系統設計中的應用03-18

        嵌入式系統中的PS/2接口設計11-22

        嵌入式系統中的CACHE問題03-19

        嵌入式Linux系統中的GUI系統的研究與移植03-18

        嵌入式系統中“軟外設”的研究03-19

        嵌入式系統中的內存壓縮技術03-18

        ARM7TDMI-S在嵌入式系統中的Bootloader代碼設計03-18

        面向對象的嵌入式系統設計方法03-18

        国产高潮无套免费视频_久久九九兔免费精品6_99精品热6080YY久久_国产91久久久久久无码

        1. <tt id="5hhch"><source id="5hhch"></source></tt>
          1. <xmp id="5hhch"></xmp>

        2. <xmp id="5hhch"><rt id="5hhch"></rt></xmp>

          <rp id="5hhch"></rp>
              <dfn id="5hhch"></dfn>