Gerenciar memória e considerações de latênciaManage memory and latency considerations

Este tópico descreve as considerações básicas de uso de memória e latência para aplicativos em tempo real que são executados no chip MT3620.This topic describes basic memory use and latency considerations for real-time applications that run on the MT3620 chip.

Observação

Para obter mais detalhes sobre a configuração de memória ou DMA, consulte a folha de MT3620 publicada em MediaTek; Se as perguntas permanecerem, você poderá solicitar a "folha de MT3620 M4" do Avnet por email 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 de memória nos núcleos em tempo realMemory layout on the real-time cores

A tabela a seguir resume a memória disponível nos núcleos em tempo real:The following table summarizes the memory available on the real-time cores:

Tipo de memóriaMemory type Endereço básicoBase Address
TCMTCM 0x001000000x00100000
Flash XIPXIP flash 0x100000000x10000000
SYSRAMSYSRAM 0x220000000x22000000

Cada núcleo em tempo real tem 192 KB de memória agrupada com proximidade (TCM), que é mapeada em três bancos de 64 KB, começando em 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. Os acessos de TCM são rápidos, mas apenas o núcleo em tempo real pode acessar a memória.TCM accesses are fast, but only the real-time core can access the memory. A TCM não pode ser compartilhada com um aplicativo de alto nível ou com um aplicativo com capacidade para tempo real (RTApp) executado em um núcleo diferente.TCM cannot be shared with a high-level application or with a real-time capable application (RTApp) that runs on a different core.

Cada núcleo em tempo real também tem 64 KB de SYSRAM, que é mapeado começando em 0x22000000.Each real-time core also has 64 KB of SYSRAM, which is mapped starting at 0x22000000. O controlador DMA também pode direcionar o SYSRAM, para que os periféricos podem acessá-lo.The DMA controller can also target SYSRAM, so that peripherals can access it. Os acessos a SYSRAM do núcleo em tempo real são mais lentos do que os acessos à TCM.Accesses to SYSRAM from the real-time core are slower than accesses to TCM. Assim como acontece com TCM, o SYSRAM não pode ser compartilhado com outro aplicativo.As with TCM, SYSRAM cannot be shared with another application.

A memória flash XIP (executada no local) é compartilhada com aplicativos de alto nível.Execute-in-place (XIP) flash memory is shared with high-level applications. Uma janela para o mapeamento de XIP do flash é visível para cada núcleo no endereço 0x10000000.A window into the XIP mapping of the flash is visible to each core at address 0x10000000. O sistema operacional configura o mapeamento de XIP antes de iniciar o aplicativo se o arquivo do aplicativo ELF contém um segmento que tem as seguintes propriedades: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:

  • O endereço de carregamento (conforme especificado na coluna VirtAddr do cabeçalho de programa) é igual a 0x10000000Load address (as specified in the VirtAddr column of the Program Header) is equal to 0x10000000
  • Deslocamento de arquivo e o tamanho (conforme especificado nos campos FileSiz e MemSiz no cabeçalho do programa) se encaixam no arquivo de ELF do aplicativoFile offset and size (as specified in the FileSiz and MemSiz fields in the Program Header) fit in the application’s ELF file

Se houver um cabeçalho de programa com essas propriedades no arquivo de ELF do aplicativo, a janela XIP será posicionada para que o segmento fique visível em 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. O arquivo pode ter não mais de um segmento XIP, e ele deve indicar 0x10000000; ele não pode especificar nenhum outro endereço.The file can have no more than one XIP segment, and it must point to 0x10000000; it cannot specify any other address.

Implantação de ELFELF deployment

Imagens de RTApp devem ser arquivos ELF.RTApp images must be ELF files. A imagem de ELF é encapsulada em um pacote de imagem do Azure Sphere e implantada como um aplicativo.The ELF image is wrapped in an Azure Sphere image package and deployed as an application. Para carregar o aplicativo, o sistema de operacional do Azure Sphere inicia um carregador do ELF que é executado no núcleo em tempo real.To load the application, the Azure Sphere OS starts an ELF loader that runs on the real-time core. O carregador processa cada segmento de CARGA no arquivo ELF e carrega-os em tipo de memória indicada pelo endereço virtual no cabeçalho do programa.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.

Use arm-none-eabi-readelf.exe -l (L minúsculo), que faz parte da cadeia de ferramentas inseridas GNU Arm, para exibir os cabeçalhos de programa para o seu aplicativo.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. A coluna de endereço virtual (VirtAddr) que aparece no cabeçalho indica o endereço de destino para o segmento de carga.The virtual address column (VirtAddr) that appears in the header indicates the destination address for the load segment. Isso não significa que o próprio processador realiza conversão adicional.It does not mean that the processor itself performs any additional translation. O carregador do ELF Azure Sphere não usa o endereço físico (PhysAddr).The Azure Sphere ELF loader doesn't use the physical address (PhysAddr).

Considere este exemplo: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
  • O segmento no 0x00100000 destina-se a memória agrupada com proximidade (TCM).The segment at 0x00100000 is targeted at tightly-coupled memory (TCM). O carregador copia dados do pacote de imagem na RAM ou zero-inicializa o TCM conforme necessário.The loader either copies data from the image package into RAM or zero-initializes the TCM as required.

  • O segmento no 0x10000000 é mapeado para a janela XIP de núcleo.The segment at 0x10000000 is mapped to the XIP window for the core. Em tempo de execução, acessos a 0x10000000 + offset são convertidos em <address-of-XIP-segment-in-flash> + offset quando eles deixam o núcleo em tempo real.At run time, accesses to 0x10000000 + offset are translated to <address-of-XIP-segment-in-flash> + offset when they leave the real-time core.

  • O segmento de dados no endereço virtual 0x00100e78 é mapeado para o TCM.The data segment at virtual address 0x00100e78 is mapped to TCM.

Considerações de runtime do ELFELF runtime considerations

O carregador ELF executa algumas das tarefas que um binário bruto (ou encadeado de carregador de inicialização) deve executar na inicialização.The ELF loader performs some of the tasks that a raw binary (or chained bootloader) would perform at start-up. Especificamente, ele inicializa a zero dados do bloco-iniciado-por-símbolo (BSS) e copia dados inicializados, mas mutáveis do flash somente leitura na RAM, de acordo com os cabeçalhos do programa.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. O aplicativo, em seguida, inicia e executa suas próprias funções de inicialização.The application then starts and runs its own initialization functions. Na maioria dos casos, alterações em aplicativos existentes não são necessárias.In most cases, changes to existing applications aren't required. A anulação de dados BSS no aplicativo é desnecessária, mas inofensiva, porque o carregador já zerou a memória.Zeroing the BSS data in the application is unnecessary but harmless, because the loader has already zeroed the memory.

A cópia de dados mutáveis do flash para a memória RAM podem em algumas circunstâncias causar problemas, dependendo de como o arquivo ELF é disposto. O carregador ELF processa os cabeçalhos de programa em sequência, sem alterar o layout geral dos segmentos no arquivo.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. Em seguida, ele mapeia não apenas o próprio segmento XIP para 0x10000000, mas também todos os segmentos subsequentes na ordem.It then maps not only the XIP segment itself to 0x10000000, but also any subsequent segments in order. Se os segmentos no arquivo ELF estiverem em ordem sequencial sem alinhamento ou lacunas, o código de inicialização do sistema operacional pode usar aritmética de ponteiro para encontrar o início do segmento de dados.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 o arquivo ELF tem um layout diferente, no entanto, aritmética de ponteiro não resulta no endereço correto, portanto, o código de inicialização do aplicativo não deve tentar copiar a seção de dados.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. Isso pode causar problemas se o aplicativo ou o RTOS usar um carregador de inicialização encadeado ou precisar configurar uma pilha canário antes de zerar o BSS ou inicializar dados mutáveis.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.

Destinos de memóriaMemory targets

Você pode direcionar o código no TCM, XIP flash ou SYSRAM ao editar o script linker.ld para seu aplicativo.You can target code at TCM, XIP flash, or SYSRAM by editing the linker.ld script for your application. Os aplicativos de exemplo do Azure Sphere são executados do TCM, mas o arquivo de script linker.ld para cada aplicativo descreve como destinar flash XIP.The Azure Sphere sample applications run from TCM, but the linker.ld script file for each application describes how to target XIP flash instead. Como mostra o exemplo a seguir, você pode alterar um exemplo para ser executado em XIP ao fazer alias de CODE_REGION e RODATA_REGION ao FLASH, em vez do TCM padrão: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);

Para determinar se um aplicativo compilado é executado de flash TCM ou XIP, use arm-none-eabi-readelf.exe, que faz parte da cadeia de ferramentas incorporadas de Arm GNU.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. Execute-o no arquivo .out, que está no mesmo diretório que o pacote de imagem, e especifique o sinalizador -l (L minúsculo) para ver o local em que o código e os dados somente leitura foram colocados.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. O código e dados somente leitura na memória flash são carregados no endereço 0x10000000; o código e os dados no TCM são carregados na região do 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.

O exemplo a seguir mostra um aplicativo que é executado a partir de memória 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

Local da tabela de vetoresVector table location

Em dispositivos ARMv7-M, a tabela de vetores deve estar alinhada em um limite de potência de dois que tenha pelo menos 128 bytes e não menos do que o tamanho da tabela, conforme observado no Manual de referência de arquitetura do 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. Cada núcleo de RT de e/s no MT3620 dá suporte a 100 interrupções externas.Each I/O RT core on the MT3620 supports 100 external interrupts. Portanto, incluindo o ponteiro de pilha e 15 exceções padrão, a tabela tem 116 entradas de 4 bytes, com um tamanho total de bytes 464, arredondado para 512 bytes.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 o código é executado no flash XIP, a tabela de vetores deve ser colocada no 0x10000000 e estar alinhada em um limite de 32 bytes dentro do arquivo 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 o código não é executado do flash XIP, a tabela normalmente é colocada no início de TCM0, que é 0x100000.When the code is not run from XIP flash, the table is typically placed at the start of TCM0, which is 0x100000. Em ambos os casos, para garantir que o endereço virtual da tabela esteja alinhado corretamente, coloque a tabela de vetores em uma seção dedicada e defina CODE_REGION para o endereço apropriado.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.

Os exemplos de MT3620 BareMetal no repositório de Exemplos do Azure Sphere mostram como fazer isso.The MT3620 BareMetal samples in the Azure Sphere Samples repository show how to do this. A declaração da tabela de vetores em main.c define seu atributo section como .vector_table.The declaration of the vector table in main.c sets its section attribute to .vector_table. Os script do vinculador realiza o alias de CODE_REGION para início do TCM ou do XIP e o atributo ALIGN define o alinhamento da seção de texto dentro do arquivo ELF da seguinte maneira: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
...
}

Considerações de tempo real e latênciaReal-time and latency considerations

Aplicativos de alto nível e RTApps disputam acesso à memória flash, mesmo se eles não se comunicam entre si.RTApps and high-level applications contend for access to flash memory, even if they don't communicate with each other. Como resultado, RTApps que estão sendo executados do flash XIP poderão encontrar latência alta e imprevisível.As a result, RTApps that are running from XIP flash may encounter high and unpredictable latency. Gravações em flash, como durante uma atualização podem envolver a picos de latência até várias centenas de milissegundos.Writes to flash, such as during an update, may involve latency spikes up to several hundred milliseconds. Dependendo dos requisitos do seu aplicativo, você pode gerenciar isso de várias maneiras:Depending on your application's requirements, you can manage this in several ways:

  • Coloque todo o código e dados em TCM.Put all code and data in TCM. O código que é executado de TCM não é vulnerável a contenção para flash.Code that runs from TCM is not vulnerable to contention for flash.

  • Divida o código em seções críticas e não críticas e execute o código não-crítico do flash.Split code into critical and non-critical sections, and run the non-critical code from flash. O código que tem requisitos em tempo real, como um timer de watchdog não deve ter que ser executado quando o outro código está acessando o flash.Code that has real-time requirements, such as a watchdog timer, should not have to run when other code is accessing the flash. Destinos de memória descrevem como destinar flash XIP em vez de TCM.Memory targets describes how to target XIP flash instead of TCM.

  • Use o cache.Use cache. Um aplicativo pode usar os 32KB mais baixos de TCM como cache XIP.An application can use the lowest 32KB of TCM as XIP cache. Essa abordagem não oferece garantias em tempo real difícil no caso de uma perda no cache, mas melhora o desempenho típico sem a necessidade de mover todo o código na 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. Consulte a "folha de dados MT3620 M4" para obter informações sobre a configuração de cache XIP.Refer to the "MT3620 M4 Datasheet" for information about XIP cache configuration.