本文繼續闡述基於低端控制器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嵌入式軟件架構設計（控制器SoC固件架構）系列博文：
SoC嵌入式軟件架構設計之二：沒有MMU的CPU實現虛擬內存管理的設計方法