RAM Verbrauch / avr-nm

[Obs (Gast)]

Hi Community,

ich habe eine Frage zur Speicherplatzausnutzung. Mit dem Tool avr-nm 
kann man sich ja anzeigen lassen, wie die einzelnen Symbole im Speicher 
platziert werden und wie viel Speicherplatz sie verbrauchen. Allerdings 
ist mir nicht ganz klar, wieso es bei mir so aussieht:

...
00800200          D __data_start
0080033a 00000012 D resource_helloworld
00800379 00000012 D resource_chunks
008003af 00000012 D resource_pushing
008003c1 00000012 D periodic_resource_pushing
...

Erstmal ist mir nicht ganz klar, wieso __data_start bei 0x800200 beginnt 
und nicht einfach bei 0x800000, weil ich dachte der Offset wäre einfach 
0x800000 bei nem ATmega1281. Und dann verstehe ich nicht, wieso er das 
erste Symbol erst bei 0x80033a ablegt. Und das nächste Symbol ist dann 
auch nicht bei  0x80033a + 0x12 = 0x80034c, sondern erst bei 0x800379. 
Was ist mit den Lücken dazwischen?

Später sieht es dann beispielsweise so aus:
...
00800a54 00000001 b state
00800a55 00000002 b begin
00800a57 00000002 b end
00800a59 00000090 b rxbuf
00800ae9 00000002 b pkt_end
...
Man kann deutlich sehen, dass die Symbole hier ohne Lücken 
aneinanderliegen. Also kann es wohl nicht an irgendwelchen 
Alignment-Sachen liegen, oder? Wieso ist das am Anfang nicht auch so?

Danke schon mal.

[Obs (Gast)]

Mir ist grade aufgefallen, dass der erste Teil in meinem Post ja .data 
ist und der zweite Teil .bss. Aber das ist nicht der Grund für diese 
Lücken. Ich hab nur einfach ein bisschen gescrollt und mir das 
rausgesucht. In der .data-Sektion sieht es später aber auch so aus. 
Beispielsweise:

...
008009f0 00000008 d parent_memb
008009f8 00000001 d dao_sequence
008009f9 0000000e D rpl_of_etx
00800a16 0000000a D ctimer_process
...

Auch hier kann man gut erkennen, dass die Symbole direkt 
aneinanderliegen.

[Jörg W. (dl8dtl) (Moderator)]

Obs schrieb:
> Erstmal ist mir nicht ganz klar, wieso __data_start bei 0x800200 beginnt
> und nicht einfach bei 0x800000, weil ich dachte der Offset wäre einfach
> 0x800000 bei nem ATmega1281.

Der Offset ist 0x800000, richtig, aber im Adressbereich des
Controllers beginnt der eigentliche SRAM erst auf Adresse 0x200,
weil davor noch die CPU- und IO-Register liegen.

> Und dann verstehe ich nicht, wieso er das
> erste Symbol erst bei 0x80033a ablegt.

Da liegen dann vermutlich private Daten (Strings vielleicht?) der
einzelnen Objektmodule, deren Symbole nicht in die globale
Symboltabelle exportiert worden sind.

[Obs (Gast)]

Ah ok, das kann gut sein mit den Strings. Danke :)

Noch eine Frage dazu: Ich habe mir mal die Linker-Skripte angesehen und 
da steht Folgendes:

MEMORY
{
  text      (rx)   : ORIGIN = 0, LENGTH = 128K
  data      (rw!x) : ORIGIN = 0x800060, LENGTH = 8K
  eeprom    (rw!x) : ORIGIN = 0x810000, LENGTH = 4K
  fuse      (rw!x) : ORIGIN = 0x820000, LENGTH = 1K
  lock      (rw!x) : ORIGIN = 0x830000, LENGTH = 1K
  signature (rw!x) : ORIGIN = 0x840000, LENGTH = 1K
}

Da steht jetzt auf einmal ein Offset von 0x800060. Wo kommt die 0x60 
noch her? Heißt das nun, dass die ersten 0x140 CPU- und IO-Register sind 
und dann dementsprechend die eigentlichen Daten erst bei 0x800200 
beginnen?

[marixstorm (Gast)]

Obs schrieb:
> Da steht jetzt auf einmal ein Offset von 0x800060. Wo kommt die 0x60
> noch her? Heißt das nun, dass die ersten 0x140 CPU- und IO-Register sind
> und dann dementsprechend die eigentlichen Daten erst bei 0x800200
> beginnen?

jop.
32Byte Register (0x20) + 64byte IO (0x40). Beides im Speicheradressraum 
gemappt.

[Jörg W. (dl8dtl) (Moderator)]

Obs schrieb:
> Wo kommt die 0x60
> noch her?

Aus dem Linkerscript. ;-)

Die AVRs sind nur ganz grob klassiviziert, damit man nicht für
jeden einzelnen einen eigenen Linkerscript braucht.  Der tatsächliche
Beginn des SRAM wird, wenn er von 0x60 abweicht, vom Compiler dann
überschrieben (indem er dem Linker ein -Tdata=0x800200 mitgibt).