free erzeugt Fehler

[Martin Sche (Gast)]

Hallo Leute!
Ich wollte nur mal kurz ein kleines Programm schreiben, um zu testen, ob 
ich ein dynamisch erzeugtes Array auch irgendwie global verfügbar machen 
kann bzw. auch in einer ISR verwenden kann.
Ich nehme nen globalen Zeiger und lasse ihn auf ein dnymaisch erzeugtes 
Array zeigen, fertig...
Funktioniert eigentlich ganz gut, nur die Funktion free(pointer) erzeugt 
nen Fehler. Das "volatile" stört hier, aber das muss ich ja wohl lassen, 
da ich den Pointer in ner ISR brauche...oder?
Hier mal der Code:

#include <avr/io.h>
#include <avr/wdt.h> /* Watchdog*/
#include <avr/interrupt.h> 
#include <avr/eeprom.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <string.h>


volatile uint16_t *pointer;
void funktion();

int main()
{
int k=3;
pointer= (uint16_t *) malloc(k*sizeof(uint16_t)+1);


funktion();
int i;
int array[3];
for(i=0;i<k;i++)
  {
    array[i]=pointer[i];
  }

free(pointer);
return 0;

}


void funktion()
{

pointer[0]=96;
pointer[1]=5;
pointer[2]=256;

}

Kann ich das Problem irgendwie umgehn? Ist der Speicher automatisch wenn 
die Funktion (wo er bereitgestellt wurde) abgeschlossen ist wieder 
frei??

Vielen Dank!
P.S. Das spätere Programm wird auf einen Atmega 32 laufen...

[Peter (Gast)]

du kannst das volatile weglassen, weil der ISR es ja nicht im Register 
buffern kann. Und Das hauptprogramm kann der compiler überblicken.

[der mechatroniker (Gast)]

Äh... Schön, dass du so ein gewissenhafter Programmierer bist. du bist 
auf nem Mikrocontroller. Hast du Angst vor einem Memory Leak beim 
Ausschalten des Geräts?

Scherz beiseite: wenn du aus irgendwelchen Gründen das Ding doch 
freigeben musst, darfst du das volatile wegcasten. Aber versprich mir, 
höllisch aufzupassen, dass keine ISR dazwischenfunkt, während der 
Pointer (da gefreet) nicht gültig ist.

P.S. Zeig mal ein vollst. Programm inkl. ISR, so wie du das benutzen 
willst.

[Martin Sche (Gast)]

Danke für die schnelle Antworten!

Ich erklär jetzt mal wie ich das verwenden will:
Von außen wird festgelegt wie oft ein Interrupt ausgelöst werden darf, 
nehmen wir an k-mal. Bei jedem Interrupt schreib ich etwas in ein Array, 
das ich später in meinem Hautprogramm verarbeite. Danach werden die 
Interrupts gesperrt.
Ich habe dann also k Werte in meinem k großen Array.
Wenn ich diese Werte verarbeitet habe, brauch ich das Array nicht mehr 
und hätte es jetzt einfach mal "gefreet" um wieder Speicher für weitere 
Variablen zu haben (der Platz wird aber wohl nicht eng, dachte nur free 
waäre ganz nett*gg*).
Kann ich also das free getrost wegglasen?

[Karl H. (kbuchegg)]

Martin Sche schrieb:


> Von außen wird festgelegt wie oft ein Interrupt ausgelöst werden darf,
> nehmen wir an k-mal. Bei jedem Interrupt schreib ich etwas in ein Array,
> das ich später in meinem Hautprogramm verarbeite. Danach werden die
> Interrupts gesperrt.
> Ich habe dann also k Werte in meinem k großen Array.
> Wenn ich diese Werte verarbeitet habe, brauch ich das Array nicht mehr
> und hätte es jetzt einfach mal "gefreet" um wieder Speicher für weitere
> Variablen zu haben

Welche anderen Variablen?

Wir bewegen uns doch auf einem µC.
D.h. du kannst alles SRAM, welches dir noch zur Verfügung steht, von 
Haus aus in dein Werte-Array buttern. Ob dieses SRAM jetzt brach liegt, 
oder ob du dort von voneherein ein Array reinlegst, ist Jacke wie Hose.
Der einzige Unterschied:
Legst du das Array statisch an, dann weißt du zur Compilerzeit, wie groß 
das Array ist und kannst darauf einfach reagieren, wenn das k zu groß 
wird.
Ganz abgesehen davon, dass du bereits nach dem Compilieren weißt, 
wieviel Speicher du im SRAM für dich verbrutzelt hast.
Mehr SRAM, als wie wenn du das Array statisch allokierst, kriegst du 
auch dann nicht, wenn du eine dynamische Allokierung machst. Auch ein 
malloc kann keinen Speicher aus dem Hut zaubern.

> Kann ich also das free getrost wegglasen?
In dem Fall nicht.
Aber das ist auch die falsche Frage. Die richtige Frage lautet: Was 
bringt dir eine dynamische Allokierung ausser dass du dem µC zusätzliche 
Arbeit aufbürdest?


(Es sei denn natürlich du hättest mehrere dynamische Allokierungen, die 
wechselseitig den Speicher belegen. Dann könnte es Sinn machen, mit 
malloc zu arbeiten)