ibo schrieb:
> typedef struct daten
> {
> uint8_t datennummer;
> uint16_t datengroesse;
> uint8_t *startadresse;
> uint8_t *endadresse;
>
> }daten;
>
> daten datum[25];
OK. Gut.
Das sind im Grund etwas, das man Deskriptoren nennen könnte.
Ein Deskriptor beschreibt eine Allokierung im externen SRAM.
Soweit so gut.
> Da die größen unterschiedlich sind habe ich ja auch die probleme. Sonst
> ist es ja kein Problem. Ich adressiere die Daten statisch.
Meine Glaskugel sagt:
Dein Problem besteht NICHT in der Verwaltung der Deskriptoren an sich,
sondern in der Verwaltung des externen SRAM. Also: wie findest du bei
der momentan Speicherbelegung einen Speicherbereich, der groß genug ist,
um die Speicheranforderung aufzunehmen. Für diese Anforderung erstellst
du dann einen Deskriptor und hast somit diesen Speicher als allokiert
markiert. End damit verknüpft ist natürlich die Fragestellung: Was muss
man tun, damit bei Speicherrückgabe der zurückggebene SRAM wieder in den
Pool des verfügbaren Speichers zurückkehrt.
Aber im Grunde sind das 2 Seiten derselben Medaille: Man braucht eine
Verwaltung, die den Speicher verwaltet und je nachdem wie die aussieht,
folgt daraus wie man allokiert bzw. wie man zurückgibt.
Ist das so richtig?
Dein Problem steckt in der Verwaltung des SRAM.
Das ist nämlich aus deinem Urposting nicht klar rübergekommen. Für mich
hat das so ausgesehen, als ob die ein Problem damit hast, die
Deskriptoren selber zu verwalten.
Für den eigentlichen SRAM Speicher kann man eine ähnlich Technik wie die
Freelist einsetzen. D.h. im Grunde ist das sogar fast identisch, nur
dass man
* bei der Allokierung einen 'optimal' geeigneten Speicerblock suchen
sollte. Was immer dann auch 'optimal' bedeutet
* beim free einen höheren Aufwand treiben muss um einen
freizugebenden Speicherbereich mit eventuellen benachbarten und
bereits freigegebenen Speicherbereichen 'verschmelzen' muss, um
wieder möglichst große freie Speicherblöcke zu erzielen aus denen
dann die nächsten Allokierungen bestritten werden können.
Edit:
Und ja. Das ganze klingt für mich in der Tat danach, als ob du
eigentlich eine Speicherverwaltung suchst.
In der Erstversion von K&R war eine entsprechende Implementierung
enthalten. Ob sie in der jetzigen Version noch drinnen ist, weiß ich
nicht. Aber du solltest auf jeden Fall mal deinen Kernighan&Richtie
(Programmieren in C) konsultieren. Ich denke, die Implementierung und
Besprechung der internen Funktionsweise von malloc() und free() ist da
immer noch enthalten, weil es ein wunderbares Beispiel für nichttriviale
Verwendung von vielen Sprachkonzepten ist.
