Hallo,
Ich bin gerade etwas mit SD-Karten und FAT32-Dateisystem am testen.
Nur komme ich dort erneut an Probleme, wo ich nicht klar komme..
Ich verwende einen Atmega644, dieser Stellt bereits einen Webserver
bereit (von U. Radig). Da ich eine SDHC-Speicherkarte habe mit 16GB,
muss ich diese mindestens mit Fat32 formatieren, was die Erweiterung bei
U.Radig auf der Seite unbrauchbar macht, da diese nur Fat16 kann.
Habe mich dann hier ein wenig eingelesen und komme immer wieder auf
FatFs zurück. Habe mir also die Library geladen und in Atmel Studio
importiert.
Die Dateien habe ich angepasst. Dazu habe ich mir dann aus einem
Beispiel noch die mmc_avr_spi.c kopiert und die defines und power_on
Funktionen alle angepasst.
Kompilieren, keine Fehler.
Dann habe ich in der main.c folgendes hinzugefügt:
1
#include "sdcard/diskio.h"
2
#include "sdcard/ff.h"
3
4
FIL fil;
5
char line[100];
6
FRESULT fr;
7
8
f_mount(&FatFs, "", 0);
9
10
fr = f_open(&fil, "index.html", FA_READ);
11
12
if (fr) {
13
usart_write("FILE FOUND");
14
15
}
16
else {
17
usart_write("FILE NOT FOUND");
18
19
}
Versuche ich das ganze jetzt zu Kompilieren erhalte ich folgende
Meldung:
Data Memory Usage: 7028 bytes 171,6% Full (Memory Overflow)
Hat das schon mal jemand gehabt? Ist FatFs für Atmega644 ungeeignet? Ich
lese immer wieder das es aktiv so betrieben wird..
Danke !!
Fat32 ist eine Erweiterung auf Fat16 zur Unterstützung langer
Dateinamen. Soweit mir bekannt ist, kann man also Fat32 Filesystem mit
einem Fat16 Treiber lesen. Man sieht dann halt nur die kurzen
Dateinamen, die auch DOS Programme sehen würden.
Wie dem auch sei, ich bin mit der avrfat32 Library
(https://www.mikrocontroller.net/articles/AVR_FAT32) auf einem
ATmega644P und einem Xmega128D3 bisher gut zurecht gekommen.
Eventuell musst du die Karte mit einer kleineren Partition ausstatten.
Ich meine, dass der SD Standard nur bis 2GB geht, habe allerdings auch
schon eine 4GB Karte verwenden können. Größere habe ich nicht versucht.
> Versuche ich das ganze jetzt zu Kompilieren erhalte ich folgende> Meldung:> Data Memory Usage: 7028 bytes 171,6% Full (Memory Overflow)
Ich glaube, da hast du ein ganz anderes Problem. Die avrfat32 Library
belegt weniger als 1kB RAM und es würde mich wundern, wenn das bei FatFs
großartig anders wäre.
Wie hast du denn deine String-Konstanten geschrieben? Sind Dir die
Makros PSTR() und PROGMEM bekannt?
Stefanus F. schrieb:> Fat32 ist eine Erweiterung auf Fat16 zur Unterstützung langer> Dateinamen. Soweit mir bekannt ist, kann man also Fat32 Filesystem mit> einem Fat16 Treiber lesen. Man sieht dann halt nur die kurzen> Dateinamen, die auch DOS Programme sehen würden.
Nich wirklich.
FAT32 hat eben 32Bit lange Pointer auf Blöcke statt 16Bit lange.
Mit einer FAT32 Implementierung kann man auch FAT16 lesen, aber nicht
andersrum.
FAT32 kann auch nur 8.3
Das mit den langen Dateinamen ist noch eine Erweiterung.
Nennt sich VFAT:
https://de.wikipedia.org/wiki/File_Allocation_Table#VFAT
Zum Thema:
Aber dass elmchans fatfs ein Programm auf einmal auf 171% RAM aufbläst
ist merkwürdig. Das braucht eigentlich nicht so viel.
Guck doch mal ins map file was da so viel Speicher zieht.
Stephan B. schrieb:> Ich verwende einen Atmega644, dieser Stellt bereits einen Webserver> bereit (von U. Radig). Da ich eine SDHC-Speicherkarte habe mit 16GB,> muss ich diese mindestens mit Fat32 formatieren, was die Erweiterung bei> U.Radig auf der Seite unbrauchbar macht, da diese nur Fat16 kann.
Welche Erweiterung genau?
Mw E. schrieb:> FAT32 hat eben 32Bit lange Pointer auf Blöcke statt 16Bit lange.> Das mit den langen Dateinamen ist noch eine Erweiterung.> Nennt sich VFAT
Super, danke für die Klarstellung. Da habe ich glatt einen
Zwischenschritt vergessen.
Someone is wrong on the Internet!!!
https://xkcd.com/386/
;)
Bei elmchans fatfs kann man LFN sogar deaktivieren, dann geht FAT32 auch
mit 8.3
Das spart dann noch maln paar Bytes, aber dann werden 171% RAM Verbrauch
nicht auf einmal nurnoch 71%.
Ich hab mal Fat16 für einen Attiny gemacht. Das Problem war, dass man um
an eine Datei zu kommen immer die FAT neu einlesen musste, weil die FAT
im Ram vorzuhalten nicht ging: Zu groß.
Eventuell versucht hier die Lib die FAT in den Ram zwischenzuspeichern
und kommt damit auf den enormen Rambedarf. Eventuell kann man das
abschalten und sagen: Lies die FAT immer neu.
Nur so als Idee.
Hallo,
Vielen dank für eure Vielen Antworten. Nach dem Beitrag von Stefanus
habe ich direkt mal umgebaut auf AVRFat32.
Die Library ist nicht für den ATMEGA644 ausgelegt. Deshalb habe ich in
der Datei sd_raw_config.h bei defined Atmega32 den Atmega644
hinzugefügt.
Habe jetzt also folgende Config vorgenommen:
Most = B5
SCK = B7
SS = B4
MISO = B6
select_card = B1
unselect_card = B1
pin_available = A4
pin_locked = A5
Das Programm läuft durch bis:
sd_raw.c sd_raw_init(); bis zu /* reset card */
dort erreicht das Programm:
if (I == 0x1ff)
und unselectiert dort die Karte wieder.
Ich habe mir zum Experimentieren folgenden Slot gekauft:
https://www.pollin.de/p/sd-speicherkartenmodul-810359https://www.pollin.de/productdownloads/D810359B.PDF
Kann das Modul das Problem sein??
DANKE !
Stephan B. schrieb:> Kann das Modul das Problem sein??
Das Modul eignet sich nur, wenn der µC mit 3,3V betrieben wird. Wenn du
deinen mit 5V betrieben hast, ist jetzt vielleicht die SD Karte kaputt.
Stefanus F. schrieb:> Fat32 ist eine Erweiterung auf Fat16 zur Unterstützung langer> Dateinamen.
Nein, das eine hat mit dem anderen nichts zu schaffen. Man kann auch in
einem FAT16-fs lange Dateinamen haben und umgekehrt ist es auch möglich,
ein FAT32-fs ohne Support für lange Dateinamen zu betreiben.
> Eventuell musst du die Karte mit einer kleineren Partition ausstatten.> Ich meine, dass der SD Standard nur bis 2GB geht, habe allerdings auch> schon eine 4GB Karte verwenden können. Größere habe ich nicht versucht.
SD ist durch den Standard künstlich auf 2GB-Partitionen beschränkt.
Diese Beschränkung ist den ollen DOS-Ablegern von Windows gewidmet, denn
die können tatsächlich nur damit umgehen. Allerdings kann Linux und auch
die Windows-NT-Abkömmlinge durchaus auch mit 4GB-Partititionen auf SD
korrekt umgehen. Deswegen gibt (vielmehr: gab) es SD-Karten mit solchen
Kapazitäten.
Standard ist heute aber auch schon lange nicht mehr SD, sondern SDHC
bzw. SDXC. SDHC kann 64GB-Partitionen, SDXC kann noch größere, erfordert
aber lt. Standard wiederum EXFAT als Filesystem. Natürlich: Linux hat
kein Problem mit einer FAT-Partition auf so einer Karte, denn es handelt
sich (mal wieder) um eine künstliche Beschränkung...
Stephan B. schrieb:
>> Versuche ich das ganze jetzt zu Kompilieren erhalte ich folgende>> Meldung:>> Data Memory Usage: 7028 bytes 171,6% Full (Memory Overflow)
Buffer zu groß. Lösung: Geklauten Code verstehen und korrekt
konfigurieren. Oder: Device mit mehr RAM verwenden.
Hallo Stefanus,
Tatsächlich habe ich die falsche library importiert...
Jetzt habe ich die richtige von dir empfohlene..
Habe gleichzeitig die Chance genutzt und die Versorgungsspannung von 5V
auf 3.3V gesenkt.
Jetzt läuft alles in der Schaltung auf 3.3V.
Habe jetzt folgendes aus dem Beispiel in meiner main.c:
1
while (FALSE == mmc_init()) {
2
asm("nop");
3
usart_write("TRY MMC INIT");
4
}
Da bleibt auch hängen. mmc_init() wird nicht TRUE.
Habe nochmals die Belegung kontrolliert... Angeschlossen sollte alles
richtig....
Eine Idee dazu :( ?
Danke !!
c-hater schrieb:> SD ist durch den Standard künstlich auf 2GB-Partitionen beschränkt.> Diese Beschränkung ist den ollen DOS-Ablegern von Windows gewidmet, denn> die können tatsächlich nur damit umgehen. Allerdings kann Linux und auch> die Windows-NT-Abkömmlinge durchaus auch mit 4GB-Partititionen auf SD> korrekt umgehen. Deswegen gibt (vielmehr: gab) es SD-Karten mit solchen> Kapazitäten.
SD Karten haben ja eine Byteweise Adressierung und könnten damit bis
4GB.
Daher könnt man durchaus von künstlicher Beschränkung reden.
Ist es nicht eher so, dass als größere Flashspeicher absehbar waren dann
direkt SDHC entworfen wurde?
SD 1.0 kann übrigens nur 1GB, erst SD 1.1 kann 2GB.
Der SD Standard kam aus Zeiten wo 64MB Flash schon viel waren.
@ Stephan B
Wie schnell ist denn der SPI Takt?
Beim Init mögen Sd Karten nicht mehr als 400kHz.
Erst danach darf der AVR Vollgas geben.
Ansonsten musste dir mal Debugausgaben in die INit bauen und gucken ab
wanns dir um die Ohren fliegt.
Stephan B. schrieb:> Da bleibt auch hängen. mmc_init() wird nicht TRUE.> Eine Idee dazu :( ?
Habe ich schon geäußert: Die Karte könnte defekt sein. Würde mich nach
der Gewalt-Aktion mit 5V Signalen nicht wundern.
Noch etwas: Nicht jede SD Karte unterstützt den SPI Modus sauber. Je
älter, umso höher stehen Chancen, dass es gut geht.
Die SD-Karte funktioniert am PC problemlos, probiere ich immer mal
wieder aus.
Die hat zum Glück keinen Schaden genommen.
Hersteller ist SanDisk der ja eigentlich ganz gut dadrin ist :-(
ISP steht auf 125kHz
Stefanus F. schrieb:> Stephan B. schrieb:>> ISP steht auf 125kHz>> In der Doku der AVR FAT32 Library steht, dass viele Karten mit 400KHz> initialisiert werden müssen.
Ich habe alle Karten bisher mit 125KHz initialisiert und noch nie
irgendwelche Probleme damit gehabt.
Stephan B. schrieb:> Data Memory Usage: 7028 bytes 171,6% Full (Memory Overflow)
In der ffconf.h:
1
#define _FS_TINY 1
Sollte erheblich RAM sparen, denn mít FS_TYINY 0 hat jedes FIL auch noch
einen 512 Byte Sektor Puffer mit drin.
Daneben sollte man _FS_EXFAT und LFN ausschalten. Grade LFN schaufelt
Dir IMHO noch einige große Arrays zur Unicode Konvertierung ins RAM.
Marc V. schrieb:>> In der Doku der AVR FAT32 Library steht, dass viele Karten mit 400KHz>> initialisiert werden müssen.>> Ich habe alle Karten bisher mit 125KHz initialisiert und noch nie> irgendwelche Probleme damit gehabt.
Spec sagt klar die Frequenz bei Initialisierung: 100kHz <= CLK <=
400kHz. Da liegst Du mit 125kHz gut drin.
Thread beobachten
Seitenaufteilung abschalten