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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.