Hallo ich habe ein Array startadressen[] da stehen jeweils die startadressen (auf einem externen SRAM) des zu übertragenden Datei. in groesse[] steht die jeweilige größe. wenn ich 'n' empfange bekomme wird der index um 1 erhöht und übertragen... funktioniert alles wunderbar... jedoch möchte ich diesen Bereich auch löschen können... also wenn ich 'd' bekomme soll die Datei an der aktuellen index gelöscht werden. wie geht das in C. Sollte ich lieber eine verkettete Liste nehmen? Soll aber etwas schwer zu implementieren sein. Hat jemand ein BeispielCode zu einer verketteten Liste? Speicherverwaltung?
ibo schrieb: > also wenn ich 'd' bekomme soll die Datei an der aktuellen index gelöscht werden. wie geht das in C. Z.B. mit
1 | memset(startadressen[d], 0, groesse[d]); |
Hab ich diese Woche schon mal gepostet. Lies einfach den Klassiker "Algorithmen und Datenstrukturen" von Niklaus Wirth (1975) Dort sind solche Basisalgorithmen erklärt. Ansonsten nehme ich std:vector<> aus der C++ Standard Bibliothek. Die Klasse nimmt einem einiges ab. Ist aber C++, also auch Lernen angesagt.
> startadressen[] da stehen jeweils die startadressen > (auf einem externen SRAM) des zu übertragenden Datei. > in groesse[] steht die jeweilige größe. Nicht gut. Besser: mittels einer Struktur baust du dir die Beschreibung eines Speicherblocks zusammen. Eine derartige Beschreibung besteht aus startadresse und groesse. Und erst davon (von den Beschreibungen) baust du dann ein Array auf. Lass die Dinge beisammen, die zusammengehören! Der Zusammenhang von startadresse und groesse ist stärker als der von groessen untereinander. Also sollten die Dinge auch so gruppiert werden. > Sollte ich lieber eine verkettete Liste nehmen? Eine freelist ist zwar im Prinzip auch eine verkette Liste, ist aber trivial zu implementieren. Vor allen Dingen dadurch, dass du das Array ja schon hast und alle Listenoperationen immer nur am Anfang der Liste stattfinden. Du musst einfach nur die momentan nicht benutzten Arrayeinträge (ausgehend von einem zusätzlichen freelistPointer) miteinander verketten. Mit etwas Glück passt sogar der Member startadresse als Pointer in den Strukturen, so dass das ganze Konstrukt noch nichteinmal mehr Speicher verbraucht. Wird ein Eintrag angefordert, so wird der jeweils erste Eintrag aus der Freelist ausgehängt (so es noch einen gibt) und ein Pointer darauf zurückgegeben. Wird ein Eintrag zurückgegeben, so wird er einfach am Anfang in die Kette der Freelist erneut eingehägt. So dass er bei einer erneuten Anforderung wieder benutzt werden kann.
ibo schrieb: > die Datei an der aktuellen index gelöscht werden. Benutzt Du dynmische Puffer (malloc() o.ä.) oder feste (statische) Puffer?
Tut mir Leid für die späte Rückmeldung. Ich habe ein struct mit daten
gemacht gehabt.
typedef struct daten
{
uint8_t datennummer;
uint16_t datengroesse;
uint8_t *startadresse;
uint8_t *endadresse;
}daten;
daten datum[25];
Da die größen unterschiedlich sind habe ich ja auch die probleme. Sonst
ist es ja kein Problem. Ich adressiere die Daten statisch.
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.
Also habe ich doch richtig gedacht. Ich dachte ich würde zu kompliziert denken. Aber es ist wirklich nicht so leicht. Denn ich werde sicher Speicher verschwenden müssen ob ich es will oder nicht. Das ist inwischen egal. Ich glaube ich ändere meine Pläne :D. Ist besser so. Wenn ich eine SD Karte dranschliessen würde, was müsste ich dann machen? (Für später vllt :D) DAnn müsste ich mit malloc usw arbeiten oder? Oder gibt da fertige Speicherverwaltung?
ibo schrieb: > Oder gibt da fertige Speicherverwaltung? > ja, nennt sich Dateisystem (FAT, EXT, ...)
> Denn ich werde sicher Speicher verschwenden müssen ob ich es > will oder nicht. Natürlich musst du das. Bei jedem dynamisch allokiertem System mit variablen Allokierungsgrößen läuft es letztendlich unter Anderem darauf hinaus. Genau das ist der Grund, warum man auf den kleinen AVR malloc() und free() tunlichst meidet. Hat man so schon nicht wahnsinnig viel SRAM, will man sich dann auch noch den Luxus eines brachliegenden SRAM, das man eigentlich dringend benötigen würde, nicht leisten.
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.