SD.remove() Fehler

SD.remove("pommes.text");
SD.remove("user/pommes.text");
SD.remove("user"+dateiname+".text");

egal wie, beim aufruf von SD.remove bootet der Controler neu.
woran kann das liegen?

Habe die Rechte kontrolliert, schreibweisen (groß/klein) probiert.

Andre

Welcher Arduino?
Welches Board?
Zeige den kompletten Sketch!

Du solltest dich an das 8+3 Format für Dateinamen halten

Hallo,

vermute auch das es am nicht einhalten vom 8.3 Format liegt. Lösche die Datei am Rechner und probiere das ganze mit *.txt statt *.text. Ansonsten hat HotSystems die richtigen Fragen gestellt.

Ich hänge mich mal an den Thread ran und möchte die SD-Usern fragen:

Wenn man diese Library einbindet geht auf einmal eine Menge Speicher flöten,
geht das nur mir so ?

Viele Grüße

Harry

Nutze keine SD Karten für sowas, aber ja, das ist normal. Die Lib braucht ordentlich Speicher.

Was ist eine "Menge"?
Welcher Speicher?
Flash, Ram, EEProm?

Die Lib benötigt Platz für Puffer!

Die Sektor-Größe einer SD Karte ist 512 Bytes. Das muss im RAM gepuffert werden.

Zu der "Speicher-Frage".

Ich kann es im Moment nicht genau beziffern, aber bei meinem aktuellen Projekt musste ich die SD rausschmeissen,
da die Sketch-Größe zu groß war .. der Sketch ist jetzt ~ 16KB groß, mit SD überschreiten wir die 32K-Grenze.

Grüße

Harry

Die Lösung liegt wohl an meinem Speicher, zu voll,
obwohl ich erst 50% verbraucht habe, aber was der Kompiler anzeigt stimmt anscheinend nicht.

Ich werde wohl auf einen xmega 384 C3 umsteigen müssen.

Wäre schön wenn man das xmega c3 xplained mit Arduino nützen könnte,
Atmel Studio ist mir etwas zu langsam und zu komplex.

Wenn ihr von "Speicher" redet müsst ihr auch sagen was gemeint ist. Der eine meint Flash. Der andere RAM.

Bei RAM kann man unter Umständen Dinge optimieren. Dynamischer RAM Verbrauch wird übrigens vom Compiler nicht angezeigt. Der kann nur erkennen was auch zur Compile-Zeit bekannt ist.

Serenifly:
Wenn ihr von "Speicher" redet müsst ihr auch sagen was gemeint ist. Der eine meint Flash. Der andere RAM.

Bei RAM kann man unter Umständen Dinge optimieren. Dynamischer RAM Verbrauch wird übrigens vom Compiler nicht angezeigt. Der kann nur erkennen was auch zur Compile-Zeit bekannt ist.

Also, bei mir ging es schon um die Größe des Sketches, wenn ich an die 512 Byte für den Sektor-Buffer denke
wäre mir der Speicher sicher der dynamische Speicher auch bald ausgegangen. Und das, obwohl ich exzessiv,
fast alle Strings via PROGMEM schon entdynamisiert habe :slight_smile:

Grüße Harry

PS.: Gibt es eine Möglichkeit zur Laufzeit die verfügbare Größe des dynamischen Speichers herauszubekommen ?

HarryR:
Und das, obwohl ich exzessiv, fast alle Strings via PROGMEM schon entdynamisiert habe

Das ist nicht was dynamischer Speicher bedeutet. Sondern Speicher der erst zur Laufzeit per new oder malloc() angelegt wurde.

void setup()
{
  Serial.begin(9600);
  delay(300);

  Serial.println(get_free_RAM());

  char* mem1 = new char[200];
  Serial.println(get_free_RAM());

  char* mem2 = new char[500];
  Serial.println(get_free_RAM());

  delete[] mem2;
  Serial.println(get_free_RAM());

  delete[] mem1;
  Serial.println(get_free_RAM());
}

void loop()
{
}

int get_free_RAM()
{
  extern int __heap_start, *__brkval;
  int v;
  return (int)&v - (__brkval == 0 ? (int)&__heap_start : (int)__brkval);
}

Ausgabe:

1824
1622
1120
1622
1824

heap_start ist der Anfang des Heaps. brkval ist das Ende des Heaps. Dynamische Daten landen auf dem Heap. Dieser liegt auf den unteren Adressen und wächst nach oben. Andere Laufzeit Variablen wie lokale Variablen landen auf dem Stack. Dieser liegt oben im RAM und wächst nach unten. v ist eine Variable auf dem Stack und &v ist damit die Adresse des Stacks. Der Freie Speicher ist der Abstand zwischen Heap und Stack.

Siehe:
http://www.nongnu.org/avr-libc/user-manual/malloc.html
Da ist ein Bild das das klarer macht

Wenn brkval 0 ist existiert kein Heap und man zieht man zieht vom Stack den Heap-Anfang ab (heap_start). Wenn ein Heap existiert zieht man das Ende des Heaps ab (brkval).

Serenifly:
Das ist nicht was dynamischer Speicher bedeutet. Sondern Speicher der erst zur Laufzeit per new oder malloc() angelegt wurde.

heap_start ist der Anfang des Heaps. brkval ist das Ende des Heaps. Dynamische Daten landen auf dem Heap. Dieser liegt auf den unteren Adressen und wächst nach oben. Andere Laufzeit Variablen wie lokale Variablen landen auf dem Stack. Dieser liegt oben im RAM und wächst nach unten. v ist eine Variable auf dem Stack und &v ist damit die Adresse des Stacks. Der Freie Speicher ist der Abstand zwischen Heap und Stack.

Siehe:
avr-libc: Memory Areas and Using malloc()
Da ist ein Bild das das klarer macht

Wenn brkval 0 ist existiert kein Heap und man zieht man zieht vom Stack den Heap-Anfang ab (heap_start). Wenn ein Heap existiert zieht man das Ende des Heaps ab (brkval).

Joo, das "dynamisch" war sehr frei angewandt :o

Das kann man/ich gut gebrauchen, um Fehler wg Heap/Stackmangel analysieren bzw entdecken zu können.

Grüße

Harry

Es liegt nicht am Speicher!
habe mal ein kleines Testscript gemacht:

if (SD.open("user/test.txt")) {
datei.close();
SD.remove("USER/test.txt");
Serial.println("datei geloescht");
}

  1. Warum habe ich SD.open verwendet?
    Weil bei nicht eingesteckter SD-Karte "exists" nicht funktioniert

  2. ich habe viele Versuche gemacht mit Groß- und Kleinbuchstaben

Immer das gleiche, der Mega startet neu!

Probier mal andere Hardware

Hallo,

jetzt mal Butter bei de Fische. Ohne Angaben zur kompletten Hardware und ohne kompletten Code macht alles weitere keinen Sinn.