Verständnisfrage Heap

Hallo,

bei diesen Thema oder besser gesagt deinen Fragen kann ich dir nur den 
folgenden Link ans Herz legen wenn du mit externen RAM arbeiten 
möchtest.

http://www.nongnu.org/avr-libc/user-manual/malloc.html

CA Dirk

Der Techniker wrote:
> Hallo Dirk,
>
> Danke für deinen Tipp.
>
> Diese Seite kenne ich schon und beantwortet leider nicht meine Frage..
> (oder habe ich da was überlesen?)

Na, Teilweise. Oder besser gesagt wie du den speicher aufteilen kannst 
mit den avr-gcc Optionen.
Deine restlichen Überlegungen über die Zuteilung des RAM war schon so 
korrekt gewesen. Die beste Aufteilung ist wenn man externen Speicher hat 
den internen komplett für den Stack zu benutzen, da auf diesen sehr 
schnell zugegriffen werden kann und so lokale Variablen in Funktionen 
genauso schnell sind wie ohne externen RAM.
 In das externe RAM sollte dann eigentlich nur noch der Rest rein ( 
Heap, .bss und .data, siehe Grafiken zu malloc). Darauf erfolgt der 
Zugriff geringfügig langsamer ( mindestens 1 Takt bei 0 Waitstates ) was 
aber nicht stört, da diese Variablen nicht so oft gebraucht werden im 
Idealfall.

> Gruß,
> _Techniker_

Der Techniker wrote:
> Wenn ich selber nicht explizit malloc und Konsorten verwende, gibt es
> dann auch keinen Heap?!?
Es gibt ihn. "Heap" ist nicht viel mehr als ein Speicherbereich, von dem 
zumindest die Startadresse bekannt ist (Endadresse für Tests auf "Heap 
voll"). Vgl. head_start, heap_end auf der von Dirk Boßwick genannten 
Seite.

> Globale Variablen laden doch im .data bzw .bss und lokale Variablen auf
> dem Stack.
und evtl. Parameter und Rücksprungadressen

> Gibt es evtl. auch eine Situation (Makro, Präprozessoranweisung ect.),
> welche Daten auf dem Heap ablegen?
Über das im Dokument der avr-libc gezeigt hinausgehend wird es etwas 
kniffig: Man kann per section-attribute Funktionen und Variablen 
bestimmten sections zuweisen, siehe dazu die Dokumentation des gcc 
(gcc.gnu.org). Diese sections kann man per Linker auf bestimmte 
Speicherbereiche zuweisen, siee dazu die Dokumentation der GNU Binutils 
(ld). Variablen kann man z.B. ein ".data2" "compiler-Section"zuweisen 
und für die Elemente dieser "compiler-Section" eine "Linker-section"  im 
externen RAM anlegen. Meines Wissens ist das aber in den Linker-Skripten 
der avr-libc nicht vorgekaut. Evtl. reicht es mit 
"section-start"-Linker-Option Startadressen manuell festzulegen. Würde 
das aber durch eigenes Linkerscript machen (mit einem aus der avr-libc 
anfangen und erweitern). Weiterhin muss man dann noch eine 
Kopierfunktion schreiben, die die Initialwerte von "data2" Variablen ins 
RAM kopiert. Ähnliches bei einem "bss2", dann aber den davon belegten 
RAM-Speicher beim Startup mit nullen voll schreiben. Alles in Allem 
nicht ganz simpel und vielleicht gar nicht nötig. Evtl. weiss jemand 
noch eine einfacheren Ansatz.

Falls man dennoch nicht allen Variablen Speicher im externen RAM 
zuweisen will (stack sollte immer intern bleiben), vielleicht doch mit 
"malloc und Konsorten" arbeiten. Wenn man das etwas umsichtig macht und 
nicht verschachtelt und zudem noch verschieden große Speicherbereiche 
"malloct" und "freet", spricht meiner Meinung nichts dagegen (jaja, er 
hat "Johova" gesagt).

> Hintergrund:
> Ich möchte schon gern wissen, was im Ram passiert und wie ich den
> RAM-Aufbau (mit dem Make-File) am sinnvollsten gestalte..
Allein mit Parametern im Makefile kann man wohl nicht so viel mehr 
machen können, also schon in der Dokumentation der avr-libc beschrieben 
ist.