Megosztás a következőn keresztül:

Memória- és késéskezeléssel kapcsolatos szempontok

  • Cikk

Ez a témakör az MT3620 chipen futó valós idejű alkalmazások alapvető memóriahasználati és késési szempontjait ismerteti.

Megjegyzés

A memóriakonfigurációval vagy a DMA-val kapcsolatos további információkért lásd a MediaTek közzétett MT3620-adatlapját; Ha a kérdések továbbra is fennállnak, e-mailben kérheti az "MT3620 M4 Adatlap" kérését Azure.Sphere@avnet.comaz Avnettől.

Memóriaelrendezés a valós idejű magokon

Az alábbi táblázat összefoglalja a valós idejű magokon elérhető memóriát:

Memória típusa Alapcím
TCM 0x00100000
XIP flash 0x10000000
SYSRAM 0x22000000

Minden valós idejű mag 192 KB szorosan összekapcsolt memóriával (TCM) rendelkezik, amely három 64 KB-os bankban van leképezve 0x00100000-től kezdve. A TCM-hozzáférések gyorsak, de csak a valós idejű magok férhetnek hozzá a memóriához. A TCM nem osztható meg magas szintű alkalmazással vagy valós idejű, más magon futó alkalmazással (RTApp).

Minden valós idejű mag 64 KB SYSRAM-tal is rendelkezik, amely 0x22000000-től kezdve van leképezve. A DMA-vezérlő a SYSRAM-et is megcélozhatja, hogy a perifériák elérhessék azt. A SYSRAM valós idejű magról való elérése lassabb, mint a TCM-hez való hozzáférés. A TCM-hez hasonlóan a SYSRAM nem osztható meg másik alkalmazással.

A helyben történő végrehajtás (XIP) flash memóriája magas szintű alkalmazásokkal van megosztva. A villám XIP-leképezésének ablaka látható az egyes magok számára a cím 0x10000000. Az operációs rendszer az alkalmazás indítása előtt konfigurálja az XIP-leképezést, ha az alkalmazás ELF-fájlja olyan szegmenst tartalmaz, amely a következő tulajdonságokkal rendelkezik:

  • A betöltési cím (a Programfejléc VirtAddr oszlopában megadottak szerint) egyenlő 0x10000000
  • A fájl eltolása és mérete (a Program fejlécének FileSiz és MemSiz mezőiben megadottak szerint) illeszkedik az alkalmazás ELF-fájljához

Ha egy ilyen tulajdonságokkal rendelkező programfejléc található az alkalmazás ELF-fájljában, az XIP-ablak úgy lesz elhelyezve, hogy a szegmens látható legyen a 0x10000000. A fájl legfeljebb egy XIP-szegmenst tartalmazhat, és 0x10000000 kell mutatnia; nem adhat meg más címet.

ELF üzembe helyezése

Az RTApp-képeknek ELF-fájloknak kell lenniük. Az ELF-rendszerkép egy Azure Sphere-rendszerképcsomagba van csomagolva, és alkalmazásként van üzembe helyezve. Az alkalmazás betöltéséhez az Azure Sphere operációs rendszer elindít egy ELF-betöltőt, amely a valós idejű magon fut. A betöltő feldolgozza az ELF-fájl minden LOAD szegmensét, és betölti azt a program fejlécében lévő virtuális cím által jelzett memóriatípusba.

A GNU Arm Embedded toolchain részét képező (kisbetűs L) használatával arm-none-eabi-readelf.exe -l megjelenítheti az alkalmazás programfejléceit. A fejlécben megjelenő virtuális cím oszlop (VirtAddr) a terhelési szegmens célcímét jelzi. Ez nem jelenti azt, hogy maga a processzor végez bármilyen további fordítást. Az Azure Sphere ELF-betöltője nem használja a fizikai címet (PhysAddr).

Vegyük például a következőt:

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

  • A 0x00100000 szegmense szorosan összekapcsolt memóriára (TCM) irányul. A betöltő vagy adatokat másol a képcsomagból a RAM-ba, vagy szükség szerint nullával inicializálja a TCM-et.

  • A szegmens 0x10000000 a mag XIP-ablakára van leképezve. Futásidőben a hozzáférések 0x10000000 + offset a valós idejű mag elhagyásakor lesznek lefordítva <address-of-XIP-segment-in-flash> + offset .

  • A virtuális cím 0x00100e78 adatszegmens tCM-re van leképezve.

Az ELF futtatókörnyezetének szempontjai

Az ELF-betöltő végrehajtja azokat a feladatokat, amelyeket egy nyers bináris (vagy láncolt bootloader) végrehajtana az indításkor. Pontosabban, ez nulla inicializálja blokk-started-by-symbol (BSS) adatok és másolatok inicializált, de módosítható adatok írásvédett flash RAM szerint a program fejlécek. Az alkalmazás ezután elindítja és futtatja a saját inicializálási függvényeit. A legtöbb esetben nem szükséges módosítani a meglévő alkalmazásokat. Az alkalmazásban a BSS-adatok nullázása szükségtelen, de ártalmatlan, mivel a betöltő már nullázta a memóriát.

A mutable adatok flashről RAM-ra másolása bizonyos körülmények között problémákat okozhat, attól függően, hogy az ELF-fájl hogyan van elhelyezve. Az ELF-betöltő sorrendben dolgozza fel a programfejléceket anélkül, hogy módosítaná a fájl szegmenseinek általános elrendezését. Ezután nemcsak magát az XIP-szegmenst képezi le 0x10000000, hanem az azt követő szegmenseket is. Ha az ELF-fájl szegmensei egymás utáni sorrendben vannak igazítás vagy hézagok nélkül, az operációs rendszer indítási kódja a mutató aritmetikai használatával megkeresheti az adatszegmens kezdetét. Ha azonban az ELF-fájl elrendezése eltér, a mutató számtani adatai nem a megfelelő címet eredményezik, ezért az alkalmazás indítási kódjának nem szabad megpróbálnia másolni az adatszakaszt. Ez problémákat okozhat, ha az alkalmazás vagy az RTOS láncolt rendszertöltőt használ, vagy a BSS nullázása vagy a módosítható adatok inicializálása előtt be kell állítania egy veremtárat.

Memóriacélok

Az alkalmazás linker.ld szkriptjének szerkesztésével megcélozhatja a kódot A TCM, az XIP flash vagy a SYSRAM használatával. Az Azure Sphere-mintaalkalmazások a TCM-ből futnak, de az egyes alkalmazások linker.ld szkriptfájlja leírja, hogyan célozhatók meg az XIP flashek. Ahogy az alábbi példában látható, a minta XIP-n való futtatására úgy módosíthatja, hogy az alapértelmezett TCM helyett a CODE_REGION, a RODATA_REGION pedig FLASH értékre van kapcsolva:

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

Annak megállapításához, hogy egy lefordított alkalmazás TCM-ről vagy XIP flashről fut-e, használja arm-none-eabi-readelf.exea parancsot, amely a GNU Arm Embedded Toolchain része. Futtassa a .out fájlon, amely ugyanabban a könyvtárban található, mint a képcsomag, és adja meg a -l (kisbetűs L) jelölőt a kód és az írásvédett adatok elhelyezésének megtekintéséhez. A flash memóriában lévő kód- és írásvédett adatok a 0x10000000 címére töltődnek be; A kód és a TCM adatai a TCM-régióba töltődnek be.

Az alábbi példa egy flash memóriából futó alkalmazást mutat be.

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

Vektortábla helye

Az ARMv7-M-eszközökön a vektortáblát egy legalább 128 bájtos és a tábla méreténél nem kisebb, kétirányú határvonalhoz kell igazítani az ARMv7-M architektúra referencia-kézikönyvében leírtak szerint. Az MT3620 minden I/O RT magja 100 külső megszakítást támogat. Ezért a veremmutatóval és 15 szabványos kivétellel együtt a táblázat 116 4 bájtos bejegyzéssel rendelkezik, összesen 464 bájt méretben, amely 512 bájtra kerekít.

Ha a kódot XIP flashből futtatja, a vektortáblát 0x10000000 kell elhelyezni, és az ELF-fájl 32 bájtos határához kell igazítani. Ha a kód nem XIP flashből fut, a táblázat általában a TCM0 elejére kerül, amely 0x100000. Mindkét esetben a tábla virtuális címének megfelelő igazítása érdekében helyezze a vektortáblát egy dedikált szakaszba, és állítsa CODE_REGION a megfelelő címre.

Az Azure Sphere-minták adattárában található MT3620 BareMetal-minták bemutatják ennek módját. A main.c vektortábla deklarációja az attribútumát értékre .vector_tableállítjasection. A linker szkript aliasai CODE_REGION a TCM vagy az XIP elejére, az ALIGN attribútum pedig a szövegszakasz igazítását állítja be az ELF-fájlban az alábbiak szerint:

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

Valós idejű és késéssel kapcsolatos szempontok

Az RTApps és a magas szintű alkalmazások akkor is képesek hozzáférni a flash memóriához, ha nem kommunikálnak egymással. Ennek eredményeképpen az XIP flashből futó RTApps nagy és kiszámíthatatlan késéssel szembesülhet. A flash típusú írások, például egy frissítés során, akár több száz ezredmásodpercnyi késési csúcsot is magukban foglalhatnak. Az alkalmazás igényeitől függően ezt többféleképpen is kezelheti:

  • Helyezze el az összes kódot és adatot a TCM-ben. A TCM-ből futó kód nem sebezhető a flashért való versengés miatt.

  • Ossza fel a kódot kritikus és nem kritikus szakaszokra, és futtassa a nem kritikus kódot flashből. A valós idejű követelményekkel( például watchdog időzítővel) rendelkező kódnak nem kell futnia, amikor más kód hozzáfér a flashhez. A memóriacélok azt írják le, hogyan célozhatja meg az XIP flasht a TCM helyett.

  • Használja a gyorsítótárat. Az alkalmazások a legalacsonyabb 32 KB TCM-et használhatják XIP-gyorsítótárként. Ez a megközelítés nem biztosít nehéz valós idejű garanciákat gyorsítótár-hiba esetén, de javítja a tipikus teljesítményt anélkül, hogy az összes kódot át kellene helyeznie a RAM-ba. Az XIP-gyorsítótár konfigurálásáról az "MT3620 M4 Adatlap" című témakörben olvashat.