Bellek ve gecikme süresiyle ilgili dikkat edilmesi gerekenleri yönetme

  • Makale

Bu konuda, MT3620 yongasında çalışan gerçek zamanlı uygulamalar için temel bellek kullanımı ve gecikme süresi konuları açıklanmaktadır.

Not

Bellek yapılandırması veya DMA hakkında daha fazla ayrıntı için bkz. MediaTek'ten yayımlanan MT3620 Veri Sayfası; sorular kalırsa, e-posta Azure.Sphere@avnet.comgöndererek Avnet'ten "MT3620 M4 Veri Sayfası"nı isteyebilirsiniz.

Gerçek zamanlı çekirdeklerde bellek düzeni

Aşağıdaki tabloda gerçek zamanlı çekirdeklerde kullanılabilen bellek özetlemektedir:

Bellek türü Temel Adres
TCM 0x00100000
XIP flash 0x10000000
SYSRAM 0x22000000

Her gerçek zamanlı çekirdek, 0x00100000 başlayarak 64 KB'lık üç bankayla eşlenen 192 KB sıkı bağlanmış belleğe (TCM) sahiptir. TCM erişimleri hızlıdır, ancak belleğe yalnızca gerçek zamanlı çekirdek erişebilir. TCM, üst düzey bir uygulamayla veya farklı bir çekirdek üzerinde çalışan gerçek zamanlı özellikli bir uygulamayla (RTApp) paylaşılamaz.

Her gerçek zamanlı çekirdek, 0x22000000 başlayarak eşlenen 64 KB SYSRAM'a sahiptir. DMA denetleyicisi, çevre birimlerinin erişebilmesi için SYSRAM'ı da hedefleyebilir. Gerçek zamanlı çekirdekten SYSRAM'a erişimler, TCM'ye erişimlerden daha yavaştır. TCM'de olduğu gibi SYSRAM başka bir uygulamayla paylaşılamaz.

Yerinde yürütme (XIP) flash belleği üst düzey uygulamalarla paylaşılır. Flash'ın XIP eşlemesine bir pencere, adres 0x10000000 her çekirdek tarafından görülebilir. Uygulamanın ELF dosyası aşağıdaki özelliklere sahip bir kesim içeriyorsa, işletim sistemi XIP eşlemesini uygulamayı başlatmadan önce yapılandırıyor:

  • Yük adresi (Program Üst Bilgisinin VirtAddr sütununda belirtildiği gibi) 0x10000000
  • Dosya uzaklığı ve boyutu (Program Üst Bilgisi'ndeki FileSiz ve MemSiz alanlarında belirtildiği gibi) uygulamanın ELF dosyasına sığar

Uygulamanın ELF dosyasında bu özelliklere sahip bir program üst bilgisi varsa, XIP penceresi segmentin 0x10000000 görünür olacak şekilde konumlandırılır. Dosya birden fazla XIP kesimine sahip olamaz ve 0x10000000 işaret etmelidir; başka bir adres belirtemez.

ELF dağıtımı

RTApp görüntüleri ELF dosyaları olmalıdır. ELF görüntüsü bir Azure Sphere görüntü paketine sarmalanır ve uygulama olarak dağıtılır. Azure Sphere işletim sistemi, uygulamayı yüklemek için gerçek zamanlı çekirdek üzerinde çalışan bir ELF yükleyicisi başlatır. Yükleyici, ELF dosyasındaki her LOAD segmentini işler ve program üst bilgisindeki sanal adres tarafından belirtilen bellek türüne yükler.

Uygulamanızın program üst bilgilerini görüntülemek için GNU Arm Embedded Toolchain'in bir parçası olan (küçük harf L) kullanın arm-none-eabi-readelf.exe -l . Üst bilgide görüntülenen sanal adres sütunu (VirtAddr), yük segmentinin hedef adresini gösterir. Bu, işlemcinin kendisinin herhangi bir ek çeviri yaptığı anlamına gelmez. Azure Sphere ELF yükleyicisi fiziksel adresi (PhysAddr) kullanmaz.

Şu örneği göz önünde bulundurun:

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'daki segment, sıkı bir şekilde bağlanmış belleğe (TCM) hedeflenmiştir. Yükleyici görüntü paketindeki verileri RAM'e kopyalar veya gerektiğinde TCM'yi sıfır başlatır.

  • 0x10000000'daki segment, çekirdeğin XIP penceresine eşlenir. Çalışma zamanında, erişimleri 0x10000000 + offset gerçek zamanlı çekirdekten ayrıldığında öğesine çevrilir <address-of-XIP-segment-in-flash> + offset .

  • Sanal adres 0x00100e78 veri kesimi TCM ile eşlenir.

ELF çalışma zamanıyla ilgili dikkat edilmesi gerekenler

ELF yükleyicisi, bir ham ikilinin (veya zincirli önyükleyicinin) başlatma sırasında gerçekleştireceği görevlerin bazılarını gerçekleştirir. Özellikle, program üst bilgilerine göre, block-started-by-symbol (BSS) verilerini sıfırdan başlatır ve başlatılan ancak değiştirilebilir verileri salt okunur yanıp sönen RAM'e kopyalar. Ardından uygulama başlatılır ve kendi başlatma işlevlerini çalıştırır. Çoğu durumda, mevcut uygulamalarda değişiklik yapılması gerekmez. Yükleyici belleği zaten sıfırladığından, uygulamadaki BSS verilerinin sıfırlanması gereksiz ama zararsızdır.

Flash'tan RAM'e değiştirilebilir verilerin kopyalanması, ELF dosyasının nasıl yerleştirilebileceğine bağlı olarak bazı durumlarda sorunlara yol açabilir. ELF yükleyicisi, dosyadaki segmentlerin genel düzenini değiştirmeden program üst bilgilerini sırayla işler. Daha sonra yalnızca XIP segmentinin kendisini 0x10000000 değil, sonraki segmentleri de sırayla eşler. ELF dosyasındaki segmentler herhangi bir hizalama veya boşluk olmadan sıralı sıradaysa, işletim sistemi başlangıç kodu veri kesiminin başlangıcını bulmak için işaretçi aritmetiğini kullanabilir. ANCAK ELF dosyasının düzeni farklıysa, işaretçi aritmetiği doğru adresle sonuçlanmaz, bu nedenle uygulama başlatma kodu veri bölümünü kopyalamayı denememelidir. Uygulama veya RTOS zincirlenmiş bir önyükleyici kullanıyorsa veya BSS'yi sıfırlamadan veya değiştirilebilir verileri başlatmadan önce yığın kanaryasını ayarlaması gerekiyorsa bu sorunlara neden olabilir.

Bellek hedefleri

Uygulamanız için linker.ld betiğini düzenleyerek TCM, XIP flash veya SYSRAM'da kod hedefleyebilirsiniz. Azure Sphere örnek uygulamaları TCM'den çalıştırılır, ancak her uygulamanın linker.ld betik dosyası bunun yerine XIP flash'ın nasıl hedeflenemez olduğunu açıklar. Aşağıdaki örnekte gösterildiği gibi, varsayılan TCM yerine CODE_REGION ve RODATA_REGION FLASH olarak RODATA_REGION XIP üzerinde çalışacak şekilde değiştirebilirsiniz:

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

Derlenmiş bir uygulamanın TCM'den mi yoksa XIP flash'tan mı çalıştırıldığını belirlemek için arm-none-eabi-readelf.exeGNU Arm Embedded Toolchain'in bir parçası olan kullanın. Görüntü paketiyle aynı dizinde yer alan .out dosyasında çalıştırın ve kodun -l ve salt okunur verilerin nereye yerleştirildiğini görmek için (küçük L) bayrağını belirtin. Flash bellekteki kod ve salt okunur veriler 0x10000000 adrese yüklenir; TCM'deki kod ve veriler TCM bölgesine yüklenir.

Aşağıdaki örnekte flash bellekten çalışan bir uygulama gösterilmektedir.

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

Vektör tablosu konumu

ARMv7-M cihazlarında vektör tablosu, ARMv7-M Mimari Başvuru Kılavuzu'nda belirtildiği gibi en az 128 bayt ve tablonun boyutundan küçük olmayan iki güç sınırına hizalanmalıdır. MT3620 üzerindeki her G/Ç RT çekirdeği 100 dış kesmeyi destekler. Bu nedenle, yığın işaretçisi ve 15 standart özel durum da dahil olmak üzere, tablonun toplam boyutu 464 bayt olan ve 512 bayt'a kadar yuvarlayan 116 adet 4 baytlık girdisi vardır.

Kod XIP flash'tan çalıştırıldığında vektör tablosu 0x10000000 yerleştirilmelidir ve ELF dosyasının içindeki 32 baytlık sınıra hizalanmalıdır. Kod XIP flash'tan çalıştırılmadığında, tablo genellikle 0x100000 TCM0'nin başına yerleştirilir. Her iki durumda da, tablonun sanal adresinin doğru hizalandığından emin olmak için vektör tablosunu ayrılmış bir bölüme yerleştirin ve CODE_REGION uygun adrese ayarlayın.

Azure Sphere Örnekleri deposundaki MT3620 BareMetal örnekleri bunun nasıl yapılacağını gösterir. main.c içindeki vektör tablosunun bildirimi, özniteliğini section olarak .vector_tableayarlar. Bağlayıcı betiği diğer adları TCM veya XIP'nin başına CODE_REGION ve ALIGN özniteliği de ELF dosyası içindeki metin bölümünün hizalamasını aşağıdaki gibi ayarlar:

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

Gerçek zamanlı ve gecikme süresiyle ilgili dikkat edilmesi gerekenler

RTApps ve üst düzey uygulamalar, birbirleriyle iletişim kurmasalar bile flash belleğe erişim için kullanılır. Sonuç olarak, XIP flash'tan çalışan RTApps yüksek ve öngörülemeyen gecikme süresiyle karşılaşabilir. Güncelleştirme sırasında olduğu gibi flash'a yazma işlemleri, birkaç yüz milisaniyeye kadar gecikme süresi artışları içerebilir. Uygulamanızın gereksinimlerine bağlı olarak, bunu çeşitli yollarla yönetebilirsiniz:

  • Tüm kodu ve verileri TCM'ye yerleştirin. TCM'den çalışan kod, flash çekişmeye karşı savunmasız değildir.

  • Kodu kritik ve kritik olmayan bölümlere ayırın ve kritik olmayan kodu flash'tan çalıştırın. İzleme zamanlayıcı gibi gerçek zamanlı gereksinimleri olan kodun, diğer kod flash'a erişirken çalıştırılması gerekmez. Bellek hedefleri , TCM yerine XIP flash'ı hedeflemeyi açıklar.

  • Önbelleği kullanın. Bir uygulama XIP önbelleği olarak en düşük 32 KB TCM kullanabilir. Bu yaklaşım, önbellek kaçırma durumunda gerçek zamanlı garanti sağlamaz, ancak tüm kodu RAM'e taşımanıza gerek kalmadan tipik performansı geliştirir. XIP önbellek yapılandırması hakkında bilgi için "MT3620 M4 Veri Sayfası" bölümüne bakın.