Linker Script - RAM Größe

[Harald (Gast)]

Hallo,

ich bin gerade dabei ein Programm für den LPC1768 fertig zustellen. 
Jetzt möchte ich aber herausfinden, wie viel ROM und RAM denn mein 
Programm vertilgt. Wie kann ich das herausfinden? Ich seh z.B. am ende 
des LPC1768_RAM.ld Scripts folgendes:

   /* 
    * The ".stack" section is our stack.
    * Here this section starts at the end of the ram segment.
    */
   _estack = ORIGIN(RAM) + LENGTH(RAM);

Bedeutet LENGTH(RAM) die komplette Größe meines RAMs oder nur die der 
globalen Variablen? (Also alles, was nicht auf dem Stack landet).

Hat jemand einen Vorschlag wie ich das bewerkstelligen könnte?

Grüße, Harald

[Werner (Gast)]

gcc-size application.elf

Dem gcc stellst du noch den Crosscompilerprefix voran und die elf-Datei 
ist dein Programm.

[Harald (Gast)]

Werner schrieb:
> gcc-size application.elf
>
> Dem gcc stellst du noch den Crosscompilerprefix voran und die elf-Datei
> ist dein Programm.

Hallo Werner,

dass meine elf-Datei mein Programm ist weiß ich ja (kann aber nicht ins 
ROM geladen werden, dafür ist bin zuständig).
Leider find ich auf dem Arbeits-PC kein gcc-size und habe keine 
root-Rechte. Und das mit dem Crosscompilerprefix versteh ich leider auch 
nicht so recht.
Wenn du mir das näher erläutern könntest wäre das spitze.

Grüße, Harald

[Dr. Sommer (Gast)]

Harald schrieb:
> Leider find ich auf dem Arbeits-PC kein gcc-size und habe keine
> root-Rechte. Und das mit dem Crosscompilerprefix versteh ich leider auch
> nicht so recht.
Wie rufst du deinen GCC auf? Vermutlich mit "arm-none-eabi-gcc"? Dann 
ist "arm-none-eabi-" dein Prefix, und dein "size" ist 
"arm-none-eabi-size". Detaillierter ist aber "arm-none-eabi-readelf -S 
programmdatei.elf".

[Gas (Gast)]

Hätte hierzu auch mal eine Frage.
Mein Board hat 64kB an Speicher zur Verfügung. In der .map Datei des 
kompilierten Programms stehen die Sektoren wie .text, .data und .bss. 
Wenn ich die mir so anschaue stehen da Sachen wie:

.text           0x00000000     0xd678
                0x00000000                __cs3_region_start_rom = .
                0x00000000                _stext = .

...

 *fill*         0x0000d525        0x3 00

...

.data           0x10000000      0x848 load address 0x0000d680

...

.bss            0x10000848     0x75b8 load address 0x0000dec8

...

 COMMON         0x1000347c     0x2dec ./src/can.o

...

.heap           0x10007e00      0x100 load address 0x0000dec8
                0x10007e00                . = ALIGN (0x8)
 *(.heap)
                0x10007f00                . = (. + HEAP_SIZE)
 *fill*         0x10007e00      0x100 00
                0x10007f00                . = ALIGN (0x8)

.stack          0x10007f00      0x100 load address 0x0000dec8
                0x10007f00                . = ALIGN (0x8)
 *(.stack)
                0x10008000                . = (. + STACK_SIZE)

Leider kann ich so eine .map Datei schlecht interpretieren. Kennt jemand 
einen Link der alles gut erklärt? Ich könnt z.B. raten, dass die zweite 
Hex-Zahl bei .text die Länge des ROMs ist. Aber was COMMON sein soll 
usw. ist mir schleierhaft. Oder das fill...

[Gas (Gast)]

Nachtrag:

Mittels arm-none-eabi-size habe ich herausgefunden, dass das Programm 
knapp 37 kB Speicher benötigt. Wenn ich aber in meinem Source-Code einen 
Array erzeuge, der 64kB-37kB = 27kB = 0x6c00 groß ist (uint8_t 
arr[0x6c00]), meldet mir arm-none-eabi-gcc, dass der RAM überläuft. In 
Wirklichkeit darf ich aber lediglich 10436 Bytes (0x28c4) noch belegen 
bevor die Fehlermeldung eintritt. Das bedeutet doch, dass mein Programm 
in Wirklichkeit 55098 = 0xD731 Wieso? Liegt es an irgendwelchen dubiosen 
Debug-Optionen wo noch extra Speicher benötigt wird?

[Ronny S. (duselbaer)]

[entfernt]

LPC1768 hat doch 64k RAM - sorry!

[Ronny S. (duselbaer)]

Lt. Manual hat der LPC

- 32/16 kB of SRAM on the CPU with local code/data bus for 
high-performance CPU access.
- Two/one 16 kB SRAM blocks with separate access paths for higher 
throughput. These SRAM blocks may be used for Ethernet, USB, and DMA 
memory, as well as for general purpose CPU instruction and data storage.

/* Linker script for mbed LPC1768 */
GROUP(-lstdc++ -lsupc++ -lm -lc -lnosys -lgcc)

/* Linker script to configure memory regions. */
MEMORY
{
  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 512K
  RAM (rwx) : ORIGIN = 0x100000C8, LENGTH = 0x7F38

  USB_RAM(rwx) : ORIGIN = 0x2007C000, LENGTH = 16K
  ETH_RAM(rwx) : ORIGIN = 0x20080000, LENGTH = 16K
}

Das hab ich jetzt mal bei der Suche nach LPC1768 Linker Script gefunden. 
Sieht so aus, als ob die 64k RAM nicht fortlaufend addressierbar sind. 
Damit kann Dir alles, was > 16k ist prinzipiell Probleme machen.

RSp

[Gas (Gast)]

Das ist ja wirklich knifflig.

So hab jetzt ein paar Berechnungen gemacht.
Bin die .map Datei durchgegangen und habe folgendes zusammen gezählt:
Es werden momentan (THEORETISCH) 22217 Bytes gebraucht, bei 32 kB RAM 
sind also noch 10551 Bytes frei. Dabei habe ich die Sektoren .data, 
.bss, .heap, .stack und .iap zusammengezählt, plus alles, was so an 
padding betrieben wird.

Dann habe ich im Code einen Array erzeugt, um die fen freien RAM 
auszutesten.
Dabei kam heraus, dass 10436 Bytes frei sind. Das sind 131 Bytes 
weniger! Von wo kommen die?
An den 16kB kanns nicht liegen, da 10436 Bytes < 16kB.

Ich habe dann probiert, den Speicher vom USB und Ethernet zu benutzen, 
also die Kommentarzeichen zu entfernen, kriege beim kompilieren immer 
noch denselben Fehler. Dann habe ich mir das Script für den Linker 
angeschaut, und entdeckt, dass sowas z.B. drinnen steht:

MEMORY
{
  /* bootloader (rx)  : ORIGIN = 0x00000000, LENGTH = 60K */
  rom (rx)  : ORIGIN = 0x00000000, LENGTH = 60K
  ram (rwx) : ORIGIN = 0x10000000, LENGTH = 32K
  /* USE USB RAM */
  ram1 (rwx) : ORIGIN = 0x2007C000, LENGTH = 16k
  /* USE ETH RAM */
  ram2 (rwx) : ORIGIN = 0x20080000, LENGTH = 16k
  config (rx): ORIGIN = 0x0000F000, LENGTH = 4K
}

... /*blablabla*/

  .data :
  {
    _sdata = .;
    __cs3_region_start_ram = .;
    *(.cs3.region-head.ram)
    KEEP(*(.jcr))
    *(.got.plt) *(.got)
    *(.shdata)
    *(.data .data.* .gnu.linkonce.d.*)
    *(.ram)
    . = ALIGN (8);
    _edata = .;
  } >ram AT>rom

  .bss :
  {
    . = ALIGN (8);
    _sbss = .;
    *(.shbss)
    *(.bss .bss.* .gnu.linkonce.b.*)
    *(COMMON)
    _ebss = .;
    *(.ram.b)
    . = ALIGN (8);    
    end = .;
    _end = .;
    __end = .;
  } >ram AT>rom

Bedeutet das denn nicht, dass der Linker dann versucht alles von .data 
und .bss NUR in ram rein zu tun? ram1 und ram2 scheint er 
offentsichtlich ausser Acht zu lassen. Muss man denn dem Linker sagen 
dass ram1 und ram2 auch RAM sind und er da Variablen reinpacken kann? 
Oder erkennt er das automatisch mittels (rwx) in MEMORY{...}?

Und wenn ich den arm-none-eabi-size verwende (Input: elf-Datei des 
kompilierten Programms), sagt er mir das hier:

  text     data   bss     dec     hex    filename
  54912    2120   24348   81380   13de4 /xxx...

.data stimmt mit meiner Berechnung überein, aber wieso ist .bss so viel 
größer als meine Berechnung?

[Werner (Gast)]

Wenn du mehr Infos über den Speicherverbrauch brauchst dann ist:

arm-none-eabi-objdump -ax appl.elf

hilfreicher. Falls bei dir vorhanden kannst du mit:

arm-none-eabi-objdump -ax appl.elf | sort


direkt die Adressen sortieren.

[Werner (Gast)]

Gas schrieb:
> Bedeutet das denn nicht, dass der Linker dann versucht alles von .data
> und .bss NUR in ram rein zu tun? ram1 und ram2 scheint er
> offentsichtlich ausser Acht zu lassen. Muss man denn dem Linker sagen
> dass ram1 und ram2 auch RAM sind und er da Variablen reinpacken kann?
> Oder erkennt er das automatisch mittels (rwx) in MEMORY{...}?

Du musst dem Linker das mit angeben. Die Frage ist aber, ob der Speicher 
zur Startzeit schon "vorhanden" ist oder erst die Periphery 
eingeschaltet werden muss. Du könntest versuchen bss z.B. in ram1 zu 
legen.

[Erik L. (erikl)]

Hallo,

ich kenne arm und gcc nicht, aber Linker-Scripte aus anderen Umgebungen.

In denen wäre es so dass Du wenn Du USB_RAM (ram1) und ETH_RAM(ram2) 
nutzen willst im Code entsprechende Anweisungen geben musst "leg das in 
die spezielle RAM-section"
(z.B. nutzen dann die einen Quellcode-Module ram, die anderen ram1 usw.)
Das kann man beispielsweise machen, indem man eigenen Section-Namen 
vergibt und im Linker-Script entsprechende Anweisungen einführt.
Man muss dann halt vorher ungefähr wissen wer wieviel RAM braucht.

Die RAM-bereiche sind ja offenbar auch adresstechnisch nicht 
fortlaufend, ich weiss nicht, ob der gcc es unterstützt dass man im 
Linker-Script definiert "fuer .bss und .data  benutze ram und wenn voll 
dann laufe über in ram1 und ram2"
bei anderen Toolketten geht das leider nicht auch wenn man es bräuchte 
...

Gruß Erik