Hallo!
Wie ich in dem Beitrag "MSP430 Interrupts zählen (Herzfrequenz)" gelesen habe,
kann man bei der Entwicklung einer Firmware für den MSP430 Speicher mit
malloc dynamisch allozieren und wieder mit free freigeben.
Hierzu habe ich ein paar Fragen;
* Wieviel zusätzliche Systemressourcen dadurch gebraucht werden?
Irgendwie muss dieses malloc und free ja implementiert sein...
* Werde die FW unter CCS entwickeln. In den HW-Optionen kann man ja die
Größe des dynamischen Speichers angeben. Ich denke mal das ist der
Speicherpool, mit dem malloc arbeitet?
* Was ist ein praktischer Wert für die Größe des dynamischen Speichers?
* Was passiert, wenn ich z.B. 2k RAM habe, 1,5k RAM durch globale
Variablen "verbrauche" aber meinen dynamischen RAM auf 1k stelle?
* Mit welcher Verabreitungszeit zur Laufzeit ist zu rechnen, wenn ich
malloc und free verwende?
* Gibt es sowas wie "Defrag" für den dynamischen Speicher, um den
Speicher aufzuräumen und wieder größeren zusammenhängenden Speicher
allozieren zu können?
Vielen Dank für eure Hilfe.
Gruß
Karl
Karlchen schrieb:> * Wieviel zusätzliche Systemressourcen dadurch gebraucht werden?> Irgendwie muss dieses malloc und free ja implementiert sein...
Das werden ein paar hundert Bytes Code sein. Das ist keine
Raketenwissenschaft, und nicht ansatzweise so komplex wie
float-Arithmetik.
> * Werde die FW unter CCS entwickeln. In den HW-Optionen kann man ja die> Größe des dynamischen Speichers angeben. Ich denke mal das ist der> Speicherpool, mit dem malloc arbeitet?
Wird vermutlich so sein.
> * Was ist ein praktischer Wert für die Größe des dynamischen Speichers?
Weniger als die Differenz aus vorhandenem RAM und der Summe aus
statischen/globalen Variablen und Stack.
> * Was passiert, wenn ich z.B. 2k RAM habe, 1,5k RAM durch globale> Variablen "verbrauche" aber meinen dynamischen RAM auf 1k stelle?
Dein Programm wird abstürzen oder sich merkwürdig verhalten.
> * Mit welcher Verabreitungszeit zur Laufzeit ist zu rechnen, wenn ich> malloc und free verwende?
Vernachlässigbar.
> * Gibt es sowas wie "Defrag" für den dynamischen Speicher, um den> Speicher aufzuräumen und wieder größeren zusammenhängenden Speicher> allozieren zu können?
Nein, gibt es nicht.
Und spätestens wegen des letzten Punktes solltest Du Dir wirklich sehr
gut überlegen, ob Du dynamische Speicherverwaltung auf einem µC mit nur
wenigen kiB RAM einsetzen willst.
Sinnvoll ist das bei den Rahmenbedingungen nur sehr selten.
Rufus Τ. Firefly schrieb:> Und spätestens wegen des letzten Punktes solltest Du Dir wirklich sehr> gut überlegen, ob Du dynamische Speicherverwaltung auf einem µC mit nur> wenigen kiB RAM einsetzen willst.
Aha. Und ab wann rentiert sich das?
Das hängt davon ab, was Deine Software mit dem dynamischen Speicher
anstellen soll. Anders als bei einem PC ist ja niemand anderes außer
Deiner Software da, der etwas mit wieder freigegebenem Speicher anfangen
kann.
Wozu willst Du also dynamische Speicherverwaltung nutzen?
Verkette Listen zum Beispiel.
Wen ich das nämlich nicht dynamisch machen würde, ist die
Wahrscheinlichkeit, dass ich zu viel oder zu wenig Speicher durch ein
Array fester Größe belegte, höher, als eine Punktlandung.
Karlchen schrieb:> Verkette Listen zum Beispiel.> Wen ich das nämlich nicht dynamisch machen würde, ist die> Wahrscheinlichkeit, dass ich zu viel oder zu wenig Speicher durch ein> Array fester Größe belegte, höher, als eine Punktlandung.
Falsch.
Durch dynamisches Allokieren hast du ja nicht mehr Speicher zur
Verfügung.
Ob du jetzt den freien Speicher in ein vordefiniertes Array fixer Größe
pumpts oder ob du zur Laufzeit dynamisch anforderst, schenkt sich so
gesehen also nichts. Ganz im Gegenteil: Das Array wird ökonomischer
sein, weil dazu weniger Verwaltungsinformation notwendig ist, als bei
dynamischer Allokierung. Denn irgendwo muss ja auch malloc darüber Buch
führen, welcher Speicher frei und welcher belegt ist.
Ob du daher empirisch ermittelst, wieviel Speicher du in dein Array
pumpen kannst, ehe du den Stack zerschiesst, oder ob du diesen Speicher
empirisch in der Größe für dynamischen Allokierung reservieren musst,
ist Jacke wie Hose. Nur dass dir Netto bei einem fixen Array mehr
Speicher übrig bleibt. Von den ganzen Problemen, die durch
Speicherfragmentierung entstehen, reden wir erst mal gar nicht.
Karlchen schrieb:> Wen ich das nämlich nicht dynamisch machen würde, ist die> Wahrscheinlichkeit, dass ich zu viel oder zu wenig Speicher durch ein> Array fester Größe belegte, höher, als eine Punktlandung.
Und was machst Du mit dem "eingesparten" Speicher? Gibst Du den dem
Hersteller des µC zurück?
Rufus Τ. Firefly schrieb:> Und was machst Du mit dem "eingesparten" Speicher? Gibst Du den dem> Hersteller des µC zurück?
Wenn er genug dafür bietet ... ;)
Karl Heinz Buchegger schrieb:> Falsch.> Durch dynamisches Allokieren hast du ja nicht mehr Speicher zur> Verfügung.> Ob du jetzt den freien Speicher in ein vordefiniertes Array fixer Größe> pumpts oder ob du zur Laufzeit dynamisch anforderst, schenkt sich so> gesehen also nichts. Ganz im Gegenteil: Das Array wird ökonomischer> sein, weil dazu weniger Verwaltungsinformation notwendig ist, als bei> dynamischer Allokierung. Denn irgendwo muss ja auch malloc darüber Buch> führen, welcher Speicher frei und welcher belegt ist.
Ok, ich hätte das ganze vielleicht etwas anders formulieren sollen.
Es geht ja nicht nur um ein Array, sondern um mehrere.
Wenn ich alles fest mache, dann ist von vorne herein die maximale Anzahl
der in den Array abgelegten Parameter festgelegt.
Jetzt gibt es aber z.B. denn Fall, dass in dem einen Anwendungsfall "des
Produkts" mehr Parameter des Typs A statt B benötigt werden. Dann habe
ich mit der dynamischen Speicherverwaltung damit kein Problem, so lange
eben der Gesamtspeicherbedarf in meinen verfügbaren Speicher passt.
Ist alles Fest, müsste ich dem Kunden sagen: Du kannst nur n vom
Datentyp A und m vom Datentyp B, so kann ich sagen: Mach soviel du
willst, so lange n+m nicht mehr als 30 ergibt (oder so ähnlich)...
Karlchen schrieb:> Ist alles Fest, müsste ich dem Kunden sagen: Du kannst nur n vom> Datentyp A und m vom Datentyp B,
das nennt sich definiertes Verhalten
> so kann ich sagen: Mach soviel du> willst, so lange n+m nicht mehr als 30 ergibt ...
".. wobei ein A 2x und ein B 3x zählt"
kann man A und B nicht in einer Struktur abbilden?
Dann könnte man 2 Lsiten nehmen, die aus einem Pool schöpfen
Karlchen schrieb:> Datentyp A und m vom Datentyp B, so kann ich sagen: Mach soviel du> willst, so lange n+m nicht mehr als 30 ergibt (oder so ähnlich)...
Du wirst lachen, aber dein Kunde will das in den meisten Fällen gar
nicht. Dem ist eine fixe Zusage viel lieber als ein "eventuell, wenn der
Wind günstig steht und die Pakete in der richtigen Reihenfolge
daherkommen".
Denn du hast eines vergessen: Speicher-Fragmentierung!
Du kannst durchaus in deinem Speicher noch 200 Bytes frei haben. Aber du
hast sie eben nicht in einem Stück, sondern dort ein paar Bytes und da
ein paar Bytes. Und schon kannst du in den Fall rein laufen, dass eine
Allokierung von 10 Bytes schief geht (bei 200 Bytes verfügbar), weil
diese 10 Bytes eben nicht in einem Stück verfügbar sind.
Und das erklär mal deinem Kunden!
Karlchen schrieb:
> Datentyp A und m vom Datentyp B, so kann ich sagen: Mach soviel du> willst, so lange n+m nicht mehr als 30 ergibt (oder so ähnlich)...
Selbst das ließe sich mittels Array wesentlich leichter und gefahrloser
implementieren als mit malloc/free.
Man nimmt einfach zwei Arrays, eins A und eins für B und legt diese
mittels Union übereinander. Das eine Array füllt man von unten, das
andere von oben.
