管理記憶體和延遲考慮

  • 發行項

本主題說明在 MT3620 晶片上執行的即時應用程式的基本記憶體使用與延遲考慮。

注意

如需記憶體設定或 DMA 的詳細資料，請參閱 從 MediaTek 發佈的 MT3620 資料工作表;如果問題仍然存在，您可以透過電子郵件向 Avnet 要求「MT3620 M4 資料工作表」 Azure.Sphere@avnet.com 。

即時核心上的記憶體版面配置

下表摘要列出即時核心上可用的記憶體：

記憶體類型 基本位址
中醫 0x00100000
XIP 快閃 0x10000000
SYSRAM 0x22000000

每個即時核心都有 192 KB 緊密結合的記憶體 (TCM) ，從 0x00100000 開始對應三組 64 KB。 TCM 存取速度很快，但只有即時核心可以存取記憶體。 TCM 無法與高階應用程式或具有即時功能的應用程式共用， (在不同核心上執行的 RTApp) 。

每個即時核心也有 64 KB 的 SYSRAM，從 0x22000000 開始對應。 DMA 控制器也可以以 SYSRAM 為目標，讓周邊裝置可以存取它。 從即時核心存取 SYSRAM 的速度比存取 TCM 的速度還要慢。 跟 TCM 一樣，SYSRAM 無法與其他應用程式共用。

XIP) flash 記憶體執行就地 (與高層級應用程式共用。 在位址0x10000000，每個核心都會看到進入 FLASH 的 XIP 對應視窗。 如果應用程式的 ELF 檔案包含具有下列屬性的區段，作業系統會在啟動應用程式前先設定 XIP 對應：

  • [程式標題]) 的 [VirtAddr] 欄中所指定的載入位址 (等於 0x10000000
  • [程式標題] (中的 [FileSiz] 和 [MemSiz] 欄位中所指定的檔案位移和大小) 符合應用程式的 ELF 檔案

如果具有這些屬性的程式標題出現在應用程式的 ELF 檔案中，則會將 XIP 視窗放置在位置，以便在0x10000000顯示區段。 檔案只能有一個 XIP 區段，而且必須指向0x10000000;它無法指定任何其他位址。

ELF 部署

RTApp 影像必須是 ELF 檔案。 ELF 影像會纏繞在 Azure 球體圖像套件中，並以應用程式的形式部署。 若要載入應用程式，Azure 球體 OS 會啟動在即時核心上執行的 ELF 載入器。 載入器會處理 ELF 檔案中的每個 LOAD 區段，並將它載入到程式標題中虛擬位址所指示的記憶體類型。

使用 GNU Arm Embedded Toolchain 的一部分，使用 arm-none-eabi-readelf.exe -l (小寫 L) 來顯示應用程式的程式標題。 頁首中顯示的 VirtAddr) (虛擬位址欄會指出載入區段的目的地位址。 這並不表示處理器本身會執行任何其他翻譯。 Azure 球體 ELF 載入器不會使用實體位址 (PhysAddr) 。

請考慮這個範例：

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000098 0x00100000 0x00100000 0x00000 0x00e78 RW  0x8
  LOAD           0x0000a0 0x10000000 0x10000000 0x03078 0x03078 RWE 0x10
  LOAD           0x003118 0x00100e78 0x10003078 0x000f0 0x000f0 RW  0x4

  • 0x00100000 的區段是以緊密結合的記憶體 (TCM) 為目標。 載入器會視需要將影像套件中的資料複製到 RAM，或零初始化 TCM。

  • 0x10000000區段會對應至核心的 XIP 視窗。 在執行時間，存取權 0x10000000 + offset 會在離開即時核心時翻譯成 <address-of-XIP-segment-in-flash> + offset 。

  • 虛擬位址0x00100e78的資料區段對應至 TCM。

ELF 執行時間考慮

ELF 載入器會執行一些原始二進位 (或鏈結開機載入器) 會在啟動時執行的工作。 具體來說，它以零初始化區塊起始符號 (BSS) 資料，並根據程式標題，將初始化但可靜音的資料從唯讀閃入 RAM 中複製。 應用程式隨即啟動並執行自己的初始化函數。 在大多數情況下，不需要變更現有的應用程式。 將應用程式中的 BSS 資料設為零是不必要的，但不會造成傷害，因為載入器已經將記憶體自訂為零。

視 ELF 檔案的配置方式而定，將可靜音資料從 Flash 複製到 RAM 在某些情況下可能會造成問題。ELF 載入器會依序處理常式標題，而不會變更檔案中區段的整體版面配置。 接著它不僅會將 XIP 區段本身對應至0x10000000，還會依序對應任何後續的區段。 如果 ELF 檔案中的區段是依序排列，沒有任何對齊方式或間距，作業系統啟動程式碼可以使用指標算術來尋找資料區段的開頭。 不過，如果 ELF 檔案的版面配置不同，則指標算術不會產生正確的位址，因此應用程式啟動程式碼不能嘗試複製資料區段。 如果應用程式或 RTOS 使用鏈狀開機載入器，或需要在將 BSS 除以或初始化可靜音資料之前設定堆疊 Canary，這可能會造成問題。

記憶體目標

您可以編輯應用程式的 linker.ld 腳本，以 TCM、XIP flash 或 SYSRAM 為目的程式代碼。 Azure 球體範例應用程式是從 TCM 執行，但每個應用程式的 linker.ld 腳本檔案說明如何改為以 XIP 刷新為目標。 如下列範例所示，您可以將CODE_REGION別名變更為在 XIP 上執行的樣本，RODATA_REGION變更為 FLASH，而非預設的 TCM：

REGION_ALIAS("CODE_REGION", FLASH);
REGION_ALIAS("RODATA_REGION", FLASH);

若要判斷編譯的應用程式是從 TCM 還是 XIP Flash 執行，請使用 arm-none-eabi-readelf.exe GNU Arm Embedded Toolchain 的一部分。 在與影像套件位於相同目錄的 .out 檔案上執行，並指定 -l (小寫 L) 標幟，以查看已放置程式碼和唯讀資料的位置。 在快閃記憶體中的程式碼和唯讀資料會在位址0x10000000載入;TCM 中的程式碼和資料會載入于 TCM 區域。

下列範例顯示從快閃記憶執行的應用程式。

arm-none-eabi-readelf.exe -l UART_RTApp_MT3620_BareMetal.out

Elf file type is EXEC (Executable file)
Entry point 0x10000000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000074 0x00100000 0x00100000 0x00284 0x003c0 RW  0x4
  LOAD           0x000300 0x10000000 0x10000000 0x013b9 0x013b9 R E 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .data .bss
   01     .text .rodata

向量表格位置

在 ARMv7-M 裝置上，向量資料表必須與至少 128 位元組且不小於表格大小的兩個電源對齊，如 ARMv7-M 架構參考手冊中所述。 MT3620 上的每個 I/O RT 核心都支援 100 個外部中斷。 因此，包括堆疊指標和 15 個標準例外狀況，表格有 116 個 4 位元組專案，總大小為 464 位元組，最多可四捨五入 512 位元組。

當程式碼從 XIP Flash 執行時，向量資料表必須放在 0x10000000，而且必須在 ELF 檔案中的 32 位元組邊界上對齊。 當代碼無法從 XIP Flash 執行時，表格通常會放在 TCM0 的開頭，也就是0x100000。 無論哪種情況，為了確保資料表的虛擬位址正確對齊，請將向量資料表放在專用區段中，並將CODE_REGION設定為適當的位址。

Azure 球體範例存放庫中的 MT3620 無所不在的範例會顯示如何執行此動作。 main.c 中向量資料表的宣告會將其 section 屬性設為 .vector_table 。 連結器腳本別名會CODE_REGION至 TCM 或 XIP 的開頭，而 ALIGN 屬性會將 ELF 檔案中文字區段的對齊方式設定為：

SECTIONS
{
    .text : ALIGN(32) {
        KEEP(*(.vector_table))
        *(.text)
    } >CODE_REGION
...
}

即時和延遲考慮

RTApps 和高階應用程式即使彼此沒有通訊，也能存取快閃記憶體。 因此，從 XIP Flash 執行的 RTApps 可能會遇到高且無法預測的延遲。 寫入以閃爍，例如在更新期間，可能會涉及高達數百毫秒的延遲。 根據應用程式的需求，您可以透過數種方式管理此專案：

  • 將所有程式碼和資料放入 TCM。 從 TCM 執行的程式碼不會容易受到閃爍的競賽。

  • 將程式碼分割成關鍵和非關鍵區段，並從閃爍執行非臨界值代碼。 具有即時需求的程式碼，例如輔助計時器，在其他程式碼存取快閃時，就不需要執行。 記憶體目標 說明如何以 XIP 刷新取代 TCM 為目標。

  • 使用快取。 應用程式可以使用最低的 32KB TCM 做為 XIP 快取。 此方法不會在快取遺漏時提供難以即時的保證，但可以改善一般效能，而不需要將所有程式碼移至 RAM。 如需 XIP 快取設定的相關資訊，請參閱「MT3620 M4 資料工作表」。