Dynamische Speicherverwaltung für AVR Sinnvoll?

[TheDarkRose]

Man sollte natürlich auch beachten, dass der Heap (malloc/free/realloc) nur Code ist. Also brauchst du zuerst mal eine Implementierung, wie z.b die avr-libc. Dann solltest du beachten, das AVR keinen Speicherschutz haben. Der Stack fängt immer vom Ende des Speichers an. Der Heap wird dann nach .bss und .data Segmenten plaziert. D.h. Heap und Stack arbeiten aufeinander zu und können sich gegenseitig zerstören. Die Heapimplementierung kann zwar prüfen, dass es nicht in den Stack reinarbeitet. Aber da der Stack nichts vom Heap weiß, kann der Stack dir den Heap kaputt machen. Also du solltest unbedingt überdenken was in den Heap soll. Und auch auf die Rekursionstiefe vom Funktionen ist dann acht zu geben, dass der Stack nicht zu groß wird.

Gegen die Speicherfragmentierung des Heaps hilft natürlich eine möglichst intelligente malloc/free-Routine, die Fragmentierung vermeidet oder im Notfall sogar den Heap defragmentieren kann.

[TheDarkRose]

wenn deine Daten zwar dynamisch unterschiedlich groß sind, aber eigentlich relativ klein und nur innerhalb der einen Funktion leben müssen, wäre alloca() auch eine Möglichkeit. Damit kannst du dynamisch Speicher am Stack allozieren, welcher beim Verlassen der Funktion automatisch wieder frei gegeben wird.

[markusj]

Gegen die Speicherfragmentierung des Heaps hilft natürlich eine möglichst intelligente malloc/free-Routine, die Fragmentierung vermeidet oder im Notfall sogar den Heap defragmentieren kann.

Den Heap defragmentieren geht nicht bei AVRs. Und die möglichst intelligente malloc/free-Routine gibt es auch nicht, weil immer von deinem Einsatzszenario abhängt, was möglichst intelligent ist. Wenn du malloc sparsam und unter Berücksichtigung der Arbeitsweise einsetzt, bekommst du mit einer Speicherfragmentierung keine Probleme. Unbedachtes malloc fliegt dir wahrscheinlich um die Ohren wenn du Objekte mit sehr unterschiedlicher Lebensdauer hast.

mfG
Markus

[TheDarkRose]

Gut, defragmentieren war etwas überspitzt. Dennoch, wenn zwei Blöcke nebeneinander freigegeben werden, sollte natürlich die Heapverwaltung erkennen, dass diese wieder zu einen zusammenhängenden freien Block werden. Wenn es nicht um Geschwindigkeit geht, kann man natürlich schon speichereffektivere malloc-Routinen verwenden.

Aber wie gesagt, wenn die Bedingung ist, dass einfach nur dynamisch die Größe des eigentlichen Objektes nötig ist, und der Pointer nicht raus aus der Methode muss (also den Pointer returnen), dann sollte alloca() die bessere Alternative sein.

[Iqon]

Ich bin im Embedded Bereich (vor allem bei so kleinen Controllern) im allgemeinen gegen Malloc und Co und nutze sie nur im Notfall. Nur wenn aller genutzter Speicher statisch allokiert wird, kannst du dir sicher sein, dass dir der RAM nicht ausgeht. Am PC ist das nicht so wild, weil a) viel viel mehr RAM da ist und b) RAM auf die Festplatte ausgelagert werden kann, wenn der Platz knapp wird.

Wenn überhaupt würde ich für deinen CanOpen Stack einen festen Bereich reservieren und den je nach Bedarf neu zu teilen. Allerdings musst du dir auch hier sicher sein, dass 2 Komponenten nicht gleichzeitig den selben Speicher brauchen.