mikrocontroller.net

Forum: Projekte & Code MMC SD library FAT16 FAT32 read write


Autor: Amega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab die Funktion fat_loadFileDataFromDir geändert und nun filegt das 
Ding :)

fat.c@172
  while(!((  (i>=0x8ffffff && i<=0xfffffff ) 
&&fat.fatType==32)||(i==0xffff&&fat.fatType==16))){// prueft ob weitere 
sektoren zum lesen da sind (fat32||fat16)



Bin neugierig, ob linux-formatierte Karte unter Winx lesbar ist.

Autor: Amega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch was habe ich festgestellt: append funktioniert bei mir nicht 
wenn die Datei leer ist.

Autor: Amega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ups 0x#FFFFFF8 != 0x8ffffff !?!?
..war sonnig heute ;)

Autor: Amega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch was:
http://www.pjrc.com/tech/8051/ide/fat32.html
Also, the end-of-file number is actually anything equal to or greater 
than 0xFFFFFFF8, but in practive 0xFFFFFFFF is always written.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ups 0x#FFFFFF8 != 0x8ffffff !?!?
Kommt auf die Endianness an ;)


>fat.c@172
>  while(!((  (i>=0x8ffffff && i<=0xfffffff )
>&&fat.fatType==32)||(i==0xffff&&fat.fatType==16))){// prueft ob weitere
>sektoren zum lesen da sind (fat32||fat16)

Ja sollte so laufen, bläht das den Code auf? Keine Ahnung wie viel mehr 
Aufwand ein größer gleich im Gegensatz zu gleich ist...

>append funktioniert bei mir nicht
>wenn die Datei leer ist.

Das schau ich mir mal an. Aber eigentlich sollte das kein Problem sein, 
weil ans Ende spulen bei Dateigröße 0 kein Problem ist.

file.c@168
while( offset>=512 ){ ...

offset ist hier die Byte Stelle zu der man spulen möchte. Bei Dateigröße 
0 ist das 0 und 0 ist nicht >= 512, also wird in ffseek nichts 
sinnvolles gemacht...

Nur um sicher zu gehen, du appendest ;) ja so oder?
if(MMC_FILE_EXISTS == ffopen(file_name)){
   ffseek(file.length);
   uputc('a');
   ffclose();
}

Grüße Daniel

Autor: Amega (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
End-of-Cluster - FAT32 - >= 0x0FFFFFF8
Der Beweis ist here zu finden:
http://download.microsoft.com/download/1/6/1/161ba...
......
IsEOF = FALSE;
If(FATType == FAT12) {
    If(FATContent >= 0x0FF8)
        IsEOF = TRUE;
} else if(FATType == FAT16) {
    If(FATContent >= 0xFFF8)
        IsEOF = TRUE;
} else if (FATType == FAT32) {
    If(FATContent >= 0x0FFFFFF8)
        IsEOF = TRUE;
}

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja krass, das hatte ich doch tatsächlich immer überlesen.
Wird geändert werden, danke.
Gewundert hatte es mich doch schon warum Linux das so seltsam formatiert 
:)

Grüße Daniel

Autor: Alex G. (almalex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann es sein das man bestimmte ascii zeichen nicht schreiben kann? weil 
ich schicke den richtigen string, und wenn ich die zeichen einzeln 
ausgebe stimmen sie auch, nur auf der sd karte stehen sie nicht
danke mfg alex

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du Strings mit der Funktion ffwrites schreibst, darf in dem String 
logischerweise kein '\0' alias 0x00 vorkommen, da dies ja ein String 
Ende markiert. Bei anderen Steuerzeichen bin ich mir nicht sicher ob die 
gehen.

Mit ffwrite kannst du jedes Byte Zeichen auf die Karte schreiben.

Falls das immer noch nicht geht, müsstest du mal ein bisschen Code 
zeigen und die Zeichen die du schreiben möchtest.

Viele Grüße

Daniel

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab ne allgemeine Frage: Warum verwendest du für Strings unsigned 
char* anstatt char*? Die Ascii Tabelle geht doch nur bis 127 und dadurch 
gibt es bei mir viele Warnings.

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kann ich nur aus dem eigenen Nähkästchen plaudern: signed char ist 
einfach nur krank, wenn es Zeichen und keine int-Werte enthält.

Aber vielleicht ist es auch Gewohnheitssache, mit den Abstrusitäten von 
signed char - Vergleichen zurecht zu kommen.

Autor: Lowtzow .. (lowtzow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe heute versucht daten über den uart einzulesen, lib ist ja 
vorhanden.

verwende ich jedoch
 ugetc();
zum auslesen, dann bekomme ich beim kompilieren folgenden fehler

:369: undefined reference to `ugetc'
#include "uart.h"
 ist im maincode geaddet und initalisieren und
 uputc(ffread());
 funktioniert im main programm auch, beim kompilieren dabei gibts auch 
keine fehler. nur wenn ich ugetc aufrufen möcte schreit er eine 
fehlermeldung.
kann das bitte mal wer testetn obs ähnliche fehler gibt?!

mfg
low

Autor: Lowtzow .. (lowtzow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab die einstellung gefunden die geändert werden muss config.h ;-)

Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MS-Patent für FAT bleibt gültig:
http://www.heise.de/newsticker/meldung/Bundesgeric...

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm,
hab ich da was überlesen oder geht es im Prinzip nur um vfat, also mit 
langen Dateinamen?

Das die da so auf dem fat noch herumreiten, wird wohl eher irgendwie 
exFat mit Zusammenhängen ?!?

Fat16/32 ist ja schon ziemlich in die Jahre gekommen. Wenn man mal so 
moderne Dateisysteme sieht...

Autor: Lowtzow .. (lowtzow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo

wenn ich einen string mit vielen zeichen schreiben will hängt sich das 
programm auf. hab schon vieles probiert. \0 macht auch keinen 
unterschied. anscheinend gibt es ein limit für die stringlänge?! denn 
mit strings die kürzer sind funktioniert alles problemlos. anbei ein 
beispiel für eine länge die bei mir nicht mehr klappt.
char map_start[] = "awedawereeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeawedawereeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeawedawereeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\0 ";
ffwrites(map_start);

hat wer einen tipp?!

ps. fat32 formatierte karten klappen derzeit auch nicht, kann man das wo 
umstellen?!

speicher ist eigentlich noch da
Program:   14360 bytes (43.8% Full)
(.text + .data + .bootloader)

Data:       1528 bytes (74.6% Full)
(.data + .bss + .noinit)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich vermute mal Ram Überlauf. Wo in deinem Programm kommst du auf die 
1528 bytes Ramverbrauch??

Pack den String mal ins Flash und probier das nochmal.
Oder mach ein kleines Array und schreib das wiederholt auf die Karte...

Mit was Fat32 Formatiert? Mit Windows?
Welche Version der Lib nutzt du?
Was genau meinst du mit klappt nicht ?!?

Wenn du ein CharArray so erstellst brauchst du das '\0' am Ende nicht! 
Das wird dann automatisch mit dran gemacht.
char map_start[] = "awedaweree";


Welchen Controller benutzt du?

Grüße Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
und wie sieht es aus? Läufts?

Autor: Lowtzow .. (lowtzow)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> Hallo,
> ich vermute mal Ram Überlauf. Wo in deinem Programm kommst du auf die
> 1528 bytes Ramverbrauch??
>
> Pack den String mal ins Flash und probier das nochmal.
> Oder mach ein kleines Array und schreib das wiederholt auf die Karte...
>
> Mit was Fat32 Formatiert? Mit Windows?
> Welche Version der Lib nutzt du?
> Was genau meinst du mit klappt nicht ?!?
>
> Wenn du ein CharArray so erstellst brauchst du das '\0' am Ende nicht!
> Das wird dann automatisch mit dran gemacht.
>
>
> char map_start[] = "awedaweree";
> 
>
>
> Welchen Controller benutzt du?
>
> Grüße Daniel

ok, mal wieder ein programmfehler meinerseits ;-)
anscheinend is das ram übergelaufen. habe mal die ganzen strings ins 
eeprom des avr (atmega328p) abegelegt und jetzt klappts das beschreiben 
mit langen strings auf die sd problemlos.
mein ram ist so voll weil ich große array habe ca. 100 uint16_t array 
und dann noch lcd/sd/gps. und alles sehr unaufgeäumt.
das mit fat32 muss ich noch testen, aber ich tipp mal drauf es 
funkt.formatiert ist jedenfalls alles it windows.
bin derzeit ganz zufieden mit fat16 läuft alles super und prima!!  danke 
daniel!!
hab das programm jetzt soweit geschireben, dass ich auf der sd-karte ein 
kml file für google earth  erstelle und die gps koordinaten reinschreib.

mfg low

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
es gibt auf http://www.mikrocontroller.net/svnbrowser/avr-fat32/ eine 
neue Version, in der ist nur die Bestimmung des Cluster Endes geändert.
Das behebt das Problem mit Linux formatierten Karten :)

Wurde hier thematisiert 
Beitrag "Re: MMC SD library FAT16 FAT32 read write"

Danke  Amega (Gast)


Grüße Daniel

Autor: aga (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich würde gerne meine gps Datensammlung gerne speichern
und bin auf diesen Foren Beitrag gestoßen

Das was hier angeboten wird ist ein bischen viel
kann mir jemand sagen welche DAteien und Methoden ich brauche, um nur 
die Datensammlung zu speichern.

benutze einen atmega16

mfg aga

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
orientier dich einfach an dem Beispiel in der main.c

Oder hier dran: 
http://www.mikrocontroller.net/articles/AVR_FAT32#...

Da ist ein einfaches Beispiel wie man die schreib/lese Funktionen 
benutzt.
Wenn du speziellere Hilfe möchtest, musst du schon ein bisschen mehr 
verraten :)

Oder noch besser ein wenig Code Posten, zu dem man Hilfestellung geben 
kann.

Grüße Daniel

Autor: Nig G. (nig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
erstmal meinen herzlichsten Dank für deine Arbeit an diesem Projekt, das 
über die Zeit wirklich hervorragend geworden ist!

@alle: Mein Dank gilt natürlich auch für alle anderen, die sich an 
diesem Projekt beteiligt haben oder wertvolle Vorarbeit geleistet haben!

Ich verwende die SD-Library (leicht angepasst) auf einem ATmega64 unter 
IAR und soweit läuft auch alles perfekt mit unterschiedlichsten 
SD-Karten.
Nun sind mir aber 3 Dinge/fehler aufgefallen, die ich hier mal 
ansprechen wollte, weil ich die in den bisherigen Diskussionen noch 
nicht finden konnte.

1.) Fehler in der Funktion "fat_loadFileDataFromCluster"?
Beim Vergleich des Dateinamens werden in der folgenden Zeile nur 10 
Zeichen verglichen, obwohl der Dateiname aus 11 Zeichen besteht. 
Folglich wird also das letzte Zeichen ignoriert, wodurch "MEINFILE1.TXT" 
und "MEINFILE1.TX2" im Vergleich identisch sind!
Bisher:
if(0==strncmp((char*)file.name,(char*)name,10)){
Korrigiert:
if(0==strncmp((char*)file.name,(char*)name,11)){

2.) Fehler in der Funktion "fat_loadSector"?
Am Ende der Funktion steht "return FALSE;" wobei diese Stelle niemals 
erreicht werden kann. Diese Funktion kann in der bestehenden Form nur 
"TRUE" zurückgeben, weshalb sich eine Prüfung auf Fehler bisher auch 
völlig erübrigt. Bei welcher Bedingung, hätte denn FALSE zurückgegeben 
werden sollen?

3.) Hier (http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten) 
steht:
"Nachdem die Karte deselektiert wurde (/CS auf high), die Taktleitung 
noch einige Male pulsen, damit die Karte DO hochohmig/tri-state schaltet 
(vgl. Chans Erläuterungen)."
Das wird in der SD-Library bisher noch nicht gemacht, weshalb ich das 
bei mir noch eingefügt habe. Das könnte z.B. folgendermaßen gelöst 
werden. An jeder Stelle, wo im Source "MMC_Disable()" steht, müsste nur 
ein Schreibbefehl folgen, oder?. So z.B.:
MMC_Disable();  // CS High
mmc_write_byte(0xFF); // dummy write, 8 CLK-Pulse nachdem CS High, damit die Karte DO tri-state schaltet

Viele Grüße
Nig

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann mir jemand sagen welche MMC SD Katen man am besten benutzen

die auch günstig zu bekommen sind?!?!


MfG

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

@ Nig G. (nig)

Bei Punkt 1 und 2 hast du recht, ist mir irgendwie durchgegangen :)
Wird geändert.

Zu Punkt 3, diese Karten sind SPI hörig, also brauchen eigentlich für 
alles einen CLK um was zu machen, zumindest die meisten. Das mit dem "DO 
hochohmig/tri-state" wirkt sich aber auch nur aus, wenn man mehrere 
"Geräte" am selben SPI Bus hat, sonst wäre das egal.
Wird aber geändert.

Danke für die Unterstützung.

@ test (Gast)

Man kann jede Karte nehmen, auch so ganz billige für 2-3 Euro. Wichtig 
nur, es müssen MMC, SD oder SDHC Karten sein.

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, ich überlege grade die Prüfung in fat_loadSector ganz raus zu 
nehmen, ist zwar nicht so schön ohne Fehler Prüfung, aber so wie es bis 
jetzt immer war bringt es ja auch nix...

Mal als Zwischenlösung:
unsigned char fat_loadSector(unsigned long int sec){
  
  if(sec!=fat.currentSectorNr){
  #if (MMC_WRITE==TRUE)
    if(fat.bufferDirty==1){      
             fat.bufferDirty=0;
             if(FALSE==mmc_write_sector(fat.currentSectorNr,fat.sector)) return FALSE; 
    }
  #endif
  if(FALSE==mmc_read_sector(sec,fat.sector)) return FALSE; 
  fat.currentSectorNr=sec;      
  }  
    
  return TRUE;             
}


Autor: mega8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bekomme immer die Fehlermeldung aus der funktion ffclose:

../file-0.3.c:119: error: 'kb_buffer' undeclared (first use in this 
function)

Damit liegt der Compiler auch völlig richtig, kb_buffer wurde da 
nirgendwo deklariert, aber hab natürlich nichts verändert, einfach nur 
eure Codebeispiele kopiert.
Muss ich was im Projekt bei AVR Studio einstellen?
Makefile benutze ich nämlich keine...

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
oha du versuchst da die Version 0.3 zu kompilieren...
Nimm die aus dem SVN und dann sollte das ohne Probleme gehen.

Viele Grüße

Daniel

PS: In der SVN Version ist auch eine AVR-Studio Projektdatei dabei...

Aktuelle Version: 0.5.9
http://www.mikrocontroller.net/svnbrowser/avr-fat32

Autor: Marek N. (bruderm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich experimentiere derzeit auch mit SD-Karten an einem ATmega32. Derzeit 
noch mit dem Code von Ulrich Radig.
Würde gerne mal am WE diesen Code ausprobieren.
Gibt es schon Unterstützung für LFN?

Beste Grüße, Marek

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
nein gibt es noch nicht.
Hab da aber eine Idee, wie man da tatsächlich reguläre Unterstützung für 
lange Dateinamen hin bekommt ohne nochmal 256 Byte Ram zu brauchen :)
Aber vor Mitte Juli wird da nix draus werden...

Aber es ist jeder herzlich eingeladen mit zu entwickeln. Ich pflege das 
dann in die Lib ein.

Viele Grüße

Daniel

Autor: Thorsten J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab nun auch endlich die Software erfolgreich zum Laufen bekommen. 
Der Kasus Knaxus war bei mir, dass ich die Software-SPI verwendet habe, 
welche eben so schnell läuft, wie es der Prozessortakt hergibt. Bei 
18,432MHz ist das für die SD-Karte einfach zu schnell. Ich habe ein paar 
zusätzliche Delays eingebaut und dann ging es.

Von meiner Seite dann auch nochmals vielen Dank, für die ganze Mühe, die 
du bisher hier rein gesteckt hast.

Gruß Thorsten

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kannst du mal zeigen an welchen Stellen du da delays reingebaut hast, 
weil eigentlich ist selbst 20 MHz SPI nicht zu schnell für SD/MMC 
Karten...

Viele Grüße

Daniel

Autor: GG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,



Thorsten J. schrieb:



> ich hab nun auch endlich die Software erfolgreich zum Laufen bekommen.
>
> Der Kasus Knaxus war bei mir, dass ich die Software-SPI verwendet habe,
>
> welche eben so schnell läuft, wie es der Prozessortakt hergibt. Bei
>
> 18,432MHz ist das für die SD-Karte einfach zu schnell. Ich habe ein paar
>
> zusätzliche Delays eingebaut und dann ging es.

ich betreibe meine SD-Card (Verbatim Micro 2 GB) hardwaremäßig mit 20 
MHZ!
Proz. Atxmega
Prozessortakt 2*10 MHz,keine SPI-Teilung, also 20 MHZ am SPI. Das ist 
eine nachweisbare Geschwindigkeit.


Deine Aussage: „Ein paar zusätzliche Delays“  kann heißen: 1,2 oder xx 
Mhz.

Wei schnell ist der SPI-Takt nun wirklich?

Gruß GG

Autor: Thorsten J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab in der mmc_read_byte() und mmc_write_byte()
MMC_Write &=~(1<<SPI_Clock);  //erzeugt ein Clock Impuls (Low)

ergänzt zu
_delay_us(SOFT_SPI_DELAY_US);
MMC_Write &=~(1<<SPI_Clock);  //erzeugt ein Clock Impuls (Low)
_delay_us(SOFT_SPI_DELAY_US);

und hab dann getestet. Die Funktion _delay_us() stammt dabei aus der 
<util/delay.h>.

Für SOFT_SPI_DELAY_US waren Werte größer 0.3 notwendig, damit die Karte 
arbeitet. Das ergibt einen Takt von etwa 300kHz, der jedoch einen hohen 
Jitter aufweist.

Wenn ich das noch recht im Hinterkopf habe war es auch so, dass die 
Karten zur Initialisierung mit maximal 400kHz betrieben werden dürfen. 
Bei Verwendung der Hardware-SPI wird dem auch Rechnung getragen und erst 
nach erfolgter Initialisierung auf volle SPI-Geschwindigkeit geschaltet.

Gruß

Thorsten

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ja guter Einwand. Die Initialisierung im Software SPI Modus schau ich 
mir nochmal an. Bin eh grade eine ordentliche Platine für eine SD Karte 
am machen. Wenn das fertig ist, gibt es eine neue Version...

Danke und viele Grüße

Daniel

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuch gerade die Funktionen auf einem "myAVR Stamp256 PLUS" zum 
Laufen zu bringen.
http://shop.myavr.de/index.php?sp=article.sp.php&a...

Zunächst mal hab ich in mmc.h folgende Ergänzungen gemacht:
  // der SS pin des SPI ports wird nicht benutzt! also da nich die karte anschließen, sondern an MMC_Chip_Select !

  #if defined (__AVR_ATmega2560__)
    #define SPI_MISO            3  //Port Pin an dem Data Output der MMC/SD-Karte angeschlossen ist (DO)
    #define SPI_MOSI            2  //Port Pin an dem Data Input der MMC/SD-Karte angeschlossen ist (DI)
    #define SPI_Clock           1  //Port Pin an dem die Clock der MMC/SD-Karte angeschlossen ist (clk)
    #define MMC_Chip_Select     0  //Port Pin an dem Chip Select der MMC/SD-Karte angeschlossen ist (CS)
    #define SPI_SS              0  //Nicht Benutz muß aber definiert werden
  #endif

  #if defined (__AVR_ATmega128__)


Bei diesem Board ist die CS-Leitung der SD-Karte direkt mit dem SS-Pin 
des Controller verbunden.
Daher hab ich einfach mal ganz "blauäugig" den entsprechenden Portpin in 
die obigen Definitionen eingetragen.

Das mitgelieferte Beispielprogramm liefert "Boot..OK"
Ich hab zur Fehlersuche noch weitere "uputs" eingebaut, und schon der 
nächste Aufruf meldet sich nicht mehr zurück: (keine augabe von uputs)
    // Datei existiert nicht, also anlegen !
    if(MMC_FILE_NEW == ffopen(file_name)){

        uputs((uint8_t*)"wrote new File\r\n");

ich würde mich über einen Tip freuen!

Harry

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das Problem ist gelöst, seitdem ich die aktuelle Version aus dem SVN 
verwende.
Danke nochmal an Daniel für dieses Library!!!

Harry

Autor: Harry L. (mysth)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anpassungen für ATMega2560:

Ich hab das Library um Support für ATMega2560 CPUs erweitert.

Im Anhang sind die geänderten Files.

Harry

<edit>

Mein Fehler!
nicht mmc.c, sondern mmc.h wurde angepasst.

Autor: Harry L. (mysth)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
die fehlende mmc.h

Harry

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wird im neuen Release aufgenommen werden.

Danke und viele Grüße

Daniel

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe mal eine Frage wie ich es schaffe, dass es nur eine FAT auf der 
SD-Karte gibt, ist fürs Verständnis leichter nachzuvollziehen.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
unter Linux gibt es die Möglichkeit zu sagen das nur mit 1 er Fat 
formatiert werden soll... Unter Windows geht das so glaube ich nicht.

Viele Grüße

Daniel

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das bis jetzt immer mit GParted unter ubuntu gemacht, da habe 
ich die Option nur 1 Fat anzulegen noch nicht gefunden. Könntest du mir 
bitte ein Stichwort geben wonach ich besser googlen kann.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also so formatiere ich unter Linux Fat32 mit einer Fat und 4 Sektoren 
pro Cluster:
/sbin/mkdosfs -v -F32 -f1 -s4 -I /dev/sde

Formatiert wird so das Gerät /dev/sde, das ist bei mir ein Kartenslot 
mit einer SD Karte drin.


Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich habe auch mal wieder ein Problem:

Ich will grade die neuste Version einbinden (von 0.5.7 auf 0.5.9).
Ich rufe in meinem Programm an manchen Stellen die ffwrites-Funktion wie 
folgt auf
ffwrites("huhu");
jedoch bekomme ich nun zu jedem Schreibbefehl die Nachricht, daß da was 
mit den Definitionen nicht passt. Hier einer der vielen gleichen Fehler:
main.c:62: warning: passing argument 1 of 'ffwrites' makes pointer from integer without a cast

Ich habe etwas geforscht und an jeder Ecke steht in der neuen Version 
"unsigned". Und daran wird es wohl auch liegen. Warum wurde das denn 
umgestellt?!

Aber was mir viel wichtiger ist, was kann ich gegen diesen Fehler 
machen?

Vielen Dank für alle guten Ratschläge!! :)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
das hatte mehrere gute Gründe, einer davon ist z.B. das so evtl. das 2er 
Komplement entfällt...
Versuch es so und das Warning verschwindet:
ffwrites((unsigned char*)"huhu");

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool! Danke! Hätt ich aber auch selber drauf kommen können... :( Naja, 
manchmal is man eben betriebsblind ;)

Autor: Matze N. (hupe123)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So nun habe ichdas zweite Problem: ich kann weder mit der alten (0.5.7) 
noch mit der neuen (0.5.9) Version auf meine SD-Karten schreiben. Obwohl 
SDHC aktiv ist.
Als Speicherkarten benutze ich die zwei im Foto.
Ich formatiere mit WindowsXP Pro.

Ich habe jeweils mit den Beispiel programmen ausprobiert.
Komisch ist, daß in der neuen Version machmal (jedes 15-20ste Mal) durch 
die
mmc_init
 gegangen wird (die drei Punkte erscheinen), jedoch erscheint nie das 
"OK".
Bei der alten Routine klappt noch nicht mal der erste Schritt.

Die Hardware die ich benutze ist ein ATmega128 mit 7,3728Mhz.

Angeschlossen ist alles richtig, sonst würden ja die drei Punkte auch 
nich erscheinen - wurde aber dennoch schon x-Mal kontrolliert.

Kann mir jemand helfen?!

Grüße aus Hannover

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
so Fehler wie irgendwas klappt manchmal und manchmal nicht, sind 
meistens Hardware Fehler... Benutzt du Software SPI oder Hardware, wie 
lang sind die Kabel, Welche Spannungs Pegel...
Mach mal ein Bild vom Aufbau, dann kann ich evtl. mehr sagen

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm... ich habe eben noch mal alle Lötstellen kontrolliert und 
vorsichtshalber alle nachgelötet - geht aber immer noch nichts.

ich betreibe die karte:
- ohne treiber baustein
- direkt an einem ATmega128
- bei 3,3V.

Meinen Eagleplan habe ich angehängt. Ich hoffe, ich hab keinen Fehler in 
der Verschaltung gemacht :)

Viele Grüße und schon mal besten Dank für deine Hilfe!

Autor: Matze N. (hupe123)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab den Anhang vergessen: hier nun der Schaltplan

Autor: Matze N. (hupe123)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ich habe eben einfach mal zwei 10k Ohm Pull-Up-Widerstände an die CS- 
und die MISO eingebaut (siehe Anhang), weil ich das hier gelesen hatte: 
http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten. aber das 
hilf auch nichts! Ich verzweifel noch!!! Hilfe!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
du steckst doch den SPI Programmer aus wenn du die Karte testest oder?

Mehr fällt mir grad nicht ein, schaue aber später nochmal genauer...

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber klar. Geht aber trotzdem nich...

Viel Spaß beim Fußball nachher!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, Schaltplan sieht Ok aus.
Jetzt könnte der Fehler immer noch in der Software liegen oder im 
Tatsächlichen Aufbau der Schaltung.
Ich hab selber so eine 2GB Scandisk Karte und mit der funktioniert es...
Hast du was in der config.h geändert oder in der mmc.h ?
Wie sieht die Initialisierung genau aus?
Mach doch mal ein Foto der fertigen Schaltung.

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi danke für deine Mühe!!!

Ich denke nich, daß es an der Software liegt. Ich hab nichts in deinem 
Beispielprogramm geändert. Ich will morgen noch mal die Schaltung in 
schön aufbauen - sieht echt nach Kraut und Rüben aus.
Wenns fertig is, lade ich ein paar Fotos hoch.

Grüße und genieß das schöne Wetter - in Hannover sind noch 30°C und ich 
muss raus: hier drinnen sind die nämlich auch ;)

Grüße,
Matze

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi es lag wirklich nich an der Software. Ich habe zwei Sachen geändert:

1) beim ATmega128 geht der ISP nicht über den SPI sondern tw. über den 
USART0. Ich habe meinen UART-RS232 von dieser doppelbelegten 
Schnittstelle abgelötet.
2) Ich habe gleichzeitig den µC gewechselt. Hatte noch nen zweiten 
mega128.

Ich habe eben nochmal den neuen µC mit eingesteckter RS232 Schnittstelle 
programmiert. Geht trotzdem. Lag also wohl an einem def. µC... Jetzt 
gehts aber!!!
Aber warum mich das jetzt vier Tage meines Lebens kosten musste, weiß 
ich auch nich.. ich hasse diese Kleinigkeiten an denen es immer hängt!

Dennoch vielen Dank für deine Hilfe!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
schön das es jetzt klappt...

Es ist nur Zeitverschwendung wenn man nichts dabei gelernt hat :)

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe da etwas ganz komisches grad festgestellt. Ich kann in eine 
Datei mit einer Funktion nichts schreiben.

Ich will in eine Datei für eine Log-Datei bevor die Daten aufgezeichnet 
werden eine Startsequenz schreiben (Funktion: sd_geschw_start(void)).
Ich habe in die Datei eine UART-Ausgabe ("start") eingebaut; diese 
erscheint auch auf meinem Terminal, aber es steht kein "huhu" in der 
Datei. Nur ein "ende"... WARUM zu Teufel?!
Hat jemand ne Idee?

Grüße,
Matze

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
bei dem Stück Code das du gepostet hast, zähle ich ~95 Bytes nur an 
Ascii Zeichen... Das ist ziemliche Ram Verschwendung...

Bin mir jetzt da grad nicht sicher, aber benutzt du fat_str richtig?
Versuche mal an ffopen einen festen Dateinamen zu übergeben, um das 
Problem einzugrenzen.

Ach ja und schließt du die Datei auch irgendwann vor verlassen des 
Programms auch?!?

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Daniel,

ich habe den Tag über in meinem Wust an Funktion gewütet und vieles 
zusammen gestrichen, dabei fiel mir auf, daß in einer anderen Datei an 
zwei stellen wirklich das "ffclose()" gefehlte... dennoch danke für 
deine Mühe. Jetzt geht alles :D

Morgen gibts dann erste Probeläufe mit meinem neuen Datenlogger :D :D

Gute Nacht,
Matze ;)

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So geht alles. Allerdings habe ich grade versucht eine 
Verzeichnisstruktur anzulegen. Beim Aufruf von
ffmkdir
 habe ich aber noch Probleme:

Mein Quelltext dazu sieht wie folgt aus:
 unsigned char verzeichnis[13]=  "TEST";  
ffmkdir(verzeichnis);
(Natürlich nachdem die Karte initiallisiert wurde :)
Auf meiner SD-Karte taucht auch ein Ordner auf. Allerdings kann ich 
diesen nicht Öffnen. Windows XP Pro sagt mir:
TEST bezeiht sich auf einen Pfad, der nicht verfügbar ist. Dieser kann auf einer Festplatte dieses Computers [...] sein.Stellen Sie sicher, daß der Datenträger korrekt eingelegt ist, [...]. Und wiederholen sie den Vorgang. ... 
Muss ich bei dem Funktionsaufruf irgendwie mehr beachten?!

Achja: wieso funktionieren eigentlich nur Grossbuchstaben sowohl bei 
Dateinamen als auch bei Verzeichnissen?!

Danke für deine Hilfe,
Matze ;)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
versuch mal "TEST       " als Verzeichnisname ( 4 Buchstaben und 7 
Leerzeichen). Das mit den Großbuchstaben ist noch aus der DOS Zeit, also 
aus der Fat16 Zeit quasi.
Wenn ich lange Dateinamen Unterstützung mit eingebaut habe wird sich das 
alles etwas vereinfachen, zumindest in der Anwendung :)

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viel besser! Jetzt gehts!!!

Danke!

Autor: Andre V. (Firma: -----) (fichte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sagt mal hat es schon jemand geschaft es unter Codevision zum Laufen zu 
bekommen.?


Habe jetzt schon soviel Probiert aber leider ohne erfolg. :-(

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wenn mir ja jemand sagen könnte wie CodeVision mit void Pointern umgeht 
könnte ich da vielleicht was machen... Aber die Dokumentation da finde 
ich etwas dürftig. Glaube es hakt da am meisten, der Rest sind ein paar 
Register und Kleinigkeiten...

Grüße Daniel

Autor: Andre V. (Firma: -----) (fichte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mir mal vor einigen tagen die Neue Light Version von Codevision 
gezogen und getestet.
Die haben ja eine Sd Lib drin und die Funktioniert ja auch super.

Nur komme ich nicht ganz zurecht damit.
Kam zwar auf Display den Inhalt der Datei schreiben und auch Ordner etc. 
aber ich möchte die Werte für andere Sachen Übernehmen und das geht 
irgentwie nicht.

MFG: Andre

Autor: Rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich wollte gerne wissen, welche Lesegeschwindigkeiten ich bei der 
Verwendung dieser FS32-Bibliothek von SD-Karten zu erwarten habe.

Im Einsatz soll ein ATmega168 mit 8 Mhz eingesetzt werden.
SPI in Hardware mit halber Taktgeschwindigkeit.

Und gibt es Möglichkeiten die Leserate zu maximieren, z.B. FAT16 anstatt 
FAT32?

MfG
Rene

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also wesentlich schneller wird es durch Fat16 nicht werden, da das nur 
mit den Fat einträgen selbst in Zusammenhang steht. Also nur bei Fat 
lookups ins Gewicht fällt...
Also mit Fat32, multiblock-write und 4 Mhz SPI werden wohl so um die 
100-150 k Bytes/Sec gehen. Mit MMC Karten evtl. sogar mehr.

Viele Grüße

Daniel

Autor: Rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Daniel,

danke für die prompte Antwort.

Das mit dem Multiblock ist ja so eine Sache, da es wohl nicht von jeder 
Karte unterstützt wird.
Wie ist denn die maximal zu erwartende Leserate ohne 
Multiblock-Unterstützung?
Ich würde gerne universell bleiben, was die SD-Karten angeht.

MfG
Rene

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm,
ich hab nur eine uralte Karte die Multiblock nicht unterstützt.
Bei den neueren sollte das wohl immer gehen.
Die Geschwindigkeit hängt auch stark von der Karte ab.
Schätzungsweise wird lesen auch im Bereich 100-150 kBytes/sec liegen...

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hier mal eine kleine Beta der Version 0.6
Falls da mal jemand reinschauen mag :)

Neu:
Lange Dateinamen, kleinere Vereinfachungen.

Was geht noch NICHT:
Root dir bei Fat16 beschreiben wenn dort schon mehrere Einträge sind.
Einen vollen Ordner erweitern.

Was geht:
Dateien mit langem Dateinamen lesen.
Ordner mit langem Dateinamen lesen/wechseln zu.

Beim Anlegen wird wie gesagt noch der Ordner nicht erweitert!
Bei einem leeren Ordner und 4 Sektoren/Cluster könnte man aber 
mindestens 4 Dateien mit Dateinamen von 255 Zeichen Länge anlegen ;)

Datei mit langem Dateinamen anlegen löschen.
Ordner mit langem Dateinamen anlegen rekursiv löschen.

Beispiel für den Aufruf:
ffopen((unsigned char*)"langer name test.txt")

So wird wie gehabt, die Datei angelegt wenn nicht vorhanden, oder 
geöffnet wenn vorhanden.

Viele Grüße

Daniel

Autor: martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo
funktioniert auch eine microsd mit einem adapter?

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
was meinst du mit einem Adapter?
Ein Card-slot?!?
MicroSd geht.

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hier mal die zweite Beta.

Lange Dateinamen werden jetzt komplett unterstütz. Bei Ordnern und 
Dateien. Das ist allerdings nicht ganz Standard konform. Sollte aber 
keine Probleme Machen solange man die Karte mit Geräten liest/schreibt, 
die auch lange Dateinamen unterstützen !

Es gibt eine Option in der config.h die heißt "MMC_ENDIANNESS_BIG", wie 
der Name vermuten lässt, kann damit die Byteorder umgestellt werden. Wer 
mit den void Pointer Probleme hatte sollte das mal ausprobieren :)

Die Funktion "fflushFileData()" kann jetzt während geschrieben wird 
aufgerufen werden, sie sorgt dafür, dass die Dateiinformationen 
gesichert werden. Allerdings sollte das möglichst selten gemacht werden, 
da immer mindestens 2 Sektoren geschrieben werden müssen !

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soo, ist fertig :)

Wäre schön, wenn ich evtl. ein bisschen Feedback bekommen könnte, falls 
irgendwo was schief läuft oder es Verbesserungen gibt.

Das einzige Problem, dass immer noch besteht ist, dass bei Software-SPI 
bei der Initialisierung nicht langsamer getaktet wird, da is mir noch 
nicht wirklich was schönes zu eingefallen :)

Die neue Version gibts hier: 
http://www.mikrocontroller.net/svnbrowser/avr-fat32

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, Wiki:http://www.mikrocontroller.net/articles/AVR_FAT32
wird noch angepasst werden...

Autor: Buzzwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin neu hier und habe es mal ausprobiert.

Die 0.6.0 hat nicht getan !
Ich habe es 1:1 genommen und laufen lassen.
Der Controller konnte wohl schreiben + lesen + zufügen.
Aber in Windows wurde die Datei nicht erkannt. Windows zeigte die Datei 
mit "Test.txt." (mit '.' am Ende) mit 0kb an.
Öffnen und Löschen ging nicht. Nur neu formatieren.

Danach bin ich auf die 0.5.9 umgestiegen. Hat geklappt.

Info:
2GB Flash Karte
ATMEGA16 @ 16 MHz

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ja ich war irriger weise davon ausgegangen, dass wenn Linux das 
ordentlich anzeigt, Windows das auch macht. Macht es aber nicht...
Werde später ein update machen, da gibts dann auch noch mehr neue Sachen 
:)

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So neue Version 0.6.1 hochgeladen.

http://www.mikrocontroller.net/svnbrowser/avr-fat32/

Man kann jetzt wesentlich mehr konfigurieren in der config.h


Viele Grüße

Daniel

PS: Als Anhang noch ein Benchmark Programm für atmega168 @ 16 MHZ

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Also ich habe getestet 0.6.0 - das Problem mit dem nich lesen können 
etc. unter Windows hatte ich auch. Jetzt habe ich 0.6.1 getestet, im 
Prinzip funktionierts, wenn die Karte leer ist legt es die Datei an, 
allerdings steht dann 2 x "Hallo Datei!" in der Datei, je einmal in 
einer Zeile.
Ist das normal / gewollt?
Darüber hinaus, befindet sich eine leere test.txt auf der Karte passiert 
nichts bzw. das Programm kommt nicht zum Ende - habe 3 LED zum debuggen, 
irgendwo nach dem init bleibts stehen und die Datei bleibt leer, ich 
werde berichten wenn ich den Wunden Punkt gefunden habe ...

Ich verwende einen ATmega2561 @ 16MHz, sandisk 1GB bzw. Platinum 2GB

Aber ne tolle Sache ischs in jedem Fall

Gruß Jens

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay manchmal beantworten sich fragen von selber, das mit dem doppelten 
vorkommen des "Hallo Datei!" ist gewollt, also streichen wir die Frage!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>Darüber hinaus, befindet sich eine leere
>test.txt auf der Kart

das ist nicht normal soweit ich verstehe was Du machst. Zu welcher Datei 
befindet sich die leere test.txt auf der Karte?

Grüße Daniel


PS: Bin für jede Anregung dankbar !

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein nein, weil 0.6.0 nicht funktioniert hatte hab ich etwas rumprobiert 
- u.a. hatte ich eine leere test.txt angelegt, nach dem Durchlauf des 
Programms war die dann immernoch leer, das war dann aber auch bei 0.6.1 
so.
Werde mich noch n bissi mehr damit beschäftigen, vielleicht kann ich ja 
noch was konstruktives beitragen ;)
Grüßle

Autor: Uwe S. (lan-opfer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...kann mir jmd. ein wenig behilflich sein?? Ich habe Version 0.6.1 
heruntergeladen, im AVR-Studio meinen Controller (XMeaga 64A3) 
eingestellt und compiliert. Es hagelt gleich einige Fehlermeldungen:
../mmc.c:128: error: 'DDRB' undeclared (first use in this function)
../mmc.c:128: error: (Each undeclared identifier is reported only once
../mmc.c:128: error: for each function it appears in.)
../mmc.c:128: error: 'SPI_MISO' undeclared (first use in this function)
../mmc.c:129: error: 'SPI_Clock' undeclared (first use in this function)
.
.
.
Ich denke, es fehlen ein paar einstellungen für den Controller. Aber ich 
weiss nicht wo und was...

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich kenne die Atxmegas nicht.
Wie setzt man denn da einen Pin auf 1 bzw. 0 ?
In der mmc.h müssen die Pins an der die Karte hängt eingestellt werden.
Wenn aber bei einem xmega die Pins anders angesteuert werden müsste man 
da noch mehr anpassen...


Viele Grüße

Daniel

Autor: XMEGA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Uwe S. schrieb:
> fehlen ein paar Einstellungen für den Controller

in der mmc.h sind einige Atmega vordefiniert! Aber kein Atxmega.

Wenn du mit solchen Kaliebern arbeitest, solltest  du schon etwas 
Hintergrundwissen über die Hard- und Software besitzen.

Dir jetzt einen fertigen Code zuliefern ist nicht die richtige 
Vorgehensweise. Wenn dir der Befehl DDRB z.B. nichts sagt, ist das 
Betreiben einer SD-Card am XMEGA schon aussichtslos.

Sollte dennoch Intresse bestehen, melde dich nochmals.


Gruß GG

Autor: Uwe S. (lan-opfer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...nein - DDRB sagt mir jetzt so aus dem Kopf nix. Mit Atmels arbeite 
ich zum ersten mal. Ich habe vorher mit ARM9 (davor SAB509, PIC, ...) 
gearbeitet. Ich muss jetzt wohl hoffen,  dass mir der XMega dann nicht 
zu gross wird ;-)

@Daniel R.: bei den XMega ist die IO-Struktur neu gemacht - es gibt ein 
paar Register mehr. Ist hier ganz gut beschrieben:
http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, sollte sich ganz einfach portieren lassen.
Schau ich mir später mal an.
Mit Deiner Hilfe Uwe S. wird das schon werden. Ich selber habe keine 
atxmega da.
Du könntest schon mal rausfinden an welchen Pins die SPI Schnittstelle 
liegt und in welchen Registern man die einstellt...

Viele Grüße

Daniel

Autor: Uwe S. (lan-opfer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...so - da bin ich wieder. Ich widme mich dem Thema nur sehr 
unregelmässig - je nachdem, wie ich Zeit habe.
In der mmc.h und der uart.h werden wohl durch die Compilerdirectiven die 
prozessorspezifischen Einstellungen vorgenommen - richtig? Ich denke, da 
müsste mann den XMega "reinzaubern".
"#if defined (_AVR_ATXmega64a3_)" oder so ähnlich - weisst du, wie das 
festgelegt werden muss?

An meinem Board ist ja der 64A3 drauf und für die SD-Karte wurde 
folgende Konfig. verwendet:
CS - PB1
MOSI - PC5
MISO - PC6
SCK - PC7
-> also SPIC

Als nächstes müsste ich deine Einstellungen mal vergleichen mit dem 
Manual:
http://www.atmel.com/dyn/resources/prod_documents/... ab S. 229 
sind die Register beschrieben. Leider weiss ich nicht, in wie fern die 
sich mit dem ATMega decken.

LG

Uwe

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also ich bin ab morgen erstmal ein paar Tage weg :)

Wegen
>#if defined (AVR_ATXmega64a3)
weiß ich selber nicht genau wie das mit den Xmegas geht, weiß aber hier 
sicher jemand anderes im Forum.

Also so wie ich das sehe, müsste in der mmc.h das in etwa so geändert 
werden:
  #define MMC_Write   PORTB  
  #define MMC_Read   PINB
  #define MMC_Direction_REG DDRB

zu
  #define MMC_Write   PORTC.OUT  
  #define MMC_Read   PORTC.IN
  #define MMC_Direction_REG PORTC.DIR

Jetzt ist das Problem, dass der CS Pin auch an Port C sein sollte, geht 
das irgendwie bei Deinem Board?
  #if defined (_AVR_ATXmega64a3_)
  #define SPI_MISO        6 
  #define SPI_MOSI        5 
  #define SPI_Clock     7  
  #define MMC_Chip_Select   (zusätzlicher Pin von PORTC) 
  #define SPI_SS        0
  #endif


Dann gibt es noch 2 Stellen in der mmc.c die geändert werden müssten
// hardware spi: bus clock = idle low, spi clock / 128 , spi master mode
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1);

und
//SPI Bus auf max Geschwindigkeit
SPCR &= ~((1<<SPR0) | (1<<SPR1));
SPSR |= (1<<SPI2X);

So wie ich das sehe, brauchst Du nur das Register CTRL vom Xmega. Dann 
sollte das laufen...

Viel Spass beim Basteln.

Bis die Tage dann

Viele Grüße

Daniel

Autor: xmega (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Servus,


Daniel R. schrieb:
> So wie ich das sehe, brauchst Du nur das Register CTRL vom Xmega. Dann
>
> sollte das laufen...

ich habe dir ein lauffähiges Projekt eingestellt.

Atxmega128a3, SPIC(SD-CARD), USART 115200 USARTF0

SPIC(SD-CARD) sollte auf allen XMEGA laufen!

Gruß xmega

Autor: Buzzwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei mir läuft es nun auch super. Vielen Dank für alles.
Die neue Version braucht viel weniger Platz (ca. 4kb) als die 0.5.9.
Es tuts auch der ATMEGA8
ATMEGA8 @ 8Mhz + 2GB SD-Card

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Danke erstmal an Daniel für den Code!

In den Bemühungen den Code v.0.6.1 für eienn Mega8 auszudünnen, bin ich 
inzwischen bei 84% Speicherbelegung. Nur leider funktioniert es nicht, 
wenn ich LFN an und abschalte. Jednefalls ändert sich nach 
Neukompilierung nicht die Speichergröße.
Das zweite Problem hat wohl mit dem ersten zu tun. Ich habe den Plan 
eine START.TXT in Windows zu erzeugen, auslesen zu lassen und das in 
eine TEST.TXT (mehrmals) hineinzuschreiben. Nur für Testzwecke. Wenn ich 
mir das Ergebnis danach unter Windows anschaue, finde ich zwei 
START.TXT. Ich habe das Gefühl, dass er die Datei nochmal neu anlegt, 
wohl weil er die existierende nicht erkennt. Den Inhalt kann er aber 
lesen und schreibt ihn auch brav in die TEST.TXT

Was habe ich hier falsch gemacht?

Gruß, fiete

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, bin wieder da :)

@ xmega (Gast)
Danke dafür, muss ich mir mal in ner ruhigen Minute zu Gemüt führen.

@ Friedrich K. (fiete)
Klingt nach Benutzerfehler. Man kann beispielsweise nicht 2 Dateien 
gleichzeitig öffnen. Poste mal den Code der bei Dir Probleme macht. Dann 
kann ich bestimmt mehr dazu sagen.

Viele Grüße

Daniel

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Daniel,

danke dass dus dir mal anschaust.
int main(void)
{

    DDRD=0xCC;
    PORTD=0xCC;        //0=beide an
                //4=linke an
                //8=rechte an
                //C=beide aus
  
  

  

  // Versuch Karte zu Initialisieren, bis es klappt. Umbedingt so, weil die Initialiesierung nicht immer auf anhieb klappt.
  while (FALSE==mmc_init())
    {
    nop();
    }

    PORTD=0xC8;


  // Fat initialisieren. Nur wenn das klappt sind weitere Aktionen sinnvoll, sonst aendet das Programm !
  if(TRUE == fat_loadFatData())
    {
    
    unsigned char start_dat[] = "START   TXT";
      
    //  if(MMC_FILE_EXISTS == ffileExsists(start_dat))
        {
        if(MMC_FILE_EXISTS == ffopen(start_dat))
        
          {
          
             // lesen eines chars und Ausgabe des chars.
              // solange bis komplette Datei gelesen wurde.
        
          for(i=0; i<19; ++i)
            {
            dat[i]=ffread();
            }
        
              ffclose();
          PORTD=0xC0;
        
             }
        }
      
  unsigned char file_name[]="LOG     TXT";
    



       // Datei existiert nicht, also anlegen !
      if(MMC_FILE_NEW == ffopen(file_name))
        {

       // Schreibt String auf Karte ! Nur richtige Strings koennen mit ffwrites geschrieben werden !
       ffwrites(dat);

       // Neue Zeile in der Datei
       ffwrite(0x0D);
       ffwrite(0x0A);

       // Schließt Datei
       ffclose();
       }

      // Datei existiert, also anhaengen !
      if(MMC_FILE_EXISTS == ffopen(file_name))
        {

       ffseek(file.length);   // Spult bis zum Dateiende vor um anzuhaengen, geht auch ohne Option MMC_OVER_WRITE !

       // schreibt String
       ffwrites((unsigned char*)dat);

       // neue Zeile in der Datei
       ffwrite(0x0D);
       ffwrite(0x0A);

       // schließt Datei
       ffclose();
         }
       PORTD=0x00;

    }

}


Und ein Auszug aus der config.h, damit du weißt, was ich ein und 
ausgestellt hab.
  #define MMC_WRITE         TRUE  // TRUE, dann mit write unterstuetzung, wenn FALSE dann read only !
  #define MMC_OVER_WRITE       FALSE  // TRUE und MMC_WRITE TRUE, dann kann ffwrite dateien überschreiben, wenn FALSE dann nur normales schreiben. um an eine datei anzuhaengen ist MMC_OVER_WRITE TRUE nicht noetig!
  #define MMC_MULTI_BLOCK     FALSE  // TRUE und MMC_OVER_WRITE FALSE, dann werden multiblock schreib/lese funktionen benutzt. ist schneller, wird aber möglicherweise nicht von allen karten unterstützt. wenn FALSE ist normale operation
  #define MMC_SDHC_SUPPORT    FALSE  // TRUE, dann mit sdhc unterstuetzung, wenn FALSE, dann nur mmc/sd karten. siehe : http://de.wikipedia.org/wiki/SD_Memory_Card#SDHC_.28SD_2.0.29
  #define MMC_ENDIANNESS_LITTLE  TRUE  // TRUE, dann ist der code auf littleendian ausgelegt. AVR ist littleendian. code ist auf littleendian optimiert!! siehe: http://de.wikipedia.org/wiki/Endianness
  #define MMC_LFN_SUPPORT      FALSE  // TRUE, dann mit unterstuetzung fuer lange dateinamen. kostet wenn read und write benutzt wird um die 800 bytes flash...
  #define MMC_RM_FILES_ONLY    TRUE  // TRUE ,MMC_WRITE TRUE und MMC_RM TRUE, dann wird die funktion ffrm so mit kompiliert, dass sie nur dateien loeschen kann. wenn FALSE und MMC_WRITE TRUE, dann kann die funktion dateien und ordner rekursiv loeschen !

  // schalter die explizit funktionen mit kompilieren oder nicht!
  #define MMC_TIME_STAMP       FALSE   // TRUE, dann werden die funktionen fat_getTime und fat_getFreeBytes mit kompiliert. siehe auch abschnitt: ZEIT FUNKTIONEN, weiter unten
  #define MMC_RM           FALSE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffrm mit kompiliert.
  #define MMC_SEEK        TRUE  // TRUE,dann wird die funktion ffseek mit kompiliert. mit dieser funktion kann man in einer geoeffneten datei vor und zurueck spulen. nur in kombination mit MMC_OVER_WRITE TRUE kann in einer datei ueberschrieben werden.
  #define MMC_MKDIR        FALSE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffmkdir mit kompiliert. mit dieser funktion kann man ordner anlegen.
  #define MMC_GET_FREE_BYTES    FALSE  // TRUE, dann wird die funkton fat_getFreeBytes mit kompiliert. mit dieser funktion kann der freie platzt auf der karte ermittelt werden
  #define MMC_LS          FALSE  // TRUE, dann wird die funktion ffls mit kompiliert. mit dieser funkion kann man die dateien auf der karte anzeigen lassen
  #define MMC_CD          FALSE  // TRUE, dann werden die funktionen ffcd und ffcdLower mit kompiliert. mit diesen funktionen kann man in ein verzeichnis wechseln oder aus einem verzeichnis ein verzeichnis hoeher wechseln.
  #define MMC_FILE_EXSISTS    TRUE  // TRUE, dann wird die funktion ffileExsists mit kompiliert. mit dieser funktion kann geprueft werden, ob es die datei im aktuellen verzeinis gibt !
  #define MMC_WRITE_STRING    TRUE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffwrites mit kompiliert. mit dieser funktion koennen strings auf die karte geschrieben werden.




Ich habe mir ein paar LED's als Kontrolle eingebaut und der Code, so wie 
er ist, läuft zumindest danach zu urteilen durch. Ich muss dazu sagen, 
dass meine C-Kenntnisse auch eher dürftig sind...

Gruß, Fiete

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ohne den Code jetzt laufen zu lassen würde ich da schon ein paar Dinge 
als potentielle Probleme sehen.

Also das ist so ein Kandidat:
for(i=0; i<19; ++i)
{
   dat[i]=ffread();
}

das sollte besser "for(i=0; i<19; i++)" heißen. Dann sollte dat 
mindestens "unsigned char dat[20]" sein, weil du 19 Elemente und das 
'\0' speichern willst.

Dann noch:
ffwrites(dat);

Das funktioniert nur problemlos, wenn auf dat jetzt wirklich ein String 
steht. In C ist ein String immer mit '\0' terminiert, dafür musst Du 
sorgen. Ist das nicht so, schreibt die Funktion ffwrites Ram Inhalt auf 
die Karte bis sie auf eine 0 alias '\0' im Ram trifft.

Sonst sieht das eigentlich Ok aus.

Viele Grüße

Daniel

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Daniel,
das Array ist eigentlich richtig definiert, aber der letzte genannte 
Punkt könnte Probleme bereitet haben, das habe ich noch nicht bedacht. 
Ich probiere es mal aus...

Gruß, Fiete

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Japp, fehlenden Terminal-zeichen lag es wohl. Ich bin nun ein ganzes 
Stück weiter, allerdings habe ich nun wieder Schwierigkeiten:

Es soll ein Datenlogger werden, der zwei Kanäle loggt und das auch in 
zwei files schreiben soll. Damit er nicht bei jedem furz schreibt, soll 
er erstmal pro Kanal 95Byte in den RAM schreiben, und dann den String 
aus dem RAM auf die Karte wegschreiben.

Also habe ich zwei Arrays definiert (und somit, wenn ichs recht verstehe 
auch den RAM reserviert):

unsigned char kanal_0 [95];
unsigned char kanal_1 [95];

in einer for-Schleife schreibe ich diese nun voll und wenn sie voll 
sind, dann wird ffwrites aufgerufen:
for(unsigned int j=0;j<20;j++)
        {
        kanal_0[j+w*20]=dat[j];
        }        
        
        w++;
        if(w==5)
        {
          // Datei existiert, also anhaengen !
            if(MMC_FILE_EXISTS == ffopen(filename_knal_0))
            {
          PORTD=0x80;           // <----- Fehlerkontrolleuchte
           ffseek(file.length);   // Spult bis zum Dateiende vor um anzuhaengen, geht auch ohne Option MMC_OVER_WRITE !

           // schreibt String
           ffwrites((unsigned char*)kanal_0);

          
           // schließt Datei
           ffclose();

          PORTD=0x00;           // <------ Fehlerkontrolleuchte
          w=0;           
          }

Analog für Kanal 1.

Wenn NUR Kanal 0 angesprochen wird, dann funktioniert das wunderbar,
wenn NUR Kanal 1 angesprochen wird auch, aber wenn beide angesprochen 
werden, dann ist eine der beiden Files meist nicht mehr lesbar und die 
Strings in der Datei haben kaputte Stellen drin (irgendwelche Zeichen, 
die da nicht hingehören). Das pikante ist, dass das Problem wohl nicht 
im RAM auftritt, denn wenn ich z.B. 5x von kanal 1 auf die SD-Karte 
schreibe, und dann einmal von kanal 2, dann treten Fehler an Stellen 
auf, die vorher schon geschrieben wurden. Daher vermute ich, dass die 
FAT irgendwie Probleme macht oder ich irgendetwas anderes nicht bedacht 
habe...

Interrupts kommen eigentlich auch nicht in Frage für das Problem, weil 
ich erst wieder die Kanäle auslese, wenn alles andere abgeschlossen ist.

Jetzt hab ich überlegt, dass der Stack eventuell Probleme machen könnte, 
aber ich bin ja noch knapp 300Byte übrig für den Stack. Ich kann mir 
nicht vorstellen, dass das Probleme bereitet.

Ein weiters Problem ist, dass der Controller nur Dateinen beschreiben 
kann, die er selber angelegt hat, und auch leider nicht mehr nach einer 
Neuinitialisierung. D.h. ich muss die kanal.txt immer löschen, bevor ich 
das Programm nochmal duchlaufen lassen kann. Könnte es vielleicht auch 
damit zusammenhängen?

Bin für Tipps dankbar.

Besten Gruß aus Heidelberg,
fiete

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also eigentlich puffert die Lib schon. Um genau zu sein 512 Bytes, da 
das genau ein Sektor ist. Da könntest Du Dir den ganzen Quatsch mit dem 
Puffern der Kanäle sparen.

Das ist so gefährlich
for(unsigned int j=0;j<20;j++)
    {
    kanal_0[j+w*20]=dat[j];
    }        
Wenn w 5 ist und j 20, dann ist 20+5*20 = 120, also deutlich über der 
Array Grenze hinaus. Damit überschreibst Du was weiß ich im Ram...

Was für Daten kommen den so vor bei den Kanälen? Falls da Steuerzeichen 
vorkommen, also z.B. integer 0, dann geht das mit ffwrites NICHT.
Also noch mal ganz deutlich: NUR Strings sollten mit ffwrites 
geschrieben werden! Ein String wird mit '\0' terminiert. Also Ascii Code 
Buchstaben und Zahlen im Ascii Code quasi.

Mein Vorschlag wäre im http://de.wikipedia.org/wiki/CSV_(Dateiformat) 
Format die beiden Kanäle in eine Datei zu schreiben, aber in zwei 
Spalten in der Datei. Dann brauchst Du Dir um puffern keine Gedanken 
mehr zu machen, da das ja schon die Lib macht.

>Ein weiters Problem ist, dass der
>Controller nur Dateinen beschreiben
>kann, die er selber angelegt hat...

Ich vermute das Programm kommt vorher schon durcheinander, oder der 
Dateiname entspricht nicht den Konventionen.

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Friedrich K.,
wie läuft es? Gibt es Fortschritte?

Viele Grüße

Daniel

Autor: Friedrich K. (fiete)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hey Daniel,

sehr nett, dass du nachfragst. Aber leider funktionierts noch nicht 
zufriedenstellend. Habe mir mal den Beispielcode geschnappt und 
stückchenweise modifiziert. Die Idee war dann tatsächlich mit ffwrite 
(ohne s) wegzuschreiben und zwar auf knopfdruck == trigger.

Es bleiben dabei zwei Probleme: Ich habe es immernoch nicht geschafft 
ausser beim Beispielcode eine Datei nach dem entnehmen der Karte und 
neuinitialisierung wieder zu öffen und zu beschreiben.
Das zweite Problem ist mehr eine Frage. Ich konnte nicht ganz ausmachen, 
an welcher Stelle des Codes wirklich echt vom RAM auf die Karte 
geschrieben wird. Denn ich würde gern auf Knopfdruck ebenfalls den rest 
der im RAM steht, auf die Karte schreibt, sodass man sie entnehmen kann. 
Wenn ich das recht sehe, dann tut das ffclose nicht allein, sondern 
setzt nur die Flags null.

Am besten poste ich mal wie ich den Beispielcode modifiziert habe. 
Vielleicht ist da was schief gelaufen, was ich nicht seh...

Was du da siehst, ist meine "wunsch-Konfiguration". Sie funktioniert 
nicht. Habe vorher Stückchenweise ausprobiert und sobald ich das ffclose 
auf knopfdruck aufrufe, funktionierts nicht mehr. Die Datei kann nicht 
gelesen werden unter windows (beschädigt) es wird aber eine realistische 
größe angezeigt.
    while(1)
    {
      if(!((PINC&0x01)==0x01))
      {
        if((PINC&0x01)==0x01)  //<<---- Erst beim Loslassen schreiben.
        {
             // Datei existiert, also anhaengen !
            if(MMC_FILE_EXISTS == ffopen(file_name))
            {
            
             // bewusst kein ffseek, weil ja, nicht geschlossen und Flags noch gesetzt

             // schreibt "String" Alternativ While Schleife
             ffwrite(48);
             ffwrite(49);
             ffwrite(50);
             ffwrite(51);
             ffwrite(52);
             ffwrite(53);
             ffwrite(54);
             ffwrite(55);
             ffwrite(56);
             ffwrite(51);
             

            
             // neue Zeile in der Datei
             ffwrite(0x0D);
             ffwrite(0x0A);

             /// Bewusst kein ffclose, da erst auf knopfdruck schließen soll
             
            }
          }
        
      }
      if(!((PINC&0x04)==0x04))  // <<--- Kontroll LED
      {
      ffclose();
      PORTD=0xCC;
      }
    }

Aber Fortschirtte gibts schon. Das ganze soll ein Wasserzähler werden 
der kalt und Warmwsser loggt. Die alte ochsentour mit dem 
selbstdefinirtem RAM hat ja einigermaßen fuktioniert, sodass ich ihn 
schon 24h hab laufen lassen können. Hab mal das Histogramm angehängt ;-)

Gruß, Fiete

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

>Ich habe es immernoch nicht geschafft
>ausser beim Beispielcode eine Datei nach
>dem entnehmen der Karte und
>neuinitialisierung wieder zu öffen und zu beschreiben.

Ich vermute mal, dass Du bevor Du die Karte entfernst nicht ffclose 
aufrufst. Mach es doch so, dass Du eine LED einschaltest wenn Du ffopen 
aufrufst und aus, wenn du ffclose aufrufst. So kannst Du genau sehen ob 
die Datei geöffnet oder geschlossen ist.

>Ich konnte nicht ganz ausmachen,
>an welcher Stelle des Codes wirklich
>echt vom RAM auf die Karte...

Bei einem fflushFileData() wird alles was aktuell im Ram ist auf die 
Karte geschrieben. Zudem wird der Dateieintrag geupdatet. Das ist 
prinzipiell ein ffclose(), nur dass die Datei danach nicht neu geöffnet 
werden muss um weiter zu schreiben. Sollte aber so selten wie möglich 
aufgerufen werden, da viele Schreiboperationen auf der Karte gemacht 
werden.

Sind die Taster ordentlich entprellt? Vielleicht geht da einiges 
durcheinander.

So wie ich das sehe, öffnest Du die Datei mehrfach, bevor Du sie 
schließt.
Versuch mal das:

   if(MMC_FILE_EXISTS == ffopen(file_name))
   {
      // Datei existiert, also zum Ende spulen
      ffseek(file.length);

      // hier Status LED an
   }

   while(1)
   {
      // Pin1 gedrückt?
      if(!((PINC&0x01)==0x01))
      {
         // hier warten bis Taste losgelassen wird!
         while( !((PINC&0x01)==0x01) );;

         // schreibt "String" Alternativ While Schleife
         ffwrite(48);
         ffwrite(49);
         ffwrite(50);
         ffwrite(51);
         ffwrite(52);
         ffwrite(53);
         ffwrite(54);
         ffwrite(55);
         ffwrite(56);
         ffwrite(51);

         // neue Zeile in der Datei
         ffwrite(0x0D);
         ffwrite(0x0A);        
      }             

      // Pin4 gedrückt?
      if(!((PINC&0x04)==0x04))  
      {
         ffclose();

         // Status LED hier aus, alles OK. Karte kann entfernt werden!

         break;   // um aus endlosschleife zu kommen
      }

  }


Ohne den Code so laufen zu lassen, denke ich sollte das gehen.

Hoffe irgendwas hiervon hilft :)

Viele Grüße

Daniel

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Daniel, danke für deine Antwort. Ich werds gleich heute abend mal 
ausprobieren.

Zum Prellen: ich habe mir eigentlich entprellte Taster besorgt. Lese 
gerade, dass man da noch Vorkehrungen treffen muss. Ich bin bisher immer 
davon ausgegangen, das es bei entprellten tastern kein Problem ist... 
Vielleicht hat er bei ffclose deshalb probleme bekommen...

Zu Kontroll LEDs: Ja, hab kontroll LEDs eingefügt, bei denen ich seh, wo 
er grad ist. Ich konnte sogar sehen, dass er auf die Karte geschrieben 
hat, weil er dann läger im ffwrite war und so die LED nen bissel länger 
geleuchtet hatte. In dem code den ich dir schickte, sind die LEDs nur 
noch zum teil drin. Ich schiebe die immer rum im code, um zu gucken, wo 
er grad "hängt".

Zu ffclose: Stört es, wenn ffclose mehrfach aufgerufen wird? Weil die 
Verrenkung dass er erst beim Losassen aus der Schleife steigt, hab ich 
mir bei ffclose gespart.

Zu fflushFileData: Muss man danach noch ffclose aufrufen? Wenn ichs 
recht sehe ja.

Kann es eventuell sein, dass die Karte einen knacks hat?

Ich werde wie gesagt mich heute Abend mal damit auseinander setzen und 
bericht erstatten.

Danke nochmal.

Gruß, Fiete

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

>...Verrenkung dass er erst beim
>Losassen aus der Schleife steigt...

Die Verrenkung ist doch nur ein "break;" um aus der Schleife raus zu 
kommen. Ob jetzt bei Taste gedrückt oder losgelassen ist ja nur die 
Abfrage im if...

>Stört es, wenn ffclose mehrfach aufgerufen wird?

Eigentlich nicht, ist aber unnötig. Muss halt so programmiert werden das 
es nicht vor kommt :)

>Zu fflushFileData: Muss man danach
>noch ffclose aufrufen? Wenn ichs
>recht sehe ja.

fflushFileData ist eigentlich dazu gedacht, dass wenn ein Gerät z.B. 
über Tage läuft und Daten loggt, man zwischendurch mal zur Sicherheit 
fflushFileData aufruft. So hat man die Daten bis dahin schonmal 
gesichert, falls der Strom ausfällt oder ähnliches. Dadurch spart man 
sich ein ffclose und ffopen.


Funktioniert die Karte denn unter Windows noch ordentlich? Also 
beschreibbar, lesbar und keine Fehler beim Formatieren? Wenn es da keine 
Probleme gibt, sollte die Karte noch OK sein.



Viele Grüße

Daniel

Autor: Lukas L. (lukas5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
Ich bin hier neu im Forum und habe bis jetzt nicht so viel Erfahrung mit 
AVRs. Deswegen bitte sich nicht über meine dummen Fragen ärgern.

Ich werde mein Atmega32L mit 3,3V versorgen und mit 8MHz takten. Meine 
Karte hat 2GB. Ich möchte Fat32 benutzen.

Soll sie zuerst mit dem PC mit FAT32 formatiert werden oder macht das 
dein Programm?
Kanst du mir bitte sagen an welche Pins des Atmega32 ich die SD Karte 
anschliesen muss?
Wo soll ich im Code eine Umstellung von Fat16 auf Fat32 machen?
Mit welcher Funktion wird eine neue Datei erzeugt?
Mit welcher Funktion wird eine Datei beschrieben?

Grüße,
Lukas

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Lukas,

also das mit den SD-Karten ist nicht so ganz ohne. Du solltest schon 
mindestens nen bisschen C mitbringen und das AVR Tutorial wäre auch 
nicht schlecht, einfach, damit du nen bissel weißt, was du tust. Es ist 
jedenfalls im seltensten Fall so, dass man es einschaltet und alles 
funktioniert. Guck dir mal in der Artikelübersicht 
http://www.mikrocontroller.net/articles/MMC-_und_SD-Karten da steht 
schonmal ne Menge drin.

Gruß, fiete

Autor: Lukas L. (lukas5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
Man verwendet Belegung wie sie in der "mmc-0.2.H" Datei angegeben ist. 
Habe ich das richtig verstanden? Warum wird denn der SPI-Port für den 
Anschluss verwendet. Das ist doch unpraktisch, jedesmal die Karte 
auszustecken um zu programmieren??
Hast du deine Karte auch an PORTB abgeschlossen?

Grüße,
Lukas

Autor: Friedrich K. (fiete)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der SPI-Port stehllt das Protokoll bereit, das mit der Karte 
kommuniziert. Das ist eine Bus-Kommuikation. Es können also mehrere 
Bauteile angeschlossen werden und nur das, welches aktivirt ist, fühlt 
sich auch angesprochen. Aktivirt wird wenn ichs richtig im kopf hab wenn 
pin 0 auf high gezogen wird...

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Lukas.

Hier gibt es auch noch mehr Informationen
http://www.mikrocontroller.net/articles/AVR_FAT32

Die neuste Version ist immer unter
http://www.mikrocontroller.net/svnbrowser/avr-fat32
zu bekommen.

Dabei ist auch ein Beispiel Programm wo die Benutzung gezeigt wird.

Viele Grüße

Daniel

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche gerade die Software mit Keil µVision4 auf einen LPC2148 zu 
portieren. Der Compiler spuckt aber Fehler aus. Da soll wohl noch was 
umgecastet werden?
fat.c(120): error:  #852: expression must be a pointer to a complete object type
fat.c:                  vsector+=   6;
fat.c:                  ^
fat.c(123): error:  #852: expression must be a pointer to a complete object type
fat.c:                  vsector+=2;
fat.c:                  ^
fat.c(422): error:  #852: expression must be a pointer to a complete object type
fat.c:                          *(unsigned char*)vsector++ = 0x00;
fat.c:                                           ^
fat.c(431): error:  #852: expression must be a pointer to a complete object type
fat.c:                          *(unsigned char*)vsector++ = toupper(name[i]);
fat.c:                                           ^
fat.c(439): error:  #852: expression must be a pointer to a complete object type
fat.c:          vsector++;
fat.c:          ^
fat.c(478): error:  #852: expression must be a pointer to a complete object type
fat.c:                  vsector+=8;
fat.c:                  ^
fat.c(482): error:  #852: expression must be a pointer to a complete object type
fat.c:                  vsector+=6;
fat.c:                  ^
fat.c(486): error:  #852: expression must be a pointer to a complete object type
fat.c:                  vsector+=2;
fat.c:                  ^

void fat_loadRowOfSector(unsigned short row){

  #if (MMC_ENDIANNESS_LITTLE==TRUE)
    void *vsector;                  // voidpointer, damit man schoen umbiegen kann :)

    vsector=&fat.sector[row+20];          // row ist byteoffset einer reihe

    file.firstCluster=*(unsigned short*)vsector;  // high word von first.cluster (20,2)
    file.firstCluster=file.firstCluster<<16;
    
    vsector+=   6;

    file.firstCluster|=*(unsigned short*)vsector;  // low word von first.cluster (26,2)
    vsector+=2;

    file.length=*(unsigned long int*)vsector;    // 4 byte von file.length (28,4)
  #else
    unsigned char *psector =& fat.sector[row+31];

    file.length =  *psector--;    // 31    hoechstes byte
    file.length <<= 8;
    file.length |=  *psector--;    // 30
    file.length <<= 8;
    file.length |=  *psector--;    // 29
    file.length <<= 8;
    file.length |=  *psector;    // 28

    psector-=7;
    file.firstCluster =  *psector--;          // 21  hoechstes byte
    file.firstCluster <<= 8;
    file.firstCluster = file.firstCluster | *psector;  // 20
    file.firstCluster <<= 8;

    psector+=7;
    file.firstCluster = file.firstCluster | *psector--;  // 27
    file.firstCluster <<= 8;
    file.firstCluster = file.firstCluster | *psector;  // 26
  #endif
}
void fat_makeSfnDataEntry(unsigned char name [],unsigned char attrib,unsigned long int cluster,unsigned long int length){

  unsigned char i;       // byte zähler in reihe von sektor (32byte eintrag)
  void *vsector;         // void zeiger auf sektor, um beliebig casten zu können
  unsigned short row;    // reihe in dem sektor

  fat.bufferDirty = TRUE;   // puffer beschrieben, also neue daten darin(vor lesen muss geschrieben werden)
  row = file.row;
  row = row<<5;        // multipliziert mit 32 um immer auf zeilen anfang zu kommen (zeile 0=0,zeile 1=32,zeile 2=62 ... zeile 15=480)
  vsector =& fat.sector[row];  // anfangs adresse holen ab der stelle auf sector geschrieben werden soll

  #if (MMC_TIME_STAMP==TRUE)
    unsigned char new=FALSE;
    // pruefung ob eintrag neu ist.
    if(fat.sector[row]==0xE5||fat.sector[row]==0x00)   new=TRUE;
  #endif

  #if (MMC_TIME_STAMP==FALSE)
    // alle felder nullen...
    i = 20;
    do{
      *(unsigned char*)vsector++ = 0x00;
    }while( i-- );
    vsector =& fat.sector[row];
  #endif

  // namen schreiben (0,10)
  i = 0;
  do{
    #if (MMC_LFN_SUPPORT==TRUE)
      *(unsigned char*)vsector++ = toupper(name[i]);
    #else
      *(unsigned char*)vsector++ = name[i];
    #endif
  }while( ++i < 11);

  // attrib schreiben (11,1)
  *(unsigned char*)vsector = attrib;
  vsector++;

  #if (MMC_TIME_STAMP==TRUE)
    unsigned short time=fat_getTime();
    unsigned short date=fat_getDate();

    // reserviertes byte und milisekunden der erstellung (12,2)
    *(unsigned short*)vsector=0x0000;
    vsector+=2;

    if(new==TRUE){
      // creation time,date (14,4)
      *(unsigned long int*)vsector=date;
      *(unsigned long int*)vsector=*(unsigned long int*)vsector<<16;
      *(unsigned long int*)vsector|=time;
    }
    vsector+=4;

    // last access date (18,2)
    *(unsigned short*)vsector=date;
    vsector+=2;

    // low word von cluster (20,2)
    *(unsigned short*)vsector=(cluster&0xffff0000)>>16;
    vsector+=2;

    // last write time,date (22,4)
    *(unsigned long int*)vsector=date;
    *(unsigned long int*)vsector=*(unsigned long int*)vsector<<16;
    *(unsigned long int*)vsector|=time;
    vsector+=4;

    // high word von cluster (26,2)
    *(unsigned short*)vsector=(cluster&0x0000ffff);
    vsector+=2;

    // laenge (28,4)
    *(unsigned long int*)vsector=length;
  #else
    vsector+=8;

    // low word  von cluster (20,2)
    *(unsigned short*)vsector=(cluster&0xffff0000)>>16;
    vsector+=6;

    // high word von cluster (26,2)
    *(unsigned short*)vsector=(cluster&0x0000ffff);
    vsector+=2;

    // laenge (28,4)
    *(unsigned long int*)vsector=length;
  #endif
}

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
versuch mal "#define MMC_ENDIANNESS_LITTLE FALSE" in der config.h
Damit fliegen überall die void Pointer raus. Ist aber evtl. nicht so 
schnell dann.

Es gibt da mit mehreren Kompilern Probleme wegen void Pointern. Verstehe 
ich nicht ganz, weil das eigentlich normaler C Standard sein sollte...

Viele Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hab da auch mal wieder ne Frage.
Ich will mit der neuen Version (0.6.1) einen Ordner anlegen. In der 
Config.h ist #define MMC_LFN_SUPPORT            TRUE. So weit, so gut!
Aber wenn ich nun alle:
unsigned char datum_verzeichnis[8];    //Beispiel: "33-33-33
datum_verzeichnis[0] = datum[0];
datum_verzeichnis[1] = datum[1];
datum_verzeichnis[2] = '-';        
datum_verzeichnis[3] = datum[3];        
datum_verzeichnis[4] = datum[4];        
datum_verzeichnis[5] = '-';
datum_verzeichnis[6] = datum[6];
datum_verzeichnis[7] = datum[7];        

ffmkdir(datum_verzeichnis);
ffcd(datum_verzeichnis);
ein Verzeichnis anlegen will, dann geht das nicht. Windoofs will da wohl 
am ende der Eingabe noch ein abschließedendes Zeichen haben. Kann mir 
bitte jemand verraten, welches das ist?
Und mit einem HEX-Editor kann ich leider kein Verzeichnis öffnen... Bei 
normalen Dateien kann man ja "spicken" wie bestimmte Steuerzeichen 
aussehen. Bei Ordner geht das nich...

Danke für alle guten Tipps!
Matze

Autor: Kurt B. (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke Daniel. Das lesen von Dateien geht jetzt ohne Probleme. Aber beim 
fclose nach dem schreiben in eine Datei bleibt er hängen. Ein Hardware 
Problem schließe ich aus, da das lesen funktioniert. Timing Probleme 
dürften es auch nicht sein da ich den Prozessor bis auf 12MHz 
runtergetaktet habe.

Im Anhang ist das komplette µVison Projekt, lauffähig mit debug 
Ausgaben, und die debug Meldungen. Er bleibt ganz am Schluss zwischen 
Kontrollpunkt D und E hängen, obwohl er vorher mehrmals korrekt bis E 
durchläuft.

Ich höffe es ist einigermaßen verständlich was ich meine. ;-)


Mfg,
Kurt


PS: Ich habe die Software auch auf einem Mega32 mit 18,x MHz getestet, 
da funktionieren lesen und schreiben wunderbar!

Autor: Kurt B. (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das war natürlich die falsche Datei!
@Moderatoren: bitte löschen.

Hier kommt die richtige.

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so gehts:
unsigned char datum_verzeichnis[9];    //Beispiel: "33-33-33
datum_verzeichnis[0] = datum[0];
datum_verzeichnis[1] = datum[1];
datum_verzeichnis[2] = '-';        
datum_verzeichnis[3] = datum[3];        
datum_verzeichnis[4] = datum[4];        
datum_verzeichnis[5] = '-';
datum_verzeichnis[6] = datum[6];
datum_verzeichnis[7] = datum[7];
datum_verzeichnis[8] = 0x00;        

ffmkdir(datum_verzeichnis);
ffcd(datum_verzeichnis);

Aber da muss man erstmal drauf kommen... ;)

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider waren doch meine SPI (SSP) Funktionen falsch! Also bitte meine 
beiden letzten Beiträge ignorieren.

ABER: In der fat_loadSector() ist anscheinend ein return FALSE zuviel?

Mfg,
Kurt

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.
Wunderbar, dass sich hier alles von selber erledigt :)
Hm, das FALSE da ist wirklich überflüssig... da kommt man ja garnicht 
hin.
Wird geändert.

Viele Grüße

Daniel

Autor: max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Funktioniert der Code auch auf einen ATmega162?
was muss ich dafür im Makefile ändern?

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo max,
Du musst im Makefile bei

# MCU name
MCU = atmega162

eintragen.

Dann noch in der mmc.h die Pins der Hardware SPI Schnittstelle 
eintragen.
  #if defined (__AVR_ATmega162__)
  #define SPI_MISO        6  //Port Pin an dem Data Output der MMC/SD-Karte angeschlossen ist
  #define SPI_MOSI        5  //Port Pin an dem Data Input der MMC/SD-Karte angeschlossen ist
  #define SPI_Clock       7  //Port Pin an dem die Clock der MMC/SD-Karte angeschlossen ist (clk)
  #define MMC_Chip_Select   0  //Port Pin an dem Chip Select der MMC/SD-Karte angeschlossen ist
  #define SPI_SS          4  //Nicht Benutz muß aber definiert werden
  #endif


Viele Grüße

Daniel

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
erstmal: Super Arbeit!

Leider läuft das Schreiben auf die SD-Karte nur sehr langsam.
Ca. 4kB/s! Auf dem Osi sieht man, dass er manchmal 200ms brauch um auf 
die Karte zu schreiben.

Aber die Datei wird fehlerfrei geschrieben.

Hat jemand eine Ahnung wodran das liegen könnte, ich verzweifle dran?
Habe schon verschiedene SD-Karten ausprobiert, Takt geändert,  immer das 
gleiche Problem!

Daten:
Atmega88 @7.3728Mhz @3,3V

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das problem hab ich auch manchmal. versuch mal ne andere SD-Karte.
Wenn ich mal ausversehen die SD-Karte im Slot habe, wenn der ISP dran 
is, dann kriegt sie wohl einen "Schaden". In anderen Geräten geht sie 
dann noch, aber am µC nich mehr. Ich weiß auch nicht, woran das liegt. 
Is halt mein "Word-Around"... Nich schön, weil auf dauer teuer, aber was 
will man machen ;)

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm... habe mich wohl geirrt! Sorry!
Ich hatte ja das selbe Problem: mals liefs und mal nicht. Ich habe immer 
mit WinAVR compiliert und bin gestern einfach mal spaßeshalber in das 
AVR Studio gewechselt und habe da den selben Code compiliert - jetzt 
geht alles und zwar immer... also, wenn du mit dem WinAVR arbeitest: 
wechseln ;)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kann mir eigentlich nur vorstellen, dass es mit Kompiler Optionen zu tun 
hat oder etwas in dieser Richtung. Vielleicht ist es aber auch wenn das 
nur bei einer Karte auftritt eine extrem langsame. Habe hier auch eine 
16MB Karte die extrem langsam ist.

Grüße

Daniel

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, ich habe am Versuchsaufbau nichts geändert! Sogar die selbe Karte 
benutzt. Mit dem ARV Studio geht es nun aber flüssig und vor allem 
immer.
Is komisch, ist aber so.

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für die Anregungen.
Ich arbeite nur mit Avr Studio, also daran lag es nicht.

Habe mal ne ganze Menge an Karten ausprobiert und gemessen. Habe 
festgestellt, dass die Noname Karten am Besten funktionieren.

Habe die Benchmark bißchen umgeschrieben. Schreibe 196k-Datein und davon 
100 Stück und messe die einzelnen Zeiten! Folgende Ergebnisse:

ScanDisk SD 2Gb (neu):
3.2s für die 1.Datei
10s für die 100. Datei

SD-Formel1 256Mb (hab ich irgendwo ausgegraben):
2,6s für die 1.Datei
2,4s für die 100. Datei

NONAME SD-micro 2Gb (aus meinem Handy)
3.6s für die 1.Datei
3.4s für die 100. Datei

CN Memory SD 8Gb mit SD_HC Support (neu)
3.2s für die 1.Datei
25s für die 100. Datei

Hab da noch paar Karten getestet. Manche werden halt sehr lahm! Hab 
keine Ahnung wodran das liegt, benutze einfach die Karten die durchweg 
schnell schreiben. Das sind die Karten die sich mit FAT 16k formatieren 
lassen. Keine Ahnung, ob das damit zusammen hängt??? Bin noch Laie auf 
dem Gebiet!

Welche Karten würdet ihr denn empfehlen? Sind MMC Karten schneller?

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sollte vielleicht noch folgendes erwähnen:

Atmega88 @3.3V @7,3728MHz

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
stimmen diese Daten?

>SD-Formel1 256Mb (hab ich irgendwo ausgegraben):
>2,6s für die 1.Datei
>2,4s für die 100. Datei

>NONAME SD-micro 2Gb (aus meinem Handy)
>3.6s für die 1.Datei
>3.4s für die 100. Datei

Die werden schneller bei 100 Dateien?!?
Zeig mal den Benchmark Code !

Ja MMC Karten sind deutlich schneller, keine Ahnung wieso.

Fat16 zu Fat32 macht bei mir keinen so großen Unterschied. Ist im 
einstelligen KB Bereich.
Ob ich Multiblock ein/aus schalte macht deutliche Unterschiede.

Deine maximale SPI Geschwindigkeit ist f_cpu / 2 also 7,3728 MHz / 2 = 
3,6864 MHz. Das ist jetzt nicht so wahnsinnig schnell. Die Karten sind 
für 25 MHz ausgelegt.

Was willst Du denn eigentlich speichern? Muss das so schnell sein?

Viele Grüße

Daniel

Autor: little man (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

hab jetzt noch paar MMC Karten getestet, lassen sich so mit 77kB/s 
beschreiben. Ich glaub ich werde nun nur MMC benutzen! Funktionieren 
alle durchgehend gut.

Daniel R. schrieb:
> Die werden schneller bei 100 Dateien?!?
> Zeig mal den Benchmark Code !

Hab die benchmark angehängt.
Fand ich auch komisch. Dies tritt nur auf, wenn die Karte formatiert und 
relativ alt ist. Sind da schon Daten drauf, schreibt sie durchgehend 
konstant. Kann sein das die ersten Sektoren schon beschädigt sind!?

Hab mir jetzt mal ein größeren Controller bestellt. Wird mir hier 
einbisschen eng auf dem Atmega88. Dann drehe ich auch die Frequenz auf 
16MHz.

Daniel R. schrieb:
> Was willst Du denn eigentlich speichern? Muss das so schnell sein?

Muss Strom und Spannung mit 2.5kS/s abtasten und ablegen. Desto 
schneller ich speichern kann, desto weniger muss ich Puffern.

Bis dann und vielen Dank für den bereitgestellten Code!

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe eine Frage zu deinem Benchmark.
Kannst du mir mal bitte die Zeite
c = c==254 ? 0 : c;
 erklären. Ich kenne weder ein "?" noch ein ":" in einer Zeile. Nur 
interesse halbe (ich lerne immer wieder was dazu ;)

Liebe Grüße,
Matze

Autor: Bad U. (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das ist eine verkürzte Schreibweise für eine Abfrage. Wenn C=254 wird c 
der Wert hinter dem Fragezeichenzugewiesen. Wenn nicht der Wert hinter 
dem : Allerdings bin ich der Meinung, dass es am Ende :c++ heissen 
müsste. Ich kenne das Programm nicht, aber das soll wohl eine 
Zählvariable sein. Kann aber auch sein, dass sie woanders im Programm 
verändert wird. Dann macht diese Art der Abfrage allerdings weniger 
Sinn...

Gruß
Bad Urban

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cool! Wieder was gelernt!!!
Ich habe mal in der Quelltext geschaut, das müsste wirklich ":c++;" 
heißen.

Danke aber fürs übersetzen!!
Gruß,
Matze

Autor: Bad U. (bad_urban)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Freut mich wenn ich helfen kann. Bin da das erste mal auch mit großen 
Augen davor gesessen :-)

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe mal in der Quelltext geschaut, das müsste wirklich ":c++;"
>heißen.


Nö.

>      ffwrite(c++);
>      c = c==254 ? 0 : c;

Fällt euch was auf?

Das ist eine kryptische Schreibweise für ein if{}else{}
Sowas gehört in kein C Programm.

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, das "ffwrite(c++);" hab ich übersehen. Mein Fehler.

Aber warum sollte ein "c = c==254 ? 0 : c;" nicht in ein c-Programm? 
Vorallem die Begründung, daß es kryptisch sei halte ich für arg 
schwammig. Ich denke, ich werde es zu meinem Standart für solche Fälle 
erklären. Warum sollte ich das nicht dürfen?! Ich finds kurz und 
prägnant.

Autor: hm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so kann der kompiler auf jeden fall besser optimieren als bei einem 
if/else
und es ist ja schon standard c

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

@little man (Gast)

Die interessanten Teile hast Du weggelassen :)
Wie sehen folgende defines bei Dir aus?
#define TOP_OCR 0xF9
#define START_TCNT 0x06
#define PRESCALER 0x03  

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

hab die defines auf mein CPU Takt angepasst!
Ansonsten, wie gesagt, kaum was an deiner Benchmark verändert.

#define TOP_OCR 0x7A
#define START_TCNT 0x06
#define PRESCALER 0x03

Bis dann!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also mein Timer Rechner sagt mit einer Frequenz von 7.3728 MHZ müssen 
die Werte bei einem Überlauf von 1 ms:
#define TOP_OCR 0x72
#define START_TCNT 0x8D
#define PRESCALER 0x03

sein. Der Fehler ist dann 0.174%

Ich benutze dazu diesen Rechner:

http://www.b9.com/elect/avr/kavrcalc/index.html

welcher auch unter Linux mit Wine läuft.

Zur Not könnte man auch die Tick Zeit mal mit einem sleep vergleichen...

Viele Grüße

Daniel

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

super Rechner. Wusste garnicht, dass es sowas gibt. Hab es mir immer 
selbst alles ausgerechnet.

Bis dann!

Autor: little man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey,

hab den Test noch mal mit den genaueren Werten durchgeführt. Fehlmessung 
von ca. 1%. Also, danke noch mal für den Tipp!

Noch ne Frage!
Welche Karten (SD und MMC) akzeptieren MMC_MULTI_BLOCK? Hab bisher noch 
keine gefunden.

Bis dann!

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, seltsam.
Ich hab nur ein paar total alte Karten bei denen das nicht geht.
Neuere SD sollten das auf jeden Fall haben.

Viele Grüße

Daniel

Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich benutze auch die Lib hier, hab aber ein Problem. Ich schreib alle 5 
Minuten auf die Karte alle 5 Sekunden 2 Werte. Nach ungefaehr 2 Stunden 
bricht das schreiben ab, weil entweder der Schreibvorgang hängenbleibt 
oder die er beim öffnen der Datei hängen bleibt. Vielleicht einer eine 
Idee, woran das liegen könnte? Die Schaltung wird über einen Lf33cf mit 
3,3 v versorgt, also auch stabil. Hab mal die main angehangen, ist im 
Grunde nur eine Erweiterung des beigefügten Beispiels im svn. Ach so µC 
ist ein Atmeg644p.

Grüße Peter

Autor: Matze N. (hupe123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
*abo

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
sehe ich das richtig, dass der Atmeg644p 4k Ram hat? Weil eigentlich 
würde ich auf Ram Probleme tippen.
Läuft das Programm ohne schreiben auf die SD Karte normal durch?
Versuch mal die Datei einfach geöffnet zu lassen.
Du legst nicht alle 5 Minuten eine neue Datei an oder?

Hab grad nicht die Zeit mir das Programm im Detail anzuschauen, mach ich 
aber am Wochenende.

Viele Grüße

Daniel

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
danke für die Antwort, jo der Atmega644p hat 4kb Ram, nur öffnen geht 
über viele Stunden, hab es dann irgendwann einfach abgebrochen. Nein ich 
öffne nur die existierende Datei immer wieder, schreib rein und 
schliesse sie.
Ich teste jetzt erstmal ohne die Datei immer zu öffnen, ob das schreiben 
dann über einen längeren Zeitraum funktioniert.

Mfg
Peter

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
also so nochmal auf die schnelle...
Bist Du Dir sicher, dass nur wirkliche Strings mit ffwrites geschrieben 
werden? Wenn da irgendwo das '\0' fehlt geht das schief.

Grüße

Daniel

Autor: Tobias M. (obi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich möchte mir einen Datenlogger mit SD bauen.
Gibt es da irgendwelche Beschränkungen?
Also wie groß darf die SD- Karte maximal sein und was für einen µC 
braucht man mindestens?

Danke und Gruß
Tobias

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich möchte mir einen Datenlogger mit SD bauen.

Wofür?

>Gibt es da irgendwelche Beschränkungen?

Ja. 4GB pro Datei maximal bei FAT32.
Schreibzeiten beschissen wegen sporadischen Aussetzern von
bis zu 500ms. Es sei denn du hast einen Arsch voll RAM.

>Also wie groß darf die SD- Karte maximal sein und was für einen µC
>braucht man mindestens?

FAT32 kann ein paar Terabyte.
ATmega mit mindestens 2kB Ram.

Autor: obi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ich möchte mir einen Datenlogger mit SD bauen.
>
> Wofür?

Für eine Wetterstation

>>Gibt es da irgendwelche Beschränkungen?
>
> Ja. 4GB pro Datei maximal bei FAT32.
> Schreibzeiten beschissen wegen sporadischen Aussetzern von
> bis zu 500ms. Es sei denn du hast einen Arsch voll RAM.
>
>>Also wie groß darf die SD- Karte maximal sein und was für einen µC
>>braucht man mindestens?
>
> FAT32 kann ein paar Terabyte.
> ATmega mit mindestens 2kB Ram.

Also wenn ich eine 4GB SD- Karte nehme und nen atmega644 mit 4k sram 
müsste das kein problem sein oder?

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich nochmal,
also die Strings die mittels ffwrite geschrieben werden, sind alle mit 
\0 terminiert. Hab es jetzt ohne ständiges öffnen uns schliessen 
probiert. Brachte auch keinen Erfolg. Brauch nach circa 2h bei einem 
ffwrites ab.
Vielleicht haste noch eine Idee woran es liegen koennte. Danke schon 
mal.

Peter

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

@obi (Gast)
Nee das sollte kein Problem sein.

@Peter (Gast)
Hm, Du versuchst das nicht Batterie betrieben oder?
Beim schreiben zieht so eine Karte mal gut strom...

Über welche Datenmenge sprechen wir denn da bei den 2 Stunden?

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

@Peter (Gast)
Bist Du da noch dran an dem Problem?

Nur der Vollständigkeit halber, wenn man viel Strom aus einer schwächer 
werdenden Batterie zieht, bricht die Spannung ein -> Kontroller Reset...

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
im Grunde schon, habs erstmal nen bisschen weiter nach hinten geschoben, 
genug andere Arbeit. Ne ich betreib es mit einem Netzteil, und nen 
lf33cv, der sollte eigentlich genug Strom liefern. Ich glaub 
mittlerweile auch nicht mehr das es an der Lib liegt, sondern eher an 
der Karte, SanDisk Extreme III, hab nur leider keine andere zur Hand.

Gruesse
Peter

Autor: Paul P. (pommespaule)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,
erstmal: Absolut genial was hier für eine Lib entstanden ist. Da muss 
man schon mal den Hut ziehen !

Ich hab allerdings noch ein Problem mit dem Schreiben. Lesen 
funktioniert einwandfrei.
Wenn ich ein einzelnes Byte schreiben will (die Datei ist vorhanden und 
in ihr war vorher auch nur ein Byte):
if(TRUE == fat_loadFatData()){
  unsigned char file_name_offset[]="OFFS    KOM";
  if(MMC_FILE_EXISTS == ffopen(file_name_offset)){
    ffwrite(0x99);
    ffwrite(0x99);
    ffclose();
    }
  }
muss ich, wie ihr seht, den Befehl dazu zwei Mal geben. Wenn das zweite 
ffwrite auskommentiert ist, tut sich in der Datei gar nichts.

Das Anhängen an die Datei per vorgeschobenem
 ffseek(file.length) 
funktioniert weder mit einem noch mit zwei Befehlen.

Meine Config habe ich mal angehängt.
Bin über jeden Hinweis dankbar.
Grüße Paul

Autor: Uwe B. (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,

es wäre gut, wenn du mal einige Konstellationen von Defines in config.h 
ausprobierst! Ich wollte gerade deine Lib mit "readonly" übersetzen und 
bekam einige Fehler um die Ohren gehauen. Z.B., wenn man

#define MMC_WRITE FALSE

setzt, kommt:

/home/x/work/x/sd_card/file.c:626: undefined reference to 
`fat_setClusterChain'
/home/x/work/x/sd_card/file.c:627: undefined reference to 
`fat_getFreeClustersInRow'

Grüße & Danke Uwe

Autor: Uwe B. (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...Zusatz:

wenn man

#define MMC_LFN_SUPPORT  FALSE

setzt, stürzt das Beispielprogramm beim Schreiben der Testdatei 
reproduzierbar ab...

Du solltest wirklich mal dringenst ein Codereview machen!

Grüße Uwe

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
bin gerade etwas eng mit der Zeit die ich fürs Hobby zur Verfügung habe.

Das mit dem "readonly" Fehler ist reingekommen, weil ich da die defines 
umgebaut hatte.

#define MMC_LFN_SUPPORT  FALSE
Das schau ich mir morgen oder die Tage mal an. Glaub ich so nicht 
richtig. Läuft bei mir nämlich in anderen Projekten problemlos.

Nur bei schnellen Prozessoren kann es Probleme mit den low level mmc 
Funktionen geben hab ich bemerkt. Aber das sind dann auch keine AVR 
mehr...

Grüße

Daniel

Autor: Uwe B. (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,

meine Testumgebung ist ein Mega168 mit 16MHz getaktet, also eigentlich 
deine Default-Konfiguration...

Daniel R. schrieb:
> #define MMC_LFN_SUPPORT  FALSE
> Das schau ich mir morgen oder die Tage mal an. Glaub ich so nicht
> richtig. Läuft bei mir nämlich in anderen Projekten problemlos.
>
Das Fehlerbild sieht wie folgt aus: es kommen genau zwei Zeilen des 
Dateiinhaltes, auch wenn mehr drin steht.

Grüße Uwe

PS.: für mich wäre es wichtig, wenn die "readonly"-Geschichte 
funktioniert. Ich könnte auch selbst am Code rummachen, aber habe keine 
Berechtigung, das Zeugs wieder ins SVN zurück zu laden... Deshalb würde 
ich es gerne dir überlassen!

Autor: Uwe B. (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,

ein weiterer Fehler:

file.c --> ffls() --> lsRowsOfClust()

Ein Dateiname ist mindestens 11 Zeichen lang. Du deklarierst temp als 
Array mit 11 Byte und schreibst an die 11.Stelle eine \0, als 
Stringende. Damit geht das letzte Zeichen des Dateinamen verloren...

Grüße Uwe

PS.: sorry, dass ich so penetrant bin. Ich wollte eigentlich deine Lib 
zum Einlesen von Basic-Programmen 
(http://www.mikrocontroller.net/articles/AVR_BASIC) von einer SD-Karte 
benutzen, stolpere aber derzeit leider über die Fehler in der Lib.

Autor: Uwe B. (boerge) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MoinMoin,

...siehe 
Beitrag "Re: Basic-Interpreter auf einem AVR"

Grüße Uwe

PS.: eine Funktion ffeof() wäre auch ganz nett...

PPS.: aber auch Lob für deine Lib, ich bin trotz einige Ungereimtheiten 
relativ schnell zum Ziel gekommen!

Autor: Sven S. (schwerminator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tach auch.

Zuerst einmal: Eine super Bibliothek, die auf Anhieb funktioniert hat. 
Top!

Allerdings bin ich nun auf ein Problem gestoßen: Wenn ich eine Datei 
(zum Lesen) öffne und sie von Anfang bis Ende mit ffread() auslese, ist 
es mir danach nicht mehr möglich eine neue Datei zu öffnen. Egal ob ich 
die datei schließe oder nicht. Waron könnte das liegen?

Gruß Sven

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
da müsstest Du mal den Code zeigen. Kann ich so nicht viel zu sagen.



Grüße

Daniel

Autor: Sven S. (schwerminator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier kommt er:
unsigned char file_name[6]=" .mp3";
  unsigned char file_handle;
  for(uint8_t file_no=0; file_no<10; file_no++){
    file_name[0] = file_no + '0';
  
    printf("loop #%u, trying to open %s\n", file_no, file_name);
  
    file_handle = ffopen(file_name);
    if(MMC_FILE_EXISTS != file_handle)
      printf("Error opening file: %s (%u)\n", file_name, file_handle);
    else{
      printf("%s opened. Size: %lu Bytes\n", file_name, file.length);

      for(uint32_t b=0; b<file.length/512+1; b++) {
        // Regler per UART stellen
        input_1 = uart_getc();
        input_2 = uart_getc();
        if ( !(input_1 & UART_NO_DATA)  && !(input_2 & UART_NO_DATA) ){
          switch(input_1){
            case 1: sta015_set_atten(input_2); break;
            case 2: sta015_set_bass((int8_t)input_2); break;
            case 3: sta015_set_treble((int8_t)input_2); break;
          }      
        }
      
        // alle 128kB nenn bissel Info lesen
        if((b & (0x000000FF)) == 0xFF){
          printf("%u Kbit/s ", sta015_read_reg(STA015_REG_AVERAGE_BITRATE)<<1);
          printf("Head: 0x%02X%02X%02X ", sta015_read_reg(STA015_REG_HEAD_H), sta015_read_reg(STA015_REG_HEAD_M), sta015_read_reg(STA015_REG_HEAD_L));
          printf("Error: 0x%02X ", sta015_read_reg(STA015_REG_ERROR_CODE)&0x3F);
          //printf("Ancillary Data bits: 0x%02X%02X ", sta015_read_reg(STA015_REG_ANCCOUNT_H), sta015_read_reg(STA015_REG_ANCCOUNT_L));
          //printf("Ancillary Data 1: 0x%02X ", sta015_read_reg(STA015_REG_ANC_DATA_1));
          uart_putc('\n');
        }
    
        // Noch zu lesende Bytes ermitteln
        int16_t max = 512;
        if(b==file.length/512)
          max = file.length%512;
        
        // 512 Bytes von der SD-Karte lesen
        SPCR &= ~(1<<CPHA);
        for(uint16_t byte=0; byte<max; byte++)
          buffer[byte] = ffread();
        SPCR |= (1<<CPHA);
    
    
        // BIT_EN auf High
        SPI_CS_STA_PORT |= (1<<SPI_CS_STA);
    
        int16_t i = 0;
        // Block an den Decoder senden
        while(i < max){
          // Auf Data Request warten
          while(!(STA015_DATAREQ_PIN & (1<<STA015_DATAREQ)));
      
          // So lange wie Data Request an ist, Daten senden
          while((STA015_DATAREQ_PIN & (1<<STA015_DATAREQ)) && i < max){
            // Zeichen an den Decoder senden
            SPDR = buffer[i++]; num_bytes++;
            // auf SPI Übertragung warten
            while(!(SPSR & (1<<SPIF)));
          }
        }
    
        // BIT_EN auf LOW
        SPI_CS_STA_PORT &= ~(1<<SPI_CS_STA);
      }
    
      ffclose();
      printf("Track over\n");
    }
  }
  printf("%lu Bytes gelesen/uebertragen\n", num_bytes);
  printf("Fertig!\n");

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wie äußert sich das denn. Bleibt er beim öffnen hängen oder wie?
Versuch mal testweise die Karte vor dem erneuten öffnen neu zu 
initialisieren. Wie sieht die config.h aus und die Initialisierung der 
FAT/Karte?

Viele Grüße

Daniel

Autor: Sven S. (schwerminator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Daniel. Wenn ich die SD-Karte und die FAT neu initialisiere, 
funktionierts. Er hatte zuvor gemeldet, die Datei würde nicht 
existieren.

An der Initialisierung der SD habe ich nichts geschraubt und so von dir 
übernommen. Hier meine config.h:
  //#####################################################################################
  // BOOL DEFINITIONEN

  #define TRUE   1
  #define FALSE   0

  //#####################################################################################
  // FLAGS

  // flags fuer ffopen (sind die rueckgabewerte von ffopen, auf diese wird geprueft..)
  #define MMC_FILE_NEW       0  // datei existierte nicht, wurde gerade angelegt !
  #define MMC_FILE_EXISTS     1  // datei existiert, es kann gelesen werden !
  #define MMC_FILE_NOT_EXISTS     2  // datei existiert nicht, wird nur bei read-only zurueckgegeben, wenn die datei nicht gefunden wurde !


  //#####################################################################################
  // WICHTIGE SCHALTER

  // schalter die den funktionsumfang aendern bzw, den funktionsumfang einiger funktionen :)
  #define MMC_WRITE           FALSE  // TRUE, dann mit write unterstuetzung, wenn FALSE dann read only !
  #define MMC_OVER_WRITE       FALSE  // TRUE und MMC_WRITE TRUE, dann kann ffwrite dateien überschreiben, wenn FALSE dann nur normales schreiben. um an eine datei anzuhaengen ist MMC_OVER_WRITE TRUE nicht noetig!
  #define MMC_MULTI_BLOCK     FALSE  // TRUE und MMC_OVER_WRITE FALSE, dann werden multiblock schreib/lese funktionen benutzt. ist schneller, wird aber möglicherweise nicht von allen karten unterstützt. wenn FALSE ist normale operation
  #define MMC_SDHC_SUPPORT    FALSE  // TRUE, dann mit sdhc unterstuetzung, wenn FALSE, dann nur mmc/sd karten. siehe : http://de.wikipedia.org/wiki/SD_Memory_Card#SDHC_.28SD_2.0.29
  #define MMC_ENDIANNESS_LITTLE    TRUE  // TRUE, dann ist der code auf littleendian ausgelegt. AVR ist littleendian. code ist auf littleendian optimiert!! siehe: http://de.wikipedia.org/wiki/Endianness
  #define MMC_LFN_SUPPORT      TRUE  // TRUE, dann mit unterstuetzung fuer lange dateinamen. kostet wenn read und write benutzt wird um die 800 bytes flash...
  #define MMC_RM_FILES_ONLY    TRUE  // TRUE ,MMC_WRITE TRUE und MMC_RM TRUE, dann wird die funktion ffrm so mit kompiliert, dass sie nur dateien loeschen kann. wenn FALSE und MMC_WRITE TRUE, dann kann die funktion dateien und ordner rekursiv loeschen !

  // schalter die explizit funktionen mit kompilieren oder nicht!
  #define MMC_TIME_STAMP       FALSE   // TRUE, dann werden die funktionen fat_getTime und fat_getFreeBytes mit kompiliert. siehe auch abschnitt: ZEIT FUNKTIONEN, weiter unten
  #define MMC_RM               FALSE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffrm mit kompiliert.
  #define MMC_SEEK            TRUE  // TRUE,dann wird die funktion ffseek mit kompiliert. mit dieser funktion kann man in einer geoeffneten datei vor und zurueck spulen. nur in kombination mit MMC_OVER_WRITE TRUE kann in einer datei ueberschrieben werden.
  #define MMC_MKDIR            FALSE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffmkdir mit kompiliert. mit dieser funktion kann man ordner anlegen.
  #define MMC_GET_FREE_BYTES  TRUE  // TRUE, dann wird die funkton fat_getFreeBytes mit kompiliert. mit dieser funktion kann der freie platzt auf der karte ermittelt werden
  #define MMC_LS              TRUE  // TRUE, dann wird die funktion ffls mit kompiliert. mit dieser funkion kann man die dateien auf der karte anzeigen lassen
  #define MMC_CD              TRUE  // TRUE, dann werden die funktionen ffcd und ffcdLower mit kompiliert. mit diesen funktionen kann man in ein verzeichnis wechseln oder aus einem verzeichnis ein verzeichnis hoeher wechseln.
  #define MMC_FILE_EXSISTS    TRUE  // TRUE, dann wird die funktion ffileExsists mit kompiliert. mit dieser funktion kann geprueft werden, ob es die datei im aktuellen verzeinis gibt !
  #define MMC_WRITE_STRING    TRUE  // TRUE und MMC_WRITE TRUE, dann wird die funktion ffwrites mit kompiliert. mit dieser funktion koennen strings auf die karte geschrieben werden.

  // vorsicht, da die variable die die sektoren zählt ein short ist (MMC_MAX_CLUSTERS_IN_ROW*fat.secPerClust) !!
  #define MMC_MAX_CLUSTERS_IN_ROW 256   // gibt an wie viele cluster am stück ohne fat-lookup geschrieben bzw gelesen werden können, wenn die fat nicht fragmentiert ist !

  // wenn "#define INLINE inline" dann werden die statischen funktionen inline kompiliert. macht code groeßer, aber auch schneller!
  //#define INLINE inline
  #define INLINE


  //#####################################################################################
  // SPI EINSTELLUNGEN

  // wenn MAX_SPEED FALSE dann wird die SPI bus geschwindigkeit nicht hoch gesetzt. ist zum testen von hardware die nicht richtig läuft
  #define MMC_MAX_SPEED     TRUE
  #define MMC_STATUS_INFO   FALSE

  // software spi? wenn TRUE muessen in der mmc.h noch die pins eingestellt werden über die die spi kommunikation laufen soll
  // es werden nur pins an einem port unterstuetzt !
  #define MMC_SOFT_SPI   FALSE

Schönen Gruß!

Autor: docean (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Paul P. schrieb:
> Das Anhängen an die Datei per vorgeschobenem ffseek(file.length) funktioniert 
weder mit einem noch mit zwei Befehlen.

dito bei mir!!!

Autor: docean (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Version 0.5.9 tut!

Autor: Sven S. (schwerminator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du eine Idee, woran mein Problem liegen könnte, Daniel?


Gruß Sven

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Leider habe ich momentan keine Zeit wegen dem blöden Weihnachten.
Werde aber kommende Woche dazu kommen mir das alles anzuschauen und die 
Probleme zu beheben.

Viele Grüße

Daniel

Autor: Paul P. (pommespaule)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
docean schrieb:
> Version 0.5.9 tut!

Interessant, ich habe aber in der zwischenzeit schon einen Workaround 
gefunden. Mit der Funktion ffwrites() läuft es weil fat.bufferDirty = 
TRUE gesetzt wird. Als habe ich mir eine kleine Funktion hingepfuscht 
die das auch nach dem normalen ffwrite() erledigt. Aber mir schwant es 
schon, so elegant ist das nicht ;)
Vielleicht hilft es ja bei der Fehlersuche. Schönen Feiertag noch

Autor: Kurt B. (kurt)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
mir ist etwas merkwürdiges aufgefallen:

Ich schreibe zuerst 10kB in die Datei. Dann schließe ich sie, öffne sie 
erneut und hänge nochmal 10kB hintendran.

Win XP zeigt dann auch den richtigen Inhalt mit 20kB an. Wenn ich chkdsk 
laufen lasse werden aber Fehler korrigiert und die Datei hat danach 
24kB!

Mega32 @ 8MHz, 5V

Guten Rutsch!

Mfg,
Kurt

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
zunächst vielen Dank für die tolle Arbeit.
Ich habe eine ganzen Tag gebraucht, um meine alten 16MB-SD-Karten zum 
Laufen zu bringen.
Problem war offensichtlich, dass Windows 16MB-Karten nur mit FAT12 
formatiert und diese FAT12 dann beim Schreiben durch den AVR zerstört 
wird.

Wenn man in der Console dagegen "format x: /a:2048" verwendet, wird auch 
die 16MB-Karte in FAT16 formatiert und nun funktioniert alles. Ein 
Hinweis darauf in der Doku wäre nicht schlecht.
Oder vielleicht beim Initialisieren prüfen, ob da auf der Karte 
überhaupt eine nutzbare FAT16 oder FAT32 drauf ist, bevor man da was 
kaputtschreibt.

Eine andere Frage:
Vermutlich gibt es keine Möglichkeit, die 512Bytes RAM für den 
Sektorbuffer irgendwie zu reduzieren?
Mein ATMEGA16 ist da zusammen mit anderen Programmteilen schon extrem 
voll und ich hab da ein bissel Angst vor einem Stack Overflow, bei dem 
ich dann ewig den Bug suche.

Michael

Autor: Barny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael R. schrieb:
> Vermutlich gibt es keine Möglichkeit, die 512Bytes RAM für den
> Sektorbuffer irgendwie zu reduzieren?
Bei Flash-Speichern müssen immer 512Byte auf einmal geschrieben werden.
Wenn man alles auf einen Rutsch schreiben will, braucht man eben diesen 
Speicher.
Du hast jetzt 2 Möglichkeiten.
Entweder du optimierst den Speicherverbrauch, oder du steigst auf einen 
ATmega32 um.

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
Ich habe hier auch noch ein seltsames Problem bezüglich Anhängen.
Wenn der AVR frisch startet und an eine bestehende Datei anhängen soll, 
dann geht das schief. file.length gibt bei jedem neuen Öffnungsversuch 
immer wieder den gleichen Wert zurück, obwohl ich zwischendurch bei 
geöffneter Datei mit ffwrites was angehängt habe.
Also folgende Reihenfolge:
-Init-CARD/FAT
-ffopen
-ffseek(file.length) (falls MMC_FILE_EXISTS zurückkommt)
-ffwrites
-ffclose
-Init-CARD/FAT (Ich mach das jedes Mal, zur Sicherheit)
-ffopen
-ffseek(file.length)
-ffclose

Beim zweiten ffseek wird genau das gleich zurückgeliefert, wie beim 
ersten ffseek. Die Datei wird einfach nicht größer

Wenn die Datei dagegen frisch angelegt wird, scheint das Verlängern 
beliebig häufig zu klappen, bis ich den AVR neu starte, dann geht es 
wieder nicht.
Also eine bereits vor AVR-Boot bestehende Datei wird nicht mehr 
verlängert, eine gerade selbst angelegte Datei lässt sich immer 
verlängern.

Die 16MB-Karte Karte ist so formatiert(chkdsk-Ausgabe):
  14,1 MB Speicherplatz auf dem Datenträger insgesamt.
  14,1 MB sind verfügbar.

    2.048 Bytes in jeder Zuordnungseinheit
    7.241 Zuordnungseinheiten auf dem Datenträger verfügbar

       16 Bits in jedem FAT-Datensatz.

Irgendwie sieht das so aus, als wird irgendwas nicht richtig 
initialisiert.

  Michael

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu dem Anhängen-Problem:
Ich habe mal ein bisschen weiter gewühlt:
Beim Anhängen werden die Daten richtig auf die Karte geschrieben und 
sind mit einem Hex-Editor auffindbar. Ändert man mit dem Hex-Editor die 
Dateigröße, dann werden die geschriebenen Daten auch für das normale 
Windows Notepad sichtbar.
Beim Schließen der Datei wird scheinbar der FAT-Eintrag nicht richtig 
aktualisiert. Mindestens die Dateigröße wird falsch geschrieben.
Ich habe zwar die Funktionsaufrufe beim flush bis runter zum

mmc_write_sector( fat.currentSectorNr,fat.sector );

nachvollzogen, konnte aber nicht rausfinden, warum die Dateigröße nicht 
oder nicht richtig geschrieben wird. (Habe keinen Debugger, ist sehr 
mühsam).

Michael

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soo,
noch ein Stück weiter:

Wenn der AVR die Datei in der aktuellen Sitzung nicht selbst erstellt 
hat,
dann enthält "fat.currentSectorNr" beim Aufruf von "fat_loadSector "in 
der "fflushFileData" immer 0.

fflushFileData:
// dafuer sorgen, dass der sektor mit dem geaenderten dateieintrag geschrieben wird, beim neuladen. datensektor der datei neuladen, falls noch weitere bytes geschrieben werden.
  fat.bufferDirty = TRUE;
  fat_loadSector( save_currentSectorNr );
Das führt dazu, dass "fat_loadSector" versucht, die aktuellen Daten nach 
Sektor 0 zu speichern:
  mmc_write_sector( fat.currentSectorNr,fat.sector );  // schreiben von sektor puffer

Glücklicherweise geht das wohl irgendwie schief und dem Bootsektor 
passiert dadurch offenbar nichts.
Warum "fat.currentSectorNr" nicht die Sektornummer des FAT-Eintrags hat, 
kann ich aber nicht mehr nachvollziehen, das wird mir dann zu 
unübersichtlich.

Michael

Autor: Buzzwang (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

bei meiner SanDisk SD 2GB 2 tut es leider nicht.

Genaueres:
Bei meiner alten Karte(SanDisk Extreme III) hat es noch getan. Leider 
ist diese abgeraucht. Ich habe mir dann die oben gesagte gekauft. Init 
läuft durch. Jedoch beim Lesen des 1. Sector gibt es dann einen Zonk.
Unter Windows tut die Karte (FAT32).Im Anhang ist ein Log.
Ich werde mal sehe ob ich noch was rausfinde. Leider habe ich keine 2 
Karte zum gegentesten.

Autor: Gerd G. (elektrikser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Teste gerade die Lib mit verschiedenen Karten.
Bis jetzt funktionieren:
- Sandisk Sd-Card 2 GB
- Kingston SD-Card 256 MB
- Hama SD-Card 256 MB
- Sandisk Mikro-SD 2GB
- Sandisk Mobile Ultra Micro-SDHC 4GB

Mit Verzeichnisse anlegen habe ich noch nichts gemacht. Mir ging es erst 
einmal um das Speichern und Lesen von Daten.

Gruß Gerd

Autor: Buzzwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe gefunden woran es liegt. Ist ein Problem in "mmc_read_sector"

Warte auf 0xFE tut nicht.

Wenn man es ändert auf z.B.
   if( 0 != mmc_write_command(cmd))  
   {
      return FALSE;
   }

   a = 0;
   do
   {
    //Wartet auf Start Byte von der MMC/SD-Karte (0xFE/Start Byte)
    a++;
    if (a == 255) return FALSE;
   }
   while (mmc_read_byte() != 0xFE);

dann tut es.

Autor: ka-long (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Meine MMC/SD Ansteuerung verhält sich sehr komisch...

Mit einem AtMega16/8MHz hat es mit einer 4GB/SDHC plötzlich funktioniert 
(ein Datenloggen über zwei Stunden ohne Probleme), nachdem ich den LFS 
eingeschaltet hatte...

Wegen zu wenig Speicher hab ich den ATMega16 gegen den pinkompatiblen 
Atmega32 getauscht. Leider habe ich zwischenduch den Code mal etwas (was 
auch immer) modifiziert...

Nach drei Abenden werd ich wohl jetzt frustriert aufgeben:

* mmc_init und load_fat funktionieren

Öffne ich ne Datei in meinem Code mit ffopen ohne was anderes zu tun, 
zeigt mein PC die Datei mit 0 Byte an, gut so.

Öffne ich die Datei und schließe sie direkt wieder mit ffclose, dann 
gibt es keine Datei, aber der PC kann die Karte noch lesen.

Öffne ich die Datei und schreibe ich etwas mit ffwrites wird die FAT 
zerschossen. Egal ob mit oder ohne ffclose.

SPI wird nicht hochgesetzt, ich versorge die Karte mit 3.3V aus einem 
Labornetzteil, der ATMega arbeitet allerdings auf 5V mit 
Spannungsteilern.

Ich hab mit nem Scope die Signale nachgemessen, alle da und für die 
Geschwindigkeit ausreichende Signalintegrität.

Eine andere Karte 2GB/SD läuft gar nicht.

Gruß ka-long

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ka-long schrieb:
> Ich hab mit nem Scope die Signale nachgemessen, alle da und für die
> Geschwindigkeit ausreichende Signalintegrität.

insbesondere die Clock-Flanken bei SPI sind extrem kritisch. Wenn man 
keinen integrierten Pegelwandler verwenden möchte, kann man auch einen 
kapazitiven Spannungsteiler parallel zum normalen Spannungsteiler 
schalten. Folgende Kombinationen sollten funktionieren:

Oberer Kondensator | unterer Kondensator
22p                | 12p
27p                | 15p
33p                | 18p
39p                | 22p
47p                | 27p
56p                | 33p

Wenn ein Tastkopf dranhängt stimmt das Verhältnis wegen der 
Tastkopfkapazität aber nicht mehr. Man sieht also nicht mehr das 
gleiche, wie die Karte ohne Tastkopf sieht. Man muss sich auf die 
Mathematik verlassen.

Michael

Autor: ka-long (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

Sind die Anstiegs- und Fallzeiten denn irgendwo definiert ?

Ich werd mal auf mmc-lib Sektor-Ebene Daten lesen und schreiben und 
schauen, ob es da zu Fehlern kommt oder obs in einer der höheren 
Schichten passiert.
So kann ich vielleicht die HW als Ursache ausschließen...


Gruß ka-long

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ka-long schrieb:
> Sind die Anstiegs- und Fallzeiten denn irgendwo definiert ?

Wenn Du eine matschige CLK-Flanke hast und da noch Rauschen oder 
sonstige Spikes drauf sind, kann es passieren, dass der Empfänger 2 
Flanken kurz nacheinander sieht und dann auch 2 Bits einliest, obwohl 
nur eine Flanke gesendet wurde. In wie weit Doppelflanken unterdrückt 
werden, steht vielleicht im Datenblatt der Karte. Wenn die Karte aber 
z.B. 50MHz SPI unterstützt, dann muss sie Flanken im Abstand 10ns 
erkennen können. Wenn Deine Anstiegszeit aber z.B.100ns ist, dann hält 
sich der Pegel doch einige Zeit im kritischen Bereich auf und kann eine 
Doppelflanke auslösen, wenn Rauschen/Spikes überlagert ist.
Vernünftig entwickelte Clk-Eingänge haben Schmitt-Trigger-Eingänge und 
intelligente digitale Filter drin, die das Problem entschärfen. Aber 
gerade das ist wohl selten spezifiziert.

Die Flankensteilheit der Datenleitungen ist dagegen weniger kritisch, 
der Pegel muss nur zum Zeitpunkt der jeweiligen CLK-Flanke eindeutig 
high oder low sein.

Michael

Autor: Andi S. (laserandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
erstmal Danke für die gute Arbeit. Ich teste seit ein paar Tagen die 
Version 0.6.1 mit einem mega644. Leider läuft die main_simple.c nur dann 
durch, wenn ich den µC resete.
Schaltet man VCC aus und wieder ein bleibt das Programm in der 
fat_loadFatData(); hängen und zwar beim ersten Aufruf von 
loop_until_bit_is_set(SPSR,SPIF);" in der mmc_write_byte Funktion 
(mmc.c).
Was ich schon getestet habe:
- Verzögerung mit  _delay_ms --> ohne Erfolg
- Verschiedene 1 GB sd-Karten --> ohne Erfolg
- Brummspannung auf VCC < 20 mV (Die ganze Schaltung inkl. µC läuft mit 
3,3 V)
Ich glaube nicht, dass es ein Hardwareproblem ist.
Komisch ist, dass vor "fat_loadFatData();" noch die mmc_init(); 
problemlos aufgerufen wird, ohne das das Programm in mmc_write_byte fest 
hängt?!

Vielleicht könnt Ihr mir einen Tipp geben, was ich noch versuchen kann, 
damit die main_simple.c direkt durchläuft.
Danke.
Gruß
Andi

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich bin da gerade immer mal wenn ich etwas Zeit habe dran am arbeiten.

Ich habe jetzt einen stm32 mit jtag Debugger, damit arbeitet sich 
wesentlich leichter als mit einem avr und Debug Ausgaben über die 
Konsole :)

Was wohl auf jeden Fall geändert werden wird, sind die Delay schleifen 
in der mmc.c, die werden auf einen Timer umgestellt werden müssen.

Die Initialisierung der Karten wird auch geändert sowie der Ablauf von 
den schreibe und lese Funktionen. Also quasi der ganze Unterbau wird 
geändert. Zudem noch die Datei öffnen Funktion.

Bitte um etwas Geduld...habe bald Semesterferien, die letzten :) da wird 
das wohl spätestens was werden....

Viele Grüße

Daniel

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
wenn Du das Timing auf einen Timer umstellst, wird das Einbinden in 
verschiedene andere Projekte deutlich schwerer oder unmöglich. Ich habe 
Deine lib in einem Projekt drin, in dem keine Timer mehr verfügbar sind.

Super wäre es, erstmal eine stabile weitgehend bugfreie Version zu 
schaffen, denn derzeit ist das definitiv nicht der Fall.

Ansonsten finde ich Deine Arbeit echt super, eine Lib, die wenig 
Resourcen braucht und einfach einzubinden ist.

Michael

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

>wenn Du das Timing auf einen Timer umstellst

Genau da ist beispielsweise einer der Bugs. So eine Karte genehmigt sich 
schon mal bis zu 200 ms um Daten zu speichern oder um einen Block zu 
lesen. Da rasselt man dann einfach aus den warte Schleifen raus, 
zumindest so wie die momentan sind.

Ich hab mir das so vorgestellt, dass man einfach eine bestimmte Funktion 
im 10 ms Takt aufrufen muss.
Im Beispielcode würde ich dann ein Timer Beispiel machen, wie das dann 
letztendlich in einem eigenen Projekt umgesetzt wird muss dann jeder 
selber schauen...

Grüße

Daniel

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
ich meinte den z.B. den Bug, dass die FAT beim Anhängen nicht richtig 
geschrieben wird.
Ansonsten hat Dein Ansatz mit den Timern definitiv Vorteile, da der 
Controller in den Warteschleifen nicht blockiert wird.
Du baust also keine Timerfunktionen direkt in die Lib ein sondern 
erwartest ein Pollen Deiner Funktionen?

Michael

Autor: recently (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hätte mal eine Frage zur "Superfloppy"-Erkennung. Mit meiner frisch 
gekauften 2GB-SD-Karte lief das AVR-FAT-Paket auf meinem Pollin net-io 
mit SD-Addon zunächst tadellos. Diese SD-Karte hatte in Sektor 0 einen 
MBR mit Partitionstabelle. Nun habe ich die SD-Karte in meinem 
Windowsrechner neu mit FAT32 formattiert. Dadurch verschwand der MBR und 
die neue Partition beginnt nun ohne Umwege direkt in Sektor 0, die Karte 
hat also "Superfloppy"-Format. Wenn ich es richtig verstanden habe, 
untersucht die AVR-FAT-Software den Boot-Code der Partition auf die 
Zeichenkette "medi", die an der Stelle erwartet wird, wo sonst die 
Anfangsadresse der 1.Partition steht. Dies funktioniert bei mir nicht. 
Die Zeichenkette "medi" ist um 2 Bytes versetzt, wodurch die 
Superfloppy-Erkennung scheitert und alles weitere natürlich auch. Habe 
das Debugger-Listing angehängt, in dem der Versatz zu erkennen ist. Habe 
ich irgendetwas nicht richtig beachtet ?

Vielen Dank für Tipps
recently

Autor: daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich bin dazu gekommen mal ein wenig an der Lib zu arbeiten.
Als Anhang mal die frischen Dateien.

Es gibt einige Änderungen.

In der mmc.c ist aufgrund der Portierbarkeit ein eigener SPI Teil dazu 
gekommen. Zum anpassen an andere Plattformen müssen jetzt nur noch die 
Funktionen,

spi_init
spi_maxSpeed
spi_write_byte
spi_read_byte

und die defines,

#define MMC_CS_LOW     GPIO_ResetBits(GPIOA, GPIO_Pin_4)
#define MMC_CS_HIGH    GPIO_SetBits(GPIOA, GPIO_Pin_4)

angepasst werden.

Auch in der mmc.c geändert:
Die Initialisierung der SD/MMC Karten.
Die Bestimmung ob Superfloppy oder nicht.
Zeit gesteuerte delay Schleifen beim lesen/schreiben, wegen der Totzeit 
der Karten bei diesen Operationen.

Ganz wichtig! Es muss irgendwo eine globale Variable
 volatile unsigned char TimingDelay; 
 geben, die in 10 ms Intervallen bis 0 runtergezählt wird!

In der file.c hat sich ffopen geändert.
Es wird jetzt nicht mehr einfach die Datei angelegt wenn sie noch nicht 
vorhanden war. Hat oft zu Verwirrung geführt.

ffopen(name,'r') öffnet die Datei falls vorhanden und gibt 
MMC_FILE_OPENED zurück. Oder aber MMC_NOTHING_DONE.

ffopen(name,'c') legt eine Datei an falls es die Datei noch nicht gibt 
und gibt MMC_FILE_CREATED zurück. Oder aber MMC_NOTHING_DONE wenn es die 
Datei schon gab...

In der fat.c hat sich das suchen nach Dateinamen geändert. Bei kurzen 
Dateinamen wird von PC Betriebssystemen manchmal nur ein SFN angelegt. 
Das ist jetzt in der Lib angepasst.


Es wird demnächst noch weiter gehen...

Grüße

Daniel

Autor: Manfred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den neuen Modulen ist bei mir nichts mehr compilierbar ... schade, 
ob das jetzt wirklich ein Gewinn war ?

Gibt es denn dazu auch eine passendes "main_simple", das nach diesem 
Totalaustausch der Quellen noch läuft ? Das man es wenigstens mal 
ausprobieren kann ?

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

vielen Dank für die neue Version. Die Superfloppy-Erkennung sieht gut 
aus. Gibt es denn auch eine AVR-Version ? Die Version im fix-zip-file 
scheint für STM32-Hardware ausgelegt ?

Viele Grüße
recently

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
es wird die Tage die AVR Version geben.
Jo, das ist für einen STM32 momentan.
Sollte jetzt keine finale Version sein.

Viele Grüße

Daniel

Autor: daniel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
jetzt sollten alle Fehler behoben sein.

Hier schonmal die STM32 Version. Bisher nur mit lfn Option getestet...
Die AVR Variante braucht noch etwas Zeit,
sollte aber auch relativ einfach aus der SMT32 Version zu portieren 
sein.

Viele Grüße

Daniel

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ist der Datei Anhängen Bug gefixt?

Michael

Autor: recently (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

ich beschäftige mich gerade intensiv mit dem AVR-FAT-Code und habe eine 
Frage zum Element file.dir : Das Element wird in der Funktion 
fat_loadFatData einmal auf 0 gesetzt und dann an verschiedenen Stellen 
der Software auf 0 geprüft ... was ist die Bedeutung dieses Elements ?

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... meinte natürlich das Element "fat.dir"

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
da wird der 1. Cluster des aktuellen Verzeichnisses gespeichert. Damit 
man weiß in welchem Ordner man sich befindet.
Wird nur durch ffcd() und ffcdLower() geändert. Mit ffcd() wechselt man 
in ein Verzeichnis und mit ffcdLower() geht man ein Verzeichnis höher 
(auch als "cd.." bekannt).

Viele Grüße

Daniel


PS: Die AVR Version ist soweit. Bin nur noch ausgiebig am testen.

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die schnelle Antwort ...

Viele Grüße
recently

Autor: Daniel R. (zerrome)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
hier jetzt mal die fertigen Sachen.

Es wäre super, wenn ein paar Leute mittesten könnten.

Es gab eigentlich nur einen Bug, den ich selber eingebaut hatte von 
0.5.9 auf 0.6.1, dummerweise...

Der ist jetzt weg und es gibt neue Features...

Viele Grüße

Daniel

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

mit meinem ATMega32 (der NetIO von Pollin) mit 18.432 MHz bekomme ich 
Schwierigkeiten beim compilieren ... Die Taktfrequenz wird im Header 
nicht angeboten und weiterhin hat der Mega32 auch kein "TCCR0A" ...

Viele Grüße
recently

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, dann musst Du den Timer per Hand einstellen.
Die Timer ISR muss alle 10ms aufgerufen werden.
Für den mega32 werde ich das aber wohl auch noch einbauen...

Grüße

Daniel

Autor: nicht Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich werde deine Version auch testen.
Ich wollte mal fragen warum du überall "unsigned char var[]" als 
Parameter nutzt.
Könnte man da nicht "char *var" nehmen dann muss man nicht immer rum 
casten wenn man Standard lib Funktionen nutzt.
Also statt:
extern unsigned char ffopen( unsigned char name[], unsigned char 
rw_flag);
ein:
int8_t ffopen(char *name, uint8_t rw_flag);

Vielen dank das du das hier veröffentlicht hast, wie gesagt soll nur ein 
Vorschlag sein.

Autor: XMEGA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,


 Daniel R. schrieb:
> Es wäre super, wenn ein paar Leute mittesten könnten.

hab mich mal mit der neuen  Version beschäftigt.

Bis jetzt war ich begeistert- aber nun macht es doch erhebliche 
Probleme. Insbesondere mit einem neuen Prozessor.

Die Timer-Geschichte mag zwar funktionieren ist aber gegen der 
vorherigen Version komplizierter geworden.

Mit den #If, #else, #endif  verliert man total die Übersicht.

Trotz alledem bin ich über Deine Vorgängerversion froh, die funktioniert 
ohne Probleme auf allen Atmegas/Atxmegas.

Gruß XMEGA

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
bei der Timer Version ist das einzige komplizierte, dass es eine ISR 
geben muss die alle 10ms aufgerufen wird und in der
TimingDelay = (TimingDelay==0) ? 0 : TimingDelay-1; 
seht.
Sonst hat sich alles nur zum Vorteil geändert.
Besonders bei sfn (short file names) ist es doch wesentlich bequemer
 unsigned char file [] = "test.txt";
zu schreiben als
 unsigned char file [] = "TEST    TXT"; 

Aber gut, zu dem Timer Punkt werde ich mir etwas überlegen. Vielleicht 
hat ja jemand eine Idee, wie man aus F_CPU und ein paar Assembler 
Befehlen auch so etwas hinbekommen kann wie gezieltes warten von maximal 
200 ms.

Wenn man eclipse als IDE benutze, kann man die #if die nicht benutzt 
werden ausblenden lassen, oder sie grau hinterlegen lassen, das ist sehr 
übersichtlich.

char * mag ich nicht als Standard Typ verwenden, weil das signed ist und 
somit im 2er Komplement. Das ist nicht so Ressourcen schonend...

Viele Grüße

Daniel

Autor: nicht Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> char * mag ich nicht als Standard Typ verwenden, weil das signed ist und
> somit im 2er Komplement. Das ist nicht so Ressourcen schonend...

Aha, ok wenn du meinst, für String Bearbeitung macht das zwar keinen 
unterschied aber nun ja...

Für den Timer währe es sinnvoll wenn man per define einstellen könnte 
alle wie viel ms die Zähler runtergezählt wird, so könnte man eine 
Bestehende Timer Funktion verwenden.
// in Header
#define COUNT_VALUE  15  // Value in ms

// irgendwo im Code
TimingDelay = 1000 /  COUNT_VALUE;
if(!TimingDelay)
  TimingDelay =1;
while(wait);


Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Code versteh ich nicht...

Wie ist das gemeint?

Man kann doch bestehende Timer einfach mitbenutzen... es muss halt nur 
TimingDelay im 10ms Takt um 1 runter gezählt werden, bis auf 0.
Um mehr muss man sich nicht kümmern.

Autor: nicht Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> es muss halt nur
> TimingDelay im 10ms Takt um 1 runter gezählt werden

Und das ist der Punkt. wenn deine Timer mit z.B. 15ms oder 5ms laufen 
kannst du sie nicht so einfach benutzen.
Bzw. musst du selber im Timer schauen das du z.B (5ms) nur jedes zweite 
mal dekrementierst oder (15ms) jedes zweite mal doppelt dekrementieren 
musst.

Autor: nicht Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry hatte da noch einen kleinen Fehler im Code
// in Header
#define COUNT_VALUE  15  // Value in ms

// irgendwo in mmc.c
TimingDelay = 1000 /  COUNT_VALUE;

if(!TimingDelay)
  TimingDelay =1;

while(TimingDelay && funktionaufdiegewartetwird());

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich dachte ja nur, dass ich ein Beispiel der Benutzung gebe.

>..wenn deine Timer mit z.B. 15ms oder 5ms laufen
>kannst du sie nicht so einfach benutzen...

Wenn man das dann in ein Projekt einbaut, muss man sich genau um solche 
Dinge ja Gedanken machen und ändern.

Mit der Anweisung:
Decrementiere TimingDelay im 10ms Takt um 1, bis auf 0, sollte man ja 
klar kommen können.
Man kann aber auch einfach TimingDelay nach 200ms auf 0 setzten und gut 
ist. Die Idee ist halt, mindestens 200ms auf die Karten zu warten.

Ich Persönlich würde ja eine Lösung ganz ohne Timer auch besser finden, 
hab aber noch nicht die zündende Idee wie man das schön machen könnte.

Autor: little_man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Allgemeine Frage:
Funktioniert der Code mit MMCplus Karten?

Bekomme nämlich Transcend MMCplus Karten (1GB & 2 GB) nicht ans laufen!
Die Karte kann nicht initialisiert werden. Andere Karten funktionieren!

mfg

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bekomme leider auch eine 2GB Verbatim SD-Card und eine 1GB von 
Platinum nicht zum laufen. Nur eine alte 1GB Noname funktioniert.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ist MMCplus der Standard 3.0 ? Das sollte nämlich gehen.

Wobei ich mehrmals Probleme hatte ist, wenn der MISO Pin keinen Pullup 
hat. Das geht mit alten Karten meistens noch, aber mit neuen nicht mehr.

Den Initialisierungs Kram hab ich bei anderen abgeschaut, und nur noch 
mal mit den Specs verglichen...

>Man kann aber auch einfach TimingDelay
>nach 200ms auf 0 setzten..

Muss ich mir selber etwas widersprechen, ist nämlich einmal nach 200ms 
und beim Initialisieren der Karten 1000ms...

Viele Grüße

Daniel

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider funktioniert trotz MISO PullUP nur eine der 3 Karten. Mit der 
0.5.9C hatten die alle funktioniert.
Schade dass ich keine Zeit zur Fehlersuche habe.

Aber jetzt was positives: Die Performance scheint besser geworden zu 
sein. Statt 60kB/s sind es nun 80kB/s auf einem Mega32 mit 18,432Mhz.

Mfg,
Kurt

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>..0.5.9 hatten die alle funktioniert..

das blöde ist das ich keine Karte habe mit der es nicht klappt, daher 
ist das Fehlersuchen nicht möglich.

80kB/s ist aber trotzdem sehr langsam. Benutzt Du software SPI?
Mit 18,432Mhz Quarz und hardware SPI müsste das eine sehr langsame Karte 
sein.

Ich hab hier SD Karten die mit 16Mhz 170kB/s machen. Auch welche mit 
über 200kB/s...

Alles schreibend, lesend noch schneller...

Außerdem ist an den schreib Routinen eigentlich nichts geändert.

Viele Grüße

Daniel

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ich nutze Hardware SPI.
Wahrscheinlich liegt die geringe Geschwindigkeit daran dass ich immer 
nur ein einzelnes Byte schreibe?

Falls sonst niemand Probleme mit den SD Cards hat, habe ich wohl einen 
Fehler eingebaut der so offensichtlich ist dass ich ihn immer übersehe. 
;-)

Mfg,
Kurt

Autor: little_man (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

>ist MMCplus der Standard 3.0 ?

Ich meine das ist der neue Standard 4.0. Kann mich aber auch täuschen!

mfg

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Kurt Bohnen (kurt)

Also wenn Du normal mit ffwrite() schreibst, puffert die Lib eh 512 
Bytes zwischen. Da sollte das Problem nicht liegen.
Ach ja, wenn überschreiben an ist, ist das schreiben etwas langsamer...

@ little_man (Gast)

Ja stimmt, ist 4.x, wenn Du da eine Spezifikation findest, schau ich mir 
das mal an und setzt das dann um...


Viele Grüße

Daniel

Autor: Sven S. (schwerminator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das könnte helfen.

Gruß Sven

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ja das sieht auf den ersten blick schon mal sehr gut aus.


Danke :)

Viele Grüße

Daniel

Autor: Kurt B. (kurt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> Ich hab hier SD Karten die mit 16Mhz 170kB/s machen. Auch welche mit
> über 200kB/s...

Hallo Daniel,
kannst du ein paar Namen nennen?

Mfg,
Kurt

Autor: Markus K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Erstmal vielen Dank fuer die tolle Library. Bin ziemlich neu in der Welt 
von uC. Trotzdem habe ich es geschaft dank der Library auf die SD-Karte 
zu speichern. Das spricht wohl fuer sich. (super super Sache das)

Ein Problem habe ich aber noch.
 ffseek(file.length); 
Dauert am Anfang ca. 5ms  30min. spaeter 28ms (Datei ist dann 2.85MB 
gross)

Habe weiter oben beim Eintrag vom 17.9.2010 gesehen das ffseek nicht 
durchgefuehrt werden muesste wenn File nicht geschlossen wird. 
Funktioniert bei mir aber leider nicht. (Auf dem SPI-Bus sind noch 
andere Teilnehmer. Sollte aber doch nichts ausmachen)

Um meine Frage kurz zu fassen: Wie kann ich die Zeit zum spulen 
verkuerzen?
(Sollte doch moeglich sein file.length zu merken aber wie?)

Vielen Dank

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Kurt Bohnen (kurt)
Muss ich mal nachschauen, bin grad nicht zuhause.

@ Markus K. (Gast)
Schließt Du die Datei beim schreiben immer oder wieso das ffseek?
Du könntest alternativ ein fflush machen anstelle von schließen...

Zeig doch mal ein bisschen code


Viele Grüße

Daniel

Autor: Markus K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja ich schliesse sie nach jedem anhaengen wieder. Hab auch mal versucht 
sie offen zu lassen doch dann stimmten die Eintraege nicht mehr. Ich 
haenge alle 200ms ein paar Daten an.(sollte so eine xml Datei entstehen)

Verstehe ich das richtig:
fflushFileData(); anstelle von ffclose();
und dann kein ffopen(filename); mehr oder?

Vielen Dank.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja genau.

>Hab auch mal versucht sie offen zu lassen
>doch dann stimmten die Eintraege nicht mehr.

Das müsstest Du mal genauer erklären, bzw zeigen, wie Du die lib 
benutzt.

Viele Grüße

Autor: Markus K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry war mein Fehler hab wohl irgendwo im Code vergessen ffclose oder 
ffopen auszukommentieren.

Nun funktioniert es mit dem geoeffnet halten der Datei.
Sorry

Nochmals Vielen Dank fuer deine tolle Library

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, kein Problem.
Viel Spaß noch :)

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel.
 Danke erstmal für die Lib, grad die Fat Funktionen sind super und Fat32 
geht auch einwandfrei.

Ich habe aber immer wieder mit der Karteninitialisierung Probleme.
Kleine Karten < 1GB gingen vom Start weg aber die grossen, bei denen man 
im Init in den SDv2-Block läuft machten Probleme.
Ausserdem habe ich einige Karten gehabt, die nicht sofort auf CMD0 
reagiert haben. Und auch auf CMD16 reagieren manche nicht sofort. 
Hierfür habe ich jeweils eine Schleife eingefügt.

Ich habe die Init-Fuktion etwas angepasst:
unsigned char mmc_init (void){

  unsigned char cmd, ty, ocr[4];
  unsigned short n, j;

  spi_init();
  mmc_disable();

  for (n = 100; n; n--) spi_read_byte();    // 80 dummy clocks

  ty = 0;
  j=100;
do {
  if (mmc_send_cmd(CMD0, 0) == 1) {      // Enter Idle state 
    j=0;
    TimingDelay = 100;            // Initialization timeout of 1000 msec

    if (mmc_send_cmd(CMD8, 0x1AA) == 1) {  // SDv2? 
      for (n = 0; n < 4; n++){
        ocr[n] = spi_read_byte();    // Get trailing return value of R7 resp 
        }
      if (ocr[2] == 0x01 && ocr[3] == 0xAA) {            // The card can work at vdd range of 2.7-3.6V 
      
//        while (TimingDelay && mmc_send_cmd(ACMD41, 1UL << 30));  // Wait for leaving idle state (ACMD41 with HCS bit)
        while (TimingDelay) {  // Wait for leaving idle state (ACMD41 with HCS bit)
          mmc_send_cmd(CMD55, 0);
          if(mmc_send_cmd(ACMD41, 1UL << 30))
            break;
        }
                                ty = CT_SD2 | CT_BLOCK;
      }
    } else {        // SDv1 or MMCv3 
      if (mmc_send_cmd(ACMD41, 0) <= 1)   {
        ty = CT_SD1; 
        cmd = ACMD41;  // SDv1 
      } else {
        ty = CT_MMC; 
        cmd = CMD1;    // MMCv3 
      }
      while (TimingDelay && mmc_send_cmd(cmd, 0));      // Wait for leaving idle state 
    }
    while(TimingDelay && (mmc_send_cmd(CMD16, 512) != 0));
    if(!TimingDelay) ty = 0;
  } else { j--; }
  }while(j>0);
  fat.card_type = ty;
  mmc_disable(); 

  if( fat.card_type == 0 ){
    return FALSE;
  }
  #if (MMC_MAX_SPEED==TRUE)
    spi_maxSpeed();
  #endif

  return TRUE;
}

Um SDHC-Karte überhaupt zum laufen zu bewegen (besonders eine 
8GB-MicroSD) musste ich die ACMD41-Schleife noch um das vorherige Senden 
von CMD55 erweitern, so wie es in der Spec auch gefordert wird.

Die Abfrage auf CMD58 habe ich raus genommen, da diese von keiner meiner 
Karten anders als mit 05 (Illigal Command) beantwortet wird.
Bei meinen SDHC Karten mit 4 und 8GB hat das mit
ty = CT_SD2 | CT_BLOCK;
ganz gut funktioniert, aber jetzt habe ich eine extrememory 2GB bei der 
er auch in den SDv2-Block läuft die nur mit
ty = CT_SD2;
läuft. Also die Zugriffe der FAT-Funktionen klappen sonst halt nicht 
mehr.
Gibt es noch eine andere Möglichkeit als CMD58 hier eine Unterscheidung 
zu machen?

Eine 1GB Platinum hingegen läuft auch in diesen Block bleibt jedoch am 
ACMD41 hängen: es kommt immer 0x00 zurück, sie kommt also nie in den 
Idle-State.

Any Ideas? Gerade bezüglich des CT_SD2 bzw. CT_BLOCK, weil wenn dann nur 
noch die Platinum Karte nicht ginge wäre das zu verschmerzen...die 
scheinen ja eh etwas tricky zu sein.

Gruß
Fabian

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Ergänzung:

wenn ich die CMD58 Abfrage vor der CMD55->ACMD41 Kombination sende 
bekomme ich eine "Antwort". Die Karten senden dann nicht mehr 05 
(Illegal Command) sondern immer 01 (Idle State). Wenn ich danach noch 4 
Byte lese bekomme ich für das CCS Bit aber immer 0, egal ob SDHC oder 
nicht HC.
Es muss doch noch eine Möglichkeit geben SDv2 von SDHCv2 Karten zu 
unterscheiden?!

Gruß
Fabian

Autor: Michael R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
hatte gerade mit meinem 8MHz-System Probleme, die SD-Karte zuverlässig 
zu initialisieren. Nachdem ich den SPi-Prescaler von 128 auf 64 geändert 
habe, gehts jetzt offenbar zuverlässig. Die Initialisierungs-SPI-Clock 
wird in der MMC.C fest mit fCPU/128 gesetzt.
Vielleicht wäre es sinnvoller dass diese in Abhängigkeit vom CPU-Takt 
gesetzt wird, der in irgendeinem h-file definiert wird.

Laut einigen Quellen müssen die Init-Takte mit 100-400kHz erzeugt 
werden, was beim 128er Teiler erst ab 12,8Mhz zutrifft. Vielleicht wäre 
es auch sinnvoller, beim AVR standardmäßig den 64er-Teiler zu nutzen. 
Das deckt besser die typischen Taktfrequenzen ab.

Michael

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.

@ Fabian B. (fabs)
Hast Du einen PullUp an MISO?
Wie schnell ist dein Kontroller?
Die Init Routine hab ich selber nur abgeschaut,
die die ich selber geschrieben hatte ist raus geflogen,
obwohl die gut war...vielleicht mach ich das wieder rückgängig.


@ Michael R. (Gast)
Ja werde ich ändern.

Viele Grüße

Daniel

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel: Ich hab noch einen gravierenden Fehler in der Soft gefunden. 
Jetzt geht auch CMD58. Alle Karten initialisieren nun korrekt, soweit so 
gut.
Nur auf meiner MicroSDHC (8GB) kann ich zwar die Fat initialisieren und 
auch ffopen gibt ein Ok, aber ich bekomm keine Dateiinfos (filesize oder 
Daten). Dabei ging die Karte vorher ... ich find das aber noch raus 
(morgen) und werde die Routine dann posten.

Gruß
Fabian

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Alle Karten initialisieren nun korrekt...

Na das klingt doch schon mal gut.

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So.
 Ich habe habe jetzt die Init soweit dass alle meine Karte initialisiert 
werden. Getestet wurden:
 - Canon SD 16MB
 - Nokia MMC 32MB (2x)
 - extrememory MMC 256MB (mit FAT16 und FAT32)
 - Platinum SD 1GB (meldet sich als SDv2)
 - extrememory SD 2GB (meldet sich als SDv2)
 - SanDisk SDHC 4GB (Ultra II)
 - SanDisk MicroSDHC 8GB (2x)
 - Noname MicroSDHC 8GB

Hierfür musste ich zwei Änderungen an der mmc.c vornehmen.
Bei den Definitions ganz oben im File war das define für ACMD41 falsch.
Korrekt ist:
#define  ACMD41  (41)  // SEND_OP_COND (SDC)
vorher war dort (0x80+41) definiert.
Ich denke auch bei ACMD13 und ACMD23 müsste dieses (0x80) weg, aber da 
ich diese Kommandos nicht selbst brauchte und bisher keine Fehler 
diesbezüglich feststellte hab ich das erstmal so gelassen.

Die zweite Modifikation betrifft die Funktion mmc_init. Wie oben schon 
geschrieben hatte ich ein paar Karten die nicht sofort auf CMD0 
antworten, also habe ich hier eine Schleife drum gelegt. Auch bei 
anderen Kommandos war dies notwenig (CMD55->ACMD41, CMD58, CMD16).
Ich poste hier einfach mal die ganze Funktion:
unsigned char mmc_init (void){

  unsigned char cmd, ty, ocr[4];
  unsigned short n, j;

  spi_init();
  mmc_disable();

  for (n = 100; n; n--) spi_read_byte();    // 80+ dummy clocks

  ty = 0;
  j=100;
do {
  if (mmc_send_cmd(CMD0, 0) == 1) {      // Enter Idle state 
    j=0;
    TimingDelay = 100;            // Initialization timeout of 1000 msec

    if (mmc_send_cmd(CMD8, 0x1AA) == 1) {  // SDv2? 
      for (n = 0; n < 4; n++){
        ocr[n] = spi_read_byte();    // Get trailing return value of R7 resp 
        }
      if (ocr[2] == 0x01 && ocr[3] == 0xAA) {            // The card can work at vdd range of 2.7-3.6V 
        while (TimingDelay) {  // Wait for leaving idle state (ACMD41 with HCS bit)
          mmc_send_cmd(CMD55, 0);
          if(!mmc_send_cmd(ACMD41, 1UL << 30))
            break;
        }

        while(TimingDelay) {
        if (mmc_send_cmd(CMD58, 0) == 0x00) {    // Check CCS bit in the OCR 
          for (n = 0; n < 4; n++){
            ocr[n] = spi_read_byte();
            }
          ty = (ocr[0] & 0x40) ? CT_SD2 | CT_BLOCK : CT_SD2;  // SDv2 
          break;
        }
        }
      }
    } else {        // SDv1 or MMCv3 
      if (mmc_send_cmd(ACMD41, 0) <= 1)   {
        ty = CT_SD1; 
        cmd = ACMD41;  // SDv1 
      } else {
        ty = CT_MMC; 
        cmd = CMD1;    // MMCv3 
      }
      while (TimingDelay && mmc_send_cmd(cmd, 0));      // Wait for leaving idle state 
    }
    if(ty != (CT_SD2 | CT_BLOCK)) {
      while(TimingDelay && (mmc_send_cmd(CMD16, 512) != 0));
    }
    if(!TimingDelay) ty = 0;
  } else { j--; }
  }while(j>0);
  fat.card_type = ty;
  mmc_disable(); 

  if( fat.card_type == 0 ){
    return FALSE;
  }
  #if (MMC_MAX_SPEED==TRUE)
    spi_maxSpeed();
  #endif

  return TRUE;
}

Was mir noch auffiel:
Laut Spec muss ein ACMD immer auf ein CMD55 folgen. Im SDv1 or MMCv3 
block wird nur so direkt ein ACMD41 versucht. Ich vermute, dass hier 
eigentlich auch ein CMD55 vorher noch sein müsste, da ich aber mit keine 
Karte, die diesen Block durchläuft Probleme hatte lass ich es so.

Vielleicht kannst du, Daniel, diese Funktion so bei dir einpflegen und 
mal testen.

Nicht direkt als Bug zu bezeichnen: ich hatte noch eine 
Unregelmässigkeit.
Bei den SanDisk MicroSDHC 8GB konnte ich die Karte korrekt 
initialisieren, Fat initialisieren und auch Fileopen lieferte ein Ok, 
die Datei hatte laut file.length jedoch eine grösse von 0 und auch ein 
"blindes" ffread() lieferte nur Schrott. Da auf der Karte auch vorher 
schon Daten waren habe ich sie dann mal formatiert und die Datei wieder 
drauf kopiert und dann ging's einwandfrei.
Gibt es da vielleicht Zugriffprobleme auf Dateien ab einer bestimmten 
"Position auf der Karte", also weit hinten? Und wäre es vielleicht 
sinnvoll ffopen failen zu lassen wenn die Dateigrösse 0 ist?

Ich verwende:
At90Can128, 10MHz, HC4050 als Pegelwandler, 3V3 Regler für SD Karte, 
HW-Spi

Gruß
Fabian

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe ein Problem mit dem neuen Code:

Wenn ich das richtig verstehe, wartet die Funktion mmc_wait_ready 
lediglich solange, bis auf der Miso-Leitung H-Pegel anliegt:
static unsigned char mmc_wait_ready (void){

  TimingDelay = 50;

  do{
    if(   spi_read_byte() == 0xFF ) return TRUE;
  }while ( TimingDelay );

  return FALSE;
}

Zur Aktivierung der Karte wird also zunächst CS auf 0 gesetzt und dann 
getestet, ob Miso auf H-Pegel geht (oder bereits ist):
static unsigned char mmc_enable(){
      
   MMC_CS_LOW;
   if( !mmc_wait_ready() ){
       mmc_disable();
    return FALSE;
   }

   return TRUE;
}

Das funktioniert bei mir leider nicht. Meine Karte(n) liefert vor 
Absendung des CMD0 Kommandos immer L-Pegel. Aus diesem Grund kommt es 
bei mir nicht zur CMD0 Absendung. Habe die mmc_wait_ready erstmal 
auskommentiert, wäre für eine Erläuterung dankbar ...

Viele Grüße
recently

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

>getestet, ob Miso auf H-Pegel geht (oder bereits ist)

Miso sollte H sein, weil da ein PullUp dran sein sollte.
Ich muss das im Wiki unbedingt mal ändern.

Damit sollte das dann klappen.

Viele Grüße

Daniel

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

vielen Dank für die schnelle Antwort. Habe den Schaltplan von meinem 
Pollin Net-IO mit SD-Karten-ADD-On untersucht und finde dort keinen 
Pullup.

Bin ein wenig irritiert, die Hardware funktionierte ja mit der alten 
Software, auf dem Oszilloskop sieht das Miso-Signal auch normal aus, 
schön rechteckig und ungefähr zwischen 0 und 3V. Aber es ist 0V, wenn 
die Karte herausgezogen oder gerade hereingesteckt wurde.

Was für ein Widerstand sollte da eingelötet werden ?

- recently -

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der alten Version war das mit dem wait anders gelöst.
Es sollte ein 10K Widerstand gegen +3,3 Volt sein.
Damit die Karte am DO Pin auf jeden Fall vor cmd0 auf high ist.
Siehe auch:
Dritter Unterpunkt.
http://www.mikrocontroller.net/articles/MMC-_und_S...


Viele Grüße

Daniel

Autor: Fabian B. (fabs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann auch ein Effekt der der Karte sein, dass die die Leitung 
schwach auf low zieht wenn sie eingesteckt wird und direkt Saft bekommt 
(evtl. noch mit Prelleffekten auf der Versorgung). Da ich die Versorgung 
der Karte bei mir immer erst einschalte, wenn die Karte im Slot 
detektiert wurde, konnte ich dieses Verhalten bei inzwischen ca. 15 
getesteten Karten nicht feststellen.

@Daniel R: hast du den mmc_init mal testen können?

Gruß
Fabian

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider nein, hab diese Woche noch 2 Klausuren und es war Karneval :)
Komme ich aber bald dazu, danke das Du da soviel Mühe mit rein 
Investiert hast.

Viele Grüße

Daniel

Autor: recently (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

habe den 10k Widerstand eingebaut ... Unterschied wie Tag und Nacht. Die 
Initialisierung funktioniert jetzt sauber und reproduzierbar (ohne 
Pullup hatte ich mehrere CMD0-Wiederholungen, jetzt immer genau 1x). 
Sollte man Pollin mal mitteilen ... :-)

Vielen Dank für den Tipp !

Viele Grüße
recently

Autor: johnn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haloo,
Ich bin nur Anfänger und ich möchte nur einfacher Programm machen. 
Programm macht neue Datei – zum Beispiel „1.txt“ und schreibt jede 10 
Sekunden Temperatur (es ist in string format). Jede Temperatur an neue 
Zeile. Zuerst möchte ich nur library 0.6.2 testen.

Ich habe SD-Karte, ATMega 168 – es ist durch MISO, MOSI, SCK und CS 
verbinden.
Jetzt teste ich Version 0.6.2. Ich habe AVR Studio 4.18, ich öffne 
main_simple.c, dann gebe ich Project -> Configuration Options – ich 
schreibe Frequency 16MHz (ich habe 16 MHz Krystal). Und dann 
programmierte ich den Prozessor. Ich lasse den Programm etwa 10 sekunden 
laufen. Aber es macht nichts. Die Karte ist leer. Mache ich etwas 
schlecht ? Muss ich noch etwas machen ? Die Karte ist normal formatiert 
in Windows – FAT.
Können Sei mir bitte helfen ? Vielen Dank.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
läuft der ATMega 168 mit 3,3 Volt?
Läuft das Beispielprogramm ohne irgendwelche Änderungen?
Wie sieht die Schaltung aus?

Versuch immer in kleinen Schritten etwas auszuprobieren, bis es läuft 
und erweitere es dann erst.

Viele Grüße

Daniel

Autor: johnn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmega hatte 5Volt, jetzt läufte mit 3,3V aber es geht auch nicht.
Ich mache keine Änderungen - nur frequency.
Die Schaltung ist wie hier 
(http://www.mikrocontroller.net/articles/AVR_FAT32), aber keine HC4050 
(ich habe 3,3 Volt).

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
dann mach doch mal noch einen PullUp an MISO vom Kontroller. 
Beziehungsweise an DO der Karte.
Dann könntest Du noch mal versuchen in der mmc_config.h
#define MMC_MAX_SPEED     FALSE

zu setzen.

Und eventuell die mmc_init() zu benutzen die in folgendem Link 
angesprochen wird.

Beitrag "Re: MMC SD library FAT16 FAT32 read write"

Falls das alles nichts hilft, müsstest Du mal ein Foto vom Aufbau machen 
und hochladen, damit man sich eventuell ein bild von möglichen 
Fehlerquellen machen kann.

Du solltest auch mehrere Karten ausprobieren ob vielleicht nur eine 
bestimmte nicht funktioniert.

Viele Grüße

Daniel

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich habe ein Problem mit der AVR Fat32 Library

http://www.mikrocontroller.net/articles/AVR_FAT32

Zur Hardware:

Ich verwende einen Atmega16 mit 12MHz Quarz
Am Hardware SPI Hängt die SD Karte (micro SD)
Der Atmega wird mit 3,3V Betrieben.

Nun das Problem

Die Library funktioniert grundsätzlich sehr gut... Ich habe die Dateien 
1:1 übernommen uns es klappte auf anhieb.

Doch ich habe das problem, das wenn ich z.B. die Datei bild.bmp öffnen 
lassen will mit der Lib, dann verwende ich folgenden Code
while (FALSE==mmc_init()){  //Karte Initialisieren
      nop();
    }
  Out1_1;
  if(TRUE == fat_loadFatData()){
    unsigned char file_name[9]="bild.bmp";

    if(MMC_FILE_EXISTS == ffopen(file_name)){
      Out1_0;
      // Setzen einer Variable und dann runterzaehlen geht am schnellsten !
      seek=file.length;
      // Lesen eines chars und Ausgabe des chars.
              // Solange bis komplette Datei gelesen wurde.
              while(ucBufferCounter != 56) //Daten auslesen
              {
                 ucBuffer[ucBufferCounter] = ffread();
                 --seek;  //Byte Zähler
                 ucBufferCounter++;
              } //56Bytes Buffer auslesen
    }

  }

nicht von den 56Bytes irritieren lassen... das spielt derzeit keine 
rolle!


Doch wenn ich diesen Code ausführen lasse, dann meldet der Code das Die 
Datei existiert jedoch erstellt er selbige auf der Karte.

Wenn ich Die karte also in den PC einschiebe, befindet sich zweimal die 
Datei bild.bmp im Root verzeichniss... Windows motzt nun also und ich 
muss die Karte formatieren...

Wass jedoch prblemlos geht, ist eine von der Lib erstellte Datei lesen 
oder zu erweitern... Auch mit dem Computer... Aber es kann ja nicht 
sein, das ich immer mit dem AVR eine Datei erstellen muss und diese Dann 
am Computer bearbeiten muss. Dies geht sowiso nur bei txt dateien.

Getestet habe ich den Code mit mehreren Karten. An dennen liegt es also 
nicht! An der Lib config habe ich nichts verändert!

Was auch merkwürdig ist, das bei dem Beispielcode von hier
http://www.mikrocontroller.net/articles/AVR_FAT32#Der_Code
steht beim Filename "man beachte die Grossbuchstaben" aber es hat im 
beispiel nur kleinbuchstaben.

Hat jemand eine idee wo hier der wurm drinn sein könnte?

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich komme grad nicht dazu ne neue Version zusammen zu packen in der auch 
die neue Initialisierungsfunktion ist und auch die neue 
fat_loadFiledataFromCluster.

//***************************************************************************************************************
// prueft auf lange dateinamen (lfn), ermittelt anhand des langen dateinamens den kurzen. nur der kurze
// enthaelt die noetigen informationen um die datei lesen zu koennen. ist der gesuchte dateiname gefunden
// aber im naechsten sektor/cluster ermittelt die funktion selbstaendig diese und holt die informationen !
//***************************************************************************************************************
static unsigned char fat_loadFileDataFromCluster(unsigned long int sec , unsigned char name []){

    unsigned short row;    // um durch zeilen zu gehen, eigentlich erstes byte einer reihe...
    unsigned char sectors;  // um durch sektoren zu zaehlen, sectors+sec = tatsaechliche sektornummer (absoluter sektor)
    unsigned char i;      // um durch eine zeile/reihe zu laufen
    unsigned char j;      // laufvariable fuer sfn

    // diese variablen muessen statisch sein, weil ein lfn eintrag auf 2 cluter aufgeteilt sein kann !
    static unsigned char checksum = 0;  // die kurze dateinamen checksumme, die ausgelesene.
    static enum flags { wait=0,start,readout } lfn_state;
    static unsigned char match = 0;    // treffer bei datei namen vergleich zaehlen

    const unsigned char map[13]={1,3,5,7,9,14,16,18,20,22,24,28,30};    // index von map ist index des zu pruefenden bytes und inhalt ist index des zu pruefenden bytes in der reihe
    const unsigned char name_length = strlen((char *)name)-1;      // es wird die laenge des dateinamen zum vergleichen benoetigt!

    sectors = 0;

    // 5 moegliche zustaende im inneren der beiden schleifen...
    do{                      // sektoren des clusters pruefen
    row=0;                    // neuer sektor, dann reihen von 0 an.
    mmc_read_sector(sec+sectors,fat.sector);  // laed den sektor sec auf den puffer fat.sector
    fat.lastSector = file.currentSectorNr;    // sichern der alten sektor nummer
    file.currentSectorNr = sec + sectors;    // setzen des aktuellen sektors
    do{                      // reihen des sektors pruefen
      // 1.) nach einem eintrag mit 0x00 kommt nix mehr => restlicher cluster leer!
      if( fat.sector[row]==0x00 ){
        return FALSE;
      }
      // 2.1) ist eintrag ein lfn eintrag?   siehe: http://en.wikipedia.org/wiki/File_Allocation_Table#Long_file_names
      if( (fat.sector[row]&0x40) == 0x40 && fat.sector[row+11] == 0x0F && fat.sector[row] != 0xE5 ){                                      // ist lfn eintrag, jetzt pruefen...
        lfn_state = start;
      }
      // 2.2) ist eintrag ein sfn eintrag? 
      if( (fat.sector[row+11] == 0x10 || fat.sector[row+11] == 0x20) && fat.sector[row] != 0xE5 && lfn_state != readout){
        // vergleich von sfn dateinamen
        i = 0; j = 0;
        do{          
          if( fat.sector[row+i] == 0x20 ){     // ueberspringen von leerzeichen auf der karte
            i++; continue;
          }
          if( name[j] == '.' ){           // ueberspringen von punkt im dateinamen
            if( i <= 7) break;
            j++; continue;
          }
          if( fat.sector[row+i] != toupper(name[j]) )  break;
          i++; j++;
        }while(i<11);
        // datei gefunden
        if( i == 11 && j != 11){
          lfn_state = readout;                                      // ist lfn eintrag, jetzt pruefen...
          checksum = fat_lfn_checksum( &fat.sector[row] );
        }
      } 
      // 3.) lfn gefunden, jetzt verarbeiten. raussuchen der richtigen bytes und direkter vergleich mit dem original.
      if( lfn_state == start || match !=0 ){
        i=12;
        do{
          if( fat.sector[row+map[i]]!=0x00 && fat.sector[row+map[i]]!=0xFF ){  // gueltiger buchstabe. ist gueltig wenn, es nicht 0 oder ff ist.
            if( fat.sector[row+map[i]] == name[name_length-match] ){    // vergleich mit original, ist treffer?
              match += 1;                          // bei treffer index zaehler fuer vergleich hochzaehlen
            }
            else {            // wenn ein gueltiger buchstabe keinen treffer verursacht, ist es die falsche datei !
              lfn_state = wait;     // zurueck zu ausgangszustand
              match = 0;        // treffer zurueck setzen
              break;          // weitere pruefung nicht noetig da eintraege ungleich!
            }
          }
        }while(i--);            // zeichen index einer zeile/reihe abarbeiten
        // komplette uebereinstimmung und sequenz id 1 ==> datei gefunden !!
        if( (name_length-match) == -1 && (fat.sector[row]&0x01) == 0x01){
          lfn_state = readout;      // langer dateiname stimmt ueberein, jetzt zustand wechseln.
          match = 0;            // vergleich index zurueck setzen, damit nicht wieder in diesen zustand gewechselt wird.
          checksum = fat.sector[row+13];  // checksumme sichern zum vergleich mit der errechneten anhand des kurzen dateinamens. in naechstem zustand vergleich.
        }
      }
      // 4.) gesuchte reihe auf stuct file laden zum weiter verarbeiten. das ist der sfn eintrag, mit dem firstCluster, der laenge usw...
      if( lfn_state == readout && fat.sector[row+11] != 0x0F ){
        lfn_state = wait;
        fat_loadRowOfSector(row);
        file.row = row>>5;                  // reihe sichern, ist fuer ffrm wichtig
        if(checksum==fat_lfn_checksum(&fat.sector[row])){  // pruefen ob checksumme stimmt...wenn ja alles klar :)
          file.entrySector = file.currentSectorNr;    // sichern des sektors in dem der sfn dateieintrag steht.
          return TRUE;
        }
      }

      }while( (row+=32) < 512 );      // mit row+32 springt man immer an die 1. stelle einer reihe (zeile) und das durch einen ganzen sektor
    }while( ++sectors < fat.secPerClust );  // geht durch sektoren des clusters

    return FALSE;              // datei nicht gefunden, zumindest in diesem cluster...
}

Diese Funktion solltes Du mal test weise in der fat.c austauschen.

>man beachte die Grossbuchstaben

Die Kommentare in den Sourcen sind nicht immer aktuell ^^

Sag mir mal ob in der mmc_config.h
MMC_LFN_SUPPORT TRUE
ist.


Viele Grüße

Daniel

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> Die Kommentare in den Sourcen sind nicht immer aktuell ^^

Kein Problem :)

Vielen Dank für die Antwort

Ich habe LFN Support auf True
und auch MMC File Exists auf True

Ich verwende übrigens die neuste Version aus dem SVN

habe besagten Code ersetzt jedoch kommen nun folgende Meldungen

../fat.c:195: error: 'struct Fat' has no member named 'lastSector'
../fat.c:195: error: 'struct File' has no member named 'currentSectorNr'
../fat.c:196: error: 'struct File' has no member named 'currentSectorNr'
../fat.c:255: error: 'struct File' has no member named 'currentSectorNr'

Anscheinend ist das Struct geändert worden von dir :)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ja stimmt.
Die Version aus dem SVN ist nicht die neuste.

Nimm diese:

http://www.mikrocontroller.net/attachment/101158/0.6.2.zip

Muss das mal ins SVN hochladen...

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja und in der 0.6.2 musst Du noch die besagte Funktion tauschen...

Muss das die Tage mal alles sortieren^^

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen dank für den Hinweis und die neue Lib

Was meint der Compiler mit undefined reference timing delay?

Muss ich diese Funktion bereitstellen?

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es muss eine
volatile unsigned char   TimingDelay;  // fuer mmc.c

Variable im Programm geben die in 10 ms Intervallen runtergezählt wird 
bis 0. Wenn Du Dich an der main_simple.c orientierst sollte das kein 
Problem werden.

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat geklappt Danke!

Deine Lib ist echt Genial!!!

Hoffentlich lädstd du bald die neue Version hoch :)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön das es geklappt hat :)

Viele Grüße

Daniel

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit deiner Neusten Version ein sehr merkwürdiges aber 
reproduzierbares verhalten entdeckt.

Ich möchte auf der Speicherkarte überprüfen ob die Datei logfile.txt 
existiert...

Das mache ich wie folgt:
unsigned char file_name_2[]="logfile.txt";

  if(ffileExsists(file_name_2))
  {
    text_neu("OK",90,90,1,0,0,255);
  }
  else
  {
    text_neu("ERROR",90,90,1,255,0,0);
  }

Problem -> Die funktion liefert immer Error zurück obwohl die Datei auf 
der Speicherkarte liegt (habe auch grossklein schreibung geachtet!) LFN 
ist aktiviert.

Prüfe ich hingegen ob die Datei test.bmp existiert, klappt der test 
einwandfrei. Beide Dateien beinhalten etwas. sind also nicht 0Byte 
gross!

Nun das ganz spezielle...

Möchte ich nun also die Datei Lesen (logfile.txt) wass ja eigentlich 
nicht gehen sollte, so wird diese angelegt und es befinden sich wieder 
zweimal die selben dateien auf der Karte. Wichtig hier zu beachten ist, 
das die Lib die neue Datei mit Grossbuchstaben erstellt egal ob ich der 
Funktion kleibuchstaben übergeben habe.

Könnte dies ein hinweis darauf sein, das in dieser funktion nicht auf 
LFN geachtet wird?

Vielleicht sagt dir meine Fehlerbeschreibung ja etwas...

Ansonsten keine Probleme :)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ja klingt irgendwie danach:

Beitrag "Re: MMC SD library FAT16 FAT32 read write"

Ersetze die Funktion in der fat.c durch die Funktion aus dem Post.
Benutzt Du die Version 0.6.2 ? Da sollte wenn Du die Datei zum lesen 
öffnest auf jeden Fall keine zweite Datei mit dem selben Namen angelegt 
werden.

Viele Grüße

Daniel

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel

Ja ich habe die Funktion ersetzt... Ja ich verwende die Version 0.6.2

Ich habe das Problem gefunden...

Es scheint so, als ob die Funktion File Exists nur mit kurzen Dateinamen 
klar kommt...

Dies stört mich nicht weiter, da ich ja darauf achten kann...

Aber wollte dir halt dennoch den hinweis geben :)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du mal in ffileExsists reinschaust, dann siehst du da, dass genau 
das gleiche gemacht wird, zum prüfen ob es die Datei gibt, wie beim 
öffnen.

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann ist es allerdings etwas merkwürdig das LFN nicht unterstützt wird 
obwohl ich den Schalter auf True habe. Das selbe ist es mit SDHC karten

Ich habe den schalter auf True

Aber 8GB Karten werden nicht initialisiert.... (FAT)

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du die hier gepostete mmc_init Version benutzt?
Beitrag "Re: MMC SD library FAT16 FAT32 read write"

Hast Du die hier gepostete fat_loadFileDataFromCluster Version benutzt?
Beitrag "Re: MMC SD library FAT16 FAT32 read write"

Damit geht das auf jeden Fall.

Viele Grüße

Daniel

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach was mir noch einfällt zu

>Ja ich verwende die Version 0.6.2

Das kann nicht sein. In der 0.6.2 ist der Schalter für SDHC raus 
geflogen.

Autor: Claudio H. (hedie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel R. schrieb:
> Das kann nicht sein. In der 0.6.2 ist der Schalter für SDHC raus
> geflogen.

Ohhh.... schande... Tut mir leid... ja du hast recht... ich habe auch 
keinen.

Daniel R. schrieb:
> Hast Du die hier gepostete mmc_init Version benutzt?
> Beitrag "Re: MMC SD library FAT16 FAT32 read write"
>
> Hast Du die hier gepostete fat_loadFileDataFromCluster Version benutzt?
> Beitrag "Re: MMC SD library FAT16 FAT32 read write"
>
> Damit geht das auf jeden Fall.
>
> Viele Grüße

Ich habe diese Version von der du mir den link gesendet hast.

Autor: Daniel R. (zerrome)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, Du brauchst die Version 0.6.2 hier aus dem Thread und dann musst Du 
die beiden Funktionen austauschen. Die Beiden Funktionen aus den Links 
die ich gepostet hab. Dann wird es klappen. Bin wie gesagt noch nicht 
dazu gekommen die einzubauen und das ins SVN hochzuladen.

Viele Grüße

Daniel

Autor: Claudio H. (hedie)