Considerazioni sulla gestione di memoria e latenzaManage memory and latency considerations

Questo argomento contiene alcune considerazioni di base sull'uso della memoria e la latenza per le applicazioni con operazioni in tempo reale che vengono eseguite sul chip MT3620.This topic describes basic memory use and latency considerations for real-time applications that run on the MT3620 chip.

Nota

Per informazioni più dettagliate sulla configurazione della memoria o DMA, vedere il foglio dati MT3620 pubblicato da MediaTek; Se rimangono domande, è possibile richiedere il "foglio dati MT3620 M4" da Avnet inviando un messaggio di posta elettronica Azure.Sphere@avnet.com .For more detail about memory configuration or DMA, see the published MT3620 Datasheet from MediaTek; if questions remain, you can request the "MT3620 M4 Datasheet" from Avnet by emailing Azure.Sphere@avnet.com.

Layout della memoria sui core per operazioni in tempo realeMemory layout on the real-time cores

La tabella seguente presenta una sintesi della memoria disponibile nei core per operazioni in tempo reale:The following table summarizes the memory available on the real-time cores:

Tipo di memoriaMemory type Indirizzo di baseBase Address
TCMTCM 0x001000000x00100000
Flash XIPXIP flash 0x100000000x10000000
SYSRAMSYSRAM 0x220000000x22000000

Ogni core per operazioni in tempo reale è dotato di 192 kB di memoria TCM (Tightly-Coupled Memory), mappati in tre banchi da 64 kB a partire dall'indirizzo 0x00100000.Each real-time core has 192 KB of tightly-coupled memory (TCM), which is mapped in three banks of 64 KB starting at 0x00100000. Gli accessi alla memoria TCM sono veloci, ma solo i core per operazioni in tempo reale possono accedervi.TCM accesses are fast, but only the real-time core can access the memory. La memoria TCM non può essere condivisa con un'applicazione di alto livello o con un'applicazione con funzionalità in tempo reale (RTApp) eseguita su un altro core.TCM cannot be shared with a high-level application or with a real-time capable application (RTApp) that runs on a different core.

Ogni core per operazioni in tempo reale è inoltre dotato di 64 kB di SYSRAM, mappati a partire dall'indirizzo 0x22000000.Each real-time core also has 64 KB of SYSRAM, which is mapped starting at 0x22000000. Il controller DMA può anche gestire la memoria SYSRAM e consentire così alle periferiche di accedervi.The DMA controller can also target SYSRAM, so that peripherals can access it. Gli accessi alla memoria SYSRAM dal core in tempo reale sono più lenti rispetto agli accessi alla memoria TCM.Accesses to SYSRAM from the real-time core are slower than accesses to TCM. Come la TCM, la SYSRAM non può essere condivisa con un'altra applicazione.As with TCM, SYSRAM cannot be shared with another application.

La memoria flash a esecuzione sul posto (XIP) è condivisa con applicazioni di alto livello.Execute-in-place (XIP) flash memory is shared with high-level applications. Una finestra del mapping XIP della memoria flash è visibile a ogni core all'indirizzo 0x10000000.A window into the XIP mapping of the flash is visible to each core at address 0x10000000. Il sistema operativo configura il mapping XIP prima di avviare l'applicazione se il file ELF dell'applicazione contiene un segmento con le proprietà seguenti:The OS configures the XIP mapping before it starts the application if the application’s ELF file contains a segment that has the following properties:

  • Indirizzo di caricamento (come specificato nella colonna VirtAddr dell'intestazione di programma) uguale a 0x10000000Load address (as specified in the VirtAddr column of the Program Header) is equal to 0x10000000
  • Offset e dimensione del file (come specificato nei campi FileSiz e MemSiz nell'intestazione di programma) compresi nei valori definiti nel file ELF dell'applicazioneFile offset and size (as specified in the FileSiz and MemSiz fields in the Program Header) fit in the application’s ELF file

Se nel file ELF dell'applicazione è presente un'intestazione di programma con queste proprietà, la finestra XIP verrà posizionata in modo da rendere visibile il segmento all'indirizzo 0x10000000.If a program header with these properties is present in the application’s ELF file, the XIP window will be positioned so that the segment is visible at 0x10000000. Il file può avere un solo segmento XIP e deve puntare all'indirizzo 0x10000000. Non è possibile specificare altri indirizzi.The file can have no more than one XIP segment, and it must point to 0x10000000; it cannot specify any other address.

Distribuzione di ELFELF deployment

Le immagini delle applicazioni con operazioni tempo reale devono essere costituite da file ELF.RTApp images must be ELF files. L'immagine ELF viene sottoposta a wrapping in un pacchetto di immagine di Azure Sphere e distribuita come applicazione.The ELF image is wrapped in an Azure Sphere image package and deployed as an application. Per caricare l'applicazione, il sistema operativo Azure Sphere avvia un caricatore ELF che viene eseguito sul core per operazioni in tempo reale.To load the application, the Azure Sphere OS starts an ELF loader that runs on the real-time core. Il caricatore elabora ogni segmento LOAD nel file ELF e lo carica nel tipo di memoria indicato dall'indirizzo virtuale nell'intestazione di programma.The loader processes each LOAD segment in the ELF file and loads it into the type of memory indicated by the virtual address in the program header.

Per visualizzare le intestazioni di programma per l'applicazione, usare arm-none-eabi-readelf.exe -l (L minuscola), che fa parte di GNU Arm Embedded Toolchain.Use arm-none-eabi-readelf.exe -l (lowercase L), which is part of the GNU Arm Embedded Toolchain, to display the program headers for your application. La colonna dell'indirizzo virtuale (VirtAddr) visualizzata nell'intestazione indica l'indirizzo di destinazione per il segmento LOAD.The virtual address column (VirtAddr) that appears in the header indicates the destination address for the load segment. Questo non significa che il processore stesso esegua altre conversioni.It does not mean that the processor itself performs any additional translation. I caricatore ELF di Azure Sphere non usa l'indirizzo fisico (PhysAddr).The Azure Sphere ELF loader doesn't use the physical address (PhysAddr).

Considerare questo esempio:Consider this example:

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
  • Il segmento all'indirizzo 0x00100000 è destinato alla memoria TCM.The segment at 0x00100000 is targeted at tightly-coupled memory (TCM). Il caricatore copia i dati dal pacchetto dell'immagine nella RAM o inizializza a zero la memoria TCM, come necessario.The loader either copies data from the image package into RAM or zero-initializes the TCM as required.

  • Il segmento all'indirizzo 0x10000000 è mappato alla finestra XIP per il core.The segment at 0x10000000 is mapped to the XIP window for the core. In fase di runtime, gli accessi a 0x10000000 + offset vengono convertiti in <address-of-XIP-segment-in-flash> + offset quando lasciano il core per operazioni in tempo reale.At run time, accesses to 0x10000000 + offset are translated to <address-of-XIP-segment-in-flash> + offset when they leave the real-time core.

  • I segmento di dati in corrispondenza dell'indirizzo virtuale 0x00100e78 viene mappato alla memoria TCM.The data segment at virtual address 0x00100e78 is mapped to TCM.

Considerazioni sul runtime ELFELF runtime considerations

Il caricatore ELF esegue alcune delle operazioni che verrebbero eseguite all'avvio da un file binario non elaborato (o bootloader concatenato).The ELF loader performs some of the tasks that a raw binary (or chained bootloader) would perform at start-up. In particolare, inizializza a zero i dati BSS (Block-Started-by-Symbol) e copia i dati inizializzati, ma modificabili, dalla memoria flash di sola lettura alla RAM, in base alle intestazioni di programma.Specifically, it zero-initializes block-started-by-symbol (BSS) data and copies initialized but mutable data from read-only flash into RAM, according to the program headers. L'applicazione viene quindi avviata ed esegue le proprie funzioni di inizializzazione.The application then starts and runs its own initialization functions. Nella maggior parte dei casi non sono necessarie modifiche alle applicazioni esistenti.In most cases, changes to existing applications aren't required. L'azzeramento dei dati BSS nell'applicazione non è necessario, ma è innocuo, poiché il caricatore ha già azzerato la memoria.Zeroing the BSS data in the application is unnecessary but harmless, because the loader has already zeroed the memory.

La copia dei dati modificabili dalla memoria flash alla RAM può comportare problemi in alcune circostanze, a seconda del layout del file ELF. Il caricatore ELF elabora le intestazioni di programma in sequenza, senza modificare il layout complessivo dei segmenti nel file.Copying mutable data from flash to RAM may in some circumstances result in problems, depending on how the ELF file is laid out. The ELF loader processes the program headers sequentially, without changing the overall layout of the segments in the file. Esegue quindi il mapping non solo del segmento XIP stesso all'indirizzo 0x10000000, ma anche di tutti i segmenti successivi nell'ordine specificato.It then maps not only the XIP segment itself to 0x10000000, but also any subsequent segments in order. Se i segmenti nel file ELF sono disposti in ordine sequenziale, senza allineamento né spazi vuoti, il codice di avvio del sistema operativo può usare l'aritmetica dei puntatori per trovare l'inizio del segmento di dati.If the segments in the ELF file are in sequential order without any alignment or gaps, OS startup code can use pointer arithmetic to find the start of the data segment. Se il file ELF ha un layout diverso, tuttavia, l'aritmetica dei puntatori non consente di identificare l'indirizzo corretto e il codice di avvio dell'applicazione non deve provare a copiare la sezione di dati.If the ELF file has a different layout, however, pointer arithmetic does not result in the correct address, so application startup code must not try to copy the data section. Ciò può causare problemi se l'applicazione o l'RTOS usa un bootloader concatenato o deve configurare un canary stack prima di azzerare i dati BSS o inizializzare i dati modificabili.This may cause problems if the application or RTOS uses a chained bootloader or needs to set up a stack canary before zeroing BSS or initializing mutable data.

Destinazioni di memoriaMemory targets

È possibile destinare il codice alla memoria TCM, alla memoria flash XIP o alla memoria SYSRAM modificando lo script linker.ld per l'applicazione.You can target code at TCM, XIP flash, or SYSRAM by editing the linker.ld script for your application. Le applicazioni di esempio di Azure Sphere vengono eseguite dalla memoria TCM, ma il file di script linker.ld per ogni applicazione descrive come specificare la memoria flash XIP come destinazione alternativa.The Azure Sphere sample applications run from TCM, but the linker.ld script file for each application describes how to target XIP flash instead. Come illustrato di seguito, è possibile modificare un esempio in modo da consentirne l'esecuzione dalla memoria XIP specificando un alias FLASH in sostituzione del valore TCM predefinito per CODE_REGION e RODATA_REGION:As the following example shows, you can change a sample to run on XIP by aliasing CODE_REGION and RODATA_REGION to FLASH instead of the default TCM:

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

Per determinare se un'applicazione compilata viene eseguita dalla memoria TCM o dalla memoria flash XIP, usare arm-none-eabi-readelf.exe, che fa parte di GNU Arm Embedded Toolchain.To determine whether a compiled application runs from TCM or XIP flash, use arm-none-eabi-readelf.exe, which is part of the GNU Arm Embedded Toolchain. Eseguire il comando sul file con estensione out, ovvero nella stessa directory del pacchetto dell'immagine, e specificare il flag -l (con L minuscola) per visualizzare la posizione del codice e dei dati di sola lettura.Run it on the .out file, which is in the same directory as the image package, and specify the -l (lowercase L) flag to see where the code and read-only data have been placed. Il codice e i dati di sola lettura destinati alla memoria flash vengono caricati in corrispondenza dell'indirizzo 0x10000000, mentre quelli destinati alla memoria TCM vengono caricati nell'area TCM.Code and read-only data that are in flash memory are loaded at address 0x10000000; code and data in TCM are loaded in the TCM region.

L'esempio seguente mostra un'applicazione che viene eseguita dalla memoria flash.The following example shows an application that runs from flash memory.

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

Posizione della tabella dei vettoriVector table location

Nei dispositivi ARMv7-M la tabella dei vettori deve essere allineata a un limite che corrisponde a una potenza di due e le cui dimensioni sono di almeno 128 byte e non inferiori alle dimensioni della tabella, come indicato nel manuale di riferimento dell'architettura ARMv7-M.On ARMv7-M devices, the vector table must be aligned on a power-of-two boundary that is at least 128 bytes and no less than the size of the table, as noted in the ARMv7-M Architecture Reference Manual. Ogni core di I/O RT in MT3620 supporta 100 interruzioni esterne.Each I/O RT core on the MT3620 supports 100 external interrupts. Pertanto, includendo il puntatore dello stack e 15 eccezioni standard, la tabella contiene 116 voci da 4 byte, per un totale di 464 byte di dimensioni, arrotondate a 512 byte.Therefore, including the stack pointer and 15 standard exceptions, the table has 116 4-byte entries, for a total size of 464 bytes, which rounds up to 512 bytes.

Quando il codice viene eseguito dalla memoria flash XIP, la tabella dei vettori deve essere posizionata in corrispondenza di 0x10000000 e deve essere allineata a un limite di 32 byte all'interno del file ELF.When the code is run from XIP flash, the vector table must be placed at 0x10000000 and must be aligned on a 32-byte boundary within the ELF file. Quando il codice non viene eseguito dalla memoria flash XIP, la tabella viene in genere posizionata all'inizio di TCM0, ossia in corrispondenza di 0x100000.When the code is not run from XIP flash, the table is typically placed at the start of TCM0, which is 0x100000. In entrambi i casi, per assicurarsi che l'indirizzo virtuale della tabella sia allineato correttamente, inserire la tabella dei vettori in una sezione dedicata e impostare CODE_REGION su un indirizzo appropriato.In either case, to ensure that the table's virtual address is correctly aligned, put the vector table in a dedicated section and set CODE_REGION to the appropriate address.

Gli esempi MT3620 BareMetal nel repository di esempi di Azure Sphere illustrano come fare.The MT3620 BareMetal samples in the Azure Sphere Samples repository show how to do this. La dichiarazione della tabella dei vettori in main.c imposta il relativo attributo section su .vector_table.The declaration of the vector table in main.c sets its section attribute to .vector_table. Lo script del linker imposta CODE_REGION come alias all'inizio di TCM o XIP e l'attributo ALIGN imposta l'allineamento della sezione di testo all'interno del file ELF come segue:The linker script aliases CODE_REGION to the start of either TCM or XIP, and the ALIGN attribute sets the alignment of the text section within the ELF file as follows:

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

Considerazioni sull'elaborazione in tempo reale e la latenzaReal-time and latency considerations

Le applicazioni di alto livello e quelle con operazioni in tempo reale competono per l'accesso alla memoria flash, anche se non comunicano tra loro.RTApps and high-level applications contend for access to flash memory, even if they don't communicate with each other. Di conseguenza, le applicazioni con operazioni in tempo reale eseguite dalla memoria flash XIP possono presentare problemi di latenza elevata e imprevedibile.As a result, RTApps that are running from XIP flash may encounter high and unpredictable latency. Le scritture nella memoria flash, ad esempio durante un aggiornamento, possono comportare picchi di latenza fino a diverse centinaia di millisecondi.Writes to flash, such as during an update, may involve latency spikes up to several hundred milliseconds. A seconda dei requisiti dell'applicazione, è possibile gestire questo problema in diversi modi:Depending on your application's requirements, you can manage this in several ways:

  • Inserire tutto il codice e i dati nella memoria TCM.Put all code and data in TCM. Il codice eseguito dalla memoria TCM non è vulnerabile a contese per la memoria flash.Code that runs from TCM is not vulnerable to contention for flash.

  • Suddividere il codice in sezioni critiche e non critiche ed eseguire il codice non critico dalla memoria flash.Split code into critical and non-critical sections, and run the non-critical code from flash. Il codice che ha requisiti in tempo reale, ad esempio un timer di controllo, non dovrebbe essere eseguito quando altro codice accede alla memoria flash.Code that has real-time requirements, such as a watchdog timer, should not have to run when other code is accessing the flash. La sezione Destinazioni di memoria descrive in che modo specificare la memoria flash XIP in sostituzione della memoria TCM come destinazione.Memory targets describes how to target XIP flash instead of TCM.

  • Usare la cache.Use cache. Un'applicazione può usare i 32 kB più bassi della memoria TCM come cache XIP.An application can use the lowest 32KB of TCM as XIP cache. Questo approccio non offre una garanzia assoluta di elaborazione in tempo reale in caso di mancato riscontro nella cache, ma migliora le prestazioni tipiche senza che sia necessario spostare tutto il codice nella RAM.This approach does not provide hard real-time guarantees in the event of a cache miss, but improves typical performance without requiring you to move all the code into RAM. Per informazioni sulla configurazione della cache di XIP, vedere il foglio dati di MT3620 M4.Refer to the "MT3620 M4 Datasheet" for information about XIP cache configuration.