Hallo! Ich benutze in meinen Projekten gerne mal dynamischen Speicher, da das in manchen Situationen einfach von Vorteil ist. Da bei zu häufigem Einsatz von malloc und free der Heap bekanntermaßen dazu neigt zu fragmentieren, habe ich eine auf Handles (void**) basierende Heap-Verwaltung geschrieben, die den Heap bei bedarf defragmentiert. Dazu wird zunächst mit malloc ein großer Speicherblock allokiert. Dann können folgende Funktionen verwendet weren, die jeweils Handles als Argumente akzeptieren und/oder zurückgeben: - alloc (=malloc) - ralloc (=realloc) - ualloc (=free) Das Ganze ist noch beta. D.h, es müssen noch eventuelle Bugs beseitigt werden, es müssen noch ein paar Checks auf ungültige Argumente eingebaut werden und es muss noch etwas optimiert werden. Der Einsatz loht sich ab ca 2-4KB RAM, denn für jeden allozierten Block benötigt man 2*sizeof(void*) Bytes Overhead. Außerdem ist es nicht für zeitkritische Systeme geeignet, da man nicht vorhersagen kann, wie lange ein alloc/ralloc dauert. Ich würde gerne Wissen was ihr generell von dieser Idee haltet. Außerdem wäre es nett wenn ihr eventuelle Bugs hier hin postet und/oder behebt. Optimierungsvorschläge sind natürlich auch gern gesehen, sofern sie nicht das ganze Konzept über Bord werfen. Download: http://www.stud.uni-hannover.de/~nilschr/msp430/ (unten) MfG
Nils Brause wrote: > Ich benutze in meinen Projekten gerne mal dynamischen Speicher, da das > in manchen Situationen einfach von Vorteil ist. Kannst Du dafür mal ein konkretes Beispiel geben, wo das von Vorteil ist ? Ich komme eigentlich immer gut klar, wenn ich den Speicher direkt deklariere (z.B. am Anfang der Funktion). In ner MC-Anwendung muß ja immer der Worst-case Speicher verfügbar sein, da ich ja z.B. auf der Waschmaschine nicht ausgeben kann "schließen sie andere Anwendungen und starten sie das Waschprogramm erneut" oder "nicht genügend Speicher, um Weichspüler einlaufen zu lassen". Peter
Gast
#537244
Peter Dannegger wrote: > ..."schließen sie andere Anwendungen und starten sie das Waschprogramm > erneut" Sowas in der Art ist mir auch durch den Kopf gegangen:-) Speicherfresser wie FIFOs o.ä lege ich deswegen immer statisch an und den Wurst-Käse-Fall für Speicher von autom. Variablen kann ich abschätzen und schauen, ob mir dafür genug frei bleibt. Für eine private Bastelei habe ich eine grafische Oberfläche mit Touchscreen. Primär steuert das Teil ne Radiokarte und Verstärker an. Sekundär kann das Teil noch ein paar Spielerchen im kooperativen Multitasking starten (Tetris, Eieruhr, ...). Die Hauptanwendung "Betriebssystem"/Radio muß natürlich seinen festen Speicher bekommen. Die nachträglich startbaren Gimmiks könnten aber von Nils Speicherverwaltung profitieren, da ich für diese nicht garantieren muß, daß für alle gleichzeitig genug RAM da ist. "Taschenrechner kann wegen Speicherauslastung nicht gestartet werden" wäre hier OK.
Peter Dannegger wrote: > In ner MC-Anwendung muß ja immer der Worst-case Speicher verfügbar sein, > da ich ja z.B. auf der Waschmaschine nicht ausgeben kann "schließen sie > andere Anwendungen und starten sie das Waschprogramm erneut" oder "nicht > genügend Speicher, um Weichspüler einlaufen zu lassen". Das Problem bei der Heap-Fragmentierung ist ja nicht dass zu wenig Speicher frei wäre, sondern dass der Speicher fragmentiert ist. Das passiert, wenn Speicherblöcke verschiedener Größe in unterschiedlicher Reihenfolge reserviert/freigegeben werden.
Gast
#537255
Wie Peter vermeide ich auch dynamischen Speicher. Falls ich doch aufgrund der dynamishen Natur des Prozesses welchselnde Speicher haben muesste, wuerde ich mit Bufferpools arbeiten, es muesste aber immer bestimmt sein wieviel Speicher frei ist. Normalerweise ist alles bei powerup definiert. Der speicher, den eine Prozedur braucht ist auch abgezaehlt und definiert.
Ich finde auch, daß die Benutzung von dynamischem Speicher auf einem µC nicht sehr sinnvoll ist. Es mag sein, daß es hier und da mal einen guten Grund gibt, darauf zurückzugreifen, die technisch gerechtigten Einsätze dafür sind ziemlich rar. Die Probleme: - Dynamischer Speicher ist nicht echtzeitfähig - Selbst bei einem sonst korrekten Programm kann niemand garantieren, daß es nicht doch irgendwann wegen Problemen im Heap versagt. - Es muß reichlich Speicher verfügbar sein - Heapcorruptions sind wohl die am schwierigsten zu debuggenden Fehler. Das sind Ausschlußkriterien für alle Anwendungen, die irgendwelche Maschinen steuern.