Verwalten von Arbeitsspeicher- und Latenzaspekten

Artikel
08/09/2023

In diesem Thema werden grundlegende Überlegungen zur Arbeitsspeichernutzung und Latenz für Echtzeitanwendungen beschrieben, die auf dem MT3620-Chip ausgeführt werden.

Hinweis

Weitere Informationen zur Speicherkonfiguration oder zu DMA finden Sie im veröffentlichten MT3620-Datenblatt von MediaTek. Wenn Noch Fragen bestehen, können Sie das "MT3620 M4-Datenblatt" von Avnet per E-Mail Azure.Sphere@avnet.comanfordern.

Speicherlayout auf den Echtzeitkernen

In der folgenden Tabelle ist der auf den Echtzeitkernen verfügbare Arbeitsspeicher zusammengefasst:

Speichertyp	Basisadresse
TCM	0x00100000
XIP-Flash	0x10000000
SYSRAM	0x22000000

Jeder Echtzeitkern verfügt über 192 KB eng gekoppelten Arbeitsspeicher (TCM), der ab 0x00100000 in drei Banken mit 64 KB abgebildet ist. TCM-Zugriffe sind schnell, aber nur der Echtzeitkern kann auf den Speicher zugreifen. TCM kann nicht für eine allgemeine Anwendung oder eine echtzeitfähige Anwendung (RTApp) freigegeben werden, die auf einem anderen Kern ausgeführt wird.

Jeder Echtzeitkern verfügt außerdem über 64 KB SYSRAM, das ab 0x22000000 zugeordnet wird. Der DMA-Controller kann auch sysram als Ziel verwenden, sodass Peripheriegeräte darauf zugreifen können. Der Zugriff auf SYSRAM vom Echtzeitkern ist langsamer als der Zugriff auf TCM. Wie bei TCM kann SYSRAM nicht für eine andere Anwendung freigegeben werden.

XIP-Flashspeicher (Execute-In-Place) wird für allgemeine Anwendungen gemeinsam genutzt. Ein Fenster in die XIP-Zuordnung des Flashs ist für jeden Kern an der Adresse 0x10000000 sichtbar. Das Betriebssystem konfiguriert die XIP-Zuordnung vor dem Starten der Anwendung, wenn die ELF-Datei der Anwendung ein Segment mit den folgenden Eigenschaften enthält:

Die Ladeadresse (wie in der VirtAddr-Spalte des Programmheaders angegeben) ist gleich 0x10000000
Dateioffset und -größe (wie in den Feldern FileSiz und MemSiz im Programmheader angegeben) passen in die ELF-Datei der Anwendung

Wenn in der ELF-Datei der Anwendung ein Programmheader mit diesen Eigenschaften vorhanden ist, wird das XIP-Fenster so positioniert, dass das Segment an 0x10000000 sichtbar ist. Die Datei darf nicht mehr als ein XIP-Segment enthalten und muss auf 0x10000000 verweisen. es kann keine andere Adresse angeben.

ELF-Bereitstellung

RTApp-Images müssen ELF-Dateien sein. Das ELF-Image wird in ein Azure Sphere-Imagepaket eingeschlossen und als Anwendung bereitgestellt. Zum Laden der Anwendung startet das Azure Sphere-Betriebssystem ein ELF-Ladeprogramm, das auf dem Echtzeitkern ausgeführt wird. Das Ladeprogramm verarbeitet jedes LOAD-Segment in der ELF-Datei und lädt es in den Speichertyp, der durch die virtuelle Adresse im Programmheader angegeben ist.

Verwenden Sie arm-none-eabi-readelf.exe -l (klein geschriebenes L), das Teil der GNU Arm Embedded Toolchain ist, um die Programmheader für Ihre Anwendung anzuzeigen. Die virtuelle Adressspalte (VirtAddr), die im Header angezeigt wird, gibt die Zieladresse für das Ladesegment an. Dies bedeutet nicht, dass der Prozessor selbst eine zusätzliche Übersetzung durchführt. Das Azure Sphere ELF-Ladeprogramm verwendet nicht die physische Adresse (PhysAddr).

Betrachten Sie dieses Beispiel:

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

Das Segment bei 0x00100000 ist auf den eng gekoppelten Speicher (TCM) ausgerichtet. Das Ladeprogramm kopiert entweder Daten aus dem Imagepaket in den RAM oder initialisiert den TCM bei Bedarf null.
Das Segment bei 0x10000000 wird dem XIP-Fenster für den Kern zugeordnet. Zur Laufzeit werden Zugriffe auf 0x10000000 + offset in übersetzt <address-of-XIP-segment-in-flash> + offset , wenn sie den Echtzeitkern verlassen.
Das Datensegment an der virtuellen Adresse 0x00100e78 wird TCM zugeordnet.

Überlegungen zur ELF-Laufzeit

Das ELF-Ladeprogramm führt einige der Aufgaben aus, die eine unformatierte Binärdatei (oder ein verketteter Bootloader) beim Start ausführen würde. Insbesondere initialisiert es BSS-Daten (Block-started-by-Symbol) null und kopiert initialisierte, aber änderbare Daten aus schreibgeschütztem Flash in den RAM, entsprechend den Programmheadern. Die Anwendung startet dann und führt ihre eigenen Initialisierungsfunktionen aus. In den meisten Fällen sind Änderungen an vorhandenen Anwendungen nicht erforderlich. Das Nullen der BSS-Daten in der Anwendung ist unnötig, aber harmlos, da das Ladeprogramm den Arbeitsspeicher bereits auf Null gesetzt hat.

Das Kopieren von änderbaren Daten aus Flash in den RAM kann unter bestimmten Umständen zu Problemen führen, je nachdem, wie die ELF-Datei angeordnet ist. Der ELF-Ladeprogramm verarbeitet die Programmheader sequenziell, ohne das Gesamtlayout der Segmente in der Datei zu ändern. Es ordnet dann nicht nur das XIP-Segment selbst 0x10000000 zu, sondern auch alle nachfolgenden Segmente in der richtigen Reihenfolge. Wenn sich die Segmente in der ELF-Datei in sequenzieller Reihenfolge ohne Ausrichtung oder Lücken befinden, kann der Betriebssystemstartcode zeigerarithmetik verwenden, um den Anfang des Datensegments zu ermitteln. Wenn die ELF-Datei jedoch ein anderes Layout aufweist, führt die Zeigerarithmetik nicht zu der richtigen Adresse, sodass der Anwendungsstartcode nicht versuchen darf, den Datenabschnitt zu kopieren. Dies kann Probleme verursachen, wenn die Anwendung oder RTOS einen verketteten Bootloader verwendet oder einen Stack Canary einrichten muss, bevor BSS auf Null gesetzt oder änderbare Daten initialisiert werden.

Speicherziele

Sie können Code als Ziel für TCM, XIP Flash oder SYSRAM verwenden, indem Sie das Skript linker.ld für Ihre Anwendung bearbeiten. Die Azure Sphere-Beispielanwendungen werden über TCM ausgeführt, aber in der Skriptdatei linker.ld für jede Anwendung wird beschrieben, wie stattdessen XIP-Flash als Ziel verwendet wird. Wie das folgende Beispiel zeigt, können Sie ein Beispiel so ändern, dass es unter XIP ausgeführt wird, indem Sie CODE_REGION aliasen und RODATA_REGION in FLASH anstelle des Standard-TCM verwenden:

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

Um zu bestimmen, ob eine kompilierte Anwendung über TCM- oder XIP-Flash ausgeführt wird, verwenden Sie arm-none-eabi-readelf.exe, das Teil der GNU Arm Embedded Toolchain ist. Führen Sie es in der OUT-Datei aus, die sich im gleichen Verzeichnis wie das Imagepaket befindet, und geben Sie das -l Flag (Kleinbuchstaben L) an, um zu sehen, wo der Code und die schreibgeschützten Daten platziert wurden. Code und schreibgeschützte Daten, die sich im Flashspeicher befinden, werden an der Adresse 0x10000000 geladen. Code und Daten in TCM werden in der TCM-Region geladen.

Das folgende Beispiel zeigt eine Anwendung, die im Flashspeicher ausgeführt wird.

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

Speicherort der Vektortabelle

Auf ARMv7-M-Geräten muss die Vektortabelle an einer Potenz von zwei Grenzen ausgerichtet werden, die mindestens 128 Bytes und nicht kleiner als die Größe der Tabelle ist, wie im ARMv7-M-Architekturreferenzhandbuch beschrieben. Jeder E/A RT-Kern auf dem MT3620 unterstützt 100 externe Interrupts. Daher enthält die Tabelle einschließlich des Stapelzeigers und 15 Standardausnahmen 116 4-Byte-Einträge für eine Gesamtgröße von 464 Bytes, die auf 512 Bytes aufgerundet wird.

Wenn der Code über XIP-Flash ausgeführt wird, muss die Vektortabelle an 0x10000000 platziert werden und muss an einer 32-Byte-Grenze innerhalb der ELF-Datei ausgerichtet werden. Wenn der Code nicht über XIP-Flash ausgeführt wird, wird die Tabelle in der Regel am Anfang von TCM0 platziert, was 0x100000 ist. Um sicherzustellen, dass die virtuelle Adresse der Tabelle ordnungsgemäß ausgerichtet ist, platzieren Sie die Vektortabelle in einem dedizierten Abschnitt, und legen Sie CODE_REGION auf die entsprechende Adresse fest.

Die MT3620 BareMetal-Beispiele im Repository für Azure Sphere-Beispiele veranschaulichen dies. Die Deklaration der Vektortabelle in Standard.c legt ihr section -Attribut auf fest.vector_table. Die Linkerskriptaliase CODE_REGION am Anfang von TCM oder XIP, und das ALIGN-Attribut legt die Ausrichtung des Textabschnitts in der ELF-Datei wie folgt fest:

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

Überlegungen zu Echtzeit und Latenz

RTApps und allgemeine Anwendungen kämpfen um Zugriff auf Flashspeicher, auch wenn sie nicht miteinander kommunizieren. Daher kann es bei RTApps, die über XIP-Flash ausgeführt werden, zu einer hohen und unvorhersehbaren Latenz kommen. Schreibvorgänge in Flash, z. B. während eines Updates, können Latenzspitzen von bis zu mehreren hundert Millisekunden umfassen. Abhängig von den Anforderungen Ihrer Anwendung können Sie dies auf verschiedene Arten verwalten:

Platzieren Sie den gesamten Code und alle Daten in TCM. Code, der über TCM ausgeführt wird, ist nicht anfällig für Flashkonflikte.
Teilen Sie Code in kritische und nicht kritische Abschnitte auf, und führen Sie den nicht kritischen Code aus flash aus. Code mit Echtzeitanforderungen, z. B. ein Watchdog-Timer, sollte nicht ausgeführt werden müssen, wenn anderer Code auf den Flash zugreift. Speicherziele beschreibt, wie XIP-Flash anstelle von TCM als Ziel verwendet wird.
Cache verwenden. Eine Anwendung kann die niedrigsten 32 KB TCM als XIP-Cache verwenden. Dieser Ansatz bietet keine harten Echtzeitgarantien im Falle eines Cachefehlers, verbessert aber die typische Leistung, ohne dass Sie den gesamten Code in den RAM verschieben müssen. Informationen zur XIP-Cachekonfiguration finden Sie im "MT3620 M4-Datenblatt".