Speicherverwaltung Atmega8 was geht wohin? --> C

[michael (Gast)]

Hallo zusammen

Da mein Flash langsam uberquillt frage ich mich wo ich optimieren soll 
;-) Ja ich weiss ich könnte einen grösseren Stein nehmen.

Kann mir jemand sagen was mit der Compiler Aussage gemeint ist.

Device: atmega8

Program:    7794 bytes (95.1% Full)
(.text + .data + .bootloader)

Data:        239 bytes (23.3% Full)
(.data + .bss + .noinit)

Wenn ich es richtig verstehe dann ist
Programm: --> Flash
.data der Maschinencode des Programms.
.bootloader der Maschinencode des Bootloaders
.text --> Sind das const deklarierte Variabeln?

Data:--> RAM
.data temporäre Variabeln die als zB. als auto deklariert wurden. 
statische Variabeln die als static deklariert wurden Sie bleiben aber 
dauerhaft im RAM
.bss   --> ?
.noint --> ?

Den Bedarf des Stack sehe ich nicht da er zur Laufzeit belegt wird. --> 
richtig?

Wie kann ein Überlaufen des RAM zur Laufzeit erkannt werden bzw. geloggt 
:-)


Wenn das richtig ist könnte ich const definierte Variabeln ins EEPROM 
auslagern?
Ebenso könnte ich mehrfach vorkommende Ausdrücke in Funtionen packen.
Die Variabelngrösse überdenken.
Was habe ich noch vergessen?

PS. Ich kann kein Assembler, ich weiss das damit fähige Leute sehr 
optimierten Code erzeugen können. Bitte keinen Glaubenskrieg um die 
beste Programmiersprache. Jede hat Ihre Vor und Nachteile.

Besten Dank für eure Rückmeldungen.

Gruss Michael

[Μαtthias W. (matthias)]

Hi

Program (Flash):
.text        -> Maschinencode
.data        -> Initialierungswerte für globale Variablen (1)
.bootloader  -> vermutlich .text + .data Bootloader

Data (RAM):
.data        -> Globale Variablen mit != 0 initialisiert
.bss         -> Globale Variablen mit 0 initialisiert
.noint (2)   -> Nicht initialisiert globale Variablen

(1): Globale Variablen
Alle Variablen die außerhalb einer Funktion deklariert wurde

(2): .noint
Über spezielle Attribut markierte Variablen werden beim Programmstart 
nicht initialisiert und überleben so z.B. einen Watchdogreset.

Matthias

[Karl H. (kbuchegg)]

michael schrieb:

> Wenn ich es richtig verstehe dann ist
> Programm: --> Flash
> .data der Maschinencode des Programms.
> .bootloader der Maschinencode des Bootloaders
> .text --> Sind das const deklarierte Variabeln?

kommt auf den Compiler an.
Beim GCC nein, zb beim IAR ja

>
> Data:--> RAM
> .data temporäre Variabeln die als zB. als auto deklariert wurden.
> statische Variabeln die als static deklariert wurden Sie bleiben aber
> dauerhaft im RAM
> .bss   --> ?
> .noint --> ?
>
> Den Bedarf des Stack sehe ich nicht da er zur Laufzeit belegt wird. -->
> richtig?

Alles richtig.

> Wie kann ein Überlaufen des RAM zur Laufzeit erkannt werden bzw. geloggt
> :-)

Gar nicht.
Mit viel Glück merkst du es, weil dein Programm seltsame Sachen macht.
Es gibt Strategien, mit denen am Programmanfang das SRAM mit einem 
Muster gefüllt wird und wenn nach einer gewissen Zeit vom Muster nichts 
mehr im SRAM erkennbar ist, dann ist wohl der Stack in den Bereich der 
Variablen hineingewachsen.

> Wenn das richtig ist könnte ich const definierte Variabeln ins EEPROM
> auslagern?

könntest du.
Aber erst mal sollte man zusehen, vom Flash ein paar Bytes 
freizubekommen. Meistens geht am Anfang noch ziemlich viel, was man 
vereinfachen und optimieren kann.

> Ebenso könnte ich mehrfach vorkommende Ausdrücke in Funtionen packen.
> Die Variabelngrösse überdenken.
> Was habe ich noch vergessen?

Das sind schon 2 sehr gute und wichtige Punkte.

[Krapao (Gast)]

FAQ =>

.text der Maschinencode des Programms.
.data Werte der initialisierten Variablen
.bootloader der Maschinencode des Bootloaders

http://en.wikipedia.org/wiki/Data_segment

> Den Bedarf des Stack sehe ich nicht da er zur Laufzeit belegt wird.
> Wie kann ein Überlaufen des RAM zur Laufzeit erkannt werden bzw. geloggt

FAQ => Stackviewer + Diskussion
Beitrag "StackViewer (RAM Rechner) für WinAVR"

> Wenn das richtig ist könnte ich const definierte Variabeln ins EEPROM
> auslagern?

Schmälert ggf. .data oder .txt aber weil du für den Zugriff Funktionen 
brauchst, bläst es .text auch wieder auf.

> Ebenso könnte ich mehrfach vorkommende Ausdrücke in Funktionen packen.

Um .text aufzublasen?

> Die Variabelngrösse überdenken.

Unbedingt.

> Was habe ich noch vergessen?

Überlege, was an Variablen initialisiert sein muss. Jede 
uninitialisierte Variable rutscht aus .data d.h. dem fast vollen Flash 
raus und in .bss oder den Stack d.h. den fast leeren RAM rein.

[Falk B. (falk)]

@  michael (Gast)

>Da mein Flash langsam uberquillt frage ich mich wo ich optimieren soll
>;-) Ja ich weiss ich könnte einen grösseren Stein nehmen.

Schwer zu sagen ohne Quelltext.

>Program:    7794 bytes (95.1% Full)
>(.text + .data + .bootloader)

Flash

>Data:        239 bytes (23.3% Full)
>(.data + .bss + .noinit)

RAM

>Wenn ich es richtig verstehe dann ist
>Programm: --> Flash

Ja.

>.data der Maschinencode des Programms.
>.bootloader der Maschinencode des Bootloaders

Ja.

>.text --> Sind das const deklarierte Variabeln?

Nein, das sind diverse Textkonstanten, welche mit PGM etc. verwendet 
werden. Das können auch Arrays sein. CONST Variablen liegen beim AVR-GCC 
auch im RAM!

>Data:--> RAM

Ja.

>.data temporäre Variabeln die als zB. als auto deklariert wurden.

Nein.

>statische Variabeln die als static deklariert wurden Sie bleiben aber
>dauerhaft im RAM

Ja.

>.bss   --> ?

Initialisierte, statische Variablen.

>.noint --> ?

Nichtinitialisierte, statische Variablen.

>Den Bedarf des Stack sehe ich nicht da er zur Laufzeit belegt wird. -->
>richtig?

Ja.

>Wie kann ein Überlaufen des RAM zur Laufzeit erkannt werden bzw. geloggt
>:-)

Wenn dein uC abschmiert ;-)
Such mal im Forum, da gibt es diverse Ansätze.

>Wenn das richtig ist könnte ich const definierte Variabeln ins EEPROM
>auslagern?

Nein.

>Ebenso könnte ich mehrfach vorkommende Ausdrücke in Funtionen packen.

Ja.

>Die Variabelngrösse überdenken.

Ja.

>Was habe ich noch vergessen?

http://www.mikrocontroller.net/articles/AVR-GCC-Codeoptimierung

>PS. Ich kann kein Assembler, ich weiss das damit fähige Leute sehr
>optimierten Code erzeugen können.

Lohnt sich zu 99% nicht, der AVR-GCC ist meist schon ganz gut.

MfG
Falk

[Μαtthias W. (matthias)]

Falk Brunner schrieb:
> @  michael (Gast)
>
>>Da mein Flash langsam uberquillt frage ich mich wo ich optimieren soll
>>;-) Ja ich weiss ich könnte einen grösseren Stein nehmen.
>
>>.text --> Sind das const deklarierte Variabeln?
>
> Nein, das sind diverse Textkonstanten, welche mit PGM etc. verwendet
> werden. Das können auch Arrays sein. CONST Variablen liegen beim AVR-GCC
> auch im RAM!

Nein. .text ist Maschinencode.

>>.bss   --> ?
>
> Initialisierte, statische Variablen.

Siehe oben. Mit 0 initialisierte Variablen. Siehe 
http://de.wikipedia.org/wiki/A.out

>>Wenn das richtig ist könnte ich const definierte Variabeln ins EEPROM
>>auslagern?
>
> Nein.

Kann man. Ist aber etwas Handarbeit beim Zugriff. Die Daten landen dann 
in der Sektion .eeprom und müssen beim Flashen auch dort abgelegt 
werden.

>>Ebenso könnte ich mehrfach vorkommende Ausdrücke in Funtionen packen.
>
> Ja.

Auf jeden Fall. Hilft aber nur wenn die Ausdrücke komplex genug sind das 
der Funktionsoverhead den Spareffekt nicht auffrisst.

Matthias

[Peter D. (peda)]

michael schrieb:
> Da mein Flash langsam uberquillt frage ich mich wo ich optimieren soll

Welche Optimierung benutzt Du denn?
Default sollte man -Os nehmen.

Schreibst Du Spaghetticode oder benutzt Du Funktionen?
Sachen die ähnlich 2- oder mehrmals benötigt werden, sollte man in 
Funktionen auslagern, dann kosten sie nur einmal Code.

"int" ist auf einem 8Bitter nicht optimal. Wann immer möglich, bevorzuge 
"uint8_t".

Peter

[michael (Gast)]

Danke an alle von euch.

@Peter Ich benutze eigentlich nur die -Os. Giebt es überhaubt einen 
Grund für die anderen Optionen ?

Jeder behauptet von sich ja er produziere keinen Spagetticode ;-)

Ich packe jede logische Funktion in einzelne Module und  kapsele sie 
über die .h Datei. auf die Module wird dann nur über Funktionen 
zugegriffen. Ich verwende auch wenn immer möglich pointer als 
Variabelnübergabe.
Soweit die Theorie, aber Nowbody is perfect ;-)


@Falk Brunner danke für den Codeoptimierungslink den hatte ich 
übersehen.

Ich habe den Missetäter wohl gefunden. Ein Modul das ein IR Empfänger 
für NEC Fernbedienungen ist. Er braucht 732 Byte Flash und 15Byte Ram. 
Das ist etwas viel denke ich.

Das Modul stammte noch aus meinen Anfängen mit uC , daher ist dort 
vermutlich noch viel Potenzial.
Habe C auf PC gelernt da hat mann ja heute keine Recourcen Probleme mehr 
weil Speicher immer da ist. ;-)


Gruss und dank an alle.
Michael

[Läubi .. (laeubi)]

Achte vor allem mal darauf ob eventuell Funktionen als inline markiert 
sind wenn die häufig aufgerufen werden kann das den Flash auch gut 
vollstopfen.

[Peter D. (peda)]

michael schrieb:
> Ich verwende auch wenn immer möglich pointer als
> Variabelnübergabe.

Was soll das bringen?

Pointer sind deutlich teurer als Register.
Bis zu 3 Variablen werden in der Regel in Registern übergeben.

Pointer verwendet man nur für Strings oder größere Structs.


Peter

[Peter D. (peda)]

Läubi .. schrieb:
> Achte vor allem mal darauf ob eventuell Funktionen als inline markiert
> sind

Wenn man das macht, wird man sich ja was dabei gedacht haben.

Beim AVR-GCC ist leider die Standardeinstellung, daß er heimlich 
inlined.
Daher ist dieser Schalter sehr sinnvoll:
-fno-inline-small-functions


Peter

[Läubi .. (laeubi)]

Peter Dannegger schrieb:
> Wenn man das macht, wird man sich ja was dabei gedacht haben.

normalerweise ja aber

michael schrieb:
> Das Modul stammte noch aus meinen Anfängen mit uC

kann man schon mal schnell was übernehmen das man irgendwo gelesen hat.

Peter Dannegger schrieb:
> Beim AVR-GCC ist leider die Standardeinstellung, daß er heimlich
> inlined.

Ist ja nicht schlimm solange noch ausreichend Platz vorhanden ist.