標籤:style blog http io os 使用 ar 檔案 資料
本文繼續闡述基於低端控制器CPU的SoC韌體架構設計。第一節 SoC嵌入式軟體架構設計之一:系統記憶體需求評估 講述了系統記憶體需求的評估。這一節講述記憶體空間的具體規劃分配。CPU有兩種體繫結構:哈佛結構和馮諾依曼結構。哈佛結構是一種將程式指令儲存和資料存放區分開的儲存空間結構,如80251,代碼空間與資料空間完全分開,獨立編址;馮諾依曼結構是一種將程式指令儲存空間和資料存放區器合并在一起的儲存空間結構,如MIPS,ARM等,其代碼和資料空間是統一編址。這裡就以馮諾依曼體繫結構為例。
一、嵌入式系統軟體分層
系統軟體層次包括:啟動、驅動、作業系統、檔案系統、libc、中介軟體、應用程式框架、應用等層次。
1)驅動、檔案系統和作業系統的時間管理、中斷管理等介面一般都是通過API來進行調用;
2)libc和中介軟體、應用程式框架在系統中的處理可能以API的形式進行調用,也可以直接作為靜態庫與應用直接進行連結。
3)libc和中介軟體、應用程式框架作為靜態庫時,會減少API的佔用空間(API往往是常駐空間,沒理由調用API時還要從外儲存中將API的代碼載入到記憶體,這樣效率太低),省去API層也可以提高調用速度,但會增加庫函數的代碼空間。如果庫函數連結時可以運行在Bank記憶體中,由於Bank記憶體可以複用,增加的代碼空間可以忽略,從這一點來看其又是一個優點。如判斷某個檔案是哪種解碼格式時,其可以作為中介軟體來實現,並連結到應用的Bank空間,因為這是音樂解碼前的預先處理,可以和解碼時刻的控制流程複用同一塊Bank空間。
4)libc和中介軟體、應用程式框架以API形式來調用時,會產生API的常駐記憶體空間需求,在記憶體中也只存在一份真正的代碼,供所有模組共同調用,而且應用開發人員無需關心介面實現,也不允許開發人員去修改。
各個模組應根據實際情況來決定其供上層調用的形式。
代碼分頁(塊,Bank)設計請參考: SoC嵌入式軟體架構設計之二:沒有MMU的CPU實現虛擬記憶體管理的設計方法 和 SoC嵌入式軟體架構設計之三:代碼分塊(Bank)設計原則。
二、程式段組成
這裡程式段是指可執行檔中出現的段名,如.CODE、.DATA、.BSS等預設段名和其他自訂的段名。GNU工具鏈,各種編譯輸出段名稱是可以在連結指令碼中指定的,當然在編寫代碼時也可以指定函數或者代碼的編譯輸出段名稱,如在定義一個資料變數時添加一個屬性__attribute__((section("bank_data")))時,該資料變數將會被重定位在bank_data段。是具有Bank程式碼片段的程式與可執行檔段名的對應關係圖:
三、SoC內建記憶體規劃
一般地,如果SOC中內建SRAM超過32K,數字工程師也會將內建記憶體進行分塊,一是為了減少電路延時,二是為了讓記憶體得到更有效率的利用。如某塊記憶體在某個時刻是作為代碼使用,有時也可能作為資料使用(如果是哈佛結構,那就要切換記憶體的選址解碼電路,從代碼空間轉到資料空間),有時也可能用作特別的解碼buffer使用,而有些解碼的緩衝是以24bit作為單位,如果所有記憶體都作為一塊來設計,顯然是滿足不了這樣的需求的。是常見的SRAM:
四、程式記憶體空間分配
根據軟體分層和程式段綜合考慮,一般在實體記憶體的基礎上先進行分層劃分記憶體地區,再進行各層程式的段記憶體劃分。有以下原則:
1)各層的常駐段(代碼和資料)應該緊湊分配,而各層的Bank空間與常駐空間分塊,也應該緊湊分配。
2)Bank空間的起始地址應該與扇區單位對齊,可取得最好的載入代碼效能。
3)先把常見的情境的記憶體配置好,再考慮特殊情境的需求,看看特殊情境能否複用普通情境的記憶體空間。
4)buffer的劃分也要考慮情境的複用,否則太浪費。如解碼的buffer可以在未解碼的時候用作預先處理時的媒體檔案有效性判斷的buffer。
5)有時兩組Bank空間可以合并起來當作另一個情境的一組Bank空間來使用。如解碼時的軟體分層比較多,涉及到應用中介軟體和演算法中介軟體,而檔案瀏覽應用則沒有這麼多層次,可以將兩個中介軟體的Bank合并起來當一組Bank來使用。
6)一個模組的代碼不應該跨越兩個實體記憶體塊,否則訪問效能會降低。
7)儘可能提高記憶體利用率,避免記憶體片段。
8)記憶體配置的細節要以公開連結檔案出現,並用有意義的名稱來定義各段的起始地址和長度,除架構設計師外,其他人不允許修改該檔案。
是一個系統的局部分配,程式記憶體空間分配大致如此:Rcode是常駐段,Bank是複用記憶體的代碼塊。
SoC嵌入式軟體架構設計之四 :記憶體空間規劃分配