Speicherverwaltung Atmega8 was geht wohin? --> C

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

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.

@  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

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

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

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.

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

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

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.