AVR-gcc kennt keine Adresslimits?

[batman (Gast)]

Ähm gerade fällt mir zum ersten Mal auf, daß mein avr-gcc munter 
Fantasieadressen über die RAM-Grenzen hinaus produziert. Man merkts nur 
daran, daß das Programm dann nicht so toll läuft.

Blöde Frage aber ist das normal, daß man da selbst aufpassen muß, daß 
die data+bss-sections nicht größer als der vorhandene RAM des AVR 
werden?

Ich meine bei Überschreiten der text-section meckern ja sowohl avr-gcc 
wie auch avrdude aber beim RAM nix? Jetzt bin ich leicht verwirrt.

Aus dem .sym beim ATmega328p:
00800100 D __data_start
...
00800923 B __bss_end
00800923 B _end

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

batman schrieb:
> Blöde Frage aber ist das normal,

Ja, ist es: der Linker kennt praktisch nur Device-Klassen, daher
kann er die Limits des konkreten Devices nicht kennen.  Er würde
dir allerdings meckern, wenn du mehr als 64 KiB versuchst zu
allozieren.

[batman (Gast)]

Achso na dann. Der Stack kommt ja sowieso noch darüber am RAM-Ende mit 
unbekannter Größe oder? Ist das Mist, wenn man ans RAM-Limit kommt.

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

batman schrieb:
> Der Stack kommt ja sowieso noch darüber am RAM-Ende mit unbekannter
> Größe oder?

Ja, der Stack wächst (per default) vom Ende des SRAMs nach unten,
die Variablen dagegen vom Anfang nach oben.  Irgendwann „treffen“ sie
sich dann also.

[batman (Gast)]

Das alte Dilemma. Kann ich im C-Programm einen Test-String als letzte 
globale Variable, also quasi als Puffer anlegen oder läßt sich der 
Linker bei der Adressvergabe nicht reinreden?

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

batman schrieb:
> oder läßt sich der Linker bei der Adressvergabe nicht reinreden?

Weder Compiler noch Linker lassen sich durch irgendeine Anordnung
von irgendwas innerhalb deines Quelltextes beeindrucken.

Du kannst natürlich im Linker eine Guard-Variable explizit hinter dem
Rest platzieren, indem du sie im Compiler in eine eigene Section
packst und im Linkerscript dann arrangierst, dass genau diese Section
am Ende des statisch allozierten RAMs liegt.

[eagle user (Gast)]

Kann man die RAM-Größe nicht im Linker-Script angeben? Genau wie die 
Größe des Flash? Mit dem arm-gcc geht's hier ungefähr so:

MEMORY
{  
   flash_boot    (rx) : ORIGIN = 0x08000000, LENGTH = 16K
   flash_display (rx) : ORIGIN = 0x08008000, LENGTH = 24K
   
   ram_boot      (rw) : ORIGIN = 0x2001c000, LENGTH = 1K
   ram_display   (rw) : ORIGIN = 0x2001f000, LENGTH = 2K
}

SECTIONS
{
  .text : ALIGN(16) SUBALIGN(16) {
     FILL (0xff)
     *(.text)
     *(.text.*)
     *(.rodata)
     *(.rodata.*)
     *(.gcc*)
     . = ALIGN(4);
text_end = .;
  } > flash_display

  .stack : {
stack = .;
    . += 768;
tos = .;
  } > ram_display

  .data : ALIGN(4) SUBALIGN(4) {
data_start = .;
     *(.data)
     *(.data*)
data_end = .;
  } > ram_display AT > flash_display

  .bss : ALIGN(4) SUBALIGN(4) {
bss_start = .;
     *(COMMON)
     *(.bss)
     *(.bss*)
bss_end = .;
  } > ram_display
}

Vielleicht funktioniert es deshalb, weil ich den Stack an den Anfang 
lege?

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

eagle user schrieb:
> Kann man die RAM-Größe nicht im Linker-Script angeben?

Natürlich kann man.  AVR-GCC ist aber deutlich mehr „out of the box“
als ARM-GCC; einen Linkerscript gibt man dort daher normalerweise
nicht selbst an.  Die generischen Linkerscripts funktionieren gut
genug im Zusammenspiel mit dem Startup-Code der avr-libc, als dass
man das alles direkt benutzen kann.  Diese generischen Linkerscripts
sind aber eben, wie ich eingangs schrieb, nicht pro Device vorhanden,
sondern nur grob klassifiziert für jede eigene AVR-Klasse.

Gegen das genannte Problem der Kollision des Stacks mit den statisch
zugewiesenen Daten würde der Linkerscript ohnehin nicht helfen.  Es
bleibt damit immer beim Programmierer abzuschätzen, ob der nach dem
Linken vorhandene freie RAM aller Wahrscheinlichkeit nach ausreichend
für den Stack sein wird.

[batman (Gast)]

Absolut richtig. Ich hätte das Problem nur einen Tag früher erkannt, 
wenn es eine RAM-Overflow-Warnung gegeben hätte. Einen Overflow des (wg. 
RTOS) minimalen main-Stacks hatte ich nicht auf dem Schirm.

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

batman schrieb:
> wenn es eine RAM-Overflow-Warnung gegeben hätte

Daher gab's bei WinAVR immer noch so einen Script, der nach dem
Compilieren den Füllstand der Speicher in % ausgegeben hat.  Hat
Eric Weddington dann als schrägen Hack ins "size"-Programm hinein
gelegt, aber es war von vornherein klar, dass dieser rein
AVR-spezifische Hack es niemals hätte (in dieser Form) in die Binutils
zurück gemacht.

Die Shellscript-Variante bliebe natürlich nach wie vor.

Vorteil ist, dass man auch die Sache mit dem Stack dann schnell
abschätzen lernt.

[stack-heap collider (Gast)]

gcc -fstack-usage benutzen und dann immer schön die *.su Dateien lesen?

Oder -Wstack-usage=200 fürs gröbste..

[Johann L. (gjlayde)]

Jörg W. schrieb:

Und wozu ist das ganze Geraffel dann gut, dass crt.o nach .note.gnu.avr 
packt?

    .section .note.gnu.avr.deviceinfo, "", @note
#define NOTE_NAME "AVR"
#ifdef __AVR_DEVICE_NAME__
    #define DEVICE_NAME STR(__AVR_DEVICE_NAME__)
#else
    #define DEVICE_NAME ""
#endif

    .long .L__note_name_end - .L__note_name_start
    .long .L__desc_end - .L__desc_start
    .long 1 ; Type 1 - this is the only known note type for AVR.
.L__note_name_start:
    .asciz NOTE_NAME
    .balign 4
.L__note_name_end:
.L__desc_start:
#ifdef FLASHSTART
    .long FLASHSTART
#else
    .long 0
#endif
#ifdef PROGMEM_SIZE
    .long PROGMEM_SIZE
#elif FLASHEND > 0
    .long FLASHEND + 1
#else
    .long FLASHEND
#endif
    .long RAMSTART
#ifdef RAMSIZE
    .long RAMSIZE
#elif RAMEND > 0
    .long RAMEND - RAMSTART + 1
#else
    .long RAMEND
#endif
#ifdef E2START
    .long E2START
#else
    .long 0
#endif
#ifdef EEPROM_SIZE
    .long EEPROM_SIZE
#elif E2END > 0
    .long E2END + 1
#else
    .long E2END
#endif
    /* String offsets table.
    Index 0 - Size of offset table in bytes
    Index 1 - Device name byte offset
    */
.L__stroffsettab_start:
.long .L__stroffsettab_end - .L__stroffsettab_start /* Size of index table in bytes */
.long .L__device_name_start - .L__strtab_start /* Byte offset of device name */
.L__stroffsettab_end:
    /* String table for storing arbitrary strings.
    Offsets are stored in the string offset table above */
.L__strtab_start:
    .byte 0
.L__device_name_start:
    .asciz DEVICE_NAME
.L__device_name_end:
    .byte 0

Aus: 
http://svn.savannah.nongnu.org/viewvc/avr-libc/trunk/avr-libc/crt1/gcrt1.S?view=markup

Ich hätte gedacht, dass dass ganau dafür eingeführt wurde?  Immerhin ist 
nie erforderliche Info da.

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

Jo, könnte sein, dass das dafür mal da war – dann aber nicht richtig
zu Ende geführt worden ist.  Könnte man sich wohl zumindest hinsetzen
und es darauf basierend korrekt machen, anders als der schräge, hart
codierte Hack von Eric dazumals.

[Root (Gast)]

Die aktuelleln Versionen vom AtmelStudio geben immer noch einen Meldung 
aus:

        Program Memory Usage   :  140188 bytes   13,4 % Full
        Data Memory Usage     :  74200 bytes   56,6 % Full

Im automatisch genereierten Makefile kann man aber keinen Aufruf dafür 
erkennen.
Weiß jemand wie das funktioniert? Ich würde die Ausgabe gerne in meinen 
manuellen MakeFiles einbauen

[Oliver S. (oliverso)]

avr-size

Oliver

[Stefan F. (Gast)]

Aber immer schon dran denken, dass avr-size nur den Speicherbedarf für 
statische Variablen berücksichtigt. Der Stack und dynamischer Speicher 
sind nicht mit drin. Ich würde daher stets dafür sorgen, dass mindestens 
64 Bytes frei bleiben. Wenn man printf benutzt, dann mindestens 100 
Bytes.

[[e-mail] (Gast)]

Hi,

aber man kann sich doch beliebige neue Speicherklassen im Linkerfile 
erzeugen, explizit seine Variablem lokatieren und diese Klassen auf 
Grösse überwachen. Dann spukt der Linker die entsprechenden Fehler 
aus...

  .calram (NOLOAD) :
  {
     PROVIDE (__calram_start = .) ;
    *(.calram*)
     PROVIDE (__calram_end = .) ;
  } > data
  .data    : AT (ADDR (.text) + SIZEOF (.text))
  {
     PROVIDE (__data_start = .) ;
    *(.data)
    *(.data*)
    *(.rodata)  /* We need to include .rodata here if gcc is used */
    *(.rodata*) /* with -fdata-sections.  */
    *(.gnu.linkonce.d*)
    . = ALIGN(2);
     _edata = . ;
     PROVIDE (__data_end = .) ;
  }  > data
  ASSERT((ADDR(.calram) + SIZEOF(.calram)) <= ADDR(.data), ".calram exceeds page size")

Grüße

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

[e-mail] schrieb:

> aber man kann sich doch beliebige neue Speicherklassen im Linkerfile
> erzeugen,

Klar kann man das.  Aber nochmal: „normale“ AVR-Nutzer mögen sich
eher nicht um den Linkerscript kümmern, denn der, der mit der
Toolchain mitkommt, deckt einen Großteil der Bedürfnisse ab.

Wie schon ausreichend dargelegt worden ist, muss man sowieso extern
den Speicherfüllstand im Blick behalten, damit man ausreichend
Reserve für den Stack hat.  (Der Heap gibt sich selbst Mühe, immer
noch genügend Abstand zum Stack als Reserve zu haben.)

> Dann spukt der Linker die entsprechenden Fehler
> aus...

Na, hoffentlich spukt er nicht … Halloween ist ja schon vorbei. :)

[batman (Gast)]

Ich hab das Feature auch jahrelang nicht vermißt, also ist das schon zu 
verschmerzen, wenns der Einfachheit dient.

[Stefan (Gast)]

es gab da mal avrStackView der bekommt das erstaunlich gut hin.
Stefan