AVR FAT32 microSD lesen beschleunigen

[Matthias L. (mcl024)]

Hallo zusammen,

ich nutze die FAT32 Lib von diesem Artikel AVR FAT32 . Unter dem 
Punkt lesen steht das bei einer unfragmentierten FAT alles Cluster 
aneinander liegen und somit der lese Zugriff extrem beschleunigt werden 
kann.

Mein Frage ist nun wie erstelle ich eine unfragmentierte FAT. Ist das 
nicht ein Widerspruch FAT -> unfragmentiert ??

[micha (Gast)]

Medium frisch formatieren und große Datei anlegen dann sind alle 
Sektoren schön sequentiell. Dann geht das lesen quasi "automatisch" da 
die Sektoren-Nr (IMHO bei SD-Cards) automatisch weitergesetzt wird. 
Fragmentiert sind eventuell Sektoren 1-10-2-100-99-20 etc auszuwählen, 
d.h. man muss jeden Sektor anwählen, anspringen etc.

[Matthias L. (mcl024)]

Meine Datei ist aber nur 45KByte klein. Werden dann auch alle sektoren 
nacheinander angelegt?

[Matthias L. (mcl024)]

Also wenn ich die microSD Karte formatiere und anschließend nur meine 
ca. 45KByte kleine Datei auf die Karte kopiere, hängen leider nicht alle 
Sektoren in einer Reihe.

Was kann ich tun?

[holger (Gast)]

>Also wenn ich die microSD Karte formatiere und anschließend nur meine
>ca. 45KByte kleine Datei auf die Karte kopiere, hängen leider nicht alle
>Sektoren in einer Reihe.

Doch, tun sie. Wie hast du das festgestellt?

[Matthias L. (mcl024)]

Also es gibt folgende funktion in der FAT-Lib:

//-----------------------------------------------------------------------------
// fat_getFatChainClustersInRow
//-----------------------------------------------------------------------------
//
// Return Value : None
// Parameters   : unsigned long int offsetCluster
//
//
// sucht verkettete cluster einer datei, die in einer reihe liegen. worst case: nur ein cluster.
// sieht in der fat ab dem cluster offsetCluster nach. sucht die anzahl von MAX_CLUSTERS_IN_ROW,
// am stueck,falls möglich. prueft ob der cluster neben offsetCluster dazu gehört...
// setzt dann fat.endSectors und fat.startSectors. das -1 weil z.b. [95,98] = {95,96,97,98} = 4 sektoren
//-----------------------------------------------------------------------------
void fat_getFatChainClustersInRow( unsigned long int offsetCluster)
{
  unsigned short cnt = 0;

  fat.startSectors = fat_clustToSec(offsetCluster);    // setzen des 1. sektors der datei
  fat.cntSecs = fat.secPerClust;

  while( cnt<MMC_MAX_CLUSTERS_IN_ROW ){
    if( (offsetCluster+cnt+1)==fat_getNextCluster(offsetCluster+cnt) )    // zählen der zusammenhängenden sektoren
      fat.cntSecs += fat.secPerClust;
    else {
      PORTA ^= (1<<PA7);         // Trigger PA7 toggle
      file.lastCluster = offsetCluster+cnt;      // hier landet man, wenn es nicht MAX_CLUSTERS_IN_ROW am stueck gibt, also vorher ein nicht passender cluster gefunden wurde.
      return;
    }
    cnt+=1;
  }

  file.lastCluster = offsetCluster+cnt;          // hier landet man, wenn MAX_CLUSTERS_IN_ROW gefunden wurden
}

Da habe ich in den else zweig einen Trigger gesetzt und mit dem Oszi 
gemessen.

MAX_CLUSTERS_IN_ROW steht auf 256

[holger (Gast)]

>Da habe ich in den else zweig einen Trigger gesetzt und mit dem Oszi
>gemessen.

Ja, klar mit dem Osci gemessen;)
Lass dir besser mal die Sektornummern beim lesen
ausgeben. Das ist viel aussagekräftiger.

[Matthias L. (mcl024)]

Entweder er springt in den Else-Zweig oder nicht und wenn ich dann mein 
I/O-Pin toggle dann sagt das doch alles!?

[holger (Gast)]

>Entweder er springt in den Else-Zweig oder nicht und wenn ich dann mein
>I/O-Pin toggle dann sagt das doch alles!?

Und wenn deine Datei keine 256 Cluster belegt landet er auch dort.

[ich (Gast)]

Oh sorry da habe ich wohl etwas Mißverstanden. Mhh das bedeutet also das 
mein Datei bereits in einem Stück auf der Karte liegt. Mißt ich dachte 
ich könnte damit das lesen beschleunigen.

[holger (Gast)]

>Mißt ich dachte
>ich könnte damit das lesen beschleunigen.

Wie schnell ist es denn jetzt?
Wie schnell soll es werden?
Und wie liest du die Datei?

Ich denke mal beim letzten Punkt könnte dein Problem liegen.

[Markus (Gast)]

Es könnte sein, dass auf der untersten Ebene, da wo die Bytes gelesen 
und geschrieben werden, noch etwas zu holen ist. Schau dir den 
Assemblercode  (oder poste ihn hier) der Schleife an, in der das SPDR 
gelesen bzw. beschrieben wird.

[Matthias L. (mcl024)]

Hallo,

erstaml danke für eure Antworten.

Ich benötige ca. 5ms pro 1KByte. Geht das schneller? Ich hoffe!!

Hier die sd_read_byte funktion in C und Assembler

unsigned char sd_read_byte(void)
{
  SPDR = 0xff;
  while( ! (SPSR & (1<<SPIF)));  // warten bis SPIF=1 (Uebrtragung beendet)
  return (SPDR);
}

00004488 <sd_read_byte>:
    4488:  8f ef         ldi  r24, 0xFF  ; 255
    448a:  8f b9         out  0x0f, r24  ; 15
    448c:  77 9b         sbis  0x0e, 7  ; 14
    448e:  fe cf         rjmp  .-4        ; 0x448c <sd_read_byte+0x4>
    4490:  8f b1         in  r24, 0x0f  ; 15
    4492:  08 95         ret

Ich nutze den Code aus dem Artikel FAT FAT32

[holger (Gast)]

>Ich benötige ca. 5ms pro 1KByte. Geht das schneller? Ich hoffe!!
>Hier die sd_read_byte funktion in C und Assembler

Versuchs mit inline.

inline unsigned char sd_read_byte(void)
{
  SPDR = 0xff;
  while( ! (SPSR & (1<<SPIF)));  // warten bis SPIF=1 (Uebrtragung 
beendet)
  return (SPDR);
}

Viel mehr ist da nicht zu holen.
Evtl. noch die Eigenschaften des SPI Moduls
ausnutzen und während der Übertragung schon
andere Sachen machen wie Werte abspeichern.
Mehr als 10% holst du da aber nicht mehr raus.

[Matthias L. (mcl024)]

Hallo Zusammen,

ich bin immer noch nicht weiter gekommen mit meinem Problem.

Habe jetzt heraus gefunden das, dass lesen einer Datei mit 46464 Byte 
belegt 96 Sectoren (a 512 Byte) gerade mal 2,5ms dauert. Warum genau 96 
Sectoren weiss ich nicht genau spielt auch keine entscheidene Rolle.

Das was ich nicht verstehe ist warum nur 2,5ms?

Meine SPI läuft mit 8Mhz => 0,125µs für 1Byte benötige ich also 
8x0,125µs=1µs daraus folgt das ich für 46464 Byte mindestens ca. 46ms 
benötige, brauche aber nur 2,5ms. Wo ist mein Denkfehler?

Die 2,5ms habe durch messen am Oszi ermittelt an folgenden Stellen im 
Code

         PORTA |= (1<<PA7);         // Trigger PA7 High
        // lesen eines chars und Ausgabe des chars.
        // solange bis komplette Datei gelesen wurde.
        do{
          // start data transmission
          byte = ffread();
          seek--;

        }while(seek);

        PORTA &= ~(1<<PA7);         // Trigger PA7 Low

ffread() liefert mir 8Byte der Datei.

Ja die Datei ist tatsächlich 46464 Byte groß, denn wenn ich mir den Wert 
von seek anschaue ist dieser auch 46464.

Danke für eure Unterstützung

[holger (Gast)]

>Meine SPI läuft mit 8Mhz => 0,125µs für 1Byte benötige ich also
>8x0,125µs=1µs daraus folgt das ich für 46464 Byte mindestens ca. 46ms
>benötige, brauche aber nur 2,5ms. Wo ist mein Denkfehler?

Du hast keinen Denkfehler. Deine Software bricht beim Lesen
vermutlich frühzeitig ab und liest die Sektoren gar nicht.

[Matthias L. (mcl024)]

Die Daten werden vollständig gelesen. Ich nutze sie um ein Bild auf 
einem Display anzuzeigen und dieses wird vollständig dargestellt.

[holger (Gast)]

>Die Daten werden vollständig gelesen. Ich nutze sie um ein Bild auf
>einem Display anzuzeigen und dieses wird vollständig dargestellt.

Dann hast du falsch gemessen.